VMware Cloud Community
LucFullenwarth
Enthusiast
Enthusiast
Jump to solution

vCenter LDAP binding and signing

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

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?

1 Solution

Accepted Solutions
LucFullenwarth
Enthusiast
Enthusiast
Jump to solution

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)

View solution in original post

22 Replies
LucD
Leadership
Leadership
Jump to solution

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


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

Reply
0 Kudos
LucaFabbri365
Contributor
Contributor
Jump to solution

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

Reply
0 Kudos
Texiwill
Leadership
Leadership
Jump to solution

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

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos
Mackopes
Enthusiast
Enthusiast
Jump to solution

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

LucFullenwarth
Enthusiast
Enthusiast
Jump to solution

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)

Reply
0 Kudos
LucaFabbri365
Contributor
Contributor
Jump to solution

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

Reply
0 Kudos
LucaFabbri365
Contributor
Contributor
Jump to solution

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

Reply
0 Kudos
LucFullenwarth
Enthusiast
Enthusiast
Jump to solution

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)

LucaFabbri365
Contributor
Contributor
Jump to solution

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

Reply
0 Kudos
LucFullenwarth
Enthusiast
Enthusiast
Jump to solution

Hi LucaFabbri365

I edited the answer directly in HTML and the text is now visible without trick 🙂

Thanks for the feedback!

Reply
0 Kudos
vXav
Expert
Expert
Jump to solution

Any news from VMware support on this?

komar09
Contributor
Contributor
Jump to solution

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]

Reply
0 Kudos
vXav
Expert
Expert
Jump to solution

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.

BenBrazilPH
Contributor
Contributor
Jump to solution

Hi,

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

Reply
0 Kudos
vXav
Expert
Expert
Jump to solution

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.

Reply
0 Kudos
vXav
Expert
Expert
Jump to solution

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.

Reply
0 Kudos
Antyrael
Contributor
Contributor
Jump to solution

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.

Reply
0 Kudos
vXav
Expert
Expert
Jump to solution

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.

Reply
0 Kudos