Monday, January 31, 2011

ESXi

To follow up on Call "UserDirectory.RetrieveUserGroups" for object "ha-user-directory" on ESXi "" failed.

YEP! Changing the LDAP SSL certificate requirements from "required" to uh.. not.. made the error go away on our domain.

Computer configuration - Policies - Windows Settings - Security Settings - Local Policies/Security Options - Domain Controller: LDAP server signing requirements (None/Require signing/Undefined[which is the same as None])


A quick google search brought up this likewise discussion, where a member of likewise states that they don't support ldaps.


The ticket for me was the "LDAP error code: 8 (Strong(er) authentication required)" line in /host/messages. No verbose logging was required to get to the root of the problem.
Good enough for me and my crew.

Friday, January 28, 2011

ESXi Active Directory Lookup failure

Call "UserDirectory.RetrieveUserGroups" for object "ha-user-directory" on ESXi "" failed.

Wha?

ESXi 4.1.0 v320137, evaluation license

Looks like a known bug: http://communities.vmware.com/message/1688839.

Note my message there at the bottom that says that the actual authentication and user/group add/del works fine... you just have to manually type the users/groups.

Here's my traceback in /host/messages:

Jan 29 00:43:07 Hostd: [2011-01-29 00:43:07.905 FFDC2B90 verbose 'UserDirectory' opID=C6A12DE4-00000176] Searching for LDAP server for AD
Jan 29 00:43:07 Hostd: [2011-01-29 00:43:07.909 FFDC2B90 verbose 'UserDirectory' opID=C6A12DE4-00000176] Using LDAP base dn: DC=ad,DC=mycompany,DC=com
Jan 29 00:43:07 Hostd: [2011-01-29 00:43:07.910 FFDC2B90 verbose 'SysCommandPosix' opID=C6A12DE4-00000176] ForkExec '/bin/kinit', pid 30416, rc 0
Jan 29 00:43:07 Hostd: [2011-01-29 00:43:07.959 FFDC2B90 error 'UserDirectory' opID=C6A12DE4-00000176] LDAP error code: 8 (Strong(er) authentication required)
Jan 29 00:43:07 Hostd: [2011-01-29 00:43:07.959 FFDC2B90 error 'App' opID=C6A12DE4-00000176] Error accessing directory: Can't bind to LDAP server for domain: AD
Jan 29 00:43:07 Hostd: [2011-01-29 00:43:07.959 FFDC2B90 info 'App' opID=C6A12DE4-00000176] AdapterServer caught exception: 68130fd8
Jan 29 00:43:07 Hostd: [2011-01-29 00:43:07.960 FFDC2B90 info 'Vmomi' opID=C6A12DE4-00000176] Activation [N5Vmomi10ActivationE:0x68094b10] : Invoke done [retrieveUserGroups] on [vim.UserDirectory:ha-user-directory]
Jan 29 00:43:07 Hostd: [2011-01-29 00:43:07.960 FFDC2B90 verbose 'Vmomi' opID=C6A12DE4-00000176] Arg domain:
Jan 29 00:43:07 Hostd: "AD"
Jan 29 00:43:07 Hostd: [2011-01-29 00:43:07.960 FFDC2B90 verbose 'Vmomi' opID=C6A12DE4-00000176] Arg searchStr:
Jan 29 00:43:07 Hostd: ""
Jan 29 00:43:07 Hostd: [2011-01-29 00:43:07.960 FFDC2B90 verbose 'Vmomi' opID=C6A12DE4-00000176] Arg belongsToGroup:
Jan 29 00:43:07 Hostd: (null)
Jan 29 00:43:07 Hostd: [2011-01-29 00:43:07.960 FFDC2B90 verbose 'Vmomi' opID=C6A12DE4-00000176] Arg belongsToUser:
Jan 29 00:43:07 Hostd: (null)
Jan 29 00:43:07 Hostd: [2011-01-29 00:43:07.960 FFDC2B90 verbose 'Vmomi' opID=C6A12DE4-00000176] Arg exactMatch:
Jan 29 00:43:07 Hostd: false
Jan 29 00:43:07 Hostd: [2011-01-29 00:43:07.960 FFDC2B90 verbose 'Vmomi' opID=C6A12DE4-00000176] Arg findUsers:
Jan 29 00:43:07 Hostd: true
Jan 29 00:43:07 Hostd: [2011-01-29 00:43:07.960 FFDC2B90 verbose 'Vmomi' opID=C6A12DE4-00000176] Arg findGroups:
Jan 29 00:43:07 Hostd: true
Jan 29 00:43:07 Hostd: [2011-01-29 00:43:07.960 FFDC2B90 info 'Vmomi' opID=C6A12DE4-00000176] Throw vmodl.fault.SystemError
Jan 29 00:43:07 Hostd: [2011-01-29 00:43:07.960 FFDC2B90 info 'Vmomi' opID=C6A12DE4-00000176] Result:
Jan 29 00:43:07 Hostd: (vmodl.fault.SystemError) {
Jan 29 00:43:07 Hostd: dynamicType = ,
Jan 29 00:43:07 Hostd: faultCause = (vmodl.MethodFault) null,
Jan 29 00:43:07 Hostd: reason = "Error accessing directory",
Jan 29 00:43:07 Hostd: msg = "",
Jan 29 00:43:07 Hostd: }


Also seems from the logs that there's something running in the background using the credentials that added the host to AD for some other lookup. Not sure how I feel about that one.

I'll see if I can devote any more time to this next week. As it is, it just looks to be an obnoxious bug...

Wednesday, January 12, 2011

ESXi log file location

Damned if I had a brain freeze today and couldn't remember the url path where ESXi has it's log files:
https://hostname/host


There.