Change vCenter Identity Source from IWA to LDAPS

Introduction

Update 15/11/2021

VMware has just released [VMSA-2021-0025] describing an IWA privilege escalation vulnerability (CVE-2021-22048). There will probably be a patch, but the workaround is to use AD over LDAPS authentication or Identity Provider Federation for ADFS if you are on vSphere 7.x. So if you didn’t have time to switch to one of these methodes, now is the time and hopefully this blogpost is usefull.

Update 11/03/2021

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 administrator@vsphere.local (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:

1. Remove IWA Identity Source (don’t leave the domain, or rejoin later. See here)
2. 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.

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 (chain) of your root (and intermediate) CA Click Add.

Some Notes

• In your environment you may have to point to a more specific Base DN to lookup Users and Groups.
• <update 11/03/2021> Domain alias does not have to be used, unless specific conditions apply (click on the Information icon next to the field). Note that If you use the FQDN here (like I did initially) the existing Permissions will not work.
• For the Primary 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.

You should end up with a new LDAPS based Identity Source like this:

Next steps

• 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.

Windows session authentication

Recently I received a question from a colleague about the use of Windows session authentication in combination with the above ldaps configuration. They were not able to select the “Use Windows session authentication” tickbox.
This was quickly fixed by installing the VMware Enhanced Authentication Plug-in (including the VMware Plug-in Service).

Unfortunately logging in with this option did not work. The solution was to join vcsa to the domain.