Hi,
the often used Active Directory source “Active Directory (Integrated Windows Authentication)” is from VMware marked as deprecated.
The recommendation is to use “Active Directory over LDAP”. My current view is that this has some limitions/nuisances:
- You can no longer login with a Active Directory User which is member of the “Protected User Group”
- You have to get the certificate of each LDAPs Server
- If the certificate of the LDAPs Server is changed you have to delete the identity source and recreate it.
- You have to define 2 domain controller which are used for authentification. vSphere can no longer recognize the domain controllers over DNS
I describe the command line way. Make an snapshot of your vCenter to be prepared for a rollback if something goes wrong.
Prerequierments:
- A User with read permissions, vCenter can no longer uses the machine account. In this example QueryUser
- Join the active directory to get an DNS entry
If an (LDAP) Active Directory identity source already exists delete them.
root@myCenter ~ # /opt/vmware/bin/sso-config.sh -get_identity_sources ... ********** IDENTITY SOURCE INFORMATION ********** IdentitySourceName : myad.domain.org DomainType : EXTERNAL_DOMAIN Identity Settings: alias : MYAD authenticationType : PASSWORD userBaseDN : DC=myad,DC=domain,DC=org groupBaseDN : DC=myad,DC=domain,DC=org username : QueryUser@myAD.domain.org providerType : IDENTITY_STORE_TYPE_LDAP_WITH_AD_MAPPING servicePrincipalName : placeholder useMachineAccount : false FriendlyName : myad.domain.org SearchTimeoutInSeconds : 0 ... Connection Settings:
If configured delete an exiting entry
root@myCenter ~ # /opt/vmware/bin/sso-config.sh
root@myCenter ~ # /opt/vmware/bin/sso-config.sh -delete_identity_source -i myad.domain.org
Define your AD domain controller, and
root@myCenter ~ # export DOMAIN_CONTROLLER1=dc1.myad.domain.org root@myCenter ~ # export DOMAIN_CONTROLLER2=dc2.myad.domain.org
Get the AD domain controller LDAP certificates and save it temporarily
root@myCenter ~ # openssl s_client -showcerts -connect ${DOMAIN_CONTROLLER1}:3269 </dev/null 2>/dev/null|openssl x509 -outform PEM > /tmp/${DOMAIN_CONTROLLER1}.cer root@myCenter ~ # openssl s_client -showcerts -connect ${DOMAIN_CONTROLLER2}:3269 </dev/null 2>/dev/null|openssl x509 -outform PEM > /tmp/${DOMAIN_CONTROLLER2}.cer
Add the identity source. As per documentation the “username” should have the distinguished name format, but user@domain should also work.
root@myCenter ~ # /opt/vmware/bin/sso-config.sh \ -add_identity_source -name "myad.domain.org" \ -type adldap \ -baseUserDN "DC=myad,DC=domain,DC=org" \ -baseGroupDN "DC=myad,DC=domain,DC=org" \ -domain "myad.domain.org" \ -alias "MYAD" \ -username "QueryUser@myAD.domain.org" \ -password 'mySecretPassword' \ -primaryURL "ldaps://$DOMAIN_CONTROLLER1:3269" \ -secondaryURL "ldaps://$DOMAIN_CONTROLLER2:3269" \ -useSSL true \ -sslCert /tmp/$DOMAIN_CONTROLLER1.cer,/tmp/${DOMAIN_CONTROLLER2}.cer
That’s it.
To check the LDAPs certificate locally stored at the vCenter. If these does not match the certificates on the LDAP server authentification would fail.
root@myCenter ~ # /opt/vmware/bin/sso-config.sh -check_ldaps_cert_validation
As described above, authentification will fail if the certificates does not match. There is a registry key in likewise which controls the certificate handling, but not tested yet on how that changes the behaviour.
root@myCenter ~ # /opt/likewise/bin/lwregshell add_value '[HKEY_THIS_MACHINE\Software\VMware\Identity\Configuration]' LdapsCertValidation REG_SZ true root@myCenter ~ #/opt/likewise/bin/lwregshell set_value '[HKEY_THIS_MACHINE\Software\VMware\Identity\Configuration]' LdapsCertValidation true
Michael