Greater AD Integration via NFS and Automounts

Tuesday, November 21, 2006 in Interoperability | 35 comments

This solution builds upon the integration of Solaris 10 and Linux (again, CentOS specifically, but I’ll use Linux here instead of mentioning the specific distribution) into Active Directory for authentication and authorization as outlined in these related articles:

Refined Solaris 10-AD Integration Instructions
Linux, Active Directory, and Windows Server 2003 R2 Revisited

In these articles, we describe a configuration whereby we can use Kerberos against Active Directory for authentication, and LDAP against Active Directory for user and group lookups.  This allows us to centralize the user account information (username, UID number, home directory, login shell, etc.) into Active Directory so that when an account is provisioned in AD it is also available to associated UNIX and Linux systems (as applicable).  Using the information in this article, we can extend that integration to auto-mounted shared home directories between Solaris and Linux.

We’ll accomplish this by using the UNIX interoperability tools included in Windows Server 2003 R2; namely, the Server for NFS, Server for NIS, and the User Name Mapping Server.  On the Solaris and Linux side, we’ll use autofs.

OK, let’s dive right in.

Configuring Solaris

Configuring Solaris is pretty straightforward; it’s pretty much designed out of the box to use auto-mounted home directories.  This is one area where Solaris shows its enterprise pedigree (that’s not a knock against Linux, just an observation about Solaris).

The only real change that needs to be made is to the /etc/auto_home file, which specifies the auto-mounted home directory mappings.  The easiest thing to do is use a wildcard mapping, like this:

*   nfssrvr.example.com:/home/&

Here, the asterisk (*) and the ampersand (&) will be replaced with the appropriate information.  So, if a user name “bjones” logs on, then the the /home/bjones NFS share on the server nfssrvr.example.com would be mounted on /home/bjones on the Solaris server.  Useful, eh?

Note that autofs may be disabled in your installation of Solaris; it wasn’t in mine, but I’ve seen references elsewhere that this is not typical.  Use these commands to check the status and enable autofs, if necessary:

svcs -a | grep autofs
svcadm -v enable svc:/system/filesystem/autofs

At this point, Solaris should be ready to go.  Let’s look at the Linux configuration.

Configuring Linux

The Linux configuration is only slightly more complicated than the Solaris configuration.  Whereas Solaris uses /etc/auto_master to define the automounted filesystems, autofs on Linux uses /etc/auto.master, and it does not (by default, as far as I can tell) define a map for automounted home directories.

So we must first edit /etc/auto.master and add the following line:

/home   /etc/auto.home

This tells autofs to look in the file /etc/auto.home to find the automounted directories under /home.  Then we create the /etc/auto.home file with the following line:

*   nfssrvr.example.com:/home/&

(Just like the Solaris box in this case.)  Finally, we can check for the autofs startup status, fix it, and start autofs with the following commands, respectively:

chkconfig --list autofs
chkconfig autofs on
service autofs start

In fact, you will need to restart the autofs daemon (with “service autofs restart”) in order for the changes to /etc/auto.master and /etc/auto.home to be recognized.  (The same goes for Solaris, too, only using the “svcadm -v restart svc:/system/filesystem/autofs” command instead.)

To further streamline any differences between Solaris and Linux, I also created a /export/home on the Linux server, in the event I wanted/needed local home directories as well.  Please note that I would need to modify the /etc/auto.home (on Linux) or /etc/auto_home (on Solaris) as well if this were the case.

Now that Linux and Solaris are both done, let’s have a look at configuring the UNIX interoperability components on Windows.

Configuring Windows (NFS, NIS, and User Name Mapping)

Surprisingly enough, this part was the hardest part for me.  I don’t know if it was the documentation (if it can be called that) or something else, but I had a hard time with this.  Hopefully the information I share here can help someone else avoid this headache.

Configuring the Domain Controllers

On the domain controllers in your Active Directory domain, install the following components:

  • Server for NIS and Administration Components (under Active Directory Services > Identity Management for UNIX)
  • Microsoft Services for NFS Administration, RPC External Data Representation, RPC Port Mapper, Server for NFS Authentication, and User Name Mapping (under Other Network File and Print Services > Microsoft Services for NFS)

It may be possible to get by with less than that installed, but I couldn’t get it working until all of those are installed.  If you’ve followed my instructions for AD integration, the Server for NIS and Administration Components are probably already installed, as those expose the “UNIX Attributes” tab in Active Directory Users & Computers.

Once these are installed, use these steps to configure them appropriately:

  1. Using the Services MMC, make sure that Server for NIS is running.
  2. In the Microsoft Services for NFS MMC, right-click on “Microsoft Services for NFS” and select Properties.  Specify the name of the DC as the “User Name Mapping Server”, check the box labeled “Active Directory Lookup”, and specify the name of the Active Directory domain.  Click OK to save those changes and close the dialog box.
  3. Still in Microsoft Services for NFS MMC console, right-click User Name Mapping and select Properties.  Go to the “Simple Mapping” tab, check the box marked “Use simple maps”, and then add one of the DCs from the domain that’s running Server for NIS at the bottom of the dialog box.
  4. Right-click on both User Maps and Group Maps and select “Show simple maps,” then click Refresh.  You should see a list of the users in Active Directory that have been UNIX-enabled, i.e., have UNIX attributes specified for their account.  At this point, you can close the Microsoft Services for NFS MMC.

The DC should now be ready to go.  It’s time to move to the file server.

Configuring the File Server

We need to install the Server for NFS component on the file server that will host our automounted home directories.  The Server for NFS is found under “Other Network File and Print Services” in Add Windows Components.

Once that has been installed, repeat step #2 above (configuring the User Name Mapping Server and Active Directory lookup) on the file server.

We’re now ready to create some NFS shares.  Right-click the folder you’d like to share via NFS (I created a folder named “home”—I know, not very creative) and shared that via NFS (there’s an NFS Sharing tab when you open the properties for the folder).  When specifying the share name, be wary of the case since UNIX/Linux are cAsE sEnSiTiVe.  (It’s probably best to stick to all lowercase.)  If you want to allow anonymous access and/or root access, configure it appropriately at this point.

Word of warning:  be sure to include UNIX-enabled groups and/or users in the NTFS access control list for the folder and containing files!  This one threw me for a loop.  At first, I didn’t have any UNIX-enabled groups in the ACL and I kept getting “insufficient permissions” errors when trying to mount the share via NFS.  It wasn’t until I ensured that at least one UNIX-enabled group had read permission to the folder that things started working as expected.

To test your NFS share, use this command from Solaris or Linux, respectively:

mount -F nfs nfssrvr.example.com:/home/nfs /mnt/nfs (for Solaris)
mount -t nfs nfssrvr.example.com:/home/nfs /mnt/nfs (for Linux)

If this mounts the NFS share without any problems, then you should be ready to roll.

(Note:  In case you hadn’t already picked this up, one advantage of using a Windows NFS server is that we can also share the same folder via CIFS/SMB and create unified home directories for Solaris, Linux, and Windows.)

Now, upon logging in to either Solaris or Linux (I tested this via SSH), you should get dropped into “/home/username” (assuming that’s where you configured the automounter to mount the NFS share) automatically.

How I Tested

I tested this procedure using Solaris 10 6/06 and CentOS 4.3.  These systems were configured for Active Directory integration and native Kerberos logons via SSH.  I used Windows Server 2003 R2 Standard Edition for the NFS server, and Windows Server 2003 R2 Standard Edition for the Active Directory domain controllers.  All of these systems were created as virtual machines hosted on a VMware Virtual Infrastructure 3 server farm with servers running ESX Server 3.0.1.

Tags: , , , , , , , , ,

35 comments

Comments feed for this article

Friday, December 8, 2006 at 5:06 am

David G

Scott,

You dont need to install User Name Mapping or Server for NIS if all your users come from AD.

At step 2 in your ‘Configuring Domain Controllers’ section just check the box labeled “Active Directory Lookup” and specify the name of the Active Directory domain.

Dont bother changing “User Name Mapping Server”

The only time you need the User Name Mapping component is when you have users from a ‘foreign’ NIS domain NFS mounting shares off your Windows boxes. Technically, when you do need it, you also only need one mapping server but you normally install them on your DCs anyway.

I can see you’ve discovered how ‘touchy’ Server for NFS is about permissions/ownership of NFS shared directories. And the mystery of the 4294967294 uids and gids… Somewhere in the mire of papers on my desk in the office, I have some MS docs on the Server for NFS bits (Ok - from MS-SFU days but still relevant) which I can send you the URLs for when I get in. In particular, I’m thinking about one doc which has info about registry settings that you can pull to affect how Server for NFS interprets/sets NTFS permissions.

Friday, December 8, 2006 at 4:22 pm

slowe

David G,

I didn’t seem like I would, but try as I may I could NOT make it work without enabling Server for NIS and all the rest. It didn’t seem intuitive that those components needed to be installed and running, but that was the only way it seemed to work.

I plan on going back and performing some additional testing to see if I can make it work without the Server for NIS and/or User Name Mapping services.

Thanks,
Scott

Friday, January 5, 2007 at 12:07 am

Dand K.

David,

What is the mystery of the 4294967294 uids and gids…?

I am facing same problem, when users home directorys are mounted on linux and group id is showing 4294967294. Where is it coming from and how do you change this with proper group id?

Thanks
Dand

Thursday, January 18, 2007 at 3:03 am

alaxa

DandK,
those 4294967294 come out because there is no map between the user/group on linux and the one on the AD server. You have to set a map for each user is going to write on the NFS share. You can this via the ‘Unix Attribute’ on the User Account Property tab or via “simple map”
I’m testing other settings so I’d like to share my (un)knowledge with others, my email:
pink0.pallino (a-t) libero.it

Tuesday, January 30, 2007 at 9:47 am

Nikolay

Hello Scott,
I have seen in your once post mentioning about NetApp. As known DataONTAP has an opportunity to give access to resources on NFS.
As you think, whether probably in to use NetApp as NFS server?

Tuesday, January 30, 2007 at 10:23 am

slowe

Nikolay,

You are absolutely right, we can use a NetApp storage system running Data ONTAP as our NFS server. I’ve been working on the details for this, but haven’t yet completed the research and testing. Stay tuned–that’s definitely something I want to do and I will publish more information here as soon as I have it ready.

Scott

Monday, February 5, 2007 at 4:49 am

Paul

Hello
I mounted home folder created with this instruction on the system not configured to AD integration, I created local user with name and UID idenctical whith AD, only password is different. On this system I have access to files on server for nfs Winows 2003. How to configure server for nfs to authenticate with kerberos ?

Tuesday, February 6, 2007 at 9:43 pm

Maria C.

hi Scott,
thanks for the article, this is very informative. Is it possible to mount user home directories using Samba/AD/LDAP where the home directories reside on a Solaris 10 nfs server (in this example you have a Windows NFS server)? We have a mix of Linux, Solaris, and Windows clients. The Windows clients need to be able to access their unix home directories from the Samba server.

Maria

Tuesday, February 6, 2007 at 10:04 pm

slowe

Maria,

I don’t see any reason why it wouldn’t work. However, for seamless access to Windows home directories via Samba, you’ll want AD integration and the use of Kerberos tickets; I have yet to find a precompiled Samba binary for Solaris 10 x86 that includes AD/Kerberos support.

Otherwise, assuming NFS is working correctly, I don’t see any concerns with using Solaris 10 as the home directory server instead of Windows.

Post back here if you try it and let us know how the tests proceed.

Thanks,
Scott

Saturday, February 10, 2007 at 6:53 pm

alaxa

Anyone has found any way to use the UPG (private groups) also on Active Directory?
I think I need only this step to have a (hopeful) full working NFS share on the windows 2003 server.
I guess the difficult is that on AD there cannot be two object with the same name (user/group), but with openLDAP it works..
thanks

Saturday, March 10, 2007 at 6:25 pm

alaxa

I set NFS and AD integration thrugh LDAP (no NIS).
My doubts are now about permissions: I use the NFS share as home directories for linux clients. Well, I’d like to keep the same permissions capability we have on linux, I mean, on the /home I want any user can list the homes, but can access his and other only if properly shared.
I want this thing also accessible via NTFS.
how should the permission be set under NTFS?
one more question is about chmod: when I chmod a directory it gets the NTFS permissions even if I do not set them. Is this correct?

Saturday, March 10, 2007 at 7:12 pm

slowe

Alaxa,

Are you hosting the NFS shares on a Windows host? If not, NTFS never comes into the picture, since NTFS is only truly supported on a Windows host. I’m afraid I’m a bit confused by what you are trying to accomplish. If you want to set NTFS permissions so that all users can list the folders under /home but not access any of them, then use the following permissions:

Administrators - Full Control (this folder and all subfolders)
Users - Read and Execute (this folder only)
SYSTEM - Full Control (this folder and all subfolders)

On each subfolder, add the specific user for that folder with Full Control (this folder and all subfolders). Then each user will be able see all home directories, but only access his or her own.

Or am I missing your question?

Friday, March 30, 2007 at 10:42 am

Doug

Question regarding root mapping. Do you have the linux root account mapped to any AD user? I have linux-ads auth via kerberos working (per you previous Linux-AD Integration With Windows Server 2003 R2 instructions–thank BTW), but when I attempt to serve up a NFS share from the ADS, the mount would show a owner of ‘nfsnobody’ or ‘4294967294′

Friday, March 30, 2007 at 10:01 pm

slowe

Doug,

I typically don’t map the root account. If the files and directories on the NFS shared are owned by root, then you will see the ‘nfsnobody’ mapping because there is no matching AD account. You should be able to fix that by either a) mapping the root user; or b) chowning the data to an account that is matched in AD already.

Saturday, March 31, 2007 at 10:13 pm

Doug

Thanks for the reply Scott

I don’t want to map root either. WRT to (b), there is not data in the NFS share. I created a new NFS share on the AD server and gave a linux mapped group full control (the share is nothing more than a directory that I want to test xwr with from a linux client). I can mount the nfs share as root (and get the nfsnobody owner), however, I am unable to access the share from the linux client (can’t even cd to it). I still need to spend some more time with it and maybe bounce the windows nfs and nis services. Any tips would be appreciated, but I’m also using this as a sounding board and hopefully will be able to contribute the solution to my particular problem.

Sunday, April 1, 2007 at 10:33 pm

slowe

Doug,

Make sure you set the owner of the share to a mapped Linux account, and don’t just set permissions for a mapped Linux account. Remember that Linux/UNIX permissions are very different than NTFS permissions, so granting “Full Control” isn’t the same as changing the owner.

Monday, April 2, 2007 at 10:32 am

Doug

Thanks for the “hit upside my head”. Changing the owner to the mapped linux user was the missing piece of the puzzle (well that and a typo auto.master). Thanks again for this great resource on linux-ADS integration

Tuesday, April 3, 2007 at 9:52 am

slowe

Doug,

I’m glad we were able to get the issue resolved.

Thursday, June 14, 2007 at 7:53 pm

Alexandro Olivares

hello, great howto, I just wanted to ask you if you know how to automount homes from a nt4 primary domain controller (actually a samba one)

the windows clients automatically mount their home dir with samba as pdc, but the unix clients with winbind setup just see their local (workstation) home directory

Thursday, June 14, 2007 at 10:50 pm

slowe

Alexandro,

No, I don’t. Sorry! I suppose that you could massage the auto_home (or auto.home) file to try to automount an SMB share, but I don’t know what the syntax would necessarily be.

Tuesday, July 3, 2007 at 11:13 pm

Joe

In response to Aleandro’s question about mounting windows clients home folders from windows it is possible by using Winbind Kerberos and Samba. When creating the AD user specify their username home directory to be use \samba_server\username. When winbind and samba authenticate the user /home/DOMAIN/username will be mapped on the Windows client as their home directory.

You can use pam makedir to automate this.

Tuesday, July 3, 2007 at 11:18 pm

Joe

I have a different issue though. I want to use a linux server for my users home directories but seperated into staff and students. /home/staff/usernames and /home/students/2007/usernames The users will need to authenticate onto the linux server through some means of communicating with Active Directory and have their home directories available to them (for mailboxes) and on the windows clients the users again will need thier home drives mapped.

Any help would be appreciated.

Wednesday, July 4, 2007 at 7:41 am

slowe

Joe,

You should be able to use any of my AD integration articles to handle the logins to Linux, and then using this article should be able to automount the home directories via CIFS/SMB from Windows shares (by specifying the home directory in Active Directory Users & Computers) and then automount them via NFS using the /etc/auto_home (or /etc/auto.home) file on Linux. It’s the same basic setup I’ve described above, but instead of using a Windows server to do both CIFS/SMB and NFS, you’ll use a Linux server.

Wednesday, August 15, 2007 at 11:58 am

Mel

When I restart autofs I get the following (CentOS5)

Aug 15 08:57:45 library automount[2051]: create_udp_client: hostname lookup failed: Operation not permitted
Aug 15 08:57:45 library automount[2051]: create_tcp_client: hostname lookup failed: Operation not permitted
Aug 15 08:57:45 library automount[2051]: lookup_mount: exports lookup failed for .directory
Aug 15 08:57:45 library automount[2051]: create_udp_client: hostname lookup failed: Operation not permitted
Aug 15 08:57:45 library automount[2051]: create_tcp_client: hostname lookup failed: Operation not permitted
Aug 15 08:57:45 library automount[2051]: lookup_mount: exports lookup failed for .directory

Wednesday, August 15, 2007 at 6:41 pm

Mel

I’m getting the following message in the log when the user “test” logs in:

Aug 15 15:17:49 library gdm[4085]: gdm_slave_session_start: /home/test is not owned by uid 10001.

I’m sure my problem is a permissions issue on the AD server, but I’m not sure where to go… Do I need to manually make each user the “Owner” of their respective folder? This would take some time with 300 users… Are there other solutions? Right now the user folders are auto created by Windws AD (Home Directory setting) and being mapped from Linux (CentOS 5). Currently, “Administrator” is the owner of the folder.

Wednesday, August 15, 2007 at 9:23 pm

slowe

Mel,

If I recall correctly, I’m afraid that’s exactly what you’re going to have to do.

However, I’m fairly confident that you could whip up a shell script…er, batch file…that could help automate that process.

Good luck!

Wednesday, August 22, 2007 at 1:24 pm

Helder Pereira

So, if I want to map a server share to an home directory all I have to do is specify tje home directory option in the smb.com to \server\user ?
Thanks, great article…

Wednesday, August 22, 2007 at 3:08 pm

slowe

I’m not sure I understand your question. Check out the reference materials for Samba; they can give you more details on configuring smb.conf to meet your particular needs.

Wednesday, August 29, 2007 at 9:52 pm

Chris W

Your articles have been a great resource! I do have one issue though… When an AD user logs into an AD domain member linux host the home directory automounts correctly; however, that user cannot use VNC. An input/output error is recorded and the gnome session does not start properly. I am guessing that it is a permissions issue since by moving the password file to a directory other than home solves the problem.

Any thoughts?

Wednesday, August 29, 2007 at 10:10 pm

slowe

Chris W,

It’s surely a permissions issue, but I can’t tell you exactly what the issue is. It’s probably something like the permissions allow other users to read (at least, that’s what Linux thinks) and therefore VNC won’t use the password file. I know I’ve run into a number of issues where file permissions that were too lax caused things not to work properly.

Thursday, September 27, 2007 at 5:47 pm

Farris

As others have said, these are excellent articles and got me up and running in no time. However, something I haven’t seen addressed is annoyingly slow access to shares mounted on a linux client to a Windows host using NFS. I don’t know if it’s just that the MS implementation of NFS is very slow, or what. It can’t be my network hardware, as it’s wall-to-wall GigE, and all other protocols between these boxes are as expected.

Here are some examples from within a user homedir that is mounted via NFS from my Win2003R2 file server:

-bash-3.00$ time ls
1234

real 0m1.504s
user 0m0.001s
sys 0m0.001s
-bash-3.00$ time mkdir 4321

real 0m3.021s
user 0m0.000s
sys 0m0.000s
-bash-3.00$ time cd 4321

real 0m3.009s
user 0m0.000s
sys 0m0.000s

Any ideas?

Thursday, September 27, 2007 at 6:19 pm

slowe

Farris,

This may just be a wild guess, but I would make sure that that whatever AD attribute you have mapped as UID (which may be UID, since it’s included in the R2 schema) is indexed in AD. By default, UID is *not* indexed, and it can make a world of difference in how quickly AD responds. This is just a guess….

Hope this helps!

Thursday, September 27, 2007 at 11:26 pm

Farris

Scott,

Thanks for the suggestion. I’ve done just that, and I’m sure it will help with other areas. However it doesn’t appear to have much of an affect on this particular source of NFS slowness:

-bash-3.00$ time ls

real 0m5.986s
user 0m0.000s
sys 0m0.002s
-bash-3.00$ time mkdir 1111

real 0m1.494s
user 0m0.000s
sys 0m0.001s
-bash-3.00$ time cd 1111

real 0m1.496s
user 0m0.000s
sys 0m0.000s

One puzzling bit is that I’ve seen quite a few blog/forum posts about this kind of slowness, but no definitive explanation or remedy.

Thursday, October 11, 2007 at 6:48 pm

Farris

My slowness issue has gone away. Still no idea why. :) If anybody else ever has this issue, I’ll tell you the steps I took to resolve it:

1) Whine on someone’s well-thought-out blog post.
2) Contact someone at Microsoft for their opinion.
3) Wait a few days, but change nothing.

VOILA, it’s fixed. :)

Joking aside, did Chris W. ever determine what permissions issue was stopping VNC server from starting? I’m in the same boat now.

Wednesday, November 19, 2008 at 5:36 pm

Eric

it’s not the problem of permission but the fact that VNC is creating a file name with colon (:) in it, and windows won’t allow colon in the filename. Anyone have a fix?