@jasonaswell So based off your last post, Apple has relayed to you that other system events, not including iCloud, are also throwing the multiple requests which are causing lockouts for accounts?

@perrycj No, I'm sorry I can see how I worded that poorly. Apple has only confirmed to me the issue with iCloud throwing the failed password attempts - they have not confirmed anything regarding other triggers. But myself and others have seen the same issue triggered by other system events such as waking from sleep. I've reported as much to the engineer on my case - but they have only given a concrete response regarding iCloud.

@jasonaswell Ah ok gotcha. Thanks for the clarification. I've read either here in this thread or in other places, that it seems more related to iCloud Keychain. Have you noticed that if you disable iCloud Keychain, this goes away or at least, isn't as frequent? Or, it's just iCloud as a whole.. keychain or not?

@perrycj the lockout occurs for me even before I get to the point of enabling any iCloud services. I provide my iCloud password, then get a pinwheel, then the admin password prompt, at which point I'm already locked out of my account - even before actually entering my admin password.

Once I get past that stage I can turn off pretty much all iCloud services, while still staying logged into iCloud, and several minutes later I'm locked again. Logging out of iCloud altogether decreases the frequency of lockouts, but after waking from sleep/screensaver my account will sometimes be locked regardless. The only sure fire way I've found to completely avoid the issue is to not use Sierra :/

Everything is peachy on my personal Mac running Sierra at home though! So, I'll feel pretty comfortable making Sierra available in my environment once this is fixed, but for now this is a total deal breaker.

@jasonaswell

@markdmatthews and I have spent the past couple of days troubleshooting this exact issue. Our experience and environment:

• Casper 9.83


• Enterprise Connect 1.6.3


• iCloud use allowed but iCloud Keychain, Drive or Mail are restricted by use agreement


• Passcode policy enforced by Configuration Profile with Maximum number of failed attempts enabled


• Prior to computers enrolling in Casper passcode policy was enforced via pwpolicy. Most clients still have 'pwpolicy –n /Local/Default –setglobalpolicy' (exactly the same as the Config Profile) in settings

Symptoms: Users upgrade to Sierra from El Cap and are logged into iCloud. Computer reboots to login window after upgrade, user enter credentials, progress bar is displayed, after approximately 1/3 of progress user is returned to login window. Subsequent logins are rejected. User is locked out and must reset password from Recovery Volume.

We narrowed it down to an interaction between iCloud and the password policy. The most puzzling part of this problem was that we were thoroughly unable to reproduce the problem reliably. Case in point: this morning we re-imaged a test client to 10.11.6, logged into iCloud, set the password policy via pwpolicy and upgraded to Sierra. Locked out. Tested without the password policy and we were not locked out. Tested one more time with a re-image, iCloud, & the password policy via pwpolicy and did not get locked out, surprisingly.

But oddly after this, since I was using my personal Apple ID, I became locked out on my production MacBook Pro. It went to sleep during our testing and upon waking from sleep I was unable to log in successfully. I immediately jumped into our production Casper environment and excluded my production MBP from the Config Profile with the Passcode payload. Lo and behold, I was able to log in within seconds without having to boot to the Recovery Volume to reset my local password.

We'll be testing more in the morning, specifically with the "maxFailedAttempts" component. So far we've concluded that as a mitigation strategy we have two options: 1. Disable the Password Policy Config Profile in production (not good) or 2. Log everyone out of iCloud by deleting their MobileMe prefs file and lock the iCloud pref pane (also not good). Short of a bug fix from Apple this appears to be our only option.

Oh and for the rest of you having AD lockouts associated with this problem, my previous employer bound all their Macs to AD. I believe that your bound Macs are simply passing the lockout through to the domain. Disable your passcode policy or log people out of iCloud and you should avoid this issue. Good luck with convincing your Domain Admin to do the former, though!

@philburk The general consensus I have heard from other Mac Admins about this issue is that it is being caused by a Kerberos bug. iCloud appears to cause it but upon further testing you will find that even on Sierra machines without iCloud the problem will occur. iCloud just causes the bad password attempts quicker but they will happen even without iCloud enabled.

Hi all, I wanted to chime in here. I've been experiencing this as well. I tried:

Checking "Do not require Kerberos preauthentication" on my AD user account. And then logged back into iCloud on my Macbook and no lockout.

Perhaps someone with better knowledge of Kerberos preauthentication could shed some light on the ramifications of disabling that requirement? Is this a major security issue?

I definitely don't see that as an acceptable fix at this point. I'm advising any early adopters to disable iCloud for the time being.

Interesting @acaruso . Found an old post circa 2013 that mentions Kerberos preauthentication issues preventing AD bind in Mavericks that may be relevant:

https://www.jamf.com/jamf-nation/discussions/8872/can-t-bind-to-ad-in-10-9-mavericks

Apparently disabling IPv6 helped back then; probably not a valid option now, but I'd be interested to test to see whether it helps with the lockouts...

Just to reiterate:

For an environment where clients ARE NOT bound to Active Directory we discovered the following:

If you are logged into iCloud AND if you have are enforcing max Failed Password Attempts via password policy for the client by ANY means (AD, Configuration Profile, pwpolicy command) then you will be locked out. We've been able to unlock accounts by adding an exception for the user to our Config Profile Scoping and re-adding the user will not lock the account again. This only works when you're enforcing password policy via a Config Profile. The only way to recover when password policy is enforced via pwpolicy maxFailedAttempts is to boot to the Recovery Volume and use the reset password utility. I cannot test via AD since we don't bind in our environment. I assume that the mechanism creating the lockout is the same.

We've had success having users log out of iCloud prior to upgrading. FYI, they must do so before going from 10.12.0 to 10.12.1 as the lock out occurs there too.

In short if you can either removing your password policy (pwpolicy, Config Profile, AD) or log the user out of iCloud this lockout shouldn't happen.

any one tried to replicate on 10.12.2 b1?

bump Anyone seeing this issue continue in the new betas?

I can confirm that the issue is still present in the 10.12.2 Beta (16C32e).

Yup, same as @andyinindy, build 16C32e still has the issue. I've notified my AppleCare OS Support engineer (again) to remind them that with new MacBook Pros shipping with Sierra we will not be making any further hardware purchases from Apple until this is fixed; we're not going to pay for systems we can't use.

FYI, just updated to 16C32f and I'm locked out again. The only iCloud-related item that is enabled is Keychain, BTW. Good times.

Finally found a thread that deals with this issue. We've been having this problem since we integrated our Macs into AD back in July/August. This is not an issue that appeared with Sierra. We've had it since the first integration while the Macs were on El Capitan and we still do while on Sierra 10.12.1. The issue appears when we logged in our iCloud accounts or while using Apple ID to approve purchases in App Store even though IDs had nothing similar to the AD accounts and passwords.
Through further research we've gathered that using Apple ID in App Store gets you 2 wrong password attempts, logging out of your network account on Mac gets you 1 bad pwd attempt and logging into your iCloud account gets you instalocked.
Here is a link to the thread I've opened on Apple Communities that apparently gathered zero interest among Apple users.
Active Directory-Apple ID password lockout
Hopefully this gets resolved soon.
Cheers.

10.12.2 beta 2 out. fingers crossed this fixes it.

Apple told me "we are aware that the changes in the current beta do not fix this issue."

maybe beta 3...

Well, well! I just updated to 10.12.2 beta 2 (16C41b) while signed in to iCloud keychain, and I was not locked out of AD! This is a first. I am interested to hear whether others are also seeing this?

I was locked out during the upgrade to 41b and I can still replicate the lockout simply by selecting Account Details in iCloud preference pane.

We got locked out during the install of 41b.

Shit! I just got locked out after opening the account details in iCloud as @Kaltsas mentioned. Back to the drawing board...

First time post here, but thought i'd chime in on this, I'm seeing exactly the same problems, and through testing have found pretty well anything that authenticates against icloud can cause the issue.

I've blocked iCloud and Internet Accounts from the system preferences pane, but then thought "what about other applications", so signed into facetime with my icloud account and BANG, locked out of my AD account immediately, it seems there are so many routes you can sign in with an icloud account in sierra, trying to stop users locking out their accounts is like playing whack-a-mole (as is trying to stop them upgrading to sierra in the first place!)

I just wanted to chime in that we are seeing the same issues. Since my email address is different, even if my Apple ID has the same password as my AD account, it will lock it out.

Apple recently changed their iCloud policy, so you can't use the same password for iCloud that you use to log on to your computer.

Hi All! Just thought I'd throw in my 2 cents.

I've recently unbound a few of the Sierra users in my company from AD, and while this has reduced the frequency of lockouts, users are still getting locked out. I'm not sure how this is happening since there shouldn't be a connected to our Active Directory server anymore?

Fingers crossed that 10.12.2 fixes this issue.