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).
Solved! Go to 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!
@markdmatthews and I have spent the past couple of days troubleshooting this exact issue. Our experience and environment:
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:
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.
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.
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.
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!)
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.
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:
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.
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!
@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.
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.
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.
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.
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!
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 ;)
@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.