Mounting AD Home Share

[denmoff]

I'm starting to wonder if this is an issue with how our AD server(which i have no control over) is setup and not how the Mac AD plugin is configured. But i figure i should see if i'm doing something wrong on my end before complaining to our AD admin.

I have the active directory plugin configured with everything checked in "User Experience", Use UNC path with SMB. But when i do a dscl read on my AD user, i don't see a SMBHome or any other mapping that would point to the AD home share. Which would look like this if i map it from finder smb://my.server.name/[username]

I'm currently doing mobile accounts with "force local account" set, so it's not critical that this functionality work. I could just script the mounting, i suppose.

So, my question is, should the AD admin have something setup special for Mac users to get the SMBHome mapping? The PCs mount their network home as expected thru AD.

[daz_wallace]

Hey Den,

My understanding of the "Use UNC Path" is that it reads from the SMBHome attribute, so if:

a) This is not set in AD
or
b) The Macs (for some bizarre reason) can't read it

Then it won't mount.

TBH, we've had issues in the past with the "use UNC path" option, at one point stopping logins completely because it couldn't mount the share. We switched to using a LaunchAgent to mount the SMBHome at login, thereby separating the login process from the home mount. However, if you're having either of the above two scenarios (A or B) than this also shouldn't work.

I'd suggest having a poke around from an affected client using dscl and from a Windows device and check the SMBHome values.

Hope that helps!

Darren

[davidacland]

There is a possibility that the PCs are mounting the network drive a different way (not using SMBHome). To see if the attributes populated I would:

Check I can read the relevant user account from AD with “id username” (making sure the account isn’t cached on the machine - You should get a load of info back about the user

Check I can read one of the “standard” attributes with: dscl /Active Directory/AMSYS/All Domains -read /Users/username attribute - This should read back the value of the attribute you specify

Check I can read the SMBHome value: dscl /Active Directory/AMSYS/All Domains -read /Users/username SMBHome - This should read back the value of the SMBHome attribute

In the above cases, replace “AMSYS” with your short domain name and “username” with the relevant test user.

AS Darren said, I would personally use a script with a LaunchDaemon to trigger at login. In some cases (depending on the requirement) we put it in an AppleScript and add it to the user’s Dock so they can run it whenever they like.

[denmoff]

I'm just not getting an SMBHome attribute. It's not blank, the attribute doesn't exist. But it must be getting this info somewhere, because it will mount the share from time to time when the user logs in. I spoke to the AD admin and he didn't really understand what i was referring to when i told him that their should be an SMBHome attribute being passed to the user.

Thanks for your help Darren and David.
-Dennis

[davidacland]

SMBHome is the name of the attribute when looking directly on the Windows server). If they are used to the AD Users & Computers MMC it will be the network home folder section under the profiles tab of a user properties. I think if there is no value set it will appear like the attribute doesn't exist (can't be sure on that one without checking).

If it works in some cases there will probably be a pattern, perhaps its set for some users but not others or is only available when they are connected to the LAN etc.

[denmoff]

Ok. So...i now have access to my AD account on our AD server using RDC...woohoo!

Under the profile tab, there are two sections: User profile and Home folder. User profile has a blank profile path and default.bat for a logon script. Home folder has Local path selected with ourserver.ourdomain.edudenmoff. Is this what should be expected?

[davidacland]

The profile tab isn't used by Mac OS X. The value in local path for the home folder should be in the other field (I can't remember its name, it's the one with a drive letter option).

[denmoff]

That would be the Connect option. I tried setting that to a drive letter and the ourserver.ourdomain.edudenmoff path, but i get a message that says "The home folder could not be created because: The network name cannot be found." And there's no way to save those settings.

Edit: I've found that some users have their profile set with the connect option. On the mac, those settings translate to SMBHomeDrive and SMBHome. So it looks like i need to see about getting this straightened out with our AD admin. Thanks for your help Dave.

[ooshnoo · Accepted solution]

I had the same problem reading the SMBHome and other attributes. The solution was, in AD, give "Authenticated Users" group Read access to the OU, so maybe check AD permissions

[denmoff]

@davidacland Your answer appeared to be a red herring. All of the accounts that were showing SMBHome also happen to have their home directory listed in the "Connect" option and not the "Local Path" option. This may have just been coincidence.

@ooshnoo After applying the read permission to "Authenticated Users", the account now displays SMBHome. Thanks!

[jruskey]

ooshnoo/denmoff - What OU are you applying security for authenticated users? Where are you doing this? In active directory users and computers?

[denmoff]

In our domain, Authenticated Users had the 'read' permission set at the root level and it had propagated all the way down to everything except the user for some reason. Manually clicking that permission on an individual user, under their 'properties', immediately allowed the Macs to see the user's SMBHome. To fix this for everyone, the AD admin will have to write a script to enable it for all or get AD to re-propagate down to the user level.