A while ago Microsoft released an advisory regarding a change in LDAP channel binding and signing. There was some confusion about this in relation to VMware Products that used the Integrated Windows Authentication method (IWA). Fortunately, there were some great blogposts (1 and 2) from Bob Plankers on how this may impact VMware Products.
To sum things up:
- Domain joined hosts are not impacted by the patch. These use proprietary protocols and ports.
- AD over LDAP: If your authentication is configured as “AD over LDAP” these changes to Active Directory will break your authentication. This is expected – AD over LDAP is not natively secure. Switch to AD over LDAPS or Identity Federation instead (vCenter 7).
- AD over LDAPS: All is fine, your authentication communications are secure
- Integrated Windows Authentication (IWA): Not completely compatible. Authentication is secure and will continue working but you will be unable to search the Active Directory, because searching is done over an LDAP (not LDAPS) connection that does not sign the connection. This means that adding new AD users and groups to SSO may be problematic. Please consider switching to AD over LDAPS. You may also be seeing Event ID 2889 log entries.
In this blogpost I would like to share how to change your current vCenter Identity Source from IWA to LDAPS.
Before you start, I would like to put out a BIG disclaimer. The method below is tested in our homelabs, with simple Active Directory Deployments.
If you are uncertain about this action, I recommend deploying a fresh vCenter with some folders, (empty) clusters, etc., Configure IWA and setup some roles and permission like they are in your production vCenter.
Initial vCenter Identity Source configuration with IWA
On my vCenter 6.7 system I had joined an Active Directory domain and added an Identity Source based on Integrated Windows Authentication.
You can check your Identity Source by logging in with email@example.com (or the sso domain name you chose). This is what my initial Identity Sources looked like:
Some Global Permissions I have set up:
Some vCenter Permissions I have set up:
One thing to note is the difference in notation of the domain name between Global and vCenter Permissions depending of the view.
Unfortunately, you cannot change an existing Identity Source from IWA to LDAP(S). You can also not add a new LDAP Identity Source with the same domain name as the existing IWA. This will result in the error: There is already one IdenitySource of AD type registered: name ‘<domain>’. Only one IDS of AD type is allowed:
There is a VMware KB describing this https://kb.vmware.com/s/article/71083
Ok…. So what now? What we have tested is simply removing the IWA Identity Source and adding a new LDAPS Identity Source.
But wait!… Doesn’t that remove all the permissions you have setup on vSphere objects? Here comes the good part; in our testing all permissions were maintained, and we were able to log in and see all the existing permissions.
The following actions were taken:
- Remove IWA Identity Source (don’t leave the domain)
- Add an LDAPS Identity Source
Remove IWA Identity Source
First, I removed the existing IWA Identity Source like this:
- Go to Administration, Single Sign On, Configuration
- Select the IWA Identity Source from Identity Sources tab and Click Remove.
That’s it. No need to leave the domain (yet).
Add Active Directory over LDAP Identity Source
After removal of the existing Identity Source, I added a new one. This time based on Active Directory over LDAPS.
- Go to Administration, Single Sign On, Configuration.
- Click Add Identity Source from Identity Sources tab.
This was straight forward since I don’t have a complex Active Directory Environment with trusts, etc. I used the following configuration:
Import the SSL Certificate of your domain controller(s) and Click Add.
- In your environment you may have to point to a more specific Base DN to lookup Users and Groups.
- One important part is to enter the NETBIOS name as explained if you click on the Information icon next to the field. If you use the FQDN here (like I did initially) the existing Permissions will not work.
- For the Primairy Server URL, I used the Secure Global Catalog Port (3269), but you can also use LDAPS on port 636. Same advise as before; Click the Information button to learn more about the notation.
- If you enter a secondary Server URL, U must also import the corresponding SSL Certificate.
You should end up with a new LDAPS based Identity Source like this:
- Check if your Global and vCenter Permissions are still in place.
- Add some new Global and vCenter permissions to check if the same domain name is being used.
- Log out as administrator and Login as another user and see if your permissions are working as expected.
- You can leave the AD domain (vCenter restart required) and test the above steps again.