Active Directory Error Types: Kerberos Client Credentials Revoked

Kerberos authentication failures in Active Directory tend to follow a predictable pattern, and the error code tells you exactly where to look. This reference walks through the three codes you will most often encounter (5be, 775, and 18), how AD tracks lockout state, and the steps to confirm whether the problem is a locked account or a stale keytab.

How AD Tracks Account Lockout

A principal entry in Active Directory keeps three pieces of state related to account lockout:

• The time of last successful authentication
• The time of last failed authentication
• A counter of failed attempts

The last-successful-authentication timestamp is not strictly required for the lockout mechanism to function, but it is useful for administrative auditing. The lockout policy (threshold, duration, and observation window) is defined at the domain or fine-grained policy level.

Error Codes to Watch For

If you see 5be events piling up in the Security log (Event ID 4740), the account will hit the lockout threshold and subsequent attempts will return 775. A revoked keytab or a principal whose key has been reset on the KDC will surface as error 18.

Quick Troubleshooting Steps

1. Check the AD Security log for Event IDs 4740 (account locked) and 4741 (account unlocked) around the time of the failure.
2. Confirm the keytab file on the client matches the current key version in AD (klist -kt /path/to/keytab).
3. If the keytab is stale, regenerate it with ktpass or the AD “Kerberos” tab and redeploy.
4. Verify the SPN is registered to the correct account and that no duplicate SPNs exist.
5. After unlocking the account, test with kinit before restarting the service.

Reference

• MIT Kerberos 5 Admin Guide - Account Lockout

• Security
• Technology
• How-To

• Active-Directory
• Kerberos