Identity Service Engine (ISE)- und Active Directory (AD)-Kommunikation; Protokolle, Filter und Fluss - Cisco
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Identity Service Engine (ISE)- und Active Directory (AD)-Kommunikation; Protokolle, Filter und Fluss. Inhalt Einführung Voraussetzungen Anforderungen Verwendete Komponenten AD-Protokolle Kerberos-Protokoll MS-RPC-Protokoll ISE-Integration mit Active Directory (AD) Werden Sie Teil der ISE AD-Domäne beitreten AD-Domäne verlassen RZ-Failover ISE-AD-Kommunikation über LDAP Benutzerauthentifizierung gegen AD-Flow: ISE-Suchfilter Einführung In diesem Dokument wird die Kommunikation zwischen Identity Service Enginer (ISE) und Active Directory (AD) sowie allen verwendeten Protokollen beschrieben. Sie deckt auch AD-Filter und - Flows ab. Voraussetzungen Anforderungen Cisco empfiehlt, grundlegende Kenntnisse in folgenden Bereichen zu erwerben: ● ISE 2.x- und Active Directory-Integration ● Externe Identitätsauthentifizierung auf der ISE. Verwendete Komponenten ● ISE 2.x
● Windows Server (Active Directory) AD-Protokolle Kerberos-Protokoll Der Kerberos-Protokollname basiert auf der dreiköpfigen Hundefigur aus der griechischen Mythologie Kerberos. Die drei Köpfe von Kerberos umfassen das Key Distribution Center (KDC), den Client-Benutzer und den Server mit dem gewünschten Service für den Zugriff. Der KDC wird als Teil des Domain Controller (DC) installiert und führt zwei Dienstfunktionen aus: Der Authentifizierungsdienst (AS) und der Ticket-Granting Service (TGS). Wie in Abbildung 1 veranschaulicht, sind drei Datenaustausch erforderlich, wenn der Client anfänglich auf eine Serverressource zugreift: 1. AS Exchange. 2. TGS Exchange 3. Client/Server (CS) Exchange ● Domänencontroller = KDC (AS + TGS). ● Authentifizieren Sie sich mit Ihrem Kennwort bei AS (dem SSO-Portal). ● Sichern Sie sich ein Ticket-Ticket (TGT) (ein persönliches Sitzungscookie).
● Anfordern der Anmeldung bei einem Service (SRV01) ● SRV01 "leitet" Sie zum KDC um. ● Zeigen Sie dem KDC TGT an: Ich bin bereits authentifiziert. ● KDC stellt Ihnen TGS für SRV01 zur Verfügung. ● Umleitung zu SRV01 ● Service Ticket zur SRV01 anzeigen. ● Die SRV01 überprüft/vertraut das Serviceticket. ● Das Service Ticket enthält alle meine Daten. ● SRV01 meldet mich an. Bei der erstmaligen Anmeldung bei einem Netzwerk müssen Benutzer den Zugriff aushandeln, indem sie einen Anmeldenamen und ein Passwort eingeben, um vom AS-Teil eines KDC in ihrer Domäne verifiziert zu werden. Der KDC hat Zugriff auf Active Directory- Benutzerkontoinformationen. Nach erfolgreicher Authentifizierung erhält der Benutzer ein Ticket to Get Tickets (TGT), das für die lokale Domäne gültig ist. Das TGT hat eine Standardlebensdauer von 10 Stunden und kann während der Anmeldesitzung des Benutzers verlängert werden, ohne dass der Benutzer sein Kennwort erneut eingeben muss. Das TGT wird im flüchtigen Speicher auf dem lokalen Computer zwischengespeichert und dient zum Anfordern von Sitzungen mit Diensten im gesamten Netzwerk. Im Folgenden wird der TGT-Abrufprozess erläutert. Der Benutzer zeigt das TGT dem TGS-Teil des KDC an, wenn er den Zugriff auf einen Serverdienst wünscht. Der TGS auf dem KDC authentifiziert das TGT des Benutzers und erstellt ein Ticket und einen Sitzungsschlüssel für den Client und den Remote-Server. Diese Informationen, das so genannte Service-Ticket, werden dann lokal auf dem Client-Computer zwischengespeichert. Das TGS empfängt das TGT des Clients und liest es mithilfe seines eigenen Schlüssels. Wenn der TGS die Anfrage des Kunden genehmigt, wird sowohl für den Client als auch für den Zielserver ein Service-Ticket erstellt. Der Client liest seinen Teil mithilfe des TGS- Sitzungsschlüssels, der zuvor aus der AS-Antwort abgerufen wurde. Der Client stellt den Serverteil der TGS-Antwort dem Zielserver im nächsten Client/Server-Austausch vor. Nachfolgend finden Sie ein Beispiel für die Anwendung eines Testbenutzers auf ISE mit Kerberos:
Paketerfassungen von der ISE für einen Benutzer, der sich erfolgreich authentifiziert hat: Der AS-REQ enthält den Benutzernamen. Wenn das Kennwort korrekt ist, stellt der AS-Dienst uns einen mit dem Benutzerkennwort verschlüsselten TGT zur Verfügung. Danach wird der TGT dem TGT-Dienst zur Verfügung gestellt, um ein Sitzungsticket zu erhalten. Sobald Sie ein Sitzungsticket erhalten haben, wird die Authentifizierung erfolgreich abgeschlossen. Die folgenden Erfassungen beziehen sich auf das Szenario, in dem das vom Client angegebene Kennwort falsch ist: Wenn das Kennwort falsch ist, wird die AS-Anforderung daher fehlschlagen. Sie erhalten kein TGT:
meldet sich bei falschem Kennwort bei der Datei ad_agent.log an: 2020-01-14 13:36:05.442 DEBUG ,140574072981248,krb5: Anfrage (276 Byte) an RALMAIT.COM für user1@RALMAAIT.COM,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325 2020-01-14 13:36:05.444 DEBUG ,140574072981248,krb5: Fehler vom KDC empfangen: - 1765328360/Vorauthentifizierung fehlgeschlagen,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325 2020-01-14 13:36:05.444 DEBUG ,140574072981248,krb5: Eingabetypen für Preauth: 16, 14, 19, 2,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325 2020-01-14 13:36:05,444 WARNUNG,140574072981248,[LwKrb5GetTgtImpl ../../lwadvapi/threaded/krbtgt.c:329] KRB5-Fehlercode: -1765328360 (Nachricht: Vorauthentifizierung fehlgeschlagen),LwTranslateKrb5Error(),lwadvapi/threaded/lwkrb5.c:892 2020-01-14 13:36:05,444 DEBUG ,140574072981248,[LwKrb5InitializeUserLoginCredentials()] Fehlercode: 40022 (Symbol: LW_ERROR_PASSWORD_MISMATCH),LwKrb5InitializeUserLoginCredentials(),lwadvapi/threade d/lwkrb5.c:1453 MS-RPC-Protokoll Die ISE verwendet MSRPC über SMB, SMB stellt die Authentifizierung bereit und benötigt keine separate Sitzung, um den Standort eines bestimmten RPC-Service zu ermitteln. Zur Kommunikation zwischen Client und Server wird ein Mechanismus namens "Named Pipe" verwendet. wie folgt: Erstellen einer SMB-Sitzungsverbindung ● Transport von RPC-Nachrichten über den SMB/CIFS.TCP Port 445 als Transport ● In der SMB-Sitzung wird ermittelt, auf welchem Port ein bestimmter RPC-Service ausgeführt ● wird und auch die Benutzerauthentifizierung übernimmt. Stellen Sie eine Verbindung zum versteckten Teilen von IPC$ her, um die Kommunikation ● zwischen Prozessen zu ermöglichen. Öffnen Sie eine passende benannte Pipe für die gewünschte RPC-Ressource/-Funktion. ● RPC-Austausch über SMB
Über die Anforderung/Antwort des Verhandlungsprotokolls wird das Dialekt von SMB ausgehandelt. Die Sitzungseinrichtungsanfrage/-antwort führt die Authentifizierung durch. Tree Connect Request and Response stellt eine Verbindung mit der angeforderten Ressource her. Sie stellen eine Verbindung zu einem speziellen IPC$ her. Diese prozessübergreifende Kommunikationsharing bietet die Möglichkeit, zwischen Hosts zu kommunizieren und auch als Transport für MSRPC-Funktionen. Dann befinden Sie sich auf dem Paket Nr. 77, wo es die Option "Create Request File" (Anforderungsdatei erstellen) ist und der Dateiname der Name des Diensts ist, mit dem Sie eine Verbindung herstellen, in diesem Fall der Netzwerkdienst. Jetzt befinden Sie sich bei den Paketen 83 und 86, bei der NetrlogonSamLogonEX-Anforderung senden Sie den Benutzernamen für den Client, der sich auf der ISE authentifiziert, an das AD im Feld Network_INFO, das NetrlogonSamLogonEX-Antwortpaket antwortet mit dem Ergebnis, einige Flags-Werte für die Die Antwort von NetrlogonSamLogonEX bedeutet: 0xc00006a ist STATUS_WRONG_PASSWORD 0x0000000 ist STATUS_SUCCESS 0x00000103 ist STATUS_AUSSTEHEND ISE-Integration mit Active Directory (AD) Die ISE verwendet LDAP, KRB und MSRBC für die Kommunikation mit AD während des Join/Leave- und Authentifizierungsprozesses. In den nächsten Abschnitten werden die Protokolle, das Suchformat und der Mechanismus für die Verbindung mit einem bestimmten Rechenzentrum bei AD und die Authentifizierung der Benutzer gegenüber diesem Rechenzentrum beschrieben. Falls das Rechenzentrum aus irgendeinem Grund offline geschaltet wird, führt die ISE ein Failover
auf das nächste verfügbare Rechenzentrum durch, und der Authentifizierungsprozess wird nicht
beeinträchtigt.
Werden Sie Teil der ISE
Voraussetzungen für die Integration von Active Directory und ISE
1. Stellen Sie sicher, dass Sie über die Berechtigungen eines Super Admin oder System Admin
in der ISE verfügen.
2. Verwenden Sie die NTP-Servereinstellungen (Network Time Protocol), um die Zeit zwischen
dem Cisco Server und Active Directory zu synchronisieren. Der maximal zulässige
Zeitunterschied zwischen ISE und AD beträgt 5 Minuten.
3. Der konfigurierte DNS auf der ISE muss in der Lage sein, SRV-Anfragen für DCs, GCs und
KDCs mit oder ohne zusätzliche Standortinformationen zu beantworten.
Hinweis: Ein Global Catalog Server (GC) ist ein Domänen-Controller, der Kopien aller Active
Directory-Objekte im Wald speichert. Es speichert eine vollständige Kopie aller Objekte im
Verzeichnis Ihrer Domäne und eine Teilkopie aller Objekte aller anderen Walddomänen. Der
globale Katalog ermöglicht es Benutzern und Anwendungen, Objekte in jeder Domäne des
aktuellen Waldes zu finden, indem nach Attributen gesucht wird, die GC enthalten sind. Der
Globale Katalog enthält einen grundlegenden (aber unvollständigen) Satz von Attributen für
jedes Waldobjekt in jeder Domäne (Partial Attribute Set, PAT). Der GC empfängt Daten von
allen Domänen-Verzeichnispartitionen im Wald, die mithilfe des standardmäßigen AD-
Replikationsservice kopiert werden. Weitere Informationen finden Sie unter
https://theitbros.com/global-catalog-active-directory/
4. Stellen Sie sicher, dass alle DNS-Server die DNS-Abfragen für alle möglichen Active
Directory DNS-Domänen, die Sie verwenden möchten, weiterleiten und rückgängig machen
können.
5. AD muss über mindestens einen globalen Katalogserver verfügen, der von Cisco betrieben
und zugänglich ist, und zwar in der Domäne, der Sie Cisco beitreten.
AD-Domäne beitreten
Die erste ISE wendet die Domänenerkennung an, um Informationen über die Join-Domäne in drei
Phasen abzurufen:
1. Abfragen bei mehreren Domänen - Erkennt Domänen aus dem Wald und Domänen, denen
die externe Vertrauenswürdigkeit der verbundenen Domäne gilt.
2. Sucht die Stammdomänen in seinem Wald ab - etabliert Vertrauen in den Wald.
3. Abfragen von Stammdomänen in vertrauenswürdigen Wäldern - Erkennt Domänen aus
vertrauenswürdigen Wäldern.
4. Darüber hinaus erkennt die Cisco ISE DNS-Domänennamen (UPN-Suffixe), alternative UPN-
Suffixe und NTLM-Domänennamen.
Anschließend wird die ISE eine Rechenzentrumserkennung anwenden, um alle Informationen
über die verfügbaren Rechenzentren und GCs abzurufen. Gehen Sie wie folgt vor:
1. Der Join-Prozess wird gestartet, indem Sie die Anmeldeinformationen des Super Admin auf
AD eingeben, die in der Domäne selbst vorhanden sind. Wenn der Benutzername in eineranderen Domäne oder Unterdomäne vorhanden ist, sollte er in einer UPN-Notation
(username@domain) vermerkt werden.
2. Die ISE sendet eine DNS-Abfrage, in der alle Datensätze von Rechenzentren, GCs und
KDCs angefordert werden, wenn die DNS-Antwort keinen Eintrag enthält, wird die Integration
mit DNS-bezogenen Fehlern fehlgeschlagen.
3. Die ISE verwendet das CLDAP-Ping, um alle Rechenzentren und GCs zu ermitteln. Hierzu
werden den Rechenzentren CLDAP-Anfragen entsprechend ihren Prioritäten im SRV-
Datensatz gesendet. wird die erste DC-Antwort verwendet, und die ISE wird mit diesem
Rechenzentrum verbunden. Einer der Faktoren, der zur Berechnung der DC-Priorität
verwendet wurde, ist die Zeit, die das Rechenzentrum benötigt, um auf CLDAP-Pings zu
reagieren. eine schnellere Reaktion erhält eine höhere Priorität.
Hinweis: CLDAP ist der Mechanismus, mit dem die ISE die Verbindung zu den
Rechenzentren herstellt und aufrechterhält. Es misst die Reaktionszeit bis zur ersten DC-
Antwort. Es schlägt fehl, wenn Sie keine Antwort von DC sehen. Warnung, wenn die
Reaktionszeit größer als 2,5 Sekunden ist. CLDAP pingen alle Rechenzentren vor Ort (wenn
kein Standort vorhanden ist, dann alle Rechenzentren in der Domäne). Die CLDAP-Antwort
enthält den Standort des Rechenzentrums und den Client-Standort (z. B. den Standort, dem
der ISE-Computer zugewiesen ist).
4. Anschließend erhält die ISE TGT mit Anmeldeinformationen für "join user".
5. Generieren Sie mithilfe von MSRPC den Namen des ISE-Computerkontos. (SAM und SPN)
6. Suchen Sie nach AD by SPN, wenn das ISE-Systemkonto bereits vorhanden ist (z. B. bereits
erstellt), wenn das ISE-System noch nicht vorhanden ist, wird eine neue ISE erstellt (im
nächsten Abschnitt finden Sie eine kurze Beschreibung zu SPN und SAM).
7. Öffnen Sie das Maschinenkonto, legen Sie das Kennwort des ISE-Computerkontos fest, und
überprüfen Sie, ob auf das ISE-Systemkonto zugegriffen werden kann.
8. Festlegen von Kontoattributen für ISE-Systeme (z. B. SPN, dnsHostname usw.).
9. Rufen Sie TGT mit den Anmeldeinformationen des ISE-Systems über KRB5 ab, und
ermitteln Sie alle vertrauenswürdigen Domänen.
10. Nach Abschluss der Join-Aktion aktualisiert der ISE-Knoten seine AD-Gruppen und die
zugehörigen SIDS und startet automatisch den SID-Aktualisierungsprozess. Sie müssen
sicherstellen, dass dieser Prozess auf der AD-Seite abgeschlossen werden kann.
AD-Domäne verlassen
Wenn die ISE das nachfolgende AD verlässt, sollten Überlegungen berücksichtigt werden:
1. Sie müssen einen vollständigen AD-Admin-Benutzer verwenden, um die Urlaubsvorgänge
durchzuführen. Dadurch wird sichergestellt, dass das ISE-Computerkonto aus der Active
Directory-Datenbank entfernt wird.
2. Wurde das AD ohne Anmeldeinformationen belassen, wird das ISE-Konto nicht aus dem AD
entfernt, und Sie müssen es manuell löschen.
3. Wenn Sie die ISE-Konfiguration von der CLI zurücksetzen oder die Konfiguration nach einem
Backup oder Upgrade wiederherstellen, führt sie einen Urlaubsvorgang durch und trennt den
ISE-Knoten von der Active Directory-Domäne, wenn er bereits verbunden ist. Das ISE-Node-
Konto wird jedoch nicht aus der Active Directory-Domäne entfernt. Sie empfehlen, einen
Urlaubsvorgang vom Admin-Portal mit den Active Directory-Anmeldeinformationen
durchzuführen, da das Node-Konto auch aus der Active Directory-Domäne entfernt wird.Dies wird auch empfohlen, wenn Sie den ISE-Hostnamen ändern.
RZ-Failover
Wenn das mit der ISE verbundene Rechenzentrum offline wird oder aus irgendeinem Grund nicht
erreichbar ist, wird bei der ISE automatisch ein Rechenzentrums-Failover ausgelöst. Ein RZ-
Failover kann unter den folgenden Bedingungen ausgelöst werden:
1. AD Connector erkennt, dass momentan ausgewähltes DC während einiger
Kommunikationsversuche von CLDAP, LDAP, RPC oder Kerberos nicht verfügbar ist. In
diesem Fall initiiert der AD-Anschluss die Gleichstromauswahl und führt einen Failover zum
neu ausgewählten Rechenzentrum durch.
2. Das Rechenzentrum ist betriebsbereit und reagiert auf CLDAP-Ping, aber AD Connector
kann aus irgendeinem Grund nicht mit ihm kommunizieren (z. B. RPC-Port ist blockiert,
Rechenzentrum befindet sich im Zustand "defekte Replikation", Rechenzentrum wurde nicht
ordnungsgemäß außer Betrieb genommen usw.). In diesem Fall initiiert der AD-Anschluss
die Gleichstromauswahl mit einer schwarzen Liste (in der schwarzen Liste wird "schlechtes"
Gleichstrom angezeigt) und versucht, mit dem ausgewählten Gleichstrom zu kommunizieren.
Weder das mit der Blacklist ausgewählte Rechenzentrum noch die Blacklist werden
zwischengespeichert.
AD-Connector muss Failover innerhalb einer angemessenen Frist abschließen (oder ausfallen,
wenn dies nicht möglich ist). Aus diesem Grund versucht AD Connector während des Failovers
eine begrenzte Anzahl von DCs zu testen (Versuche bedeuten, dass das RZ aus dem RZ
ausgewählt wird und versucht, mit ihm zu kommunizieren). Die ISE Blacklist der AD Domain-
Controller, wenn ein Netzwerk- oder Serverfehler vorliegt, der nicht behebbar ist, um zu
verhindern, dass die ISE ein schlechtes Rechenzentrum verwendet, wodurch die
Verarbeitungszeit und der Kopfzerbrechen verringert werden. Beachten Sie, dass DC nicht zur
Blacklist hinzugefügt wird, wenn es nicht auf CLDAP-Pings reagiert. ISE senkt nur die Priorität des
Rechenzentrums, das nicht reagiert.
ISE-AD-Kommunikation über LDAP
Die ISE sucht in AD nach Geräten oder Benutzern unter Verwendung eines der folgenden
Suchformate. Wenn die Suche nach Maschinen durchgeführt wurde, fügt die ISE "$" am Ende des
Gerätenamens hinzu. Nachfolgend finden Sie eine Liste von Identitätstypen, die zur Identifizierung
eines Benutzers in AD verwendet werden:
● SAM-Name: Benutzername oder Computername ohne Domänenmarkup. Dies ist der
Benutzername für die Anmeldung im AD.
Beispiel: Sajeda oder Sajeda$
● KN: ist der Anzeigename des Benutzers auf AD, sollte er nicht mit dem SAM identisch sein.
Beispiel: sajeda Ahmed.
● Benutzername (UPN): ist eine Kombination aus dem SAM-Namen und dem Domänennamen
(SAM_NAME@domian).
Beispiel: sajeda@cisco.com oder sajeda$@cisco.com
● Alternative UPN: ist ein zusätzlicher und/oder alternativer UPN-Suffix, der im AD konfiguriertwurde, mit Ausnahme des Domänennamen. Diese Konfiguration wird global im AD
hinzugefügt (nicht pro Benutzer konfiguriert) und es ist nicht erforderlich, ein echtes
Domänenname-Suffix zu sein. Jedes AD kann mehrere UPN-Suffix(@alt1.com,@alt2.com,..
usw.) haben.
Beispiel: Haupt-UPN (sajeda@ciso.com), Alternative UPN:sajeda@aaa.com , sajeda@ise.com
●Präfixname NetBIOS: ist der Domänenname\Benutzername des Gerätenamens.
Beispiel: CISCO\sajeda oder CISCO\machine$
● Host/Präfix mit nicht qualifiziertem System: Diese wird für die Computerauthentifizierung
verwendet, wenn nur der Computername verwendet wird, sondern nur der Host-
/Computername.
Beispiel: Host/Rechner
●Host/Präfix mit voll qualifizierter Maschine: Diese wird für die maschinelle Authentifizierung
verwendet, wenn der Computer-FQDN verwendet wird, in der Regel bei der
Zertifikatsauthentifizierung, handelt es sich um Host/FQDN des Computers.
Beispiel: host/machine.cisco
● SPN-Name: Der Name, mit dem ein Client eine Instanz eines Dienstes eindeutig identifiziert,
z. B. HTTP, LDAP, SSH usw., die nur für Computer verwendet wird.
Benutzerauthentifizierung gegen AD-Flow:
1. Löst die Identität auf und bestimmt den Identitätstyp - SAM, UPN, SPN usw. Wenn die ISE
die Identität nur als Benutzernamen erhält, sucht sie im AD nach einem entsprechenden
SAM-Konto. Wenn die ISE die Identität als username@domain erhält, sucht sie im AD nach
einem übereinstimmenden UPN oder einer E-Mail. In beiden Szenarien verwendet die ISE
einen zusätzlichen Filter für den Computer oder Benutzernamen (Person).
2. Domäne oder Wald durchsuchen (abhängig vom Identitätstyp)
3. Informationen über alle übereinstimmenden Konten (JP, DN, UPN, Domäne usw.) behalten
4. Wenn kein passendes Konto gefunden wird, antwortet AD mit dem Benutzer ist unbekannt.
5. MS-RPC- (oder Kerberos)-Authentifizierung für jedes passende Konto durchführen
6. Wenn nur ein Konto mit der eingehenden Identität und dem eingehenden Kennwort
übereinstimmt, wurde die Authentifizierung erfolgreich durchgeführt.
7. Wenn mehrere Konten der eingehenden Identität entsprechen, verwendet die ISE das
Kennwort, um die Mehrdeutigkeit zu beheben, sodass das Konto mit einem
übereinstimmenden Kennwort authentifiziert wird und die anderen Konten den falschen
Kennwortzähler um 1 erhöhen.
8. Wenn kein Konto der eingehenden Identität und dem Kennwort entspricht, antwortet AD mit
einem falschen Kennwort.
ISE Filter durchsuchen
Filter werden verwendet, um eine Entität zu identifizieren, die mit AD kommunizieren möchte. Die
ISE sucht in den Benutzer- und Computergruppen immer nach dieser Entität.
Einige Beispiele für Suchfilter:1. SAM-Suche: Wenn die ISE eine Identität nur als Benutzername ohne Domänennamen empfängt, behandelt die ISE diesen Benutzernamen als SAM und sucht in AD nach allen erstellten Benutzern oder Geräten, die diese Identität als SAM-Namen haben. Wenn der SAM-Name nicht eindeutig ist, verwendet die ISE das Kennwort, um zwischen Benutzern zu unterscheiden, und die ISE ist so konfiguriert, dass sie ein Kennwort ohne Kennworteingabe wie EAP-TLS verwendet. Es gibt keine anderen Kriterien, um den richtigen Benutzer zu finden. Daher schlägt die ISE die Authentifizierung mit dem Fehler "Ambiguous Identity" (Uneindeutige Identität) fehl. Wenn das Benutzerzertifikat jedoch in Active Directory vorhanden ist, verwendet die Cisco ISE einen binären Vergleich, um die Identität aufzulösen. 2. UPN- oder MAIL-Suche: Wenn die ISE eine Identität als username@domain erhält, durchsucht die ISE die globalen Kataloge jedes Waldes nach einer Übereinstimmung mit dieser UPN-Identität oder E-Mail-Identität "identity= matching UPN or email". Bei einer eindeutigen Übereinstimmung wird die Cisco ISE mit dem AAA-Fluss fortgeführt. Wenn es mehrere Verbindungspunkte mit demselben UPN und einem Kennwort oder demselben UPN und E-Mail-Konto gibt, schlägt die Cisco ISE die Authentifizierung mit dem Fehler "Ambiguous Identity" (Ungewisse Identität) fehl.
3. NetBIOS-Suche: Wenn die ISE eine Identität mit einem NetBIOS-Domänenpräfix (z. B. CISCO\Sajedah) erhält, sucht die ISE in den Wäldern nach der NetBIOS-Domäne. Sobald diese gefunden wurde, sucht sie nach dem bereitgestellten SAM-Namen (in unserem Beispiel Sajeda). 4. Suche in Systembasis: Wenn die ISE eine Maschinenauthentifizierung erhält, wobei die Identität über einen Host/ein Präfix verfügt, durchsucht die ISE den Wald nach einem entsprechenden servicePrincipalName-Attribut. Wenn ein vollqualifizierter Domänen-Suffix in der Identität angegeben wurde, z. B. host/machine.domain.com, durchsucht die Cisco ISE den Wald, in dem diese Domäne existiert. Wenn die Identität in Form von Host/Maschine vorliegt, sucht die Cisco ISE alle Wälder nach dem Namen des Serviceprinzips. Bei mehreren Übereinstimmungen schlägt die Cisco ISE die Authentifizierung mit dem Fehler "Ambiguous Identity" (Uneindeutige Identität) fehl.
Hinweis: Dieselben Filter werden in den Dateien ISE ad-agent.log angezeigt. Hinweis: ISE 2.2 Patch 4 und frühere Versionen und 2.3 Patch 1 und frühere Versionen identifizierten Benutzer, die die Attribute SAM, CN oder beide verwendeten. Cisco ISE, Version 2.2 Patch 5 und höher und 2.3 Patch 2 und höher, verwenden als Standardattribut nur sAMAccountName.
Sie können auch lesen
