Forum Replies Created
-
Posts
-
Have you used the command line tool dscl to read all the attributes belonging to the user records of the users whose homes are on the domain controller? One thing that helped me was seeing the attributes of the records from a user record that worked and then seeing the attributes from one that did not work. We saw what was missing, and then we were able to hypothesize about what was wrong. If the attributes are ALL readable, it must be a permissions issue locking down either the sharing protocol itself or locking down the share volume. When I was looking in the settings for Windows Server 2003, I was amazed at all the finicky security settings that could be activated. One of them might be the culprit.
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.
There seems to be no rhyme or reason to what makes some user records reveal their homeDirectory and what makes some not. The ones who reveal their information may be in the exact same groups as the ones who do not. We might take one AD record and duplicate it, same OU, same just-about-everything. The old record will work, but the new record will not. We will make a user from a right click > new user (from scratch) or we will make them from a template. It seems to be only the fact that one particular admin user made the records that THOSE records work, but the ones I create with MY domain admin account never seem to work. But EVEN THAT is not consistent, because some of the aforementioned admin’s creations also do NOT work.
We see no group policies that scream out to us, “Hey! I’m a group policy that restricts info like home folders from being read by certain client machines! Gimme some candy!” or, “Hey, you! Look at me! I’m an AD machine policy that allows certain machines to read all the attributes in AD records! Trick or treat!” Is there something I should be looking for? Remember, I’m the Mac guru in the troupe. I know my way around Windows 2003 Server, but I couldn’t build and/or maintain one.
> 1. Are all the users, the ones the work and the ones that don’t, showing similar home paths when you view their user records with dscl?
No. There are three attributes we’re talking about here.
1. homeDirectory (smbHome), the AD attribute describing the home folder:
a. Working Users: \\Xserve01\Users\x_user
b. Non-Working Users:
(Nothing for the non-working users) NOTE: In Active Directory Users & Groups, these paths are ALL exactly as (a.) above.2. HomeDirectory, the DS attribute in xml format created dynamically from the homeDirectory attribute in AD:
a. Working Users: <string><home_dir><url>afp://xserve01.company.com/Users</url><path>x_user</path></home_dir></string>
b. Non-Working Users:
(That’s right, nothing)3. NFSHomeDirectory, the DS attribute that’s a literal UNIX path to the home:
a. Working Users: /Network/Servers/xserve01.company.com/Users/x_user
b. Non-Working Users: /Users/x_userIn my research, I’ve discovered that Directory Services, with the AD plug-in, dynamically translates the Windows homeDirectory UNC (\\Xserve01\Users\x_user) to the HomeDirectory attribute’s xml data string ( <string><home_dir><url>afp://xserve01.company.com/Users</url><path>x_user</path></home_dir></string> ) and then converts that into the UNIX path value of the NFSHomeDirectory (/Network/Servers/xserve01.company.com/Users/x_user), which is the pot of gold at the end of the rainbow. The problem is, Active Directory is hiding the homeDirectroy attribute from OS X’s Directory Services. It may be hiding it… period. This attribute is not revealed to multiple OS X machines. It is consistent from each OS X client bound to the AD domain. Where it IS revealed (those few AD records that ARE showing it), everything works. Where it is NOT revealed, we see the same results as the original poster describes (NFSHomeDirectory: /Users/x_user).
> 2. Are you getting errors on the Xserve as far as SMB auth problems with these users when they login to a machine?
Oddly, yes. Single sign on works for AFP (using the Windows 2003 server’s KDC), but SMB fails unless you’re logging in as a user local to the Xserve. ALL AD users fail to connect to the shares using SMB when I use Kerberos. It tells me that the username and/or password I entered were not correct. It’s as though the ticket the server gets from the KDC is inaccurate/malfunctioning OR that the Windows domain controller is rejecting the Xserve’s Samba 3 (3rd party) server (I know Samba 3 doesn’t work quite like the other Kerberized services in OS X).
As a side note, thanks for looking into this!
H: \\Xserve01\Users\x_user
We’ve also tried…
H: \\xserve01.company.com\Users\x_user
But the only one that causes AD to see the home folder aftrer typing this in and ask us if we want to take control of the folder is the former, which implies to me that that is the proper UNC for the Home folder. As I said, in my situation, it works for some users, not for others. And we have tried to reproduce the problem with the same configuration in our lab, to no avail (it works like magic in the lab!).
We’re having the same problem. dscl gives us just the /Users/x_user
Our homeDirectory attribute in Active Directory is the same for all users: \\Xserve01\Users\x_user
For some users, it translates into an xml formatted DS HomeDirectory attribute, then into a DS NFSHomeDirectory attribute (/Network/Servers/Xserve01.company.com/Users/x_user). For most, however, homeDirectory remains unseen and DS HomeDirectory is not created, therefor DS NFSHomeDirectory gets set to /Users/x_user.
We have gone over the settings in DS on OS X 10.4.8 on several machines, they all do the same thing, our configuration looks A.O.K. What’s causing this. We’re about to give up and say the domain controller or AD Schema has been altered and it’s causing DS to be unable to read all the attributes in ActiveDirectory.
Did you find a solution?
