LDAP User Login on NSX Standby Global Manager Fails with Authorization Error
search cancel

LDAP User Login on NSX Standby Global Manager Fails with Authorization Error

book

Article ID: 385137

calendar_today

Updated On:

Products

VMware NSX

Issue/Introduction

  • NSX Federation Setup: After upgrading the NSX Standby Global Manager (GM) to 4.2.x, the Active Directory (AD) users face authentication error.
  • AD users cannot log in to the NSX Standby GM. The authentication with the Local User (Admin) works fine.
  • This issue is not seen on the Active GM or LMs.
  • When the role binding is applied directly to the user, the login works fine.
  • However, when role bindings are assigned to an LDAP group (the user is a member of), the login results in an authorization error and the below could be observed in the logs:

root@NSX-Standby-Global-Manager: /var/log# tail -f syslog | grep -i username 
2024-12-24T10:10:10.929Z NSX-Standby-Global-Manager.domain.local NSX 78187 - [nsx@6868 audit="true" comp="global-manager" level="INFO" reqId="df 4444##-####-####-####-########4444" subcomp="glob username="[email protected]"] UserName="[email protected]", src="172.##.##.2", ModuleName="AAA", Operation="GetCurrentUserInfo", Operation status="success", New value-[{"root_path":"/","provide_flat_listing":false}] 
2024-12-24T10:10:10.974Z NSX-Standby-Global-Manager.domain.local NSX 76567 SYSTEM [nsx@6868 comp="global-manager" errorCode="MP401" level="ERROR" subcomp="manager"] User [email protected] with groups [] and incoming roles null is not authorized to access API with rbac_feature utilities_backup having required_permission read. 
2024-12-24T10:10:10.974Z NSX-Standby-Global-Manager.domain.local NSX 76567 SYSTEM [nsx@6868 audit="true" comp="global-manager" level="INFO" subcomp="manager"] UserName: "[email protected]" Src="172.##.##.2", ModuleName="AAA", operation="Authorization", operation status="failure", New value=[read] 
2024-12-24T10:10:10.975Z NSX-Standby-Global-Manager.domain.local NSX 76567 SYSTEM [nsx@6868 audit="true" comp="global-manager" level="INFO" subcomp="manager"] UserName: '[email protected] ModuleName: 'common-services Operation: 'GET@/api/v1/cluster/backups/overview operation status: 'failure' Error: User is not authorized to perform this operation on the application. Please contact the system administrator to get access.

Environment

VMware NSX

Cause

Different LDAP IDs on the Active and Standby Global Managers lead to this issue. Run the following command to retrieve the LDAP identity source configuration for both the Active and Standby Global Managers:

GET https://<NSX_MGR_IP-Active-and-Standby>/global-manager/api/v1/aaa/ldap-identity-sources

From the output of both the Active and Standby Global Managers, compare the 'id' field. Ensure that the 'id' value is identical on both the Active and Standby Global Managers. In the example below, you can observe that the 'id' values are different, which is the cause of the issue.

Active GM

{
"results": [ 
{
"resolve_nested_groups": true,
"group_cache_ttl": 60,
"resource_type": "ActiveDirectoryIdentitySource",
"id": "5555####-####-####-####-########5555",
"display_name": "domain.local", 
"domain_name": "domain.local", 
"base_dn": "DC=domain,DC=local", 
"ldap_servers": [
{
"url": "LDAP://##.##.##.##:389",
"use_starttls": false,
"bind_identity": "[email protected]", 
"enabled": true
}
],
"_create_time": ##:##:##,
"_create_user": "admin",
"_last_modified_time": ##:##:##,
"_last_modified_user": "admin",
"_system_owned" : false,
"_protection": "NOT PROTECTED", 
"_revision": 0
}
],
"result count": 1
}

Standby GM

{
"results":[
{
"resolve_nested_groups": true,
"group_cache_ttl": 60,
"resource_type": "Active DirectoryIdentitySource",
"id": "6666####-####-####-####-########6666"
"display_name": "domain.local", "domain_name": "domain.local", 
"base_dn": "DC=domain,DC=local", 
"ldap_servers": [
{
"url": "LDAP://##.##.##.##:389",
"use_starttls": false,
"bind_identity": "[email protected]", 
"enabled": true    
}
],
"_create_time": ##:##:##,
_create_user": "admin",
"_last_modified_time": ##:##:##,
"_last_modified_user": "admin",
"_system_owned": false,
"_protection": "NOT_PROTECTED",
"_revision": 1
}
],
"result_count": 1
}

Resolution

1) Delete the LDAP configuration with the incorrect ID on Standby Global Manager:

DELETE /global-manager/api/v1/aaa/ldap-identity-sources/<id-from-standby>

In the above example we will be running the following API on Standby Global Manager:

DELETE /global-manager/api/v1/aaa/ldap-identity-sources/6666####-####-####-####-########6666

2) Recreate the Standby GM LDAP identity source using the same ID as the Active GM.

PUT /global-manager/api/v1/aaa/ldap-identity-sources/<id-from-active>

In the above example we will be running the following API on Standby Global Manager:

Standby GM

PUT /global-manager/api/v1/aaa/ldap-identity-sources/5555####-####-####-####-########5555

{
"resolve_nested_groups": true,
"group_cache_ttl": 60,
"resource_type": "ActiveDirectoryIdentitySource",
"id": "5555####-####-####-####-########5555",
"display_name": "domain.local",
"domain_name": "domain.local",
"base_dn": "DC=domain,DC=local",
"ldap_servers": [
{
"url": "LDAP://##.##.##.##:389",
"use_starttls": false,
"bind_identity": "[email protected]",
"password": "MUST BE PROVIDED"
"enabled": true
}
]
}

Now verify successful  log in to the Standby GM using the AD credentials.

Notes:

  • No maintenance window is required to perform the changes mentioned above.
  • After updating the Identity Source on the Standby GM, login on the UI with the local Admin credentials, Navigate to System > User Management > Authentication Providers > LDAP. The connection Status may show as Failed, Click on LDAP Servers and then Check Status, a pop up window will show up to accept the new certificate.
  • After accepting the new certificate, wait for a few minutes (20 min+) for the synchronization with AD to complete then try to authenticate again with AD user. For a large AD environment with sub-domains or alternative domain names, more time may be required for synchronization to be completed.