Troubleshoot Issues with Kerberos
The following resources can help you troubleshoot time synchronization and other Kerberos issues:
- Kerberos Authentication Tools and Settings
- Authentication Errors Caused by Unsynchronized Clocks
- Kerberos Technical Supplement for Windows
- Troubleshooting Windows Server Issues (including Kerberos errors)
The following topics can help you address common issues related to Kerberos and AD Bridge Enterprise.
When an AD computer account password changes two or more times during the lifetime of a domain user's credentials, the computer's entry that matches the Kerberos service ticket is dropped from the Kerberos key table. Even though the service ticket has not expired, an action that depends on the entry, such as reading the event log or using single sign-on, will fail.
To avoid issues with Kerberos key tables, keytabs, and single sign-on, the computer password expiration time must be at least twice the maximum lifetime for user tickets, plus a little more time to account for the permitted clock skew.
The expiration time for a user ticket is set by using an Active Directory Group Policy setting called Maximum lifetime for user ticket. The default user ticket lifetime is 10 hours; the default AD Bridge Enterprise computer password lifetime is 30 days.
The computer account password can change more frequently than the user's AD credentials under the following conditions:
- Joining a domain two or more times.
- Setting the expiration time of the computer account password Group Policy setting to be less than twice the maximum lifetime of user tickets.
For more information, please see the AD Bridge Group Policy Administration Guide.
- Setting the local machine-password-lifespan for the lsass service in the AD Bridge Enterprise registry to be less than twice the maximum lifetime for user tickets.
If a computer's entry is dropped from the Kerberos key table, you must remove the unexpired service tickets from the user’s credentials cache by reinitializing the cache. Here is how:
On Linux and Unix, reinitialize the credentials cache by executing the following command with the account of the user who is having the problem:
On Mac, you must run both the native kinit command and the AD Bridge Enterprise kinit command with the account of the user who is having the problem. You must run both commands because the native ssh client uses the native credentials cache while the AD Bridge Enterprise processes, such as those that access the event log, use the MIT credentials cache: