Users granted access to NSX Manager through AD group membership are unable to access NSX, despite SSO connection being connected

search cancel

Users granted access to NSX Manager through AD group membership are unable to access NSX, despite SSO connection being connected

book

Article ID: 303291

calendar_today

Updated On:

Products

VMware NSX

Issue/Introduction

When connecting to the vSphere Web Client with a user who is granted permissions to NSX Manager because they are members of an AD group which is added to NSX, and the SSO Lookup service is configured correctly and showing a Connected status in the NSX web UI, NSX components are not available to the user.
If the user is granted access directly to their account, permissions work as expected.
On the NSX Manager, the user account displays messages similar to:

2017-06-29 13:50:21.005 GMT INFO http-nio-127.0.0.1-7441-exec-3 VcConnection:637 - Session info : Session key [####################ed037] for User [EXAMPLE\user]]

2017-06-29 13:50:21.020 GMT INFO http-nio-127.0.0.1-7441-exec-3 VcAuthenticationProvider:176 - SSO user and its groups does not have any role on vSM
In vmware-sts-idmd.log in the SSO server/PSC, you see entries similar to:

[2017-07-05T10:15:46.398-04:00 vsphere.local ffa849d1-####-####-####-1795db720967 INFO ] [VmEventAppender] EventLog: source=[VMware Identity Server], tenant=[vsphere.local], eventid=[USER_NAME_PWD_AUTH_FAILED], level=[ERROR], category=[VMEVENT_CATEGORY_IDM], text=[Failed to authenticate principal [EXAMPLE\user]

. Native platform error [code: -1765328360][null][null]], detailText=[com.vmware.identity.interop.idm.IdmNativeException: Native platform error [code: -1765328360][null][null]

[2017-06-26T14:36:41.032-04:00 vsphere.local 8ab47fb2-####-####-####-7a8aa2b4b285 WARN ] [ServerUtils] cannot bind connection: [ldap://DC01.example.com, null]

[2017-06-26T14:36:41.032-04:00 vsphere.local 8ab47fb2-####-####-####-7a8aa2b4b285 ERROR] [ServerUtils] cannot establish connection with uri: [ldap://DC01.example.com]

[2017-06-26T14:36:41.032-04:00 vsphere.local 8ab47fb2-####-####-####-7a8aa2b4b285 INFO ] [ActiveDirectoryProvider] removeDcInfo - domain [EXAMPLE.COM],

domainFQDN [DC01.corp.local], domainIpAddress [192.168.247.60]

[2017-06-26T14:36:41.033-04:00 vsphere.local 8ab47fb2-b856-403d-921e-7a8aa2b4b285 ERROR] [ActiveDirectoryProvider] Failed to get non-GC connection to domain CORP.LOCAL - domain controller might be offline com.vmware.identity.interop.idm.IdmNativeException: Native platform error [code: 40287][LW_ERROR_LDAP_LOCAL_ERROR][]

at com.vmware.identity.interop.idm.LinuxIdmNativeAdapter.LdapSaslBind(LinuxIdmNativeAdapter.java:345)

at com.vmware.identity.interop.ldap.LinuxLdapClientLibrary.ldap_sasl_bind_s(LinuxLdapClientLibrary.java:686)

at com.vmware.identity.interop.ldap.LdapConnection.bindSaslConnection(LdapConnection.java:158)

at com.vmware.identity.idm.server.ServerUtils.getLdapConnection(ServerUtils.java:354)

at com.vmware.identity.idm.server.ServerUtils.getLdapConnectionByURIs(ServerUtils.java:250)

Note: The preceding log excerpts are only examples. Date, time, and environmental variables may vary depending on your environment.

Resolution

Cause

This issue occurs because the Likewise Kerberos stack requires all DNS servers to be configured with the Reverse Lookup Zone and that all Active Directory Domain Controller (AD DC) Pointer (PTR) records are available. The Likewise Kerberos stack in the Appliances use both Forward and Reverse Name Lookup to canonically organize hostnames for use in service principal names.

Determining the DNS servers of vCenter Server

Initiate an SSH connection to the vCenter Server or vRealize Automation Appliance.
Enter the root username and password when prompted.

Note: If you are using vSphere 6.0, run these commands to switch to the Bash shell:

shell.set --enable True
shell
Run this command to review the DNS servers configured for the vCenter Server or vRealize Automation Appliance:

less /etc/resolv.conf

For example:

nameserver 10.100.10.213
nameserver 10.10.10.252

Checking Active Directory Trust Enumeration

To determine all trusts that are enumerated by the SSO 5.5, PSC 6.0, or Identity Appliance 6.x:

Initiate an SSH connection to the SSO, PSC, or Identity Appliance.
Enter the root user name and password when prompted.

Note: If using vSphere 6.0, run the following command to switch to the Bash shell:

shell.set --enable True
shell
Run this command to review all of the enumerated trusts from the Likewise Kerberos stack on the SSO, PSC, or Identity Appliance Appliance:

less /var/lib/likewise/krb5-affinity.conf

Note: This will output all of the trusts currently accessible from the SSO, PSC, or Identity Appliance.

You see output similar to:

[realms]

DomainA.local = {
kdc = 10.10.10.213
}
DomainB.local = {
kdc = 10.10.10.81
}
ChildDomainA.DomainB.local = {
kdc = 10.10.10.85
}
ChildDomainB.DomainB.Local = {
kdc = 10.10.10.83
}
DomainC.local = {
kdc = 10.10.10.252
kdc = 10.10.10.250
}
ChildDomainC.DomainB.local = {
kdc = 10.10.10.247
kdc = 10.10.10.82
}
Run this command to view a list of domain controllers that are not accessible from the Appliance:

grep "cannot establish connection with uri:" /var/log/vmware/sso/vmware-sts-idmd.log | cut -d'[' -f4 | sort -nr | uniq -c

Or

grep "cannot establish connection with uri:" /var/log/vmware/sso/vmware-sts-idmd.log | cut -d'[' -f4 | uniq

You see output similar to:

ldap://localhost:389]
ldap://dc2-root.DomainA.local]
ldap://Vigrid.local]
ldap://DC-4.DomainB.local]
ldap://dc-us.DomainC.local]
ldap://dc2-nh.DomainB.local]
ldap://sqa-dc-3.DomainB.local]
ldap://dc2-root.DomainA.local]
ldap://DC-4.DomainB.local]

Checking Active Directory Domain Controller DNS Resolution:

Initiate an SSH connection to the Appliance.
Enter the root username and password when prompted.

Note: If you are using vSphere 6.0, run this command to switch to the Bash shell:

shell.set --enable True
shell
Using nslookup from the Appliance, run this command to ensure there is DNS resolution for Forward Lookup for the Domain Controllers determined from the Checking Trust Enumeration section:

nslookup dc2-root.DomainA.local

Note: This command displays the IP address of the Domain Controller.

You see output similar to:

nslookup dc2-root.DomainB.local
Server: 10.100.10.213
Address: 10.100.10.213#53

Non-authoritative answer:
Name: dc2-root.DomainB.local
Address: 10.10.10.81
To ensure that there is DNS resolution for Reverse Lookup for the domain controllers, run this command:

nslookup 10.10.10.81

If the Reverse Lookup is incorrect or missing, you will see output similar to:

nslookup 10.10.10.81
Server: 10.100.10.213
Address: 10.100.10.213#53

Non-authoritative answer:
81.10.10.10.in-addr.arpa name = <Incorrect FQDN>.

Authoritative answers can be found from:
Repeat Steps 1 to 4 for any additional Active Directory Domain Controllers to determine the records that are missing or incorrect.
To resolve the issue when there are missing or incorrect records, use one of these options:
- Option 1: Create or update the PTR record(s) for the Active Directory Domain Controller(s) on the listed DNS Servers from the Determining the Appliance's DNS Servers section.
- Option 2: Update the DNS servers configured on the appliance to use DNS servers containing the correct PTR for your Active Directory Domain Controllers records. For more information, see Edit the DNS and IP Address Settings of the vCenter Server Appliance section in the vCenter Server Appliance Configuration guide.
- Option 3: Add the missing Reverse Lookup records for the Active Directory Domain Controller(s) to the Appliance's /etc/hosts. For more information, see Editing files on an ESX host using vi or nano (1020302).
  
  Entries added to /etc/hosts file on the Appliance should be in the following format:
  
  IP_Address FQDN_of_Domain_Controller Short_Name_of_Domain_Controller
  
  For example:
  
  10.10.10.81 dc2-root.DomainB.local dc2-root

Feedback

thumb_up Yes

thumb_down No