NSX-T NAPI treats a role binding's domain name in a case-sensitive manner leading to failed login attempts.

Products

• VMware NSX

Issue/Introduction

Customers are not able to login to the NSX-T UI using domain credentials because role-bindings are not being applied correctly. This will manifest in the logs as follows:

 

/var/log/nvpapi Insufficient privileges invoking GET /api/v1/cluster-manager/config by [email protected] (#############################==) in groups '['group1', 'group2', 'group3']' (########################################################==) with perms: ''"

/var/log/nvpapi  napi.rest_routine_rbac_utils INFO Insufficient privileges invoking GET /api/v1/node/version by [e-mail] (####################################==) in groups '['group4', 'group5', 'group6', 'group7', 'group8', 'group9', 'group10', 'group11', 'group12', 'group13', 'group14', 'group15', 'group16', 'group17', 'group18', 'group19', 'group20', 'group21', 'group22', 'group23', 'group24', 'group25']' (######################################################################################################################################) with perms: ''"

 

For the logging above we can see that the users that are attempting to login do not have any role bindings associated with them leading to authentication/authorization failure. This is despite users being within the correct groups in NSX-T that have sufficient privileges to be able to login. 

Environment

LDAP usage within NSX for Data Center 4.2.0 and earlier. 

Cause

This issue is caused by a bug within NAPI that causes NSX-T LDAP to not treat Active Directory group names in the x-nsx-groups header in a
case-insensitive fashion.

Resolution

To workaround this issue, customers can do one of two things:

1.) Edit the LDAP configuration so that the domain name is DOMAIN.COM (all upper-case), or:
2.) Delete the existing groups in NSX and re-add them. Once that's done, the role bindings will refer to "domain.com" in lower case and the users in those groups will be able to log into NSX.

Conversely, If groups are created as uppercase in active directory and then defined in a lowercase fashion within NSX this issue will occur as NSX-T is case sensitive. 

Additional Information

Testing and validation that has been done in NSX 4.2.0 and suffices for validating the issue in earlier versions: 

 

1.) Created a LDAP server with upper case domain "TESTAD3.LOCAL" (DC=TESTAD3,DC=LOCAL)

2.) Created a role binding for a group in upper case, "[email protected]"

3.) log in to the NSX as a remote LDAP user belonging to the group in step2 with the upper case domain([email protected])

Observation: Login was successful with the user name shown in top right corner as ([email protected])

4.) Login to the nsx with the user belonging to the group in step2 lower case domain ([email protected])

Observation: Login was successful and the same user name was reflected on the top right corner.

5.) Edited the LDAP server to use the lower case domain name (testad3.local) and saved the config successfully.

6.) log in to the NSX as a remote LDAP user belonging to the group in step2 with the upper case domain ([email protected])

Observation: Login was successful with the user name shown in the top right corner as ([email protected])

7.) log in to the nsx with the user belonging to the group in step2 lower case domain ([email protected])

Observation: Login was successful and the same user name was reflected on the top right corner.