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: http://lucd.info | Twitter: @LucD22 | PowerCLI Reference co-author: http://tinyurl.com/hkn4glz
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 ?
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.
We're seeing the same.. I just opened a ticket with VMware to see what they have to say about it.
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...
As soon as we have some time we will test this one:
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.
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:
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.
Any news from VMware support on this?
we got an answer to an issue related SR:
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.
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.
is there an update to this? I would agree that the statement contradicts Microsoft's KB article.