Change vCenter Identity Source from IWA to LDAPS

Introduction

Updated 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:

IDS Config

Some Global Permissions I have set up:

vCenter Global Permissions

Some vCenter Permissions I have set up:

vCenter Permissions

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:

Add Duplicate IDS

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.

Henk Engelsman

4 Responses

  1. Hello Henk,
    I just went through this on the weekend and before I came across your post. Your steps are spot on. The only thing I did not do was the alias part, but everything seemed to have worked just fine with our testing after the change. I did notice you said to make sure to enter the NETBIOS name. I don’t have that filled out in my lab so didnt think too much about it.
    How did your permissions look after 24 hours? All our domain accounts, that were there when testing after the change, disappeared.
    Thanks

    • Hi Philip,

      I have retried the whole migration from scratch and you are right about the NETBIOS name. It shouldn’t matter, unless you have a specific AD setup as mentioned under the info button. I did not see the permissions disappearing. They are still there after 48 hours (and longer in my other environment). you may want to checkout the Platform Services Controller Service Logs to see what’s happening in the background.

  2. Hello Henk,
    Thank you, I tested in my lab to try and recreate it and it worked perfectly fine. The only difference is our prod has Enhanced Linked mode, 3 different vCenters.
    Ill check the PSC service logs, thanks for your help

Leave a Reply

Your email address will not be published. Required fields are marked *

Post comment