How to troubleshoot NSX-T v3.2 LDAP Authentication

[KWKirchner]

I am trying to setup authentication against our local AD domain controllers in NSX-T. We are using LDAPS and everything in the setup appears to be green and successful. If I build the base DN and point it into our Security Groups folder, when I start typing the name in the new user/group field, it correctly finds the group and I select the role and hit apply.

But it doesnt work. At all. None of the members of that group can log in.  If I instead try to point the base DN into our users OU, it can find some people based on SAMAccountName, others based on UPN.  But even directly mapping one of those users does not allow them to log in.

Where are the logs for this process found? How do I increase log level for it if needed?  Is there some secret to getting LDAPS working? Seems like it should be pretty straight forward. Can I force it to use UPN over SAMAccountName?  How can this thing not support SAML or some other SSO?

[KWKirchner]

No bites here... I have opened a support ticket.

[engyak]

Hello,

The LDAP connector is...finicky.

Logs go to /var/log/auth.log, but it doesn't always tell you the full story - it's using an LDAP connector ( libldapidentity-java-proto.jar ) that doesn't appear to have public docs.

Check for all of the usual suspects:

• Too many groups
• Groups with invalid characters (em-dash). GSS might be able to provide you a list of invalid characters in a group, but if they're in *any* group a user is a member of the search will fail in the way you described.
  • For me, the issue appeared because AD admins were copying users and stuff from MS Word -> Active Directory, and MS Word was changing the characters.

If you want SAML, vIDM would be the way to go. It doesn't support 3rd party IDPs though.

HTH,

[KWKirchner]

Thank you for that bit of detail.  It is unfortunate that VMware doesnt put more effort into standardizing their authentication methods across all of their products. We are deploying Ping Federate to try and get a handle on SSO and there are just some things that arent going to work.

[grimsrue]

Hey KWKirchner,

I am not sure of your exact issue, but I can tell you what I ran into and how I fixed it.

NSX-T LDAP is stupid basic. It does not like any LDAPS that uses a VIP that load balances to multiple LDAPS servers or an DNS Alias. You have to connect NSX-T LDAPS directly to a specific LDAPS server. So if you are using Active directory and you have multiple domain controllers and your company is using an DNS ALIAS then that will not work in NSX-T LDAP config.

It is all about that certificate that NSX-T LDAP grabs. Meaning you need to have LDAPS configured to connect directly to the LDAP server that the certificate was pulled from or it will not work. A VIP or an Alias will just pick a random Domain controller or LDAP server in the list and if its not the Domain controller or LDAP server the cert came from then LDAPS stops working on NSX-T.

I agree with you last Statement. Why can't VMWare just stick to one LDAP standard for all their products. vCenter is different from NSX-T, which is different from vROPs, which is different from vRNI, which is different from HXC, etc., etc. It is really annoying.

[KWKirchner · Accepted solution]

So just to follow up with what fixed it for me:

In our environment we have DoD PKI in use so that users can use their Common Access Card (CAC) to authenticate into systems. In a typical user AD record for us, the UPN is EDIPI on the CAC and the sAMAccountName is the first.last@domain.com.  The EDIPI is in the format of "10 digit number@mil" (ex: 1234567890@mil).  NSX-T was picking up the @MIL as a new domain, even though we had everything configured to use the sAMAccountName and the domain.com domain.  All I had to do was add "mil" to the Alternative Domain Names list and it started working.