vCenter LDAP binding and signing

[LucFullenwarth]

According to Microsoft, LDAP binding and signing will automatically be enforced on January 2020.

https://support.microsoft.com/en-ca/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirement-for-windows

I have enabled LDAP logging on domain controllers.

Set-ItemProperty hklm:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics -Name '16 LDAP Interface Events' -Value 2

It appears that the vCenter is comming out in the "Directory Service" log with a lot of 2889 events:

The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing (integrity verification),
or performed a simple bind over a clear text (non-SSL/TLS-encrypted) LDAP connection.

Does anyone know how to make the vCenter (vSphere 6.7U3) use LDAP binding (No anonymous or Simple but SASL authentication) and signing?

[LucD]

Apparently VCSA, since 6.0, tries to use LDAP SASL/SRP (over port 389) to connect to the LDAP node.

Documentation is sparse, but see Other Observations  in Using JXplorer to connect to vSphere PSC Servers​

The further analyse, I suggest following the procedure outlined in Finally Remove Insecure LDAP and Protect your Credentials with Project VAST​

And check what the Binding Type is (0 or 1).

[Luca Fabbri]

Hello LucFullenwarth​,

have you updates regarding this question?

We have VMware 6.7 U2 and Identity Source set to "Active Directory (Windows Integrated Authentication)"; I noticed event logs with id 2889 coming from our Virtual Center's computer account.

Should I switch to Active Directory over LDAP and SSL enabled instead?

What about ?

Thank you,

Luca

[Texiwill]

Hello Luca,

THat is a tough call and depends on AD more than anything, but in general you should ALWAYS use an encrypted protocol for authentication and authorization.

-- Texiwill

[LucFullenwarth]

Hi Luca,

We are in the same configuration as you.

We opened a ticket at VMware but for the moment we just got a basic documentation link...

Configuring vCenter Single Sign-On Identity Sources

As soon as we have some time we will test this one:

Using the CLI to add or configure SSO identity sources in vSphere 6.5 & 6.7 (67304)

[Luca Fabbri]

Hello LucFullenwarth​,

I looked at the second link you provided: Using the CLI to add or configure SSO identity sources in vSphere 6.5 & 6.7 (67304)​; it explains how to enable either Adding Active Directory (Windows Integrated Authentication), Adding AD over LDAP, Adding AD over LDAP using LDAPS (LDAP over SSL) or Adding Open LDAP using command line; they are the same configuration settings available on web GUI (nothing else).

It seems choosing the first method, it uses SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing. This is confirmed by the value "Binary Type: 0" contained in the event id 2889 on Domain Controller (thank you LucD for sharing the second link).

So, if it won't be possible to enable SASL with signature in VMware, the only way is to use the third method (Adding AD over LDAP using LDAPS).

Maybe you already know, however I share this useful blog article from Secure Infrastructure team at Microsoft explaining the LDAP Signing: Step by Step: Enforce Require LDAP Signing on domain controllers. Part 1.

Please, let us know any information from VMware support.

Thank you,

Luca

[Luca Fabbri]

Hello guys,

I didn't notice this other community post: LDAP server signing requirements security policy setting set to Require signing. Look at latest answer.

Bye,

Luca

[Aaron Kopel]

We're seeing the same.. I just opened a ticket with VMware to see what they have to say about it.

[LucFullenwarth]

Hi all,

The event disappeared from the logs when we removed the SSO and created it again with the command line:

sso-config.sh -add_identity_source -type adldap -baseUserDN "DC=MyDomain,DC=com" -baseGroupDN "DC=MyDomain,DC=com" -domain "mydomain.com" -alias "MyDomain" -username "CN=VMwareServiceAccount,OU=Service Accounts,DC=MyDomain,DC=com" -password 'MyP@ssw0rd' -primaryURL "ldaps://dc1.mydomain.com:3269" -secondaryURL "ldaps://dc2.mydomain.com:3269" -useSSL true -sslCert ~/DC1-LDAPS.cer,~/DC2-LDAPS.cer

Here again is the link to the documentation:

Using the CLI to add or configure SSO identity sources in vSphere 6.5 & 6.7 (67304)

[Luca Fabbri]

Hello LucFullenwarth​

it seems the command you posted (I had to use Developer Tools in my Chrome to view the entire row because truncated) configures the Identity Provider to use AD over LDAPS; exactly the same configuration that could be added, graphically, via web gui.

Currently, we have the Identity Provider configured as Active Directory (Windows Integrated Authentication) - it makes unsigned SASL requests against AD. I'd like to know from VMware if they planned to support signed SASL before January 2020 or not.

If not, then, the only way currently supported is to switch from Active Directory (Windows Integrated Authentication) to AD over LDAP using LDAPS (LDAP over SSL) like you are currently using.

Bye,

Luca

[LucFullenwarth]

Hi LucaFabbri365​

I edited the answer directly in HTML and the text is now visible without trick :-)

Thanks for the feedback!

[vXav]

Any news from VMware support on this?

[komar09]

we got an answer to an issue related SR:

[quote]

We have already opened a case with our Dev team with a query for the impact of the Microsoft LDAP change.

The respond for the vCenter is:

"Both "Integrated Windows Authentication" and "Active Directory over LDAP" have been verified as working with the configuration Microsoft has documented for LDAP channel binding and signing. Customers are not expected to have issues in their environments when Microsoft's update happens or if the customer applies the settings manually."

Shortly there should be publicly available KB for the customers.

[/quote]

[vXav]

I'm confused.

That seems to contradict the current observations of 2889 events with Windows Integrated Authentication which don't appear with LDAPS.

2889 events being Microsoft's way to identify clients that try to make an unsigned LDAP bind.

[Ben Brazil]

Hi,

is there an update to this? I would agree that the statement contradicts Microsoft's KB article.

[vXav]

No news regarding this unfortunately. I guess it will be a wait and see kind of thing.

Microsoft pushed the deployment to March 2020 though.

[schindlerdvi]

VMware vSphere & Microsoft LDAP Channel Binding & Signing (ADV190023) - VMware vSphere Blog

[vXav]

Pushed to Second part of 2020.

Windows Updates in March 2020 add new audit events, additional logging, and a remapping of Group Policy values that will enable hardening LDAP Channel Binding and LDAP Signing. The March 2020 updates do not make changes to LDAP signing or channel binding policies or their registry equivalent on new or existing domain controllers.

A further future monthly update, anticipated for release the second half of calendar year 2020, will enable LDAP signing and channel binding on domain controllers configured with default values for those settings.

I'm trying to keep a blog up to date on this.

[Antyrael]

On several sources I see this text:

If your identity sources are configured as “Active Directory (Windows integrated)” or “LDAPS” you don’t need to change anything.

However, that's how our Vcenter is configured and I still see the following events:

The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing (integrity verification), or performed a simple bind over a clear text (non-SSL/TLS-encrypted) LDAP connection.

Client IP address:

10.10.10.10:46108

Identity the client attempted to authenticate as:

DOMAIN\VCENTER$

Binding Type:

0

(The IP address, domain and computer account have been anonymised)

It seems to me that we still need to change something to address this.

[vXav]

I built a lab specifically to test all these things and indeed the windows integrated still generates 2889 events now and again but it does work.

You shouldn't see anything with LDAPS though.

[rschmitz]

The news from Microsoft and the statement from VMware is delaying the inevitable.  The big question is how do we make this work with LDAPS on vcenter?  No one wants to have to deal with this again in the 2nd half of 2020.  Come on VMware...quit being so damn obscure.

I, too, can't seem to properly get the exported LDAPS cert from my DC (verified working LDAPS) to import into vCenter to even attempt an LDAPS bind.  Getting the dreaded  Check the network settings and make sure you have network access to the identity source.

Is there a trick to the cert needing to be imported?  I'm just exporting the LDAPS one from my DC.  Do we need a private key (pfx), or not (cer)?  Maybe that's incorrect...

[vXav]

The only thing VMware is being a little bit obscure about is the fact that Windows Integrated still generates 2889 events.

However it still works with channel binding and LDAP signing enabled.

This blog details very well how to retrieve the certificate.

You don't need the private key of course, just retrieve the certs on all DCs and add them to the identity source.

[vFaust09]

VMware Knowledge Base: "Event 2889" logged on the Domain Controller when using IWA Identity Source (78644)