ESXi 4.1 Diretory Services Authentication failure

[yevk]

Hello,

I've recently installed the 4.1 version of ESXi, now running with the free hypervisor license.

After successfully joining the domain I'm trying to add a permission to a domain object and when selecting the domain name in the source of the object getting the following error: "Call "UserDirectory.RetrieveUserGroups" for object "ha-user-directory" on ESXi "esxi-my-machine-name".domain.com" failed.

The time is synchronized the the computer account for the machine exists. Leaving the domain and joining back works well but the same error, any ideas?

Thank you.

[gdelgado]

Same issue here as well any suggestions?..

Thanks..

[MentholMoose]

Check the computer account in AD and make sure it's not disabled. Also verify the DNS and Routing settings for the ESXi host (make sure the DNS Servers are configured as the DCs, and set the correct Domain). You can also check the Event Log on the DCs to see if there are errors related to the host.

---

Kirk Kosinski

VCP 4, MCITP: EA/VA/EDA7

[gdelgado]

I've checked the DNS and routing also checked the computer account I am able to delete the computer account and rejoin the server to the domain. After a couple of minutes or so the Authentication goes from Active Directory back to Local Authentication. Not sure if this may be something that would be fixed via reboot as this was working before without any issues and I have not updated any packages recently.

[Dave_Mishchenko]

After a couple of minutes or so the Authentication goes from Active Directory back to Local Authentication

Are you seeing a configuration task for this or do you just return to the Authentication Services screen to find it changed back to local?




Dave

VMware Communities User Moderator

Now available - vSphere Quick Start Guide

Do you have a system or PCI card working with VMDirectPath? Submit your specs to the Unofficial VMDirectPath HCL.

[gdelgado]

I go back to the Authentication Screen and see it back to Local Authentication. Even though I see the computer account added to AD and the configuration task completes successfully.

[Dave_Mishchenko]

Take a look through /var/log/messages after you join the domain. It may log why the host is leaving the domain. Is this a fresh 4.1 install or upgrade?




Dave

VMware Communities User Moderator

Now available - vSphere Quick Start Guide

Do you have a system or PCI card working with VMDirectPath? Submit your specs to the Unofficial VMDirectPath HCL.

[gdelgado]

This is a fresh 4.1 install.

[josian25]

I'm having same problem. I think my problem is with our AD | DNS forrest | domains using single-label names. My company implemented a single forrest with multiple child domain trees. On my test lab, I have domain1 as root and domain2 as child, both with single label names. If I joined the ESXi host to domain2, then go to ESX to add a group, I can browse domain1; if I try domain2 fails with above error. I demoted domain2 and ran dcpromo again using a two-name label (i.e. domain2.com) and everything worked fine. I tried to implement this http://support.microsoft.com/?id=300684 but didn't help.

Hopefully someone can point me in the right direction.

[kattrap]

I'm seeing the same message on a fresh ESXi 4.1 (320137) host.

Interestingly I can still add users and groups, I just can't search for them.

When I manually put "user@ad.mycompany" or "AD\groupname" and hit Check Names it will return with nothing. But if I put in a bad username or group "AD\gobbletygook" it will return with an error message (Incorrect group).

So, the auth is working and users/groups added without searching are able to get into the host with the correct privilege level.

Hope that helps someone else who stumbles upon this communities post.

[jkoon]

I opened an SR with VMware on this issue and there is a targeted fix in ESX/ESXi 4.1 U2. The issue was due to single label domain names which is not recommended. There was no workaround provided.

VMware provided these steps for enabling the likewise agents (netlogond, lwiod, lsassd) on ESX/ESXi 4.1

Purpose

Likewise agents are used on ESX/ESXi 4.1 to facilitate joining the host to an Active Directory domain and subsequent user authentication attempts.  By default, none of these agents generate a log file.  These steps will detail how to enable logging for the Likewise agents in the event that advanced troubleshooting of ESX/ESXi Active Directory integration is needed.

Resolution

The netlogond daemon is used to join the ESX/ESXi host to the domain.  If it is not running, the host will not stay connected to the domain and the Authentication Service Settings will revert to Local Authentication.  Attempts to re-connect to the domain will restart the daemon.

To enable logging for the netlogond daemon, use a text editor to modify the /etc/init.d/netlogond script.

The line,

"PROG_ARGS="--start-as-daemon"

should be modified to read,

"PROG_ARGS="--start-as-daemon --logfile /var/log/vmware/netlogond.log --loglevel debug"

The logfile can be any file and the loglevel can be one of error, warning, info, verbose or debug.

If the netlogond service is running when the /etc/init.d/netlogond file is modified, it will need to be restarted via the "service netlogond restart" command.

The lwiod damon is an SMB client driver.  It is responsible for allowing communcation between the ESX/ESXi host and the Active Directory domain controller.

To enable logging for the lwiod daemon, use a text editor to modify the /etc/init.d/lwiod script.

The line,

"PROG_ARGS="--start-as-daemon"

should be modified to read,

"PROG_ARGS="--start-as-daemon --logfile /var/log/vmware/lwiod.log --loglevel debug"

The logfile can be any file and the loglevel can be one of error, warning, info, verbose or debug.

If the lwiod service is running when the /etc/init.d/lwiod file is modified, it will need to be restarted via the "service lwiod restart" command.

The lsassd daemon allows one to select the AD domain for users when creating permissions on ESX/ESXi.  It is also responsible for some login behavior when AD users login to an ESX/ESXi host at the console or via SSH.  If it is not running, no AD users will be able to login to the system (via the vSphere Client, console or SSH) and only local users can be assigned permissions.

To enable logging for the lsassd daemon, use a text editor to modify the /etc/init.d/lsassd script.

The line,

"PROG_ARGS="--start-as-daemon"

should be modified to read,

"PROG_ARGS="--start-as-daemon --logfile /var/log/vmware/lsassd.log --loglevel debug"

The logfile can be any file and the loglevel can be one of error, warning, info, verbose or debug.

If the lsassd service is running when the /etc/init.d/lsassd file is modified, it will need to be restarted via the "service lsassd restart" command.

On ESXi run "/sbin/services.sh restart"

[lamw]

Did you mean ESX(i) 4.1 Update 1 or Update 2? Update 1 has not even released yet

Also here is the new VMware KB article that was created to enable further logging for Likewise agent, looks like it stemmed from your SR - http://kb.vmware.com/kb/1026554

[jkoon]

VMware said 4.1 U2, end of 2011

[lamw]

I wonder if this is an issue resolved by Likewise, I know the version that's embedded with vSphere 4.1 is running Likewise 5.x and the latest release is 6.x from Likewise. In either case, they would need to provide the latest compiled version against Busybox for use with ESXi, where as on ESX, you can probably use an "unsupported" method to just upgrade the RPM package.

[kattrap]

The "Single Name Domain" problem is a red herring in our case. The error message goes away and we are able to search our domain when we remove the requirement for signed ldaps:

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 on setting likewise to use ldaps brought up this conversation: http://www.likewise.com/community/index.php/forums/viewthread/565/

So as of Feb 2010, likewise was intentionally not supporting ldaps communication.

For our use, this is far enough down the rabbit hole. It's not hindering our use of AD auth, just an annoyance that may or may not go away at a later date. I hope this was helpful to some of you.