KDC has no support for encryption type (14)
This morning was like every morning, everything up and running and had good cup of coffee. All VMware components worked fine.
After that I went to a meeting, had some talk with colleagues and came back to my workplace. Mmm a colleague tells me that he can’t login to vCenter anymore, we have 2 seperate vCenters in 2 diffent datacenters. Somehow he couldn’t login in both vCenters. Strange, as they have very few components shared.
First thing I tought of was authentication, logged in with admin@vsphere.local user in webclient and checked SSO settings. When testing the connection I got an error.
The settings in SSO for LDAP are:
- Reuse session (this was our setting and didn’t work anymore)
- Password (this works with my own user account so AD should be ok?)
- Anonymous (Prohibited error)
So somehow, when I use the option password the authentication to AD is fine, but with reuse session I get an error.
Let’s check the SSO logging :
C:\Program Files\VMware\Infrastructure\SSOServer\logs\imsTrace.log
The errors I found where like:
Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: KDC has no support for encryption type (14))] Caused by: GSSException: No valid credentials provided (Mechanism level: KDC has no support for encryption type (14))
So let’s ask the security team if happened something in the time I had a meeting.
“Uh yes we upgraded the functional domain level from Windows2003 to Windows2008”
*To be sure I rebooted the vCenters in the meanwhile
Ah so we might have a trigger which caused this issue. When searching the internet I find a similar error messages:
http://visualplanet.org/blog/?p=20
I adviced the security team to restart the Domain Controllers or restart the service. Because the impact of restarting the service is unknown we decided to restart the domain controllers later that evening.
As a workaround I used the SSO “Password” option with a service account to let people login and don’t disturb the backup process.
The day after domain controllers where rebooted, I changed the authentication type back to “Reuse session” and tested the connection….BINGO! Worked again.
The problem was probably like described in the posts, there isn’t much public information on this I could find. Our security team even verified with Microsoft for impact and stuff, but never had this mentioned.
Well took me a few minutes of my day :S