Recently, after several of my users here at Dwolla upgraded to Sierra I began receiving complaints of their accounts being locked out for no apparent or specific reason. In order to investigate this further we implemented a simple script to email our IT team when someone’s account was locked out using a simple PowerShell script that was fired every time the event ID of 4740 on our Domain Controller was triggered.

What we found was, that even though we have multiple domain controllers, the only DC that was firing an account lockout was the primary DC—the PDC emulator (also a kerberos key distribution center).

If a user would type their password incorrectly multiple times, or if Nessus would harass a machine, multiple domain controllers would fire the 4740 event. At this point it was clear, Kerberos problems have reared their ugly head again…

A simple klist -f revealed this on my machine running 10.2:

Credentials cache: API:(removed)
        Principal: koala@OUR.DOMAIN.CONTROLLER
  Issued                Expires             Flags    Principal
Jan  4 12:16:22 2017  Jan  4 22:16:22 2017  FRIA    krbtgt/OUR.DOMAIN.CONTROLLER@OUR.DOMAIN.CONTROLLER

This is what 10.11.6 looks like:

Credentials cache: API:(removed)
Principal: colleague@OUR.DOMAIN.CONTROLLER
Issued                Expires             Flags    Principal
Jan  4 12:55:51 2017  Jan  4 22:55:51 2017  FRIA   krbtgt/OUR.DOMAIN.CONTROLLER@OUR.DOMAIN.CONTROLLER

There’s no difference in flags for Kerberos between these two systems – that’s good. This means that the Kerberos service on the DC is not treating the users differently.

What was the common link between my users and this issue? It appears that iCloud calling for authentication may be the issue as shown by the great folks over at JAMF.

Looking at the system log, iCloud reads a login keychain and a system keychain, then initiates TCP connections to read information from iCloud servers.

In the System log the pieces that interest me are: AuthKit continuation-key token is missing! Account: <private>. Credential: <private>.
"ACDAuthenticationPluginManager: an authentication plugin of class (null) for auth type <private> could not be instantiated! Load Error: (null)"
"The authentication plugin for account <private> could not be found!"

It appears that this is a bug in Apple’s AuthKit.

These messages are repeated many times, and presumably querying our PDC for keys every time for key verification for pre-auth. The issue is that it does not seem to differentiate from my domain login, and my iCloud creds, or at least it triggers an event to auth.

Some proof from Wireshark when I hit the “Account Details” button in the iCloud control panel:

This issue has persisted ever since Mac OS X Sierra was released. 10.12.2 does not fix the issue.

While not an optimal strategy, disabling Kerberos Pre-authentication for each affected user in Active Directory can mitigate the issue.

Hopefully the release of 10.12.3 fixes this issue.

Start building in our sandbox for free, right now. Get a feel for how our API works before going live in production.


Stay Updated