In diesem Dokument wird beschrieben, wie die LDAP-Authentifizierung (Lightweight Directory Access Protocol) auf Cisco IOS®-Headends verwendet und der Standard-RDN (Relative Distinguished Name) von Common Name (CN) in sAMAccountName geändert wird.
Für dieses Dokument bestehen keine speziellen Anforderungen.
Die Informationen in diesem Dokument basieren auf einem Cisco IOS-Gerät, auf dem Cisco IOS Software Release 15.0 oder höher ausgeführt wird.
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).
Die meisten Microsoft Active Directory (AD)-Benutzer mit LDAP-Benutzern definieren ihren RDN in der Regel als sAMAccountName. Wenn Sie den Authentifizierungsproxy (auth-proxy) und eine Adaptive Security Appliance (ASA) als Headend für Ihre VPN-Clients verwenden, kann dies leicht behoben werden, wenn Sie den AD-Servertyp definieren, wenn Sie den AAA-Server definieren, oder wenn Sie den Befehl ldap-naming-attribute eingeben. In der Cisco IOS-Software ist jedoch keine dieser Optionen verfügbar. Standardmäßig verwendet die Cisco IOS-Software den CN-Attributwert in AD für die Authentifizierung von Benutzernamen. Beispielsweise wird ein Benutzer in AD als John Fernandes erstellt, seine Benutzer-ID wird jedoch als jfern gespeichert. Standardmäßig überprüft die Cisco IOS-Software den CN-Wert. Das heißt, die Software überprüft John Fernandes auf die Benutzernamenauthentifizierung und nicht den sAMAccountName-Wert von jfern für die Authentifizierung. Um zu erzwingen, dass die Cisco IOS-Software den Benutzernamen vom sAMAccountName-Attributwert überprüft, verwenden Sie dynamische Attributzuordnungen, wie in diesem Dokument beschrieben.
Obwohl Cisco IOS-Geräte diese Methoden der RDN-Änderung nicht unterstützen, können Sie in der Cisco IOS-Software dynamische Attributzuordnungen verwenden, um ein ähnliches Ergebnis zu erzielen. Wenn Sie den Befehl show ldap attribute im Cisco IOS-Headend eingeben, wird diese Ausgabe angezeigt:
LDAP-Attribut | Format | AAA-Attribut |
---|---|---|
airespaceBwDataBurstVertrag | unendlich | bsn- data-bandwidth-burst-contr |
UserPassword | Zeichenfolge | Kennwort |
airespaceBwRealBurstVertrag | unendlich | bsn-realtime-bandwidth-burst-c |
Mitarbeitertyp | Zeichenfolge | Mitarbeitertyp |
airespaceServiceType | unendlich | Servicetyp |
airespaceACLName | Zeichenfolge | bsn-acl-Name |
priv-lvl | unendlich | priv-lvl |
Mitglied von | string DN | Supplicant-Gruppe |
cn | Zeichenfolge | Benutzername |
airDSCP | unendlich | bsn-dscp |
policyTag | Zeichenfolge | Tag-Name |
AirQOSL-Ebene | unendlich | bsn-qos-Ebene |
Air8021PType | unendlich | bsn-8021p-Typ |
airespaceBwRealAveVertrag | unendlich | bsn-Echtzeit-Bandbreite - Durchschnitt |
airespaceVlanInterfaceName | Zeichenfolge | bsn-vlan-Schnittstellenname |
airespaceVapID | unendlich | bsn-wlan-id |
airBwDataAveVertrag | unendlich | bsn-data-bandwidth-average-con |
sAMAccountName | Zeichenfolge | Kontoname |
meetingContactInfo | Zeichenfolge | Kontaktinformationen |
Telefonnummer | Zeichenfolge | Telefonnummer |
Wie Sie aus dem hervorgehobenen Attribut sehen können, verwendet das Cisco IOS Network Access Device (NAD) diese Attributzuordnung für Authentifizierungsanforderungen und Antworten. Grundsätzlich funktioniert eine dynamische LDAP-Attributzuordnung im Cisco IOS-Gerät bidirektional. Mit anderen Worten, Attribute werden nicht nur beim Empfang einer Antwort, sondern auch beim Versenden von LDAP-Anforderungen zugeordnet. Ohne benutzerdefinierte Attributzuordnungen, eine grundlegende LDAP-Konfiguration im NAD, wird diese Protokollmeldung beim Versenden der Anforderung angezeigt:
*Jul 24 11:04:50.568: LDAP: Check the default map for aaa type=username *Jul 24 11:04:50.568: LDAP: Ldap Search Req sent ld 1054176200 base dn DC=csco,DC=com scope 2 filter (&(objectclass=*)(cn=xyz))ldap_req_encode put_filter "(&(objectclass=person)(cn=xyz))" put_filter: AND put_filter_list "(objectclass=person)(cn=xyz)" put_filter "(objectclass=person)" put_filter: simple put_filter "(cn=xyz)" put_filter: simple Doing socket write *Jul 24 11:04:50.568: LDAP: LDAP search request sent successfully (reqid:13)
Um dieses Verhalten zu ändern und zu erzwingen, das sAMAccountName-Attribut für die Überprüfung des Benutzernamens zu verwenden, geben Sie den Befehl ldap attribute map username ein, um diese dynamische Attributzuordnung zuerst zu erstellen:
ldap attribute map username map type sAMAccountName username
Wenn diese Attributzuordnung definiert wurde, geben Sie den Befehl attribute map <dynamic-attribute-map-name> ein, um diese Attributzuordnung der ausgewählten AAA-Servergruppe (aaa-server) zuzuordnen.
Hinweis: Um diesen gesamten Prozess zu vereinfachen, wurde die Cisco Bug ID CSCtr45874 (nur registrierte Kunden) abgelegt. Wenn diese Erweiterungsanfrage implementiert wird, können Benutzer ermitteln, welche LDAP-Server verwendet werden, und einige dieser Standardzuordnungen werden automatisch geändert, um die von diesem Server verwendeten Werte wiederzugeben.
In diesem Abschnitt erhalten Sie Informationen zum Konfigurieren der in diesem Dokument beschriebenen Funktionen.
Hinweis: Verwenden Sie das Command Lookup Tool (nur registrierte Kunden), um weitere Informationen zu den in diesem Abschnitt verwendeten Befehlen zu erhalten.
In diesem Dokument werden folgende Konfigurationen verwendet:
Geben Sie diesen Befehl ein, um die dynamische Attributzuordnung zu definieren:
ldap attribute mapmap type sAMAccountName username
Geben Sie diesen Befehl ein, um die AAA-Servergruppe zu definieren:
aaa group server ldapserver
Geben Sie diesen Befehl ein, um den Server zu definieren:
ldap serveripv4 attribute map bind authentication root-dn password base-dn
Geben Sie diesen Befehl ein, um die Liste der zu verwendenden Authentifizierungsmethoden zu definieren:
aaa authentication logingroup
Um den absoluten DN eines Benutzers zu überprüfen, geben Sie einen der folgenden Befehle über die AD-Eingabeaufforderung ein:
dsquery user -name user1
ODER
dsquery user -samid user1
Hinweis: "user1" oben erwähnt ist in regex String. Sie können auch alle DNs des Benutzernamens auflisten, die mit Benutzer beginnen, indem Sie die regex-Zeichenfolge als "user*" verwenden.
Um alle Attribute eines einzelnen Benutzers zu registrieren, geben Sie diesen Befehl über die AD-Eingabeaufforderung ein:
dsquery * -filter "(&(objectCategory=Person)(sAMAccountName=username))" -attr *
Bei einer LDAP-Bereitstellung wird zuerst der Suchvorgang und später der Bindungsvorgang ausgeführt. Dieser Vorgang wird ausgeführt, da bei der Rückgabe des Kennwortattributs im Rahmen des Suchvorgangs die Kennwortüberprüfung lokal auf dem LDAP-Client durchgeführt werden kann und kein zusätzlicher Bindungsvorgang erforderlich ist. Wenn das Kennwort-Attribut nicht zurückgegeben wird, kann zu einem späteren Zeitpunkt eine Bindung ausgeführt werden. Ein weiterer Vorteil, wenn Sie zuerst den Suchvorgang und später den Bindungsvorgang ausführen, besteht darin, dass die im Suchergebnis empfangene DN als Benutzer-DN statt als Verzeichnisnummer verwendet werden kann, wenn dem Benutzernamen (CN-Wert) ein Basis-DN vorangestellt wird.
Es können Probleme auftreten, wenn der Befehl authentication bind-first zusammen mit einem benutzerdefinierten Attribut verwendet wird, das sich ändert, wenn die Zuordnung des username-Attributs angezeigt wird. Wenn Sie beispielsweise diese Konfiguration verwenden, ist bei Ihrem Authentifizierungsversuch wahrscheinlich ein Fehler aufgetreten:
ldap server ss-ldap ipv4 192.168.1.3 attribute map ad-map transport port 3268 bind authenticate root-dn CN=abcd,OU=Employees,OU=qwrt Users,DC=qwrt,DC=com password blabla base-dn DC=qwrt,DC=com authentication bind-first ldap attribute-map ad-map map type sAMAccountName username
Als Ergebnis wird die Fehlermeldung Ungültige Anmeldeinformationen, Ergebniscode =49 angezeigt. Die Protokollmeldungen sehen ähnlich aus wie folgt:
Oct 4 13:03:08.503: LDAP: LDAP: Queuing AAA request 0 for processing Oct 4 13:03:08.503: LDAP: Received queue event, new AAA request Oct 4 13:03:08.503: LDAP: LDAP authentication request Oct 4 13:03:08.503: LDAP: Attempting first next available LDAP server Oct 4 13:03:08.503: LDAP: Got next LDAP server :ss-ldap Oct 4 13:03:08.503: LDAP: First Task: Send bind req Oct 4 13:03:08.503: LDAP: Authentication policy: bind-first Oct 4 13:03:08.503: LDAP: Dynamic map configured Oct 4 13:03:08.503: LDAP: Dynamic map found for aaa type=username Oct 4 13:03:08.503: LDAP: Bind: User-DN=sAMAccountName=abcd,DC=qwrt,DC=com ldap_req_encode Doing socket write Oct 4 13:03:08.503: LDAP: LDAP bind request sent successfully (reqid=36) Oct 4 13:03:08.503: LDAP: Sent the LDAP request to server Oct 4 13:03:08.951: LDAP: Received socket event Oct 4 13:03:08.951: LDAP: Checking the conn status Oct 4 13:03:08.951: LDAP: Socket read event socket=0 Oct 4 13:03:08.951: LDAP: Found socket ctx Oct 4 13:03:08.951: LDAP: Receive event: read=1, errno=9 (Bad file number) Oct 4 13:03:08.951: LDAP: Passing the client ctx=314BA6ECldap_result wait4msg (timeout 0 sec, 1 usec) ldap_select_fd_wait (select) ldap_read_activity lc 0x296EA104 Doing socket read LDAP-TCP:Bytes read = 109 ldap_match_request succeeded for msgid 36 h 0 changing lr 0x300519E0 to COMPLETE as no continuations removing request 0x300519E0 from list as lm 0x296C5170 all 0 ldap_msgfree ldap_msgfree Oct 4 13:03:08.951: LDAP:LDAP Messages to be processed: 1 Oct 4 13:03:08.951: LDAP: LDAP Message type: 97 Oct 4 13:03:08.951: LDAP: Got ldap transaction context from reqid 36ldap_parse_result Oct 4 13:03:08.951: LDAP: resultCode: 49 (Invalid credentials) Oct 4 13:03:08.951: LDAP: Received Bind Responseldap_parse_result ldap_err2string Oct 4 13:03:08.951: LDAP: Ldap Result Msg: FAILED:Invalid credentials, Result code =49 Oct 4 13:03:08.951: LDAP: LDAP Bind operation result : failed Oct 4 13:03:08.951: LDAP: Restoring root bind status of the connection Oct 4 13:03:08.951: LDAP: Performing Root-Dn bind operationldap_req_encode Doing socket write Oct 4 13:03:08.951: LDAP: Root Bind on CN=abcd,DC=qwrt,DC=com initiated.ldap_msgfree Oct 4 13:03:08.951: LDAP: Closing transaction and reporting error to AAA Oct 4 13:03:08.951: LDAP: Transaction context removed from list [ldap reqid=36] Oct 4 13:03:08.951: LDAP: Notifying AAA: REQUEST FAILED Oct 4 13:03:08.951: LDAP: Received socket event Oct 4 13:03:09.491: LDAP: Received socket event Oct 4 13:03:09.491: LDAP: Checking the conn status Oct 4 13:03:09.491: LDAP: Socket read event socket=0 Oct 4 13:03:09.491: LDAP: Found socket ctx Oct 4 13:03:09.495: LDAP: Receive event: read=1, errno=9 (Bad file number) Oct 4 13:03:09.495: LDAP: Passing the client ctx=314BA6ECldap_result wait4msg (timeout 0 sec, 1 usec) ldap_select_fd_wait (select) ldap_read_activity lc 0x296EA104 Doing socket read LDAP-TCP:Bytes read= 22 ldap_match_request succeeded for msgid 37 h 0 changing lr 0x300519E0 to COMPLETE as no continuations removing request 0x300519E0 from list as lm 0x296C5170 all 0 ldap_msgfree ldap_msgfree Oct 4 13:03:09.495: LDAP: LDAP Messages to be processed: 1 Oct 4 13:03:09.495: LDAP: LDAP Message type: 97 Oct 4 13:03:09.495: LDAP: Got ldap transaction context from reqid 37ldap_parse_result Oct 4 13:03:09.495: LDAP: resultCode: 0 (Success)P: Received Bind Response Oct 4 13:03:09.495: LDAP: Received Root Bind Response ldap_parse_result Oct 4 13:03:09.495: LDAP: Ldap Result Msg: SUCCESS, Result code =0 Oct 4 13:03:09.495: LDAP: Root DN bind Successful on:CN=abcd,DC=qwrt,DC=com Oct 4 13:03:09.495: LDAP: Transaction context removed from list [ldap reqid=37] ldap_msgfree ldap_result wait4msg (timeout 0 sec, 1 usec) ldap_select_fd_wait (select) ldap_err2string Oct 4 13:03:09.495: LDAP: Finished processing ldap msg, Result:Success Oct 4 13:03:09.495: LDAP: Received socket event
Die hervorgehobenen Zeilen weisen darauf hin, was mit der ursprünglichen Bindung vor der Authentifizierung nicht stimmt. Es funktioniert einwandfrei, wenn Sie den Befehl authentication bind-first aus der oben beschriebenen Konfiguration entfernen.
In diesem Abschnitt überprüfen Sie, ob Ihre Konfiguration ordnungsgemäß funktioniert.
Das Output Interpreter Tool (nur registrierte Kunden) (OIT) unterstützt bestimmte show-Befehle. Verwenden Sie das OIT, um eine Analyse der Ausgabe des Befehls show anzuzeigen.
LDAP-Attribute anzeigen
ldap server all anzeigen
Dieser Abschnitt enthält Informationen zur Fehlerbehebung in Ihrer Konfiguration.
Das Output Interpreter Tool (nur registrierte Kunden) (OIT) unterstützt bestimmte show-Befehle. Verwenden Sie das OIT, um eine Analyse der Ausgabe des Befehls show anzuzeigen.
Hinweis: Beachten Sie vor der Verwendung von Debug-Befehlen die Informationen zu Debug-Befehlen.
debuggen ldap all
debuggen ldap-Ereignis
debuggen aaa authentication
debuggen aaa autorisierung