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

[mattpogue]

@Njofrekk The main reason I use the screensaver is for convenience; I very frequently have 10 - 12 open programs at any given time and a full log off would force me to close out of everything and re-open when I log back on. Just due to the nature of my job I'm up and down quite a bit so I would be logging off and back on probably 5 or 6 times per day, not including bathroom breaks, lunch, etc. and - especially as it relates to software development, which is not my primary duty, but is something I do on a daily basis - this would be a productivity killer for me.

Something else that's a little different for me - my local failedLoginCount value, obtained my running dscl . -readpl /Users/<me> accountPolicyData failedLoginCount - always shows zero, even when I'm locked out on the domain. I'm not sure why this is, but I've spot checked a few times and it's always been zero.

A big thank you to everyone on this thread and others in the forum; I've picked up quite a few answers from the community here and I really appreciate everyone's professionalism and willingness to work together to resolve issues that come up.

My plans this weekend are to go home and not think about work, computers, account lockouts, or anything else technology-related if at all possible, except for maybe my Netflix subscription. I've had my eye on a new weird alien show on TBS (People of Earth) that looks kind of entertaining, so maybe I'll do a little binge watching. Happy Friday and happy weekend all! :)

[jcwoll]

@gachowski around 1300 for now.

[gachowski]

@jcwoll

Great news : ) thank you : )

C

[Njofrekk]

@mattpogue There is another method of locking your system without losing all your work (which we use) and that is showing the login window, without actually logging out. You can do this by enabling fast user switching in the Accounts System Preferences panel. Click the Login Options button (enter your administrator password to unlock it first) and then select the Enable Fast User Switching option. Once you have fast user switching enabled, you’ll see either an icon or a name in the top right corner of the menubar, depending on what option you chose on the Login Options screen. Click on your name or icon in the menubar and select Login Window from the drop-down menu. The login window will appear. When you log back in, all your applications will be just as your left them.
Sadly there is no shortcut key for this option so you'll have to click every time but it is the best way in my opinion. Try it out.
On another note, using the terminal command (dscl . -readpl /Users/Username accountPolicyData failedLoginCount) returns a value of 1 every time for my network account, even though there is 0 in my badpwdCount AD Attribute. Interesting thing is that locking and unlocking my network account, raises the failedLoginCount of my local Admin account by two. It is currently at 578. It doesn't lock because we don't use local bad password count policy.
Cheers.

[chris206]

I am a business user, but after numerous lockout issues since installing the Sierra GM (3-5+ a day some days) I have found the following to be the most effective (without modifying the 'screen saver' password timing). If the user is running wifi only, then every time they have an event that would potentially lock their computer (shutting the lid, screensaver, etc), just tell them to remember to Turn off the wifi before doing so. Then logon as normal once they are back, and just switch the wifi back on. They wont remember to do this every time (which I can say from personal experience), but if dramatically drives down the amount of lockouts (to zero if perfectly executed, I believe) such that this small hassle is worth not calling the helpdesk repetitively, and stops those particularly pesky 'I just walked into a conference room with my laptop shut and now its locked out when I need to present' moments...

[mattpogue]

@Njofrekk Ah, thank you! I was not even aware that a fast user switching option existed on the Mac! I've been a Linux and Windows guy for a long time but I'm only about 7 months old as a Mac user and I learn something new just about every day :) I re-enabled my password-protected screensaver, which I will avoid using, and instead will now try that option when I'm leaving my desk. I'll give this a shot for a few days and post my results later this week.

[benshawuk]

I can't add to this thread, other than to confirm that we're experiencing the exact same problems in our environment (AD bound macs, mobile accounts, constant lockouts).
Hopefully Apple will fix this bug soon. It's certainly a show stopper for Sierra upgrades.

[djdavetrouble]

Just upgraded my own workstation to prep for Sierra and instant lockout, twice today so far. Going to unbind to survive this week.

[NowAllTheTime]

Latest update from Apple is that they no longer expect a fix to make it into 10.12.2. So, while we're all free to hope against hope and keep testing beta builds, it seems incredibly unlikely that we'll have a fix until after the new year. I've again emphasized to our TAM and several other contacts within enterprise support that we are halting 100% of our Mac purchases until a fix exists - I'm not going to start the clock on warranties for machines that we can't even use in our environment. I've been assured this has the highest level of internal engineering attention possible, but that doesn't really mean anything when we are over two months into production release of Sierra with a bug that renders the OS completely incompatible with our environment. Apple has suggested that in the mean time we can lift our failed password attempt policies on users who are on Sierra machines but doing so would compromise the integrity of our security - which is an absolute non-starter in a healthcare institution. This is so frustrating...

[djdavetrouble]

What is frustrating is the budgetary block for Enterprise Connect. How about a little investment in us, Apple?

The enterprise environment is dominated by Active Directory, everybody knows this. So why yank back the reigns on something that could benefit companies with large fleets of macs existing in an AD environment? You would think they would be begging people to gain any sort of entrenchment or traction in the enterprise environment. Hell, we are the ones that replace computers every 3 years like clockwork.

In the meantime, I enabled 256 bit encryption and no lockouts since my initial setup.

[mlavine]

Thanks for keeping us updated @jasonaswell. I agree with you 100%, it is ridiculous and unacceptable that this bug has not been fixed yet. Apple had better get a fix into 10.12.3.

[Kaltsas]

Agree'd @jasonaswell ,we are a medical institution and I'd be driven out of the building as the devil if I suggested excluding a subset of the population from password policy.

I do feel a little bad for the support person on the other end of my enterprise case who has to deal with my daily barrage of "did you fix it now?" ¯_(ツ)_/¯

[mlavine]

The Mac Admin community to Apple right now about this bug -> Fix it! Fix it! Fix it!

[dgreening]

I wish I could post a message of extreme displeasure in the only language Apple seems to understand these days: EMOJI

[danshaw]

I've been following this thread with great interest as we are close to wanting to deploy the upgrade. Our macs are bound to AD and all are mobile accounts. Screen savers are set to lock immediately. So far we have tested a few users with Sierra (including myself) and we have had no lockout issues since Sierra first came out.

We do have a lockout policy in place, but I need to check with my Windows Admin to see what the threshold is because this issue doesn't seem to be affecting us. ¯_(ツ)_/¯

[gachowski]

@djdavetrouble

Can you provide more info about "budgetary block for Enterprise Connect." without getting your source in trouble?

C

[Kaltsas]

I'm guessing they are referring to the base cost of EC which costs approximately $5500, some bean counters think that's a high cost for something that should be built into the OS. I don't think the cost is particularly high but I do think it should be built into the OS (or MDM framework). We pay (an arguable premium) for macs, we pay for MDM. Oh BTW pay for this other thing too :)

[dgreening]

Pretty sure that has to do with EC being developed and maintained by Professional Services outside of the development teams for OS X/macOS, so there is no official "budget" for EC past what PS allocates inside their group? Thats just speculation from what I have gathered though.

[gachowski]

I was thinking something like this

http://macosxautomation.com/about.html

[dgreening]

Yeah. That doesn't bode well for the future. He says speak up, but I'm not really sure Apple is listening anymore (unless it is blasting out of Beats)...

[vinny83]

Thanks for the updates @jasonaswell and everyone. I've been following this thread for a while now. Like many of you, excluding staff from password policies would be met with a strong no from our InfoSec team and maybe some nerf darts to the head.

I've been running Sierra on my Mac and we've allowed a couple of production users to upgrade but on the basis they disabled 2FA before the upgrade. 2FA isn't required in our environment so thats a blessing for us, but that of course could change any day from the powers above.

[djdavetrouble]

@gachowski Yes what @Kaltsas said, I was talking about the fee from Apple.

[gachowski]

So EC isn't really an "Apple" app : )

Think of it more of an Apple "Enterprise Support or Professorial Services" app. It's my understanding that the Enterprise Support team wrote it to address a client issue and they want to keep supporting the app and to make sure that everyone is using the app correctly that is why there is a small cost.

C

[gachowski]

@jasonaswell

Are you willing to share you case number? I have not opened a ticket yet with Apple and I can "pile on" yours

C

[NowAllTheTime]

@gachowski Sure thing, my case is 100026962372. I also got a notice today that Apple Enterprise Support opened another case under 100078642515, but it's not clear to me why they did this yet since this case number isn't associated with our account.

[gachowski]

Thanks Jason, I have opened a ticket and added you case number. I will keep everyone up to date...

C

[NowAllTheTime]

Our engineer just called me to talk through my testing workflow and to toss some thoughts back and forth about what we are seeing (myself in our production environment, and them in their test setup). So, I know they are actively working on this, and it sounds like they are definitely tying the threads together between customer cases. I can appreciate all of that and am grateful for the work they are doing. I want to make clear here that everyone that I've directly interacted with from Apple is taking this very seriously. My concern mainly lies with the fact that this has gone on for so long and I wonder whether or not the powers that be at Apple are allocating an adequate amount of resources towards solving this. For the sake of my and everyone else's users, I hope a solution turns up soon.

[andyinindy]

FYI @gachowski our case number is:

100057936834

Feel free to add it to your case for impact.

We are working to escalate the severity of our case with Apple; hopefully our combined efforts will be sufficient to get some movement, but I am not holding my breath based on @jasonaswell's post:

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

Cheers,

--Andy

[jonlju]

I am watching this thread as well as we have a handful of users experiencing the very same issue. It's quite annoying.
The Windows event logs from our DCs don't mention the source/caller computer name of the lockout either, just the account being locked out so we know there's something fishy causing this issue as it would otherwise say what computer/device the lock out originated from.

[salvruiu]

Hi everyone,

i'm experiencing a problem that seems similar to the one in this thread. Since i enabled "Allow your Apple Watch to unlock your Mac", my AD account goes locked out every hour. Do you think i need to open another case or is better if i add my questions on existing cases?

[jalcorn]

Yeah i was getting the apple watch thing too. Its a thing.

[rob74lee]

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!

[perrycj]

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

[whaking2k]

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

[Hexley]

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.

[McCabe]

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?

[Kaltsas]

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

[sdamiano]

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.

[Serge]

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

[kmorning]

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.