Roaming Homes on Xserve with AD Authentication

Question

Roaming Homes on Xserve with AD Authentication

Alright, this is a tough one:

I am integrating an OS X Server (Xserve, Xeon Quad) in an Active Directory environment (Win 2003 Server). I have the Xserve set up as an Open Directory Master and it's bound to the Active Directory domain. Kerberos is working for AFP, but SMB is NOT working (seems SMB is actually not Kerberized and requires the /etc/smb.conf file to be configured correctly - another issue for another day... but if you have advice, I won't stop you).

The reason they're doing this is because they want their Mac folks to have roaming network home folders. So, the "home folder" (smbHome) records for all the users in AD (Active Directory) point to the User share on the Xserve. Clients bound to AD and OD (AD first, of course) are able to authenticate and log in.

Here's the messed up thing:

SOME users get the networked home folders mounted (/private/Network/Servers/server x.company_x.com/Users/userx). OTHERS do NOT.

From best I can tell, Mac OS X knows where to mount the home folder based on the Directory Services attribute called "NFSHomeDirectory," which regularly (in the case of NetInfo, for example) goes to the Users's folder (/Users/user_x). In order for it to be a roaming home folder, the NFSHomeDirectory attribute needs to have a value of /Network/Servers/server x.company_x.com/Users/userx and AD has NO attribute for "NFSHomeDirectory" (or HomeDirectory, for that matter).

So how does OS X get the NFSHomeDirectory value? As far as I can tell, dynamically. It takes the smbHome field (which DOES exist in AD) and uses it to dynamically sculpt a HomeDirectory (xml plist format) and, using that, then an NFSHomeDirectory (at last).

Here's the problem - SOME of the AD users are getting a "HomeDirectory" attribute and SOME are getting NOTHING. They all have an smbHome and the format is the same for every one (\\Xserve\Users\user_x). When I get a user with a "HomeDirectory" attribute, it makes the right kind of "NFSHomeDirectory." When I get a user with NO "HomeDirectory," the "NFSHomeDirectory" is dynamically set to "/Users/user_x" which forces OS X to make the user's home folder locally, thwarting my plan to make the home folders NETWORKED (stored on the Xserve) and completely negating the reasons for why I'm out there.

Forward and reverse lookups (using the host command line binary) are working for the Xserve using the Windows DNS system.

Is my understanding flawed? What on Earth is going on here??

Anyone ever done this? Anyone know why some AD users get the dynamically assigned "HomeDirectory" attribute while others do not? Is that even what's happening?

Quad Core Xeon Xserve Mac OS X (10.4.8) Win 2003 AD Server

Quad Core Xeon Xserve Mac OS X (10.4.8) Win 2003 AD Server

Posted on Jan 15, 2007 8:36 PM

Reply

Answer 1

Jan 18, 2007 7:47 AM in response to Matthew Delfino

Does anyone have any suggestions at all? Am I being unclear? Is there anything I can say to get one of you guys to think of some ideas?

Quad Xeon Xserve Mac OS X (10.4.8)

Reply

Answer 2

C.Moser

Level 2

244 points

Jan 18, 2007 8:11 AM in response to Matthew Delfino

We had a similar setup, but we had the os x server bound to AD only to manage the clients. All XP and OSX clients home folders where on a w2k3 server.

More informations about your setup is needed to find the problem...

Reply

Answer 3

Jan 18, 2007 8:52 AM in response to C.Moser

It's a Windows 2003 server and most of the domain controller settings are set to default. I don't have the specifics on what is on and what is not on in order to be exact.

Each directory service record has attributes and values (RecordName, Password, UniqueID, GeneratedUID, etc). This is how authentication is possible in OS X.

NFSHomeDirectory is the Directory Services attribute that sets the path to the home directory for every user. However, here's what happens when I use dscl to look at NFSHomeDirectory for users where networked home folders is working. I type:

dscl localhost -read /Search/Users/user_x NFSHomeDirectory

Which returns me the following:

NFSHomeDirectory: /Network/Servers/xserve01.xxx.com/Users/user_x

As I understand it, usually Directory Services MAPS all the attributes in one directory service to what OS X is looking for (UID in LDAP to RecordName is Directory Services, for example). However, there is NO NFSHomeDirectory attribute in AD. There is an "smbHome" attribute (I think that's what it's called), which has a value that can be reformatted to a value that Directory Services can use for the NFSHomeDirectory. But that has to be mapped dynamically. I can't remember where I found the info on how NFSHomeDirectory is set for AD records. I seem to remember that NFSHomeDirectory is created from the HomeDirectory attribute, which is an xml plist-style string. I may be way off. Here's what the HomeDirectory attribute in Directory Services looks like:

HomeDirectory: <homedir>(pathToHome)</homedir>

In my case, for the users where it is working, this is what happens:

dscl localhost -read /Search/Users/mdelfino HomeDirectory

Result:

HomeDirectory: <home_dir>(something to the effect of) smb://Xserve01/Users/userx)</homedir>

Now, here's what I get for the users where networked homes are NOT working:

localhost:~ $ dscl localhost -read /Search/Users/user_x NFSHomeDirectory
NFSHomeDirectory: /Users/user_x
localhost:~ $ dscl localhost -read /Search/Users/user_x HomeDirectory
HomeDirectory:

As in, there IS no HomeDirectory attribute dynamically assigned to the AD Users who cannot get their homes mounted on the Xserve.

My question is HOW can I get all the NFSHomeDirectory attributes for the AD users to show a value of /Network/Servers/xserve01.xxx.com/Users/user_x?

NFS is not involved, to be sure. That's just the name of the attribute Directory Services uses for the home folder path. Is there some group policy that can cause Directory Services on OS X to malfunction? Something that can cause it to fail to dynamically assign a HomeDirectory attribute to each AD user and, in kind, screw up the NFSHomeDirectory attribute?

If there is more info you need, please ask specifically what you'd like me to disclose. I will do it as soon as I am able.

THANK YOU for looking into this.

Quad Xeon Xserve Mac OS X (10.4.8)

Mac OS X (10.4.8)

Reply

Answer 4

Feb 20, 2007 6:29 PM in response to Matthew Delfino

The True Solution:

I smoked this bugger about a month ago, but got lazy about posting the solution we found. I apologize for those of you waiting on the edge of your seat.

The problem with us not getting the homeDirectory attribute from Active Directory was a permissions issue in Active Directory Users & Groups. You need the most fully-functional administrative version of Active Directory Users & Groups (the one with the most tabs per user - I believe it has something to do with Exchange). Pay close attention to the red circle...

Here's the way it was:

Click here to see the way it was.

Here's the way it SHOULD be in order for OS X Directory Services (with the AD Plug-in) to map all the proper attributes:

Click here to see the way it should be.

By removing the Read permissions for Authenticated Users, I'd say the granularity of their security settings may have exceeded what was necessary. Why? Because (apparently) all this means is that authenticated users cannot read all the attributes from their Active Directory user record. This may help protect them from some obscure attack, but deactivating this feature did far more harm than good.

When this option is turned off, the "homeDirectory" attribute is among those attributes hidden by Active Directory. This attribute's value contains the UNC path to the user's home (in this case, "\\Xserve\Users\user_x" was the UNC), which was the missing link for network homes for Macintosh users in this Active Directory environment.

Once authenticated users had this permission again, everything worked beautifully!

P.S. We hypothesize that this setting was also the cause of a problem that prevented the Macintosh users from being able to change their Active Directory passwords from a Server Login window.

Mac OS X (10.4.8)

Xeon Quad Core Xserve Mac OS X (10.4.8) Riches await ye who gives a crap

Reply