After few nights of troubleshooting, I was running out of clue. Came to the sudden, I accidentally search the computer name in AD under the category of Users object group, and I found an user account been created in AD with the same name as we define on the cluster name. I was wondering whether this could caused the confuse to the system. Therefore, I was suggesting to remove the user name temporally as it was not use at the moment and tried to reform the cluster. Guess what, the cluster form up as it needed to be in less than 1 minutes. We were so happy to end the marathon troubleshooting every night well and we were also very pissed off with the bugs we face here.

I am not very sure what is the real reason behind can really cause this, but this is the real case which take us few days to figure out. I think Microsoft should seriously look into this problem as it sound stupid to have this bugs in place today. User name and computer object name are always not the same thing in AD, how can the system confuse with it?If this is unavoidable, they should put in to the documentation or check list to remind the users on this. My personal comment on Windows 2008 Cluster technology, it does not make the administrator life simple, and it added too much dependency for the Microsoft AD. Please take note that this problem happen to both windows 2008 and windows 2008 R2.

The following article try to give better understanding about latest VMware ESX 3.5 authentication login using AD.

Use esxcfg-auth command – VMware ESX Server Network Management Utility

Login to VMware ESX host using SSH as root

Ping ad.malaysiavm.com to make sure you can reach AD server.

The esxcfg‐auth command includes options for configuring interoperability with several authentication providers. This note focuses on the options that are relevant to Active Directory:
esxcfg‐auth [ [ ‐‐enablead | ‐‐disablead ] [ ‐‐addomain= ] [‐‐addc= ]

Type man esxcfg-auth for more information.

–disableab
Reverts the changes required to authenticate the user against Active Directory.

–enablead
Sets up the Console OS to authenticate the user against an Active Directory server. addomain and addc are required with this option.

–addomain
Sets the domain against which the user is to be authenticated when authenticating against an Active Directory server.

–addc
Sets the domain controller against which the user’s password should be checked.

# esxcfg-auth –enablead –addomain=AD.MALAYSIAVM.COM –addc=dc01.ad.malaysiavm.com

This enables Active Directory based user authentication in the ad.malaysiavm.com domain
with the domain controller dc01.ad.malaysiavm.com.

Basically the system will generate /etc/krb5.conf file as example below:

[domain_realm]
ad.malaysiavm.com = AD.MALAYSIAVM.COM
.ad.malaysiavm.com = AD.MALAYSIAVM.COM

[libdefaults]
default_realm = AD.MALAYSIAVM.COM

[realms]
AD.MALAYSIAVM.COM = {
admin_server = dc01.ad.malaysiavm.com:464
default_domain = AD.MALAYSIAVM.COM
kdc = dc01.ad.malaysiavm.com:88

Basically the different between ESX 2.x and 3.x is in PAM configuration, make sure you have correct PAM configuration as example below:

/etc/pam.d/vmware-authd
auth required pam_stack.so service=system-auth
account required pam_stack.so service=system-auth

/etc/pam.d/system-auth
account sufficient /lib/security/$ISA/pam_krb5.so
account required /lib/security/$ISA/pam_unix.so

auth required /lib/security/$ISA/pam_env.so
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth sufficient /lib/security/$ISA/pam_krb5.so use_first_pass
auth required /lib/security/$ISA/pam_deny.so

password required /lib/security/$ISA/pam_cracklib.so retry=3
password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
password sufficient /lib/security/$ISA/pam_krb5.so use_authtok
password required /lib/security/$ISA/pam_deny.so

session required /lib/security/$ISA/pam_limits.so
session required /lib/security/$ISA/pam_unix.so
session sufficient /lib/security/$ISA/pam_krb5.so

According to previous article from VMware, you’re require /var/kerberos/krb5kdc/kdc.conf which it’s worked without this file on VMware ESX 3.5 update 2.

Create a user on the VMware ESX Server system with permissions to use the service console or SSH. To create a user, use the Linux command useradd.

# /usr/sbin/useradd user1

Note: please make sure you have user1 in your AD or create any other AD account.

Open a new SSH session(I used putty) and login with username: user1 and AD password. If you have any problem with AD authentication logon, please refer to /var/log/message.

In case you need to access to VMware ESX host directly, you’re require to define user test1 in permission tab under VI.

Done! Congratulation! You should be able to login to ESX server using Active Directory authentication.

Related Post:

• SLES 9 Authentication Login Using Active Directory
• SLES 10 Authentication Login Using Active Directory
• ESX Server Integration with Active Directory