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

[philburk]

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

[mlavine]

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

[acaruso]

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.

[andyinindy]

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

[philburk]

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.

[mrice]

any one tried to replicate on 10.12.2 b1?

[mlavine]

bump Anyone seeing this issue continue in the new betas?

[andyinindy]

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

[NowAllTheTime]

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.

[andyinindy]

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

[Njofrekk]

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.

[mrice]

10.12.2 beta 2 out. fingers crossed this fixes it.

[mrice]

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

maybe beta 3...

[andyinindy]

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?

[Kaltsas]

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.

[dpodgors]

We got locked out during the install of 41b.

[andyinindy]

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

[symbolic78]

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

[mscottblake]

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.

[donmontalvo]

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.

[sean_pascual]

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.

[mattpogue]

Hello all. I have a couple of observations to add, as well as a configuration change that I made yesterday that has resulted in over 24 hours without a lockout (knock on wood!).
My configuration: MBP (Retina, 15-inch, Mid 2015), running 10.12.2 Beta (16C41b). Machine is AD-bound to my organization's Active Directory domain.

My Sierra experience: I don't use iCloud; however, I was signed into the App Store when I performed the initial Sierra upgrade and the account lockouts began almost immediately after the upgrade was finished. My account gets locked out on average between 3 - 5 times/day. I have our helpdesk on speed dial and I've called so many times that when they see my extension, they unlock my account before they answer the phone :-P

I've been following this thread and one other at https://discussions.apple.com/thread/7617617, as these are really the only two sources of information on this issue that I've found. Getting right to the point: after scouring my syslog and Diagnostic Logs looking for any scrap of usable information, the only commonality that I've been able to find is that it seems that my account lockouts are frequently related to locking/unlocking my machine. I had one of our domain admins configure a text message alert whenever my account gets locked out and oddly, my account will frequently lock immediately after locking the screen; well before I come back and attempt to unlock it. Btw, my organization's domain is set to 5 bad passwords attempts before lockout. So yesterday, I configured my machine so that a password is not immediately required to unlock, by doing the following:

1. Go to System Preferences > Security & Privacy > General tab
2. Check "Require password <x> after sleep or screen saver begins" and set the dropdown to something other than "immediately" (which was my previous setting). In my case, I set it to "1 hour" as I'm rarely away for longer than an hour. The point of making this change was to set it to a high enough value so that I would rarely be prompted for the password; so far, the only time I've been prompted was after lunch and after one overly long meeting.

Results: So far, I've gone 27 hours without a lockout which hasn't happened ONCE since my initial Sierra upgrade.

DISCLAIMER: Is this secure? Definitely and absolutely not. When you "lock" your screen, with this setting enabled, obviously it is not actually locked, so this is the equivalent of walking away from your system and leaving it unlocked for all the world to see (and use), and I certainly am NOT recommending this change for everyone. Your IT admins and security staff will NOT appreciate this setting being changed and you may be violating company policy by changing it. In my case, the change is only temporary, made in an attempt to isolate and identify this particular issue and won't be usable as a long-term (or even short-term) fix, but might help to identify the root cause of the problem.

All that being said, my hope is that there might be others on the thread who were in a position to try this setting change and report on their results. I will report back with an update tomorrow on my lockout situation.

Thank you to everyone who has invested time and energy researching and providing information on this issue so far! As someone mentioned previously, if Apple won't fix the issue, then we as the community might be able to.

[jalcorn]

Well this is now the spot I will be looking every moment of the day now. This is an issue I'm seeing a lot our macs. Seeing disabling or killing the kerbos tickets seems to work sometimes. But no real fix so far.

[jnameth]

The post by mattpogue is almost exactly spot on from what I am seeing in my environment. I'm going to look at implementing similar changes here for some users and will report back on the results.

[mattpogue]

Hello gang, and Happy Friday! I wanted to provide an update to my previous post.

Although it didn't show up in the forums until Friday morning due to moderation delay, my original post was posted on late Thursday afternoon (11/10). At that point, I had gone approximately 27 hours without a lockout after making the change described in my post.

As I sit writing this post at 6:20 PM CST on Friday (11/11), I can now officially say that I've gone for 50+ hours without an account lockout! I'm still configured with no password on the screen saver, and as I mentioned, I can't keep this fix in place forever, but I'm going to keep it enabled for at least the first few days of next week so that I can provide a final report. Also, I'm going to find out if my employer has any kind of Apple Support available and if so, I will open a case.

I'm definitely curious to hear from others who are in a position to implement the change. I'll update you all again early next week (Monday or Tuesday) with results, but I'm almost 100% certain the setting that I have now will prevent the lockouts for me. I'm going to change the "1 hour" setting value to something a bit more conservative, like "1 minute" or "5 minutes" to see whether I can confirm my hypothesis, which as of now is that the lockouts occur when the Mac enters "password protected screensaver mode".

Thanks all and have a great weekend!

Matt

[Aaron]

That's really not an option for me in our environment, so I'll hold out and see what happens. At the moment I'm simply restricting upgrades to Sierra, but this won't be an option soon with new devices being ordered.

Thanks for looking into it!

[mrice]

any change in beta 3?

[Njofrekk]

@mattpogue Your bad password count will raise when locking and unlocking (logging in/out) of your Mac. We are certain of that. In my company and I believe in many others, the option of leaving an unlocked computer is out of the question for security reasons. It seems your password policy is set up to lock you out for as little as 2-3 bad password counts. You might want to suggest to your IT Dept to raise the count to 5-10 and that will stop your constant lockouts while locking/unlocking your Mac.
Cheers.

[troy]

Still showing the same behavior in Beta 3 build 16C48b

[jcwoll]

I've unbound my Mac from our domain, and I have not had a lockout since. Just FYI. I'm going the bind-less route either way for our Macs. Maybe this would be other people who are experiencing this issue in the meantime, unless you absolutely NEED to be bound to your AD.

[jalcorn]

Yeah not being bound would fix it. But we can't have that in our environment.

[dgreening]

In our environment all Macs MUST be bound to AD, so the "lose the bind" refrain that we have been hearing isn't going to fly. Unless Apple is officially deprecating support for AD binding, they need to get on fixing this. I am going to be so pissed off if 10.12.2 comes out without a fix.

[philburk]

I just want to reiterate that this issue also affects Macs that are not bound to Active Directory but that have a password policy set by Configuration Profile and/or pwpolicy. The common thread is being logged into iCloud. We have discovered that users that do not log into iCloud don't get locked out.

Those of you binding to Active Directory might want to see about restricting iCloud logins.

[donmontalvo]

;-)

https://www.jamf.com/jamf-nation/discussions/21320/sierra-ad-account-lockout-when-setting-up-icloud#...

[perrycj]

We've opened a case with Apple Enterprise Support as well and they had me run this command from a local account once the AD account was locked out:

dscl . -readpl /Users/username accountPolicyData failedLoginCount

For me, it was actually returning a value of 0, even though the AD account was definitely locked out in the AD console and unable to login on the Mac.

Just wanted to pass this along. And this is on Beta 3 Build 16C48b, most recent beta build as of this post.

[mrmac]

We are also getting locked out. Generally after a wake from the password protected screensaver. We dont have an AD nor bound to any directory. Local accounts only.

A password config is pushed to the devices with limits on number of failed logins, remembered passwords, min character count etc.

An Applecare enterprise case is open as well as a Jamf ticket at present as devices we were trying to upgrade to Sierra from El Capitan were being locked out after first boot. Device goes past the FV2 password prompt and users normally go straight to the desktop. Users are now seeing a user/password box and any attempt to login advises their account is locked out. Whats strange is the built in admin account is also locked out randomly so we are having to have users go into recovery, unlock their disk with the FV2 password and resetpassword in terminal before we can get them back working.

So two issues we see... one during day to day usage of the device after screensaver lock, the other after the Sierra upgrade!

[gachowski]

@jcwoll

How many mac's do you mange? Collecting data so we can move to local passwords too..

C

[djwojo]

We get 2 bad password counts just from locking the screen.
Bound to AD
iCloud is not signed in
all machines on 10.12.1

[mattpogue]

Good morning all. Wanted to to post a final followup my posts from last week. I can confirm, as tested on my machine and 2 others in my organization, removing the "password protected screensaver" (as described in my first post) fixes the lockout issue in our environment. We have ~80 Macs total, and we have restricted Sierra upgrades for the time being and are rolling back others who had already updated (with the exception of myself and a few others who are beta testers).

I also wanted to reply to the post from @Njofrekk as well. I can confirm that my user account is in an AD OU with a group policy that defines lockout at 7 bad attempts (organization-wide, we're at 5). My team is responsible for AD security and auditing, as well as being the final approval on any security-related group policy changes, so I can 100% confirm that these are our settings. After making the group policy change, the lockouts DID occur less frequently, but I was still being locked out between 3 and 5 times daily. Simply locking the screen and walking away starts generating failed login attempts. And I can also confirm that the issue is NOT resolved in 10.12.2 beta 3 (16C48b).

As I mentioned before, this is NOT a workable fix for any organization (including my own!) that cares even modestly about security, nor was it intended as a recommendation. My goal was to try and isolate the problem definitively to the screensaver and, for the machines I've tested on, I can confirm the screensaver as being the source of our lockouts. Fortunately for us, the majority of our Mac users are developers and sys/net admins, with the other 99.5% of our user base on Windows.

I realize that from a percentage standpoint, the number of Macs bound to Active Directory is probably small. However, we spend a crap-ton of money with Apple on an annual basis and to have an issue of this magnitude go unaddressed is very frustrating. Does anyone have a positive response from Apple Care regarding this issue, in terms of acknowledging that it exists and/or working on a fix? Maybe I missed it, but I've yet to see anyone post an official response from Apple about the issue.

In the meantime, I have no choice but to revert back to the password-protected screensaver and deal with the lockouts. As frustrating as it is, I still prefer my lovely and shiny MBP to my dark matte Lenovo for day-to-day usage, so I'll suffer through. I'll be continuing to monitor the thread and if I come across anything new, you all will be the first to know ;)

[Njofrekk]

@mattpogue Why do you guys use password protected screensavers? I understand it might be practical for locking your Mac but why not just going to Login Window and logging off? That option raises bad pwd count by 1 but it does it only once and when you log back in it clears the badpwdcount attribute. We use the Login Window option and we never get locked out with a password lockout policy setting at 5.
And thank you for your contribution to the investigation of this issue. This has been bugging us since we first encountered this issue and finally there is a community working to pinpoint the problem.
Cheers to all.