trouble with the AD plugin

[Anonymous]

hi

im havig trouble with the AD plugin

im trying to map to home directory to an afp server
kerberos an everything is working,
and the home dir is visible under /Network/servers/”server”/Homedirs
after login.

The right searchpath is set in ad.

but the home dir always gets created localy under /Users/

the output of dscl on an client gives “nfshomedirectry /user/username”

but when i run WGM /Active Directory…. on the client i get the right /Network/serv….. searchpath ?

and i have no cahed users in netinfo

whats wrong ?

output from dsconfigad:

Advanced Options – User Experience
Create mobile account at login = Disabled
Require confirmation = Enabled
Force home to startup disk = Disabled
Use Windows UNC path for home = Enabled
Network protocol to be used = afp:
Default user Shell = /bin/bash

Advanced Options – Mappings
Mapping UID to attribute = not set
Mapping user GID to attribute = not set
Mapping group GID to attribute = not set

Advanced Options – Administrative
Preferred Domain controller = not set
Allowed admin groups = not set
Authentication from any domain = Enabled

[SivaDelFuego]

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?

[SivaDelFuego]

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!).

[SivaDelFuego]

> 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_user

In 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!

[SivaDelFuego]

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.

[simonknee]

I may have a fix for this…

Had exactly the same problem as you lot describe.

The key to my fix is that I have two domain controllers (DC) on my domain but only one was set to be a global catalogue (GC) server.
I set them both to be global catalogue servers in AD Sites and Services>>>NTDS properties.
Now the users that couldn’t mount their home share do!

I have seen this with windows login’s too. Some users use one DC and some the other. Don’t know why or where this is set in AD

This’ll be why your lab environment works, betcha only have one DC and one GC.

If you can’t admin your Windows servers then can you set which server to logon within the OSX Directory Access > Active DIrectory settings.
See if you can set this to which ever DC is a GC in your domain.

cheers

Simon

Update….

I think that you also have to make sure that Authenticated Users are allowed Read permissions on the account. You can only do this in AD on the server. You need to enable the advanced view to see the security settings.

Simon

[SivaDelFuego]

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.

[jfranks214]

Hi all,

So we’ve experienced a similar issue, however none of the above seem to be the answer.

The situation is that authentication and home directory mounting work perfectly for any user whose home directory is NOT located on a domain controlller. forcing local homes fixes the trouble but it’s not what we want, and it’s not feasible at the moment to move the home directories from the domain controllers.

I assume that there is some elevated security setting on the DC’s that is causing the trouble, but so far I haven’t found it. Any thoughts?

[SivaDelFuego]

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.

[Author]

Posts