Solved

Some (but not all) AD-joined Mavericks computers will not unlock after screensaver or display sleep

Posted on 2014-09-09
11
900 Views
Last Modified: 2014-09-23
We have a global network with a Windows Server 2008 R2 functional level Active Directory environment. Root domain controllers are in a USA datacenter and local domain controllers are installed at our corporate office and our branch offices. Authentication for all the Windows clients and most of the Mac clients works fine.

We have about 25 Mac clients. All are running OS-X 10.9.x (mostly 10.9.4) and all are joined to the AD domain. This is the process we are using to join them to the domain:
System Preferences > Users & Groups > Login Options > Network Account Server
Click 'Join'
Leave server name blank and click 'Open Directory Utility'
Double-click 'Active Directory' to join the computer to the proper OU
'ActiveDirectory Domain': avoxi.int
Click 'Bind'
Enter the appropriate OU information:
Expand the advanced settings (Directory Utility > Active Directory > Advanced):
Go to 'User Experience' tab
Select “Create mobile account at login”
Leave unselected: “Require confirmation…”
Unselect 'Use UNC path from Active Directory...'
'Administrative' tab
Check 'Allow administration by:'
domain admins
enterprise admins
Leave checked 'Allow authentication from any domain in the forest'
Click 'OK'

The login window is set to "Name and password"

I am having continual authentication problems with 2 of the Mac clients. The end user can log in without any trouble but if sleep or screen saver begins then the user is unable to unlock the computer. (Computers are set to require a password 5 seconds after sleep or screen saver begins.) Usually the user gets the "screen shake" after entering the password but occasionally it simply does not respond. Either way, the computer must be powered off/on for the user to authenticate. I think that if one chooses "switch user" then one is able to unlock, but this hasn't been tried often enough to know if this always works.

When the password is rejected, I do not see a corresponding event on the domain controller nor does the bad password count increment.

I have not had either user try logging onto any other Mac clients to see if the problem follows the user.

Both users are in the same office. That office does not have a local domain controller, so clients authenticate across the WAN link. That office is separated from me by 6 time zones, so I am unable to physically log on to the clients but I am able to use Apple Remote Desktop. Unfortunately ARD is extremely slow when connecting to that office because of the Internet connection speed into that location. The clients were configured here in Atlanta and then shipped. I did not notice the trouble when configuring them, but I cannot say for sure that I ever actually let them go to sleep and then unlocked them. There are 4 other Mac clients in that office and they do not exhibit the same symptoms.

 - Eric
0
Comment
Question by:Eric Quackenbush
  • 6
  • 3
  • 2
11 Comments
 
LVL 38

Accepted Solution

by:
Aaron Tomosky earned 500 total points
ID: 40314713
Since you are using mobile accounts I assume these are laptops. My alternative solution is to not use the builtin ad join utility, but the free version of centrify as it caches password hashes so you can login offline without the silliness of mobile profiles. If you want to go this route and need assistance let me know
0
 

Author Comment

by:Eric Quackenbush
ID: 40314902
Hi Aaron, can you enlighten me on
the silliness of mobile profiles
? I am relatively new to Mac (especially compared to my Windows background) so I might not fully understand what's happening there. I assumed (yeah, I know one should never assume) that the "mobile account" was basically the same as Windows creating a "User Profile" in C:\Users for every user that logs on. What's different? If you use Centrify and don't create a mobile account then does OS-X still create a /users/shortname folder for the users that authenticate?
0
 
LVL 38

Expert Comment

by:Aaron Tomosky
ID: 40315151
mac joining ad is like windows joining ad, except you CANNOT login without being on the network, so basically useless for laptops.
However you can add the mobile account options and now it acts like roaming profiles, but really buggy.

centrify joining ad is like windows joining ad. When you login with the network account, it creates local folders. When you are offline it can still let you login with a password since it caches the hash.

Basically you just unjoin and get rid of your local user accounts except one as a backup to manage it with.
Go get the free centrify express for osx: http://www.centrify.com/express/free-active-directory-authentication-for-unix-linux.asp
install that, join the domain, logoff.
Login as a network user at least once to create the folders and save the hash

So far the only time centrify has failed to work correctly, was joining a vm server running the xcode ci service. That thing is basically beta still and it couldn't authenticate users over it's web interface unless I used the builtin osx ad join.
0
 
LVL 27

Expert Comment

by:serialband
ID: 40315564
You have to turn on Mobile accounts if you're roaming, so leave those enabled.  This makes the account stay on the system more like "local profiles" and allows users to log in when they're not connected to the domain controller.  This allows you to cache the profile, otherwise it's mounted and copied from across the network each time.  If you don't have it enabled, you can't log in unless you're already connected to the domain controller to authenticate and the account's local folder disappears from the disk when you log out.

The behavior you describe suggests that they may have a password mismatch between the domain controller and the local cached credentials.  I think the only thing you can do in that case is to have them connect, then load an AD share with the correct password.  This should allow the new password credentials to cache.  Alternatively, they may have to log in with a local account, then connect via VPN to your AD network, then use switch users to log in with their AD account.  They pretty much have to do the same thing as the remote Windows users.
0
 

Author Comment

by:Eric Quackenbush
ID: 40315628
Sorry, serialband, your reply doesn't fit the scenario as I described it.

One thing I could have made more clear is that the remote location is connected with a persistent WAN link, so clients can reach the domain controllers without firing up a VPN client. TCP/IP routing and DNS resolution are all working fine.
0
 

Author Comment

by:Eric Quackenbush
ID: 40315675
Aaron, I have downloaded the Centrify tool and am testing it on a MacBook that I need to get ready to be redeployed. I removed the existing Active Directory binding, installed the Centrify client and used that to re-join the domain.

I'm having a bit of trouble with an existing AD user that already had a mobile profile. When I log in as that user, the permissions for the AD user's local folders are hosed. (I also logged as an AD user who had not previously logged on to the machine and that worked fine.)  I tried to use sudo chown and sudo chmod to set permissions (using a well-documented procedure that I have used successfully many times in the past) but that failed to correct the problem.

I'm reasonably certain that if I delete the existing profile and then log in again, it will create a fresh local folder and the problem would go away. That would be fine for this box because I'm about to delete the partition and do a clean install anyway but I need to preserve the existing settings for the laptops that are in production. My users are not going to want to hear that I fixed their problems with unlocking their laptops but I deleted all their files and settings in the process.

Have you successfully transferred a Mac AD-joined user home folder to a Centrify AD-joined user?
0
 
LVL 38

Expert Comment

by:Aaron Tomosky
ID: 40315682
transferring folders didn't work well last time I tried it, but that was a year ago. Centrify also lets you map different local user names to active directory user names, but that got weird for me too. I settled on deleting all the local users and it's worked great ever since.
0
 
LVL 27

Expert Comment

by:serialband
ID: 40315741
You should be able to rename the user account folder or copy it.

rsync -a /Users/ACCOUNT/ /Users/COPY/

You can then recover everything except ~/Library and you'll get their data.  Their settings are in ~/Library
0
 

Author Comment

by:Eric Quackenbush
ID: 40319463
UPDATE: My "well-documented procedure" for chown and chmod wasn't documented very well after all. I had left out the -R switch (recursively apply the change) from the chown command. Oops. I finally noticed the omission when I compared
ls -le /Users

Open in new window

with
ls -le /Users/shortname

Open in new window

and noticed the different UIDs assigned to the subdirectories.

After I corrected that and repeated the other steps in the process, I was able to access all files and settings that had been previously created for the AD user as a mobile account.

My next step is to test the Centrify Account Migration function on another test machine that I have available. If that works, I will use that for one of the production computers that I'm having trouble with. (I cannot apply my manual solution because the final steps require physical access, which is not possible for me --remember the 6 time zone separation?)

If this works for the production computer and the computer unlocking issue is resolved then I'll assign the well-earned points to Aaron Tomosky.
0
 

Author Closing Comment

by:Eric Quackenbush
ID: 40340194
Aaron's suggestion and subsequent followup have been most helpful. I still have not had the opportunity to test the Centrify Express solution on the computer that's giving me the most trouble (the machine and I being 6 time zones apart can make scheduling support time difficult) but I was able to apply it to another computer in that office today. So far it is working well. Only time will tell, of course, since the problem is intermittent.
0
 

Author Comment

by:Eric Quackenbush
ID: 40340205
I just reread my comment above about chown -R and realized that I put the wrong ls switches. They should have read
ls -ln

Open in new window

not -le.
0

Join & Write a Comment

Synchronize a new Active Directory domain with an existing Office 365 tenant
The recent Microsoft changes on update philosophy for Windows pre-10 and their impact on existing WSUS implementations.
This tutorial will walk an individual through locating and launching the BEUtility application and how to execute it on the appropriate database. Log onto the server running the Backup Exec database. In a larger environment, this would generally be …
This tutorial will walk an individual through locating and launching the BEUtility application to properly change the service account username and\or password in situation where it may be necessary or where the password has been inadvertently change…

743 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now