Konfigurationsbeispiel für LDAP auf IOS-Geräten mit dynamischen Attributzuordnungen

Download-Optionen

  • PDF     (139.2 KB)
    Mit Adobe Reader auf verschiedenen Geräten anzeigen
  • ePub     (93.0 KB)
    In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
  • Mobi (Kindle)     (83.7 KB)
    Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen
Aktualisiert:17. Januar 2013
Dokument-ID:113689

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

Einführung

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.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

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.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).

Kernproblem

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.

Lösung

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.

Konfigurieren

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.

Beispielkonfiguration

In diesem Dokument werden folgende Konfigurationen verwendet:

AD-Tools

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 *

Potenzielle Probleme

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.

Überprüfen

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

Fehlerbehebung

Dieser Abschnitt enthält Informationen zur Fehlerbehebung in Ihrer Konfiguration.

Befehle zur Fehlerbehebung

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

Zugehörige Informationen

TAC Authored

Beiträge von Cisco Ingenieuren

  • Atri Basu, Shaik Zubair, and Craig Lorentzen
    Cisco TAC Engineers.

War dieses Dokument hilfreich?

FeedbackFeedback

Cisco kontaktieren