Network Home folders in an AD environment?

jhuls
Contributor III

Just curious what people's take are on network home folders in an AD environment. I've never dealt with them on the Mac or Windows side of things but now there's some push for us to consider it. Is it reliable? Easy to setup?

The OS we're running on most systems is Yosemite and about half of them only have 100mb connections. Only a handful are laptops working over wireless.

12 REPLIES 12

psliequ
Contributor III

They're tough to provide reliably. Apple's AD plugin has some support for them but it can be very cranky.

There are many examples on the site of hand rolled solutions too. One challenge you'll face is how to tell a client to not care about mounts when off network.

By far the hardest job you'll have is in training users to use them though :) Would providing them solve a specific problem you've been having?

Also search on the site for discussions about Enterprise Connect.

Look
Valued Contributor III

The built in solutions really don't work very well (although I have not tried Enterprise Connect from Apple which looks like a promising if somewhat expensive solution to network connections etc...).
However scripted solutions abound, basically you can read the path straight out of AD and then tell the OS to map using that (with a little awk or sed magic to make it Mac friendly).

guidotti
Contributor II

We are rolling out Office365 going away from eDirectory and Novell, but basically will do just as @look suggested. We are taking an eDirectory Novell Open Server path to a user's home folder, and stripping it out in a script, then running it as a login script to mount the cifs paths. You could substitute Novell in my scenario for any other Windows path. Hopefully in the future, we can move to OneDrive or some other storage, but that will have to do for now...

jhuls
Contributor III

@psliequ We're migrating away from Novell. In the process of that we're also migrating from our current AD forest and domain to another. Currently we have no official backup strategy at the workstation level on our campus so months ago the powers that be purchased drive space for our SAN so that it could be used for storage for everybody on campus. The plan was to have this going in the new domain and when we migrated systems in they would now have this to access. Crypto wall struck recently so now it's been pushed so we have to begin deployment of this before we migrate(I just learned this late yesterday).

So here's what I've been told...in the new domain accounts will be configured in AD to have a home drive. To get it working on the old domain I have to test whether I can access it across domains as a share. My thought is it might be best to access it as a share no matter what domain because I'm told that Windows use of a home drive is like that of a share so I'd like to keep the functionality similar. We have a few people who have both a Mac and Windows.

So some of this is still developing after a meeting late yesterday. If someone can provide feedback now as to whether a Mac can ignore the home drive configuration in AD, I'd appreciate it....or if you have any other advice. Thanks!

Look
Valued Contributor III

Yes a Mac can ignore home drive configuration (this is what we do, then mount it manually from a script).
There is a tick box in the binding section of Directory Utility for Use UNC path from Active Directory untick this and it no longer tries to mount the drive.
If your using dsconfigad to bind to AD in a script add -useuncpath disable to disable the option.

jhuls
Contributor III

@Look Thanks! For that setting is there any other functionality that we might see penalized? I remember that setting now but have always just went with the default setting. Sounds like I need to do some reading.

Look
Valued Contributor III

@jhuls The only feature I can think of is you wouldn't be able to have a synced home folder.
There may be others but certainly we have not found anything else important.

jhuls
Contributor III

Thanks for the feedback...it's been very helpful.

jhuls
Contributor III

Ok, so it looks like I need to back up a bit...originally I had read that with home folders on the Mac that I could setup a home folder through AD that would reside on the network and all of my documents, pictures, music, etc folders would be stored rather than on the local drive. Then I read that there was a way to sync that with the local drive. I wanted neither of these so I was looking into blocking this ability.

Now I've read some comments that seem to say that I can configure the home drive in AD so that it truly does work like Windows and will even put a folder in the Dock meaning that the user still has their Documents, Pictures, Music folders locally but there is a network folder for them to store data on that is setup automatically. Is anyone here familiar with that? Any ideas where I can read up on the details of this? In my google searches I feel like I'm reading partial information at each place.

Look
Valued Contributor III

The reason it feels like partial information is that there really are several different ways this can be done and it also depends on how you do your binding to AD as well, of which there are also several different ways.
AD Bindings can be done as follows and almost certianly other ways as well.
Casper Builtin
Manually Using OS X Users & Groups
Command line
Third Party App. (Centrify I think does this bit I haven't used it personally)
When you bind to AD you can specify both whether the home drive is mounted and whether it is synced, depending on how you bind how you do this is different.

If you don't do it as part oft he binding (which is sometimes not so reliable) you then also have various options.
Script mounting it directly.
Script getting the Finder to mount it.
Third Party App.

The last and somewhat expensive option which is rather new to the scene but looks to have potential is Apple's Enterprise Connect which consists of software & services & many $$$ you give them :).

My personal preferences is to have a script read the value out of AD and then call the Finder to mount it, mainly because I can do this directly out of Casper without too much trouble, others prefer other ways of doing it.

How were you planning on getting the machines bound in the first place?

jhuls
Contributor III

We currently bind the systems via Casper using the built-in directory bindings. Between doing it this way in a policy and having tried binding systems via Configuration Profiles I prefer the policy. Configuration Profiles sounded good when Jamf suggested it but I found them unreliable for our use.

If I need to bind through a script, I'm not opposed to it but it's something I'll have to take a moment and work through the logic. I'm the only Apple guy here so the more I can put into a gui that's easier for someone to figure out in a pinch if I'm not around, the better. Scripts are inevitable though depending on what it is so it's certainly an option.

Any chance I could have a peek at your script to see how you're grabbing values and mounting the drive?

Of course if there's a way to do this without bringing in a script, I'd prefer it for the reason I cited above but either way it'd be nice to see how you're doing it so I can weigh my options.

Look
Valued Contributor III

The whole script is rather complicated and does a bunch of other things relating to other shares etc... we have but the core part to do with the Home drive has the following.

Bit's most likely to be useful to you

Current_User=$(stat -f%Su /dev/console)
Machine_Domain=$(dscl /Active Directory/ -read . SubNodes | awk '{print $2}')
Share_Path="smb:$(dscl "/Active Directory/$Machine_Domain/All Domains" -read /Users/$Current_User SMBHome | awk '{print $2}' | sed 's/\///g')"
True_Path=$(echo $Share_Path | sed 's//////'$Current_User'@/g')

/usr/bin/osascript<<END
tell application "Finder"
mount volume "$True_Path"
end tell
END

The reason I like getting the Finder or the system to do it is because it automatically seems to deal with mount pounts, permissions, ejecting the drive etc... basically automatically, which if your running the script as root i.e from Casper is really useful.