Posted on 11-05-2012 12:02 PM
Can anyone chime in on this who may be in the know.
Have been having a an issue once a Mac 10.8.2 machine binds to AD (via dsconfigad) to login with a users AD credentials and actually create a proper and functional user home folder / user template.
Poking around in Apple Discussions I came up with some info on this.
The permissions in /System/Library/User Template are:
Read / Write, No Access.
What happens is the home folder never actually gets created properly on the AD login.
The Finder starts bouncing, there is no Apple Menu bar, and there are question mark icons in the dock. Finder crashes. Have to reboot.
I changed the permissions to be the same as the parent folder: /System/Library, and:
Success, I can login with AD credentials fine, creates the user home folder and subsequent AD user logins are fine.
I though this may be permissions get whacked in my cloning process, but just brought down a brand new 10.8.2 image from Apple (Recovery), and the permissions on the User Template folder are not the same as the parent (red stop sign). It seems this is by design on a brand new Mac OS 10.8.2 install.
Major issue for us, as we are doing an AD rollout with 10.8.2 very soon.
This behavior does not happen when using Centrify Express, although I think I have seen it happen at least once using Centrify Express.
Thanks in advance.
John
Posted on 11-06-2012 08:36 AM
Permissions on "/System/Library/User Template" should be 700. EDIT: In Finder speak this is system:Reas & Write, everyone:No Access
There is something else going on. I create Mobile user's using the User Template on the drive and these issues do not occur.
I know "works for me!" isn't exactly helpful but the permissions on the User Template is the wrong tree to be barking up.
Posted on 11-06-2012 08:40 AM
Can you dump your dsconfigad -show output here? One thing that can muck it up depending on your environment is leaving the UNC paths... option enabled by default.
Posted on 11-06-2012 10:41 AM
I put my own files in the proper locations in the template and then set the permissions on that User Template folder for all rights for everyone, and propagate them down through all subdirectories. I then run permissions repair on the volume and that changes what needs to be changed. This has worked well for us for years.
Posted on 02-15-2013 08:19 AM
I have this issue as well, the only files I was altering in the User Template folder were Preferences for dock, finder, sidebar, login window. I bind an admin account to AD, login as a standard user at login screen and then get the desktop and repeatedly quitting Finder.
User Template folder permissions are System: read & write, everyone: no access.
Posted on 02-15-2013 08:34 AM
In my testing, this happens if you override managed preferences on the AD user's first login, as the AD plug-in does some of its magic through managed preferences, or if you have users login as a network account, not a mobile account. A bug in 10.8.2's AD plug-in perhaps? It wouldn't be the only one. I only use mobile accounts here, so I haven't done thorough testing to see if there is a resolution for network accounts.
Posted on 03-18-2013 01:28 PM
10.8.3 solves this issue for me, maybe it will for you too.
Posted on 08-26-2013 03:53 PM
Hi - having very similar issue -when attempting AD user login (10.8.4) I get the "you are unable to log in to the user account " " at this time because an error has occured. Below are the logs, obviously showing an issue with the home directory mounting.
"mount_url: smb_mount: mount failed to [homedirectory], syserr = No such file or directory."
and
"ERROR | - [HomeDirMounter mountNetworkHomeWithURL:attributes:dirPath:username"] | PremountHomeDirectoryWithAuthentication( url=smb://studata/students$/[user.name], homedir=/home/[user.name], name=[user.name[ ) returned 1." ( also getting the same on other machines but 'returned 60')
Below is our dump from dsconfigad - if I re-attempt bind without 'Use Windows UNC path for home' I can login without issue but the home folders fail to mount.
Posted on 08-27-2013 07:45 AM
Our issue was on the AD server side (kaspersky). all set.