Managed, Mobile Account login issue

I am seeing the same issue on multiple devices, just started this week or so.
Rebooting will usually help, more stubborn machines require a PRAM reset.

Pretty sure it has been all Yosemite machines, not certain which revision.

No solution as of yet.

I have seen this issue as well. I have been able to work around it by unplugging the ethernet and then the user is able to login. My guess is that it is having trouble contacting the Directory Server and when it is offline it uses cached credentials.

I've seen this issue on both 10.10 and 10.9. Could never really put my finger on what was happening. Would have users both wired and wireless get this symptom. The only solution for us we a hard reboot.

I have this happen occasionally with some of our users. Typically I use ARD or VNC to remote in and use the admin user to clear the screen saver. Once I do that they are fine. You can change the screensaver login dialogue by holding the Option key and pressing enter. Or is it Command? I can't remember right now but it is one of those two.

Does it happen when users are on a external network (e.g. a home network or public Wi-Fi network)? The only time I have ever seen this issue is when a user is on the corporate network and their AD account is locked out.

We have also had problems with managed mobile accounts. It is likely that you are not experiencing exactly the same problem we have, but in our case the problems were all related to mobile account users running Yosemite (10.10.0 - 10.10.3) on AD-bound MacBooks and taking their devices outside the (AD) network - where the Macs would freeze at the screensaver lock after sleeping. This has been fixed in 10.10.4 (thank god for MDNSResponder coming back) and 10.10.5 seems to be ok too.

Like @yan1212 said - make sure you're up to 10.10.5 (or 10.10.4 at least): the return of mDNSResponder was a very happy development and had a major impact on our environment (AD users with mobile accounts).

Does the password immediately fail? Or does it take a few seconds? Does the login box shake when it fails? And does your user get locked out if they fail too many times? Trying to locate where the break is happening: local, local talking to remote, or remote.

If it takes a few seconds to check the password, and then fail out, try running sysdiagnose while it's checking:

https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/sysdiagnose.1.html

You can get a lot of info with that dump. When we had this issue prior to 10.10.4, we were sending these to Apple for analysis.

I've encountered this before, it involved troubleshooting it live when it happened with via SSH so I could examine the logs at the same time. In that scenario, VPN was left on before it slept, so the network routes created by VPN didn't clear.

Thanks for the responses.

This is all good info.

We haven't seen this issue before. We are running on 10.9.5 with only a handful of test machines on 10.10.4
The 10.10.4 machines seem to have no issue.

@Shaffer the screen does the shake when it fails. It does take a second before it though. My thought is that its not talking nice to AD when logging back in. Hard reset fixes the issue, but this is a band aid solution.

@dwandro92 It only happens on the work network. External, has no issues.

We've been hit pretty hard with this problem. Our environment:

1. .local AD domain
2. Centrify
3. home folder required by Centrify (until recently)
4. mobile account created upon first login
5. Smart card authentication. (The problem predates smart cards though.)
6. Filevault 2
7. 10.9.5

Macs on our network not affected by the problem. Only when off network, usually connected to wifi at user's home. When session is at screen lock (policy) and user attempts to unlock, the login is denied as if incorrect PIN entry. User attempts Switch User, but PIN is rejected if loginwindow appears or force restarts the Mac if it doesn't. Filevault login is always successful (uses password of course). No single-singon as the second loginwindow is set to appear. This main loginwindow should switch to PIN entry, however this fails, displaying Name/Password fields. A cycle of forced restarts then begins as the user tries to make the proper loginwindow appear and in many cases, this causes the user's profile (in System Preferences->Users&Groups) to disappear(!) Uninstall of all Centrify items, rename of the user's home folder, then reinstall of Centrify will not allow initial login for that user (to create that mobile account). To repair requires imaging the drive to save user data/applications, a wipe and clean install of OS X.

We feel the issue surrounds OS X thinking it is on our network and wanting to talk to the DC or other network resource and when it fails, it refuses to display the proper loginwindow or rejects any PIN entry. The .local domain doesn't help, nor does having internal server shares set to auto mount.

Turning off Wi-Fi at start up and setting centrifydc.conf to always use cached credentials appears to yield some success, but won't really know until widespread deployment.