Einleitung
Dieses Dokument enthält Informationen zur Validierung der LDAP-Konfiguration (Lightweight Directory Access Protocol) im Unified Computing System Manager (UCSM) sowie Schritte zur Untersuchung von LDAP-Authentifizierungsfehlern.
Konfigurationsanleitungen:
UCSM - Konfigurieren der Authentifizierung
Beispielkonfiguration für Active Directory (AD)
UCSM-LDAP-Konfiguration überprüfen
Vergewissern Sie sich, dass UCSM die Konfiguration erfolgreich bereitgestellt hat, indem Sie den FSM-Status (Finite State Machine) überprüfen. Dieser wird dann als zu 100 % abgeschlossen angezeigt.
Über UCSM CLI-Kontext (Command Line Interface)
ucs # scope security
ucs /security # scope ldap
ucs /security/ldap # show configuration
ucs /security/ldap # show fsm status
Über den CLI-Kontext des Nexus-Betriebssystems (NX-OS)
ucs # scope security
ucs(nxos)# show ldap-server
ucs(nxos)# show ldap-server groups
Best Practices für die LDAP-Konfiguration
1. Erstellen Sie zusätzliche Authentifizierungsdomänen, anstatt den Bereich "Native Authentifizierung" zu ändern.
2. Immer den lokalen Bereich für 'Konsolenauthentifizierung' verwenden. Falls der Benutzer von der Verwendung von 'nativer Authentifizierung' ausgeschlossen ist, kann der Administrator weiterhin von der Konsole aus darauf zugreifen.
3. UCSM führt immer dann einen Fehler bei der lokalen Authentifizierung aus, wenn alle Server in der angegebenen Authentifizierungsdomäne während des Anmeldeversuchs nicht antworten konnten (gilt nicht für den Test aaa-Befehl ).
Validieren der LDAP-Konfiguration
Testen der LDAP-Authentifizierung mit dem NX-OS-Befehl Der Befehl "test aaa" ist nur über die CLI-Schnittstelle von NX-OS verfügbar.
1. Validieren Sie die LDAP-Gruppenkonfiguration.
Der folgende Befehl durchläuft die Liste aller konfigurierten LDAP-Server, basierend auf ihrer konfigurierten Reihenfolge.
ucs(nxos)# test aaa group ldap <username> <password>
2. Validieren der spezifischen LDAP-Serverkonfiguration
ucs(nxos)# test aaa server ldap <LDAP-server-IP-address or FQDN> <username> <password>
HINWEIS 1: <Kennwort> wird auf dem Terminal angezeigt.
HINWEIS 2: Die IP-Adresse oder der FQDN des LDAP-Servers muss mit einem konfigurierten LDAP-Anbieter übereinstimmen.
In diesem Fall testet UCSM die Authentifizierung anhand eines bestimmten Servers und kann fehlschlagen, wenn kein Filter für den angegebenen LDAP-Server konfiguriert ist.
Fehlerbehebung bei LDAP-Anmeldefehlern
Dieser Abschnitt enthält Informationen zur Diagnose von LDAP-Authentifizierungsproblemen.
Problemszenario #1 - Anmeldung nicht möglich
Anmeldung als LDAP-Benutzer nicht über die grafische Benutzeroberfläche (GUI) und die Kommandozeile von UCSM möglich
Der Benutzer erhält "Fehler bei der Serverauthentifizierung" beim Testen der LDAP-Authentifizierung.
(nxos)# test aaa server ldap <LDAP-server> <user-name> <password>
error authenticating to server
bind failed for <base DN>: Can't contact LDAP server
Empfehlung
Überprüfung der Netzwerkverbindung zwischen dem LDAP-Server und der Fabric Interconnect (FI)-Verwaltungsschnittstelle durch ICMP-Ping (Internet Control Message Protocol) und Einrichtung einer Telnet-Verbindung über den lokalen Verwaltungskontext
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>
Untersuchen der IP-Netzwerkverbindung (Internet Protocol), wenn UCSM den LDAP-Server nicht anpingen oder Telnet-Sitzungen mit dem LDAP-Server öffnen kann
Überprüfen Sie, ob der Domain Name Service (DNS) die richtige IP-Adresse für den Hostnamen des LDAP-Servers an UCS zurückgibt, und stellen Sie sicher, dass der LDAP-Datenverkehr zwischen diesen beiden Geräten nicht blockiert wird.
Problemszenario #2 - Anmeldung an GUI und SSH nicht möglich
LDAP-Benutzer können sich über die UCSM-GUI anmelden, aber keine SSH-Sitzung mit FI öffnen.
Empfehlung
Bei Einrichtung einer SSH-Sitzung mit FI als LDAP-Benutzer muss UCSM vor dem LDAP-Domänennamen " ucs- " vorangestellt werden.
* Von Linux / MAC-Maschine
ssh ucs-<domain-name>\\<username>@<UCSM-IP-Address>
ssh -l ucs-<domain-name>\\<username> <UCSM-IP-address>
ssh <UCSM-IP-address> -l ucs-<domain-name>\\<username>
* Von putt client
Login as: ucs-<domain-name>\<username>
HINWEIS: Beim Domänennamen wird die Groß-/Kleinschreibung beachtet, und er muss mit dem in UCSM konfigurierten Domänennamen übereinstimmen. Die maximale Länge des Benutzernamens kann 32 Zeichen betragen, wobei der Domänenname berücksichtigt wird.
"ucs-<Domänenname>\<Benutzername>" = 32 Zeichen.
Problemszenario #3 - Benutzer hat schreibgeschützte Berechtigungen
Der LDAP-Benutzer kann sich anmelden, hat jedoch schreibgeschützte Berechtigungen, obwohl LDAP-Gruppenzuordnungen in UCSM korrekt konfiguriert sind.
Empfehlung
Wenn während des LDAP-Anmeldevorgangs keine Rollen abgerufen wurden, kann sich der Remote-Benutzer entweder mit der Standardrolle ( schreibgeschützter Zugriff ) anmelden oder sich mit der Richtlinie für die Remote-Anmeldung bei UCSM anmelden.
Wenn sich der Remote-Benutzer anmeldet und der Benutzer schreibgeschützten Zugriff erhält, überprüfen Sie in diesem Fall die Details der Benutzergruppenmitgliedschaft in LDAP/AD.
Zum Beispiel können wir das ADSIEDIT-Dienstprogramm für MS Active Directory. oder ldapserach im Fall von Linux/Mac verwenden.
Sie kann auch mit dem Befehl " test aaa " in der NX-OS-Shell überprüft werden.
Problemszenario #4 - Anmeldung mit 'Remote Authentication' nicht möglich
Der Benutzer kann sich nicht anmelden oder hat schreibgeschützten Zugriff auf UCSM als Remote-Benutzer, wenn " Native Authentication " in einen Remote-Authentifizierungsmechanismus ( LDAP usw.) geändert wurde.
Empfehlung
Da UCSM auf die lokale Authentifizierung für den Konsolenzugriff zurückgreift, wenn er den Remote-Authentifizierungsserver nicht erreichen kann, können wir die folgenden Schritte durchführen, um ihn wiederherzustellen.
1. Trennen Sie das Management-Schnittstellenkabel des primären FI (Cluster-Status anzeigen würde angeben, der als primär agiert).
2. Verbindung zur Konsole des primären FI
3. Führen Sie die folgenden Befehle aus, um die native Authentifizierung zu ändern
scope security
show authentication
set authentication console local
set authentication default local
commit-buffer
4. Anschließen des Mgmt-Schnittstellenkabels
5. Melden Sie sich über UCSM unter Verwendung des lokalen Kontos an, und erstellen Sie eine Authentifizierungsdomäne für eine Remote-Authentifizierungsgruppe (z. B. LDAP).
HINWEIS: Das Trennen der Management-Schnittstelle hat KEINE Auswirkungen auf den Datenverkehr auf Datenebene.
Problemszenario #4 - LDAP-Authentifizierung funktioniert, aber SSL ist nicht aktiviert
Die LDAP-Authentifizierung funktioniert ohne Secure Socket Layer (SSL) einwandfrei, schlägt jedoch fehl, wenn die SSL-Option aktiviert ist.
Empfehlung
Der UCSM LDAP-Client verwendet die konfigurierten Vertrauenspunkte (CA-Zertifikate) beim Herstellen der SSL-Verbindung.
1. Stellen Sie sicher, dass der Vertrauenspunkt richtig konfiguriert wurde.
2. Das Identifikationsfeld in cert muss der " Hostname " des LDAP-Servers sein. Stellen Sie sicher, dass der in UCSM konfigurierte Hostname mit dem im Zertifikat vorhandenen Hostnamen übereinstimmt und gültig ist.
3. Stellen Sie sicher, dass in UCSM 'hostname' und nicht 'ipaddress' des LDAP-Servers konfiguriert ist und dass die lokale Verwaltungsschnittstelle darauf zugreifen kann.
Problemszenario #5 - Authentifizierung schlägt nach LDAP-Anbieteränderungen fehl
Die Authentifizierung schlägt fehl, nachdem der alte LDAP-Server gelöscht und ein neuer LDAP-Server hinzugefügt wurde.
Empfehlung
Wenn LDAP im Authentifizierungsbereich verwendet wird, ist das Löschen und Hinzufügen neuer Server nicht zulässig. Ab Version UCSM 2.1 würde dies zu einem FSM-Ausfall führen.
Beim Entfernen/Hinzufügen neuer Server in derselben Transaktion sind folgende Schritte auszuführen:
1. Stellen Sie sicher, dass alle Authentifizierungsbereiche, die LDAP verwenden, in "Lokal" geändert und die Konfiguration gespeichert werden.
2. Aktualisieren Sie die LDAP-Server, und überprüfen Sie, ob der FSM-Status erfolgreich abgeschlossen wurde.
3. Ändern Sie die Authentifizierungsbereiche der in Schritt 1 geänderten Domänen in LDAP.
Für alle anderen Problemszenarien - LDAP-Debugging
Aktivieren Sie die Debugging-Funktion, versuchen Sie, sich als LDAP-Benutzer anzumelden, und sammeln Sie die folgenden Protokolle zusammen mit dem UCSM-Technologiesupport, der fehlgeschlagene Anmeldeereignisse erfasst.
1) Öffnen Sie eine SSH-Sitzung für FI, melden Sie sich als lokaler Benutzer an, und ändern Sie den NX-OS CLI-Kontext.
ucs # connect nxos
2) Aktivieren Sie die folgenden Debug-Flags, und speichern Sie die SSH-Sitzungsausgabe in einer Protokolldatei.
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) Öffnen Sie jetzt eine neue GUI- oder CLI-Sitzung, und versuchen Sie, sich als Remote-Benutzer (LDAP) anzumelden.
4) Sobald Sie eine Meldung über einen Anmeldefehler erhalten haben, deaktivieren Sie die Debugs.
ucs(nxos)# undebug all
Paketerfassung von LDAP-Datenverkehr
In Szenarien, in denen eine Paketerfassung erforderlich ist, kann Ethanalyzer verwendet werden, um den LDAP-Verkehr zwischen FI und LDAP-Server zu erfassen.
ucs(nxos)# ethanalyzer local interface mgmt capture-filter "host <LDAP-server-IP-address>" detail limit-captured-frames 0 write /bootflash/sysdebug/diagnostics/test-ldap.pcap
Im obigen Befehl wird die pcap-Datei im Verzeichnis "/workspace/diagnostics" gespeichert und kann über den CLI-Kontext "local-mgmt" aus der FI abgerufen werden.
Mit dem Befehl oben können Pakete für jeden Remote-Authentifizierungsverkehr (LDAP, TACACS, RADIUS) erfasst werden.
5. Relevante Protokolle im UCSM-Technologiesupportpaket
Im UCSM-Technologiesupport finden Sie relevante Protokolle im Verzeichnis<FI>/var/sysmgr/sam_logs.
httpd.log
svc_sam_dcosAG
svc_sam_pamProxy.log
NX-OS commands or from <FI>/sw_techsupport log file
ucs-(nxos)# show system internal ldap event-history errors
ucs-(nxos)# show system internal ldap event-history msgs
ucs-(nxos)# show log
Bekannte Vorbehalte
CSCth96721
Rootdn des LDAP-Servers auf Spam sollte mehr als 128 Zeichen zulassen.
Die UCSM-Version vor 2.1 enthält eine Beschränkung auf 127 Zeichen für eine DN-Basiszeichenfolge/eine DN-Bindungszeichenfolge.
http://www.cisco.com/en/US/docs/unified_computing/ucs/sw/cli/config/guide/2.0/b_UCSM_CLI_Configuration_Guide_2_0_chapter_0111.html#task_0FC4E8245C6D4A64B5A1F575DAEC6127
--------- Snip ----------
Der spezifische Distinguished Name in der LDAP-Hierarchie, mit dem der Server eine Suche starten soll, wenn sich ein Remote-Benutzer anmeldet und das System versucht, die DN des Benutzers anhand seines Benutzernamens abzurufen. Die maximal unterstützte Zeichenfolgenlänge beträgt 127 Zeichen.
----------------------------
Problem in Version 2.1.1 und höher behoben
CSCuf19514
LDAP-Daemon abgestürzt
Beim Initialisieren der SSL-Bibliothek stürzt der LDAP-Client möglicherweise ab, wenn der ldap_start_tls_s-Aufruf mehr als 60 Sekunden dauert, um die Initialisierung abzuschließen. Dies kann nur bei ungültigen DNS-Einträgen oder Verzögerungen bei der DNS-Auflösung der Fall sein.
Ergreifen Sie Maßnahmen, um Verzögerungen und Fehler bei der DNS-Auflösung zu beheben.
CSCvt3134 - sicheres LDAP schlägt nach UCS-Infra-Upgrade von 4.0.4 auf 4.1 fehl
LDAP-Updates in der Infrastruktur-Firmware 4.1 und höher führten zu strengeren LDAP-Konfigurationsanforderungen in UCSM. Nach dem Upgrade von UCSM kann die LDAP-Authentifizierung fehlschlagen, bis die Konfiguration angepasst wurde. Weitere Informationen finden Sie in den Versionshinweisen von CSCvt 3134.