ESXi 6 gss_acquire_cred failed

[unsichtbare]

I am building a vSphere 6 deployment in our QA environment in order to validate this version for production. I have followed all of our standard build procedures so far with no issues.

• I built ESXi using the HP image (diskless install to HP Flash Media)
• I configured NTP
• I joined ESXi to the domain
• I connected "Use Windows session credentials"
• I configured storage (iSCSI SAN)
• I redirected log and scratch to the SAN
• I rebooted the host

Today, I redirected the log files and scratch (per: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=103369...) and on reboot, I can no longer connect using "Windows session credentials." I get a: gss_acquire_cred failed

This is kind-of a big deal to us because, for compliance reasons, we will not be able to validate ESXi 6 unless it is capable of using some sort of directory-based authentication. Our team of admins that has 'root' access is small, nonetheless, we need to be uniquely differentiated from one and other. We can't all simply connect as: root

THX!

-J

[RichardBush]

Hi J,

Could i just confirm, Is this setup a stand alone esxi6 host, VCSA or Windows Vcenter server ?

R

[unsichtbare]

Standalone host. Here are the steps that make this so strange:

1. Diskless install of ESXi 6 using HP Image
2. Static IPv4 & hostname assignment in DCUI - IPv6 disabled as not in use and causing an error when un-configured (required reboot)
3. Login to host using the C# Client as: root
4. NTP configured and tested (ntpq -p), working - time is correct
5. AD joined
6. Successful login to host using the C# Client with "Windows session credentials" option (DOMAIN\user)
7. Configure iSCSI Storage & create VMFS 5 volume
8. Redirect log files to VMFS
9. Redirect scratch to VMFS (required reboot)

At this point, I am unable to login to the host using the C# Client with "Windows session credentials: option. This is where I see the gss_acquire_cred failed.

I can login to the host, however, using manually entered: user@domain.tld

[RichardBush]

Can you check /etc/likewise/krb5-affinity.conf and confirm everything looks correct ? do you have multiple dc's ? (not sure if this is a test lab or not)

Can you confirm you are using the FQDN of the esx host when connecting in the c client.

This error used to occur on 4.1, and the fix was to remove the file host_0 from /scratch/var/tmp but I'm not sure if that exists in 6 as my lab hosts aren't connected to AD.

Let me know.

R

[apendo]

Logging in using Windows credentials is one of the two problems I experience using vSphere Client. I actually have no problem entering Windows credentials manually, it’s the checkbox “Use Windows session credentials” that doesn’t work. See my post: vSphere 6.0 NTP Service and SSO malfunction

The checkbox is working fine from several clients after joining the domain until the host is rebooted. Removing and rejoining the host makes things work again until next reboot.

The scratchdir is set to a folder in the datastore. I also entered the FQDN of our RWDC in UserVarsActiveDirectoryPreferredDomainControllers without any luck. Removing the file /scratch/var/tmp/host_0 doesn’t help either. My /etc/likewise/lib/krb5-affinity.conf looks fine as far as I can tell.

Using the FQDN, host name or IP address makes no difference.

I have multiple DC’s (one RWDC and one RODC). I also have a domain trust. For us, this has been a permanent problem in 4.1, a solvable problem in 5.0 and no problem in 5.5. And now, the problem is back again …

[unsichtbare]

RichardBush wrote:

Can you check /etc/likewise/krb5-affinity.conf and confirm everything looks correct ? do you have multiple dc's ? (not sure if this is a test lab or not)

Can you confirm you are using the FQDN of the esx host when connecting in the c client.

This error used to occur on 4.1, and the fix was to remove the file host_0 from /scratch/var/tmp but I'm not sure if that exists in 6 as my lab hosts aren't connected to AD.

Let me know.

R

Confirmed, all. /etc/likewise/krb5-affinity.conf looks fine and I always use FQDN for everything!

[unsichtbare]

apendo wrote:

Logging in using Windows credentials is one of the two problems I experience using vSphere Client. I actually have no problem entering Windows credentials manually, it’s the checkbox “Use Windows session credentials” that doesn’t work. See my post: vSphere 6.0 NTP Service and SSO malfunction

The checkbox is working fine from several clients after joining the domain until the host is rebooted. Removing and rejoining the host makes things work again until next reboot.

The scratchdir is set to a folder in the datastore. I also entered the FQDN of our RWDC in UserVarsActiveDirectoryPreferredDomainControllers without any luck. Removing the file /scratch/var/tmp/host_0 doesn’t help either. My /etc/likewise/lib/krb5-affinity.conf looks fine as far as I can tell.

Using the FQDN, host name or IP address makes no difference.

I have multiple DC’s (one RWDC and one RODC). I also have a domain trust. For us, this has been a permanent problem in 4.1, a solvable problem in 5.0 and no problem in 5.5. And now, the problem is back again …

We have an almost identical experience through versions! VMware was much more careful with this version than certain previous messes, like 5.1, but it is becoming clear that the initial public release is not ready for prime-time.

I do not believe we will be able to Qualify this for use with all of the oddities we have experienced relating to authentication using AD. We will keep trying anything we can think of, to eliminate the possibility we have made a mistake, or there is a viable workaround. But until then, flakiness in authentication is a no-go!

[RichardBush]

My understanding is that you can authenticate correctly with AD, you are just unable to use Windows Session Credentials?

Could you confirm one thing for me, under host - configuration, DNS and Routing, Host Identification, can you confirm here that the hostname is correct, the domain name is correct (i believe you ve already checked the DNS servers) and the search domains are correct. All this should match up with the FQDN used to connect.

Thanks

[apendo]

Yes, I’m able to authenticate in vSphere Client when entering AD credentials manually. It’s when I activate the checkbox “Use Windows session credentials” I get the error message “A general system error occurred: gss_acquire_cred failed”.

The checkbox works initially after joining the host to the domain but stops working after the host is rebooted. If I remove the host from the domain and then rejoin it, the checkbox works again until the next reboot.

The host name is correct, the domain name is correct and the search domains are correct. They all match up with the FQDN used to connect.

[RichardBush]

Ok, i would suggest raising a case with VMware on this one.

R

[unsichtbare]

Yes, that's probably where we are going. Since this is an installation for Qualification purposes, the intent is "take what you get" and judge its suitability for use on Production systems. I believe we will be waiting for the first major update (and 30-60 days of re-Qualification) to move to vSphere 6 in production.

If I were to guess, developers at VMware are under tremendous pressure not to release 3 major upgrades within the first 30-days of public release. The way they beta'ed this one and waited for release, I imagine they expected things to be nearly perfect!

[kirandadmin]

I have a workaround !!

Just uncheck the option "Use Windows Session Credentials" and login to VC.

Kiran Kollipara

kirandadmin@gmail.com

[complexxL9]

I have very similar situation, configured NTP, joined to domain, everything was working fine until reboot. Now when trying to use windows session credentials this error pops up: gss_acquire_cred failed.

ESXi 6.0.0

[goadeff]

See https://kb.vmware.com/kb/2120522

Update ESXi

Leave/rejoin ESXi to domain

"Cannot complete login due to an incorrect username or password" after all this? Try manually typing in DOMAIN\username and password--if that doesn't work, you need to add AD group to ESXi esxAdminsGroup as per instructions at https://kb.vmware.com/kb/2075361. Also may need to logout/login again on Windows machine where vSphere client is, to refresh Windows credentials.