Installed today's build (16B2553a) and got the same results. Unfortunately no fix this time around either. This is definitely going to be a problem if we do indeed get new MBPs coming out next week. I'm sure they will be shipping with Sierra installed, which means we won't be able to making any new MBP purchases (or any other Macs that get an update) until they patch this. I'm definitely going to be reminding my TAM today about the financial impact this has on Apple from us and other customers in the same position.

It also seems that like it or not I need to start looking at moving back away from AD binding and adopt something like Enterprise Connect. Frustrating...

I shot some additional hot fire to Applecare on this. This is frankly unacceptable. AD is everywhere in the enterprise, and they clearly did not test AD functionality in a thorough manner (which is kind of typical to be honest).

I can trigger an active directory lockout on demand by going to Icloud preferences then clicking on account details on Sierra.

I only have one system at work that has Sierra. It's bound to AD but it's a non-mobile account. A couple times a week I'm getting an error message stating something to the effect that there's a problem with my iCloud account and that I need to sign in. Unfortunately I've managed to misplace the screenshots I made of it.

To add to that a few times a week when my screen goes to sleep I then can't unlock the console. I've found though that I can log in with a local account. Once I do that I get an error message in that account stating Keychain "login" cannot be found and asks me if I want to reset it. It doesn't matter if I do or not...the next time I go through this, it does the same thing. During the time it prompts me for this I also get a message that ctkahp quit unexpectedly. This will constantly keep popping up.

Now if I can get logged out of that account while it's popping up those messages on me I find that I can now log back into my account that was locked out. It's worked every single time.

This all started just after Sierra was installed. I have the rest of our campus systems configured to prevent Sierra upgrades but my CIO just came to me and asked to be excluded. I warned him about the iCloud/AD conflict but I'm not sure I was heard. sigh

So just downloaded and installed 10.12.1. It locked me out before I could even login. Also I was logged out of iCloud before I did the update. So I got unlocked and tried to go in to iCloud and of course was locked again. This is very frustrating.

I find it kind of interesting that I cannot locate another discussion about this issue on the interwebbernets...

I kind of figured that a fix for this would not make it into 10.12.1, as much as I had hoped for it. I can consistently lock myself out simply by using two Sierra Macs which are logged into my AD account.

I've had some discussion with folks about there being 0 discussion of this elsewhere. Not on stack exchange. Not on apple discussions. For good measure I replicated on non enrolled casper macs. I think it's just indicative of jamfnation being the place for this type of discussion, regardless of management platform. _(ツ)_/

My AD account just got locked out when I upgraded a new test system from 10.12.0 to 10.12.1. I hadn't set up iCloud on this system. Imaged, logged in, ran Software Update and was locked out at some point during the update. I am going to see if I can reproduce it.

Edit: I wasn't able to reproduce this, but I get locked out so rarely that I figured it was connected (it still might be).

Is anyone opening an Apple Bug Report on this issue?

I was surprised at how infrequent this seems to be mentioned as well. I did see some other mention of it on the MacAdmins slack channel in #sierra (see discussion on September 28).

Also, our symptoms were slightly different than most people here in that we have no AD accounts (and no AD in the company or any directory-bound accounts). What we saw was:

-- people using iCloud and Sierra
-- After a period ranging from hours to days, but frequently around restarts or logins
-- User account locked
-- Another admin could reset account (even using same password)
-- Problem goes away without iCloud

The odd thing was there isn't much talk of this, and the same users with the same iCloud accounts could upgrade personal machines without issue.

The Slack channel pointed me to the issue of failedLoginCount when looking at

dscl . read /Users/username accountPolicyData

What we saw was that it seems like iCloud password errors are incrementing this counter. When users receive iCloud password popups or go to the iCloud system setting we can watch the counter increment.

Then we have a profile which sets policyAttributeMaximumFailedAuthentications to a given value. This can be seen by running:

pwpolicy -u username -getaccountpolicies

When the failedLoginCount hits that value the account is locked. In all cases we have observed the locks without a single failure at the GUI login window. When the lock occurs we see the user cannot authenticate by running:

pwpolicy -u username -authentication-allowed

I would assume AD accounts run into the same issue because they enforce a lockout on password failure that uses the same counter.

We can avoid the issue by removing iCloud or removing the account lockout on password failure, but the real issue is that iCloud account login errors should not trigger this counter (and really they shouldn't happen as the user is not trying to log into iCloud at the time...these are exising iCloud configurations).

Unfortunately the work arounds both have problems, but I don't see another solution until Apple fixes iCloud logins incrementing the user account bad login counter. As others have mentioned 10.12.1 does not change this behavior at all.

Hi,
Just registered to chime in here: I'm having the exact same issue as all of you. We don't use jamf here, so I don't think the issue is related to that. It is weird that it's not being discussed anywhere else.

Just installed 10.12.1 and got locked out after restarting I don't understand why more people aren't experiencing or complaining about this...

We found the issue wasn't necessarily related to MDM, but any account lock out policy (MDM applied profile, manually installed profile, and I assume AD enforced profile though we can't test the latter).

We're seeing this in users that upgrade to Sierra as well!

I'm trying to see if NoMad can help. See the #nomad channel in MacAdmins for bindless AD binding. :-)

It usually happens to our users when the Mac either goes to sleep or to screensaver BY ITSELF, not initiated by the user... very strange.

@jcwoll What is your lockout policy set at? In testing it appears different activities will increment the failed authentications at different rates. Screen Lock will trigger 1-3 but fiddling with iCloud will trigger 5. I have heard that watch unlocks will trigger a failure as well.

Upgrading from 10.12.0 to 10.12.1 on a machine with no iCloud bind triggered 5 in testing this morning.

These numbers are roughly what we see as well. Normal use w/screen lock gives you a couple, upgrades give you five. Not sure what resets it. It is more than just a successful auth at the screen that can do it as we have seen it go back to 0 with no user action.

Users with a lockout policy of 7 get locked out very quickly. 10 or 11 is much less frequent (can take weeks), but it still happens.

@Kaltsas We're set pretty low at 3 failed attempts locks you out.

I've also seen the Apple watch lockouts as well. What are you using to track the lockouts?

I've just been calling the AD team to monitor when I've been doing testing, so however they check the failed authentications AD logging magic ¯_(ツ)_/¯

@Kaltsas Gotcha. Fortunately, we have a little tool that monitors ours, called Trigeo. The crappy thing about it is that its an SMB mount and a basic text log, so its somewhat of a pain to slog through.

I had the same problem, fortunately my system let me log in after the update (guessing it was just using local storage of login credentials before it could connect to the network server) - but after that I was locked out of exchange email and admin password on my system.

The problem is definitely with iCloud keychain, I disabled iCloud in System Preferences and got my company IT desk to unlock my account. After that haven't had any further issues with passwords or logging in after restarts.

FYI we are encountering this exact issue in our environment using Enterprise Connect, so there's no improvement to be had there.

The only thing Enterprise Connect improves in this situation is telling me that my account is locked out. Very handy.

I'm wondering if Enterprise Connect is the culprit. After my account is unlocked, EC needs me to re-enter my password to successfully authenticate. Anyone seeing this NOT using Enterprise Connect?

No Enterprise Connect here. I'm not even signed into iCloud (anymore) on either of my work 10.12.1 machines. Had a recent lockout after 10.12.1 update. Reminds me of previous OS X versions (e.g. 10.8.x) where ratio of passwords sent exceeded password attempts.

@grahamfw I am not using enterprise connect and the issue is consistently repeatable in our environment where Macs are bound directly to AD and users have mobile accounts on those Macs. As I understand the issue from our Apple engineering contact, and as some on this thread have indicated - the problem is that iCloud and several other system events in Sierra throw multiple local incorrect password attempts. These local failed password attempts end up having the domino effect locking out accounts that have failed password attempt policies associated with them - those password attempt policies could just be local (from a config profile), or directory based via Open Directory, Active Directory, Enterprise Connect, etc.

@jasonaswell Thanks for the info. Is everyone who is seeing this also seeing it where the logins are cached? We have 802.1x network profiles that are available at the login screen, so I'm just curious if this affects everyone with AD -based mobile accounts, or just those with network configs available at the login screen.

I'm pretty sure I'll be on a firstname basis with our help desk before this is all over. Sigh.