By: Dwolla,

This blog post comes from John Wood, our Systems Administrator here at Dwolla. When he’s not busy preventing people from smashing their computers against the wall, you can find John fixing his home or playing with his VMWare lab.

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.

Financial institutions play an important role in the Dwolla network.

Dwolla, Inc. is an agent of Veridian Credit Union and Compass Bank and all funds associated with your account in the Dwolla network are held in pooled accounts at Veridian Credit Union and Compass Bank. These funds are not eligible for individual insurance, including FDIC insurance and may not be eligible for share insurance by the National Credit Union Share Insurance Fund. Dwolla, Inc. is the operator of a software platform that communicates user instructions for funds transfers to Veridian Credit Union and Compass Bank.