Kerberos authentication using vCenter client does not work when 'Using Windows session credentials'

[degustator]

There's a well-known hint on how to enable Kerberos authentication with VC 2.5. I guess it is also true for vSphere 4. But this doen't work for me.

By default (when Negotate was used) I had autologon (aka 'Using Windows session credentials' aka '-passthroughAuth') working. Then I edited vpxd.cfg to enable Kerberos SSPI and restarted the services. After this autologon no longer works. I receive the following error message:

Cannot complete login due to an incorrect user name or password.

Though I am still able to enter my credentials manually and this works. But I guess that this option still uses NTLM but not Kerberos.

I know that there must be a proper SPN (Service Principal Name) in place for Kerberos to work. I guess vCenter service is supposed to register an SPN by itself. I'd like to check this out and register the SPN manually in case it is missing. But what is Service Class for vCenter? What must the SPN for vCenter look like?

[Texiwill]

Hello,

Moved to VMware vCenter Forum.

Best regards, Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009
Now Available on Rough-Cuts: 'VMware vSphere(TM) and Virtual Infrastructure Security: Securing ESX and the Virtual Environment'[/url]
Also available 'VMWare ESX Server in the Enterprise'[/url]
[url=http://www.astroarch.com/wiki/index.php/Blog_Roll]SearchVMware Pro[/url]|Blue Gears[/url]|Top Virtualization Security Links[/url]|Virtualization Security Round Table Podcast[/url]

[degustator]

Today I installed a brand new vCenter Server in a fresh domain environment and tried this trick once more. No luck... Though I'd like to share some more observations.

1. I enabled “Trivia” logging for vpxd and got a lot of logs. Most of them look pretty understandable. And here's the relevant part about the error:

-

---

2009-10-25 01:38:10.204 02484 trivia 'App' LookupByPrefix: path: /sdk

2009-10-25 01:38:10.204 02484 trivia 'App' LookupByPrefix: currentPath: /sdk

2009-10-25 01:38:10.204 02484 trivia 'App' LookupByPrefix: no match found for: /sdk

2009-10-25 01:38:10.204 02484 trivia 'App' HttpConnection::ProcessRequest: using default handler

2009-10-25 01:38:10.204 02380 verbose 'HttpSvc.HTTPService' User agent is 'VMware VI Client/4.0.0'

2009-10-25 01:38:10.204 02380 trivia 'HttpSvc.HTTPService' User agent 'VMware VI Client/4.0.0' is non-chunking: false

2009-10-25 01:38:10.204 02380 trivia 'HttpSvc.HTTPService' User agent 'VMware VI Client/4.0.0' needs Content-Length: false

2009-10-25 01:38:10.204 02380 verbose 'HttpSvc.HTTPService' HTTP Response: Client: NeedsContentLength: false UnderstandsChunking: true CanKeepAlive: true (PresetContentLength -1)

2009-10-25 01:38:10.204 02380 trivia 'HttpSvc.HTTPService' HTTP Response: SetKeepAlive(true)

2009-10-25 01:38:10.204 02380 trivia 'SoapAdapter' Version URI: urn:internalvim25/4.0

2009-10-25 01:38:10.204 02380 trivia 'SoapAdapter' Using SOAP body handler for version URI urn:internalvim25/4.0

2009-10-25 01:38:10.204 02380 trivia 'SOAP' Received soap request from : loginBySSPI

2009-10-25 01:38:10.204 02380 verbose 'App' Invoking on vim.SessionManager:SessionManager session

2009-10-25 01:38:10.204 04744 info 'App' -- BEGIN task-internal-9 -- -- vim.SessionManager.loginBySSPI -- DCA38B8F-EC5E-4ECD-B0A7-0D00758D709B

2009-10-25 01:38:10.204 04744 error 'App' AcceptSecurityContext failed: (0x80090300)

2009-10-25 01:38:10.204 04744 verbose 'App' Invoke error: vim.SessionManager.loginBySSPI session: DCA38B8F-EC5E-4ECD-B0A7-0D00758D709B Throw: vim.fault.InvalidLogin

2009-10-25 01:38:10.204 04744 verbose 'HttpSvc.HTTPService' User agent is 'VMware VI Client/4.0.0'

2009-10-25 01:38:10.204 04744 trivia 'HttpSvc.HTTPService' User agent 'VMware VI Client/4.0.0' is non-chunking: false

2009-10-25 01:38:10.204 04744 trivia 'HttpSvc.HTTPService' User agent 'VMware VI Client/4.0.0' needs Content-Length: false

2009-10-25 01:38:10.204 04744 verbose 'HttpSvc.HTTPService' HTTP Response: Client: NeedsContentLength: false UnderstandsChunking: true CanKeepAlive: true (PresetContentLength -1)

2009-10-25 01:38:10.204 04744 verbose 'HttpSvc.HTTPService' HTTP Response: Complete (processed 593 bytes)

2009-10-25 01:38:10.204 04744 trivia 'HttpSvc.HTTPService' HTTP Response: Flush(lastBlock = true)

2009-10-25 01:38:10.204 04744 trivia 'HttpSvc.HTTPService' HTTP Response: Setting Content-Length: 593

2009-10-25 01:38:10.204 04744 trivia 'HttpSvc.HTTPService' HTTP Response: Header size is 184

2009-10-25 01:38:10.204 04744 trivia 'HttpSvc.HTTPService' HTTP Response: Writing 777 bytes to stream

2009-10-25 01:38:10.204 04744 trivia 'App' ResponseCompleted(false), request version 272, closeStream false

2009-10-25 01:38:10.204 04744 info 'App' -- FINISH task-internal-9 -- -- vim.SessionManager.loginBySSPI -- DCA38B8F-EC5E-4ECD-B0A7-0D00758D709B

2009-10-25 01:38:10.204 04744 info 'App' -- ERROR task-internal-9 -- -- vim.SessionManager.loginBySSPI: vim.fault.InvalidLogin:

(vim.fault.InvalidLogin) {

dynamicType = <unset>,

faultCause = (vmodl.MethodFault) null,

msg = "",

}

2009-10-25 01:38:10.282 02484 trivia 'ProxySvc Req00006' The client closed the stream, not unexpectedly.

2009-10-25 01:38:12.689 02380 warning 'ProxySvc Req00007' Error reading from client while waiting for header: class Vmacore::SystemException(The specified network name is no longer available. )

2009-10-25 01:38:15.704 02380 warning 'ProxySvc Req00004' Error reading from client while waiting for header: class Vmacore::SystemException(The specified network name is no longer available. )

2009-10-25 01:38:32.861 02380 trivia 'App' Testing connection

2009-10-25 01:38:32.861 02380 trivia 'App' Exiting

-

---

2. And here's one error I receive in Windows Security Event log on the vCenter server during the same login attempt:

-

---

Log Name: Security

Source: Microsoft-Windows-Security-Auditing

Date: 10/25/2009 1:38:10 AM

Event ID: 4625

Task Category: Logon

Level: Information

Keywords: Audit Failure

User: N/A

Computer: <vCenter Server FQDN here>

Description:

An account failed to log on.

Subject:

Security ID: NULL SID

Account Name: -

Account Domain: -

Logon ID: 0x0

Logon Type: 3

Account For Which Logon Failed:

Security ID: NULL SID

Account Name:

Account Domain:

Failure Information:

Failure Reason: An Error occured during Logon.

Status: 0xc000009a

Sub Status: 0x0

Process Information:

Caller Process ID: 0x0

Caller Process Name: -

Network Information:

Workstation Name: -

Source Network Address: -

Source Port: -

Detailed Authentication Information:

Logon Process: Kerberos

Authentication Package: Kerberos

Transited Services: -

Package Name (NTLM only): -

Key Length: 0

-

---

And here goes the interesting part. I googled a bit and found that both 0x80090300 (happened to AcceptSecurityContext) and 0xc000009a (happened to Kerberos) are usually refferred as “SEC_E_INSUFFICIENT_MEMORY” or “STATUS_INSUFFICIENT_RESOURCES” (respectively). Looks somewhat similar, yeah? But how is it ever possible? Both my vCenter Server and AD Domain Controller have 4GB of RAM and do not suffer any performance issues.

[Will_DeHaan]

I have the same issue trying to get VC 4.0U2 to work on W2k8 with kerberos-only in vpxd.cfg

Does anyone know what SPNs should be created?