Sierra AD Account Lockout when setting up iCloud

[NowAllTheTime]

I have an AppleCare enterprise case open for this, but just curious if anyone here is experiencing the same thing:

When you are logged into a mobile account on an AD bound Mac and go to setup iCloud, the currently logged in network account will get locked out as soon as they attempt to provide a password when prompted to provide an admin password to complete the iCloud setup. The iCloud setup will "fail" but then the services seem to work anyway, but then if you unlock the network account it will lock again shortly after that as long as you stay signed into iCloud.

Been seeing this behavior for a few weeks, but wanted to wait until public release to discuss it here. Behavior has persisted through dev preview 8, and both GM builds (the second of which is the same as the final public build released today).

[NowAllTheTime · Accepted solution]

WE DID IT! Finally! I can't believe they actually included details about this bug in the release notes; I thought for sure the issue would fall under the "improves the stability..." umbrella. Thanks to everyone who opened a case and helped bring attention to it!

https://support.apple.com/en-us/HT207462

[dgreening]

"odutil set log debug" and then "/usr/bin/sysdiagnose" after you get locked out, and you will find the SD log in "/tmp".

[pdmay01]

I found that going into Active Directory on the user getting locked out and on the "Account" tab checking to enable "This account supports Kerberos AES 128 bit encryption" and "This account supports Kerberos AES 256 bit encryption" fixed several of our users. But not all. In once case the user has two machines. One no longer locks the account but the other does.

[tep]

We are also seeing this (AD shop, with mobile cached accounts) - and have a case open with Apple. It's pretty inconsistent, in that some people haven't had an issue, and some get locked out regularly. Some have iCloud, and some have never logged in. Looking at the splunk logs, we see "Kerberos pre-authentication failed."

[donmontalvo]

We use LDAP (AD) heavily and binding is a mandate for security/auditing reasons.

No mention of Enterprise Connect on this thread.

I wonder if that's going to be AppleCare Enterprise's solution. ¯_(ツ)_/¯

*20 minutes until touchdown...MSP I will soon be in you. #gogo

[tkimpton]

Log users out of icloud pre upgrade

log out of icloud

#!/bin/bash
# Log out all users from iCloud
ls /Users/ | while read USERS ;
do
if [ -d /Users/$USERS/Library/Preferences/ ];
then
rm /Users/$USERS/Library/Preferences/MobileMeAccounts.plist
fi
done
killall cfprefsd

[mlavine]

@tep I have been seeing a lot of "Kerberos pre-authentication failed" messages as well. Is everyone else seeing these as well?

[tkimpton]

No news from Apple at the moment. This is very frustrating and i thought this was the most stable release.

Apple really have to stop releasing OSes that not 100% ready.

[vyang07]

So on the Windows side using Account Lockout Status, I'm seeing 2 bad password attempts when I put my mac to sleep requiring password log in set to immediately. If I restart my Mac I get 1 bad password attempt. Every now and then I get 3 meaning I get locked out. This will depend on your Lockout Policy. This is happening with other Mac users I support. So if they made a typo entering their password for the first time during the log in window or anywhere else, they get locked out. This is with 10.12 and not signing into iCloud.

I tested this out in 10.11.6 and all looks fine. Maybe this has something to do with this thread.

[Look]

@vyang07 This matches with what I am seeing which is a slight variation on the lockout theme, I frequently use multiple Macs simultaneously and I am sleeping, waking, rebooting them constantly. I have noticed if I use two 10.12 machines simultaneously I get fairly frequent lockouts even without doing anything at all.

[mlavine]

@vyang07 @Look I have noticed this pattern too. Putting my Mac to sleep causes at least one bad password attempt.

@vyang07 What you are seeing is definitely caused by this bug.

[mlavine]

It looks like their is a new beta build of macOS 10.12.1 out today. Can anyone confirm if the issue is fixed?

[NowAllTheTime]

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...

[dgreening]

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).

[joscline]

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

[jhuls]

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

[dpodgors]

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.

[dgreening]

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.

[Kaltsas]

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. _(ツ)_/

[alexjdale]

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).

[donmontalvo]

Is anyone opening an Apple Bug Report on this issue?

[wadc]

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.

[nlj]

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...

[wadc]

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).

[jcwoll]

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.

[Kaltsas]

@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.

[wadc]

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.

[jcwoll]

@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?

[Kaltsas]

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 ¯_(ツ)_/¯

[jcwoll]

@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.

[decibelau]

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.

[philburk]

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

[dgreening]

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

[grahamfw]

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?

[CGundersen]

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.

[NowAllTheTime]

@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.

[grahamfw]

@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.

[perrycj]

@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?

[NowAllTheTime]

@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.

[perrycj]

@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?

[NowAllTheTime]

@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.