PDF(17.9 KB) View with Adobe Reader on a variety of devices
ePub(81.9 KB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(69.6 KB) View on Kindle device or Kindle app on multiple devices
Updated:October 14, 2019
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document provides information on validating the Lightweight Directory Access Protocol (LDAP) configuration on the Unified Computing System Manager (UCSM) and steps to investigate LDAP authentication failure issues.
2. Always use local realm for 'console authentication', In case the user is locked out from using 'native authentication', admin would still be able to access it from console.
3. UCSM always fails back to local authentication if all the servers in given auth-domain failed to respond during login attempt (not applicable for test aaa command ) .
Validating LDAP configuration
Test the LDAP authentication using NX-OS command. 'test aaa' command is available only from NX-OS CLI interface.
1. Validate LDAP group specific configuration.
The following command goes through list of all configured LDAP servers based on their configured order.
ucs(nxos)# test aaa group ldap <username> <password>
2. Validate specific LDAP server configuration
ucs(nxos)# test aaa server ldap <LDAP-server-IP-address or FQDN> <username> <password>
NOTE 1: <password> string will be displayed on the terminal.
NOTE 2: The LDAP server IP or FQDN must match a configured LDAP provider.
In this case, UCSM tests the authentication against specific server and can fail if there is no filter configured for the specified LDAP server.
Troubleshooting LDAP login failures
This section provides information on diagnosing LDAP authentication problems.
Problem scenario #1 - Cannot log in
Cannot login as LDAP user via both UCSM Graphical User Interface (GUI) and CLI
User receives "Error authenticating to server" while testing LDAP authentication.
(nxos)# test aaa server ldap <LDAP-server> <user-name> <password> error authenticating to server bind failed for <base DN>: Can't contact LDAP server
Recommendation Verify network connectivity between LDAP server and Fabric Interconnect (FI) management interface by Internet Control Message Protocol (ICMP) ping and establishing telnet connection from local-mgmt context
ucs# connect local ucs-local-mgmt # ping <LDAP server-IP-address OR FQDN> ucs-local-mgmt # telnet <LDAP-Server-IP-Address OR FQDN> <port-number>
Investigate Internet Protocol (IP) network connectivity if UCSM cannot ping LDAP server or open telnet session to LDAP server.
Verify if Domain Name Service (DNS) returns correct IP address to UCS for LDAP server hostname and make sure that LDAP traffic is not blocked between these two devices.
Problem scenario #2 - Can log into GUI, cannot log into SSH
LDAP user can login via UCSM GUI but cannot open SSH session to FI.
When establishing SSH session to FI as LDAP user, UCSM requires " ucs- " to be prepended before LDAP domain-name
NOTE: Domain name is case sensitive and should match the domain-name configured in UCSM. The maximum username length can be 32 chars which includes the domain name.
"ucs-<domain-name>\<user-name>" = 32 chars.
Problem scenario #3 - User has read-only privileges
LDAP user can login but has read-only privileges even though ldap-group maps are correctly configured in UCSM.
Recommendation If no roles were retrieved during the LDAP login process,remote-user is either allowed with default-role ( read only access ) or denied access ( no-login ) to login to UCSM, based on the remote-login policy.
When remote-user logs-in and user was given read-only access, In that case verify the user group membership details in LDAP/AD. For example, we can use ADSIEDIT utility for MS Active Directory. or ldapserach in case of Linux/Mac.
It can also be verified with " test aaa " command from NX-OS shell.
Problem scenario #4 - Cannot log in with 'Remote Authentication'
User cannot login or has read-only access to UCSM as remote user when " Native Authentication " was changed to remote authentication mechanism ( LDAP etc )
Recommendation As UCSM fallsback to local authentication for console access when it cannot reach remote authentication server, we can follow below steps to recover it.
1. Disconnect the mgmt interface cable of primary FI ( show cluster state would indicate which is acting as Primary ) 2. Connect to the console of the primary FI 3. Execute following commands to change the native authentication
scope security show authentication set authentication console local set authentication default local commit-buffer
4. Connect the mgmt interface cable 5. Login via UCSM using local account and create auth-domain for remote authentication (ex LDAP) group. NOTE: Disconnecting the mgmt interface would NOT affect any data plane traffic.
Problem scenario #4 - LDAP Authentication works but not with SSL enabled
LDAP authentication is working fine without Secure Socket Layer (SSL) but fails when SSL option is enabled.
Recommendation UCSM LDAP client uses the configured trust-points (Certificate Authority (CA) certificates) while establishing SSL connection.
1. Make sure the trust-point was configured correctly.
2. The identify field in cert should be the " hostname "of the LDAP server. Make sure the hostname configured in UCSM matches the hostname present in certificate and are valid.
3. Make sure UCSM is configured with 'hostname' not 'ipaddress' of the LDAP server and it is recheable from local-mgmt interface.
Problem scenario #5 - Authentication fails after LDAP provider changes
Authentication fails after deleting old LDAP server and adding new LDAP server
Recommendation When LDAP is being used in authentication realm, deleting and adding of new servers is not permitted. From UCSM 2.1 version, it would result in FSM failure.
The steps to follow when removing/adding new servers in same transaction is
1. Make sure all the authentication realms using ldap are changed to local and saved the configuration. 2. Update the LDAP servers and verify that the FSM status has completed successfully. 3. Change the auth realms of domains modified in step 1, to LDAP.
For all other problem scenarios - Debugging LDAP
Turn on the debugs, attempt to login as LDAP user and gather following logs along with UCSM techsupport that captures failed login event.
1) Open a SSH session to FI and login as local user and change to NX-OS CLI context.
ucs # connect nxos
2) Enable following debug flags and save the SSH session output to log file.
ucs(nxos)# debug aaa all <<< not required, incase of debugging authentication problems. ucs(nxos)# debug aaa aaa-requests
ucs(nxos)# debug ldap all <<< not required, incase of debugging authentication problems. ucs(nxos)# debug ldap aaa-request-lowlevel ucs(nxos)# debug ldap aaa-request
3) Now open a new GUI or CLI session and attempt to login as remote ( LDAP ) user 4) Once you received login failure message, turn off the debugs.
ucs(nxos)# undebug all
Packet capture of LDAP traffic
In scenarios where packet capture is required, Ethanalyzer can used to capture LDAP traffic between FI and LDAP server.
--------- snip ---------- The specific distinguished name in the LDAP hierarchy where the server should begin a search when a remote user logs in and the system attempts to get the user's DN based on their username. The maximum supported string length is 127 characters. ----------------------------
LDAP client may crash while initialising the ssl library if the ldap_start_tls_s call takes more than 60 secs to complete the initialisation. This could happen only incase of invalid DNS entry / delays in DNS resolution.
Take steps to address the DNS resolution delays and errors.