Skip to main content

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

Good evening guys! I have been following this thread for about a month. I've tried everything I could to stop the lockouts and I may have finally found something that works(at least for me). I have disables the 2 form authentication on iCloud and so far no lockouts. I won't know for sure if this is a fix until I get to work tomorrow and I see how my mac mini is behaving without this extra layer of security. I will keep everyone posted! Again thanks for all of the efforts and trial and errors in this thread! It has given me hope!

Beta 5 anyone? Haven't had a chance to test it myself yet.

Beta 5 still has the issue. Put my machine to sleep and it registered to bad password counts in AD.

Curious if anyone is seeing AD lockouts on Late 2016 MacBook Pros stemming from the use of TouchID in Sierra? We have a small pilot group of about ~5 of these new Macs and they're locking out pretty routinely when our testers use TouchID to unlock their Mac, or to exit pw-protected screensaver. Seems similar to the locks we've been seeing with watch unlock, potentially the same workflow is broken in the OS and it's sending 3 bad password attempts to our AD controller? Our Security team's not going to exempt their lock policies, that's for sure.

Yes, I have this issue on late 2016 MacBook Pro with TouchBar. I verify my AD account has 0 bad password attempts, lock my workstation or go to screensaver, then use TouchID to unlock and immediately my account has 2 bad password attempts.



My config is: 10.12.1 on MBP w/ TouchBar, bound to Active Directory, signed into iCloud, with Enterprise Connect 1.6, using AD user account with mobile account. I am only surviving because I unbound from AD. Unbinding immediately stopped the bad password attempts.



Can whoever has an Apple Enterprise Support case open for this issue post an update for the rest of us?

Sure I verified beta 5 still has this behavior, sent a note off to Applecare. And this is the meat of the response.
.
.
.
.
.
¯_(ツ)_/¯

We have had this issue in our environment since users started upgrading to Sierra during the Dev beta. Looking at system logs, this is all related to Kerberos preauthentication.



I have a test machine where I did a fresh install of Sierra, and then bound it to our domain. I then took a suggestion from this thread, which is enable "this account supports Kerberos AES 128/256 bit encryption" on the account. This resolved my issue, and then I enabled iCloud on the computer. Because I update my passwords frequently, my AD and iCloud password are currently the same. I know this isn't a best practice, however with both passwords being the same, I am no longer receiving Kerberos Preauthentication lockouts in our logs.



My manager then upgraded his laptop to Sierra for testing. He has iCloud enabled and his passwords are separate. He is continuing to experience Kerberos pre-authentication lockouts.



This is what one of these kerberos preuauthentication errors look like in our Splunk logs. We track the events that happen on our domain controllers. I will be omitting any confidential/identifying information, but this log may help us determine the cause of this issue. I would love to supply this information to Apple myself, however I do not have any sort of enterprise support with Apple. 



12/05/2016 01:39:21 PM

LogName=Security

SourceName=Microsoft Windows security auditing.

EventCode=4771

EventType=0

Type=Information

ComputerName=[REDACTED DOMAIN CONTROLLER ADDRESS]

TaskCategory=Kerberos Authentication Service

OpCode=Info

RecordNumber=586425209

Keywords=Audit Failure

Message=Kerberos pre-authentication failed.



Account Information:

    Security ID:        [REDACTED DOMAIN URL][REDACTED USER NAME]

    Account Name:       [REDACTED USER NAME]



Service Information:

    Service Name:       krbtgt/[REDACTED DOMAIN URL]



Network Information:

    Client Address:     10.10.113.75

    Client Port:        59033



Additional Information:

    Ticket Options:     0x40000000

    Failure Code:       0x18

    Pre-Authentication Type:    2



Certificate Information:

    Certificate Issuer Name:        

    Certificate Serial Number:  

    Certificate Thumbprint:     



Certificate information is only provided if a certificate was used for pre-authentication.



Pre-authentication types, ticket options and failure codes are defined in RFC 4120.



If the ticket was malformed or damaged during transit and could not be decrypted, then many fields in this event might not be present.

I started getting reports of this issue in my org, so I opened up a case today referencing this thread and the other cases listed by @jasonaswell and @andyinindy . Here's my case: 100083504482

I noticed this issue when using an apple watch to auto-unlock my macbook pro, after unlocking it with my watch 3 times in a row (our account lockout threshold) it would lock my AD account. The only authentication attempt shown in AD was a "Kerberos Pre-Authentication Failed" entry, so as a workaround I selected the "Do not require Kerberos preauthentication" option for my account in AD under Account Options on the Account tab. This prevents me from being locked out when unlocking my computer with my apple watch.



We only have a few Mac users that this issue applies to, so it works as a temporary workaround, but we are still awaiting an official fix.

Received this update this morning on my open case with Apple:



Our Product Engineering team is currently working on the fix of this issue and once I receive the confirmation from them and the beta version is available for testing, I will followup with you and let you know as soon as possible.


So hopefully soon.

Got the same response yesterday from Apple

Opened a bug report a couple weeks ago and included this Apple forum thread that many of us posted to.

Using Touch ID and "allow to unlock your mac" with the new Machines seems to trigger the same event...



https://www.jamf.com/jamf-nation/discussions/22372/new-mbp-with-touch-id-ad-lockouts

Beta 6 has been released. I will test as soon as it shows up as an available update.

Problem seems to persist in Beta 6 as well. Unfortunate.

Beta 6 locked during the upgrade, locks tickling iCloud. Screen Locks still slowly increment unsuccessful login attempts. No change in behavior. Sent a note off to Applecare.

Apple suggested to me that it would be fixed in 10.12.3, but no guarantee.
My guess would be late Jan.

I had a call with Apple on Friday, and they all but confirmed that 10.12.3 fixes it.

Hmmm...see first line item on the 10.12.2 Combo Update...




  • Improves setup and reliability of Auto Unlock

  • Allows addition of a Chinese Trackpad Handwriting button to the Touch Bar Control Strip

  • Adds support for taking screenshots of the Touch Bar using the Grab app or Cmd-Shift-6 shortcut

  • Fixes an issue that caused the Touch Bar emoji picker to appear on the display

  • Resolves graphics issues on MacBook Pro (October 2016) computers

  • Fixes an issue where System Integrity Protection was disabled on some MacBook Pro (October 2016) computers

  • Improves setup and opt-out experience for iCloud Desktop and Documents

  • Fixes an issue with the delivery of Optimized Storage alerts

  • Improves audio quality when using Siri and FaceTime with Bluetooth headphones

  • Improves the stability of Photos when creating and ordering books

  • Fixes an issue where incoming Mail messages did not appear when using a Microsoft Exchange account

  • Fixes an issue that prevented installation of Safari Extensions downloaded outside the Safari Extensions Gallery

  • Adds support for new installations of Windows 8 and Windows 7 using Boot Camp on supported Macs

Yup, they've made improvements alright. I got my AD account locked right after 10.12.2 update. This is the first time this kind of lockout has happened to my Mac after an OS update.

The fix isn't in 10.12.2. I've been told January and most likely 10.12.3.



Speaking of 10.12.3, the first beta is out now. I'll see if I can test it today for the lockout issue.

@Njofrekk Yup, same here! I had the problem when Sierra first came out and then it mysteriously stopped. I really don't know why it had stopped but just after this update, it came back again. I restarted and it seems to have stopped again for now. Apple really needs to get this figured out...it's maddening to deal with.

macOS 10.12.3 Beta 1 (16D12b) did not lock my test account during the upgrade and I have been rebooting and fiddling with iCloud for 10 minutes with no lockout. There is hope! Also this beta dropped fast after 10.12.2 so maybe it's fast tracked for quick release.

Apple recommended I try this build shortly after it dropped, and now I can also confirm based on my testing that the issue seems to be resolved in 10.12.3 beta build 16D12b. No failed password attempts thrown at login, iCloud Preference Pane sign in, or display lock and unlock. After so many previous beta builds from 10.12.1 through 10.12.2 not making any difference I have to say that I was shocked to see my badPwdCount finally stay at 0.



Nice job Apple; hopefully this stays fixed through production release (fingers crossed emoji).

I can also report the beta seems to have solved my related issue with local password policies. I too was very happy to see failedLoginCount: 0 when I rebooted after the update! Will continue to test, but looking good.

Terms & ConditionsCookie settings