Cannot use Windows session credentials when logging into vCenter

[ephracis]

Hi,

We have an Active Directory domain based on Server 2008 R2. I have successfully deployed a vCenter Server Appliance and joined the domain with it. I also added both forward and reverse lookup records in the DNS and I can see all users and groups when I manage my permissions in vCenter. Logging in to vCenter using a domain account also works fine if you type in the username and password.

The problems starts when I try to check the box "Use Windows session credentials". If I then click on login I get an IDM error. The exact error in the log file /var/log/vmware/sso/vmware-sts-idmd.log is the following:

I really need to get this working, typing in the username and password is not an option unfortunately. We really need "Use Windows session credentials".

ERROR [IdentityManager] Failed to authenticate principal [sspi] for tenant [vsphere.local]

I have setup a test environment with a single domain controller, a client and vcsa. There it works fine. So it is something in our existing domain. But I cannot figure out exactly what it might be. I have tried to disable all security policys, firewalls, etc. It seems to me that it tries to auth as some sspi account. To the best of my knowledge this account does not exist, so it should fail. In my test environment wiith mostly default configurations I don't see any trace of "sspi" in the logs.

Any ideas on how to proceed troubleshooting this?

Thanks!

[vmroyale]

Have you set the default domain, as described here?
vSphere 5.5 Documentation Center

[ephracis]

Yes we have. Still get the same error.

[bayupw]

Which vCenter server version are you using?
Check below KBs see if you are experiencing same issues:

VMware KB: Logging into vCenter Server 5.1 or 5.5 using the "Use Windows session credentials&qu...

VMware KB: Unable to log in to VMware vCenter Server Appliance with the Use Windows session credenti...

VMware KB: Unable to log in to vSphere Client using Windows Session Credentials with an account with...

VMware KB: Logging into VMware vCenter Server using Windows session credentials fails if VMware vCen...

[ephracis]

We are using vCenter Server Appliance 5.5.0.10000 (downloaded the OVF last week).

I have checked all those KB articles and where applicable followed the suggestions for fixing the issue. But I still get the IDM error and the logs indicate that SSO tries to find sspi in vsphere.local. I do not see this in the logs of the environment where it works.

[SanjaySP1]

hi,

May I know the option which you selected when adding the identity source ?

If you had chosen 'Active Directory as an LDAP Server', Can you try re-adding domain using 'Active Directory (Integrated Windows Authentication)' option and see if the issue persists.

[ephracis]

I am using the latter: Active Directory (Integrated Windows Authentication).

I have done some more research and I now have a client where I can login (call it Client A) and one where it doesn't (call it Client B). One caveat is that, while it works on Client A, it always fails one time after each reboot. All subsequent logins are successful, though. Logging in from the domain controller gives the same error as on Client B.

I have found an interesting difference on the log files on the vcenter server, inside /var/log/vmware/sso/vmware-identity-sts.log. When logging in from Client A I see

SOAPHeadersExtractor] Encountering node {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp searching for {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp

SOAPHeadersExtractor] Encountering node {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp searching for {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}UsernameToken

SOAPHeadersExtractor] Encountering node {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp searching for {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}BinarySecurityToken

SOAPHeadersExtractor] Encountering node {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp searching for {urn:oasis:names:tc:SAML:2.0:assertion}Assertion

SOAPHeadersExtractor] Encountering node {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp searching for {http://www.w3.org/2000/09/xmldsig#}Signature

SOAPHeadersExtractor] Searching for Action in http://www.w3.org/2005/08/addressing namespace.

XMLSignatureValidator] Inside XMLSignatureValidator

StsServiceImpl] Start handling 'challenge' request

StsServiceImpl] Extracted tenantName from request: vsphere.local

UNTAuthenticator] Authenticating by UNT...

UNTAuthenticator] No UNT found!

SamlTokenAuthenticator] Authenticating by Assertion...

SamlTokenAuthenticator] No assertion found in the request.

BETAuthenticator] Authenticating by BET...

BETAuthenticator] Authenticated principal: {Name: XXX, Domain: XXX} at time XXX

BSTAuthenticator] Authenticating by BST...

STSImpl] Authenticated principal: {Name: XXX, Domain: XXX} at time XXX

But in Client B I instead see this

SOAPHeadersExtractor] Encountering node {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp searching for {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp

SOAPHeadersExtractor] Encountering node {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}UsernameToken searching for {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp

SOAPHeadersExtractor] Encountering node {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}BinarySecurityToken searching for {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp

SOAPHeadersExtractor] Encountering node {urn:oasis:names:tc:SAML:2.0:assertion}Assertion searching for {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp

SOAPHeadersExtractor] Encountering node {http://www.w3.org/2000/09/xmldsig#}Signature searching for {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp

SOAPHeadersExtractor] Encountering node {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp searching for {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}UsernameToken

SOAPHeadersExtractor] Encountering node {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}UsernameToken searching for {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}UsernameToken

SOAPHeadersExtractor] Encountering node {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}BinarySecurityToken searching for {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}UsernameToken

SOAPHeadersExtractor] Encountering node {urn:oasis:names:tc:SAML:2.0:assertion}Assertion searching for {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}UsernameToken

SOAPHeadersExtractor] Encountering node {http://www.w3.org/2000/09/xmldsig#}Signature searching for {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}UsernameToken

SOAPHeadersExtractor] Encountering node {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp searching for {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}BinarySecurityToken

SOAPHeadersExtractor] Encountering node {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}UsernameToken searching for {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}BinarySecurityToken

SOAPHeadersExtractor] Encountering node {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}BinarySecurityToken searching for {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}BinarySecurityToken

SOAPHeadersExtractor] Encountering node {urn:oasis:names:tc:SAML:2.0:assertion}Assertion searching for {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}BinarySecurityToken

SOAPHeadersExtractor] Encountering node {http://www.w3.org/2000/09/xmldsig#}Signature searching for {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}BinarySecurityToken

SOAPHeadersExtractor] Encountering node {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp searching for {urn:oasis:names:tc:SAML:2.0:assertion}Assertion

SOAPHeadersExtractor] Encountering node {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}UsernameToken searching for {urn:oasis:names:tc:SAML:2.0:assertion}Assertion

SOAPHeadersExtractor] Encountering node {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}BinarySecurityToken searching for {urn:oasis:names:tc:SAML:2.0:assertion}Assertion

SOAPHeadersExtractor] Encountering node {urn:oasis:names:tc:SAML:2.0:assertion}Assertion searching for {urn:oasis:names:tc:SAML:2.0:assertion}Assertion

SOAPHeadersExtractor] Encountering node {http://www.w3.org/2000/09/xmldsig#}Signature searching for {urn:oasis:names:tc:SAML:2.0:assertion}Assertion

SOAPHeadersExtractor] Encountering node {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp searching for {http://www.w3.org/2000/09/xmldsig#}Signature

SOAPHeadersExtractor] Encountering node {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}UsernameToken searching for {http://www.w3.org/2000/09/xmldsig#}Signature

SOAPHeadersExtractor] Encountering node {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}BinarySecurityToken searching for {http://www.w3.org/2000/09/xmldsig#}Signature

SOAPHeadersExtractor] Encountering node {urn:oasis:names:tc:SAML:2.0:assertion}Assertion searching for {http://www.w3.org/2000/09/xmldsig#}Signature

SOAPHeadersExtractor] Encountering node {http://www.w3.org/2000/09/xmldsig#}Signature searching for {http://www.w3.org/2000/09/xmldsig#}Signature

SOAPHeadersExtractor] Searching for Action in http://www.w3.org/2005/08/addressing namespace.

XMLSignatureValidator] Inside XMLSignatureValidator

XMLSignatureValidator] Found signature XXX

SignatureValidator] Found KeyInfo

SignatureValidator] Found SecurityTokenReference

SignatureValidator] Found reference with URI: #XXX

SignatureValidator] Get signing certificate

XMLSignatureValidator] Signature XXX is valid

StsServiceImpl] Start handling ‘issue’ request

StsServiceImpl] Extracted tenantName from request: vsphere.local

StsServiceImpl] Extracted saml token:[(NULL)]

StsServiceImpl] Found JAXB ActAs entity - null

StsServiceImpl] Get STS for tenant: vsphere.local

STSImpl] issue() token

STSImpl] Validation of request

STSImpl] The request received is valid from XXX till XXX and now is: XXX

UNTAuthenticator] Authenticating by UNT…

UNTAuthenticator] Starting to authenticate principal: sspi

IDM rejected authentication by UPN

…CRASH…

(I have truncated/removed some parts of the logs like dates and stuff)

It seems that the failing client finds more soap stuff than the other client and decides to authenticate using UNT which crashes, while the client where it works instead doesn't find UNT and decides to authenticate using BET which succeeds.

I have no clue as to what the differences between the machines are when it comes to settings and configurations. They both run the same OS and have the same packages installed. Any ideas on how to proceed researching this issue?

Oh, and one last note: the environment has no Internet connection.

EDIT: I should also add that everything above the log snippets are the same in both situations.

[ephracis · Accepted solution]

I have found the culprit.

It seems vCenter needs NTLM in order to work. Two local security policies caused errors to occur. When Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers and Network security: Restrict NTLM: NTLM authentication in this domain inside Local Policies > Security Options are both set to Deny All we see this error.

Hopefully this can help someone else. It took a while to troubleshoot. 🙂