Identity Service Engine en Active Directory begrijpen

Inleiding

Dit document beschrijft hoe Identity Service Engine (ISE) en Active Directory (AD) communiceren, protocollen die worden gebruikt, AD-filters en stromen.

---

Voorwaarden

Vereisten

Cisco raadt u aan om basiskennis te hebben van:

• Externe identiteitsverificatie op ISE
• ISE 2.x en Active Directory-integratie

---

Gebruikte componenten

• ISE 2.x 
• Windows Server (Active Directory) 

---

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

---

AD-protocollen

Kerberos-protocol  

De drie hoofden van Kerberos bestaan uit het Key Distribution Center (KDC), de clientgebruiker en de server om toegang te krijgen. De KDC wordt geïnstalleerd als onderdeel van de Domain Controller (DC) en voert twee servicefuncties uit: de Authentication Service (AS) en de Ticket Granting Service (TGS).

---

Er zijn drie uitwisselingen nodig wanneer de client in eerste instantie toegang heeft tot een serverbronnen:

1. AS-uitwisseling
2. TGS-uitwisseling
3. Client/Server (CS) Exchange

---

---

• Domeincontroller = KDC (AS + TGS)
• Verifieer bij AS (het SSO-portaal) met uw wachtwoord
• Verkrijg een Ticket Granting Ticket (TGT) (een sessie cookie)
• Inloggen bij een service aanvragen (SRV01)
• SRV01 leidt u door naar KDC
• TGT aan KDC tonen – (ik ben al geverifieerd)
• KDC geeft u TGS voor SRV01
• Doorverwijzen naar SRV01
• Toont serviceticket naar SRV01
• SRV01 verifieert/vertrouwt serviceticket
• Service ticket bevat al mijn informatie
• SRV01 logt me in

---

Wanneer gebruikers zich in eerste instantie bij een netwerk hebben aangemeld, moeten ze onderhandelen over toegang en een inlognaam en wachtwoord opgeven die moeten worden geverifieerd door het AS-gedeelte van een KDC binnen hun domein. De KDC heeft toegang tot Active Directory-gebruikersaccountgegevens. Na authenticatie krijgt de gebruiker een Ticket Granting Ticket (TGT) dat geldig is voor het lokale domein. De TGT heeft een standaardlevensduur van 10 uur en wordt gedurende de aanmeldingssessie van de gebruiker vernieuwd zonder dat de gebruiker het wachtwoord opnieuw moet invoeren. De TGT wordt in een vluchtige geheugenruimte op de lokale machine in een cache opgeslagen en wordt gebruikt om sessies met services in het hele netwerk aan te vragen.

---

De gebruiker presenteert de TGT aan het TGS-gedeelte van de KDC wanneer toegang tot een serverservice nodig is. De TGS op de KDC verifieert de TGT-gebruiker en maakt een ticket- en sessiesleutel voor zowel de client als de externe server. Deze informatie (het serviceticket) wordt vervolgens lokaal opgeslagen op de clientmachine. De TGS ontvangt de TGT-client en leest met een eigen sleutel. Als de TGS het verzoek van de client goedkeurt, wordt een serviceticket gegenereerd voor zowel de client als de doelserver. De client leest het gedeelte met de TGS-sessiesleutel die eerder uit het AS-antwoord is opgehaald. De client presenteert het servergedeelte van het TGS-antwoord aan de doelserver in de volgende client/serveruitwisseling.

---

Voorbeeld:

---

Packet captures van ISE voor een geverifieerde gebruiker:

---

De AS-REQ bevat de gebruikersnaam. Als het wachtwoord correct is, biedt de AS-service een TGT die is gecodeerd met het gebruikerswachtwoord. De TGT wordt vervolgens door de TGT-service geleverd om een sessieticket te ontvangen. Authenticatie is succesvol wanneer een sessieticket wordt ontvangen.

---

Dit is een voorbeeld waarbij het wachtwoord dat door de klant is opgegeven onjuist is:

---

Als het wachtwoord onjuist is, mislukt het AS-verzoek en wordt de TGT niet ontvangen:

---

In dit volgende voorbeeld zijn dit logs in het bestand ad_agent.log wanneer het wachtwoord onjuist is:

2020-01-14 13:36:05,442 DEBUG , 140574072981248, krb5: Verzonden verzoek (276 bytes) naar RALMAAIT.COM, LwKrb5TraceCallback(TM), lwadvapi/threaded/lwkrb5.c:1325

2020-01-14 13:36:05,444 DEBUG , 140574072981248, krb5: Ontvangen fout van KDC: -1765328360/Preauthenticatie mislukt, LwKrb5TraceCallback(TM), lwadvapi/threaded/lwkrb5.c:1325

2020-01-14 13:36:05,444 DEBUG , 140574072981248, krb5: Preauth tryAgain invoertypen: 16, 14, 19, 2, LwKrb5TraceCallback(TM), lwadvapi/threaded/lwkrb5.c:1325

2020-01-14 13:36:05,444 WAARSCHUWING, 140574072981248, [LwKrb5GetTgtImpl ../../lwadvapi/threaded/krbtgt.c:329] KRB5 Foutcode: -1765328360 (Bericht: Preauthenticatie mislukt), LwTranslateKrb5Error(), lwadvapi/threaded/lwkrb5.c:892

2020-01-14 13:36:05,444 DEBUG , 140574072981248, [LwKrb5InitializeUserLoginCredentials()] Foutcode: 40022 (symbool: LW_ERROR_PASSWORD_MISMATCH), LwKrb5InitializeUserLoginCredentials(), lwadvapi/threaded/lwkrb5.c:1453

---

MS-RPC-protocol

ISE maakt gebruik van MS-RPC via SMB, en SMB biedt de verificatie en vereist geen aparte sessie om te vinden waar een bepaalde RPC-service zich bevindt. Het maakt gebruik van een mechanisme genaamd "named pipe" om te communiceren tussen de client en de server.

---

• Een SMB-sessieverbinding maken
• Vervoer RPC-berichten via SMB/CIFS.TCP poort 445 als een transport 
• SMB-sessie identificeert welke poort een bepaalde RPC-service uitvoert en verwerkt gebruikersverificatie
• Verbinding maken met verborgen IPC$-share voor communicatie tussen processen
• Open een geschikte benoemde pijp voor de gewenste RPC-bron/functie
• Transacteer de RPC-uitwisseling via het MKB

---

---

De regel Protocolaanvraag/antwoord onderhandelen onderhandelt over het dialect van SMB en het sessieopstellingsverzoek/antwoord voert de verificatie uit. Verzoek en antwoord voor structuurverbinding maken verbinding met de aangevraagde bron. U bent verbonden met een speciaal aandeel IPC$. Dit interprocescommunicatie-aandeel biedt de communicatiemiddelen tussen hosts en ook als transport voor MSRPC-functies.

---

Packet 77 is het aanvraagbestand maken en de bestandsnaam is de naam van de verbonden service (de netlogon-service in dit voorbeeld).

Pakketten 83 en 86 zijn de NetLogonSamLogonEX-aanvraag, waarbij u de gebruikersnaam voor de clientverificatie op ISE naar het AD stuurt in het veld Network_INFO. Het antwoordpakket van NetrlogonSamLogonEX reageert met de resultaten.

---

Enkele vlaggenwaarden voor de respons van NetrlogonSamLogonEX:

0xc000006a is STATUS_WRONG_PASSWORD
0x00000000 is STATUS_SUCCES
0x00000103 is STATUS_PENDING

---

ISE-integratie met Active Directory (AD)

ISE maakt gebruik van LDAP, KRB en MSRBC om met AD te communiceren tijdens het join / leave- en verificatieproces. De volgende secties bevatten de protocollen, het zoekformaat en de mechanismen die worden gebruikt om verbinding te maken met een specifieke DC op AD en gebruikersverificatie tegen die DC. Als de DC om welke reden dan ook offline wordt, wordt ISE niet doorgestuurd naar de volgende beschikbare DC en wordt het verificatieproces niet beïnvloed.

---

Een Global Catalog Server (GC) is een domeincontroller die kopieën van alle Active Directory-objecten in het forest opslaat. Het slaat een volledige kopie van alle objecten op in de directory van uw domein en een gedeeltelijke kopie van alle objecten van alle andere bosdomeinen. Met de Global Catalog kunnen gebruikers en toepassingen objecten vinden in elk domein van het huidige forest met een zoektocht naar attributen die zijn opgenomen in de GC. De Global Catalog bevat een basis (maar onvolledige) set van attributen voor elk forest object in elk domein (Partial Attribute Set, PAT).

De GC ontvangt gegevens van alle domeindirectorypartities in het forest en deze worden gekopieerd met de standaard AD-replicatieservice.

---

Sluit je aan bij ISE AD

Voorwaarden voor Active Directory en ISE-integraties.

1. Controleer of u over de rechten van een Super Admin of System Admin in ISE beschikt.
2. Gebruik de NTP-serverinstellingen (Network Time Protocol) om de tijd tussen de Cisco-server en Active Directory te synchroniseren. Het maximale toegestane tijdsverschil tussen ISE en AD is 5 minuten.
3. De geconfigureerde DNS op ISE moet SRV-vragen voor DC's, GC's en KDC's beantwoorden met of zonder aanvullende sitegegevens.
4. Zorg ervoor dat alle DNS-servers DNS-query's voor elk mogelijk Active Directory DNS-domein kunnen beantwoorden en omkeren.
5. AD moet ten minste één wereldwijde catalogusserver hebben die operationeel is en toegankelijk is voor Cisco, voor het domein dat u van plan bent aan te sluiten bij Cisco.

---

Lid worden van AD-domein

ISE past Domain Discovery toe om informatie over het domein join in drie fasen te krijgen:

1. Query's die zich bij domeinen hebben aangesloten—Hiermee worden domeinen uit het forest en domeinen die extern worden vertrouwd in het gekoppelde domein ontdekt.
2. Zoekt rootdomeinen in het forest op—hiermee wordt vertrouwen met het forest gecreëerd.
3. Zoekt naar rootdomeinen in vertrouwde bossen - ontdekt domeinen uit de vertrouwde bossen.

Daarnaast ontdekt Cisco ISE DNS-domeinnamen (UPN-achtervoegsels), alternatieve UPN-achtervoegsels en NTLM-domeinnamen.

---

ISE past een DC-detectie toe om alle informatie over de beschikbare DC's en GC's te verkrijgen.

1. Het join-proces begint met de inputreferenties van een superbeheerder op AD die in het domein zelf bestaan. Als het in een ander domein of subdomein bestaat, moet de gebruikersnaam worden genoteerd in een UPN-notatie (username@domain).
2. ISE verzendt een DNS-query voor alle DC's, GC's en KDC's-records. Als het DNS-antwoord geen antwoord ontvangt, mislukt de integratie met een DNS-gerelateerde fout.
3. ISE gebruikt de CLDAP-ping om alle DC's en GC's te ontdekken via de verzonden CLDAP-verzoeken aan de DC's die overeenkomen met hun prioriteiten in het SRV-record. De eerste DC-respons wordt gebruikt en ISE is verbonden met die DC.

Een factor die wordt gebruikt om de DC-prioriteit te berekenen, is de tijd die de DC nodig heeft om te reageren op CLDAP-pings; een snellere respons krijgt een hogere prioriteit.

---

---

4. ISE ontvangt TGT met de 'join user'-referenties.
5. Genereer de ISE-rekeningnaam met de MSRPC (SAM en SPN).
6. Zoek AD op SPN als het ISE-machineaccount al bestaat. Als de ISE-machine niet bestaat, maakt ISE een nieuwe.
7. Open het machineaccount en stel het ISE-machineaccountwachtwoord in en controleer of het ISE-machineaccount toegankelijk is.
8. Stel de ISE-systeemaccountkenmerken in (SPN, dnsHostname, enzovoort).
9. Ontvang TGT met ISE machine referenties met KRB5 en ontdek alle vertrouwde domeinen.
10. Wanneer de verbinding is voltooid, werkt ISE-node de AD-groepen en bijbehorende SIDS bij en begint automatisch het SID-updateproces. Controleer of dit proces aan de AD-kant kan worden voltooid.

---

AD-domein verlaten

Wanneer ISE vertrekt, moet het AD overwegen:

1. Gebruik een volledige AD-beheerder om de verlofprocessen uit te voeren. Hiermee wordt gecontroleerd of de ISE-systeemaccount uit de Active Directory-database is verwijderd.
2. Als de advertentie zonder referenties wordt achtergelaten, wordt de ISE-account niet verwijderd uit de advertentie en moet deze handmatig worden verwijderd.
3. Wanneer u de ISE-configuratie opnieuw instelt vanuit de CLI of de configuratie terugzet na een back-up of upgrade, voert deze een verlofbewerking uit en verbreekt deze de verbinding van de ISE-node met het Active Directory-domein. Als u echter lid wordt, wordt de ISE-nodeaccount niet verwijderd uit het Active Directory-domein.
4. Het wordt aanbevolen om een verlofbewerking uit te voeren vanaf het beheerportaal met de Active Directory-referenties, omdat het ook de nodeaccount verwijdert uit het Active Directory-domein. Dit wordt ook aanbevolen wanneer u de ISE-hostnaam wijzigt.

---

DC-failover

Wanneer de DC die is aangesloten op de ISE om welke reden dan ook offline of onbereikbaar wordt, wordt DC-failover automatisch geactiveerd op ISE. DC-failover kan worden geactiveerd door de volgende omstandigheden:

1. AD-connector detecteert dat de momenteel geselecteerde DC niet beschikbaar is tijdens een poging tot communicatie met CLDAP, LDAP, RPC of Kerberos. In dergelijke gevallen initieert de AD-connector DC-selectie en faalt deze naar de nieuw geselecteerde DC.
2. DC staat aan en reageert op CLDAP ping, maar de AD Connector kan om de een of andere reden niet met hem communiceren (bijvoorbeeld, de RPC-poort is geblokkeerd, DC bevindt zich in de staat van 'gebroken replicatie', DC is niet goed buiten bedrijf gesteld).

---

In dergelijke gevallen initieert de AD-connector DC-selectie met een geblokkeerde lijst ("slechte" DC wordt in de geblokkeerde lijst geplaatst) en probeert te communiceren met de geselecteerde DC. De DC die in de lijst met geblokkeerde apparaten is geselecteerd, wordt niet in de cache opgeslagen.

De AD-connector moet de failover binnen een redelijke termijn voltooien (of uitvallen indien dit niet mogelijk is). Om deze reden probeert de AD-connector een beperkt aantal DC's uit tijdens failover. De ISE blokkeert AD Domain Controllers als er een niet-herstelbare netwerk- of serverfout is om te voorkomen dat de ISE een slechte DC gebruikt. De DC wordt niet toegevoegd aan de geblokkeerde lijst als deze niet reageert op CLDAP-pings. ISE verlaagt alleen de prioriteit van de DC als het niet reageert.

---

ISE-AD-communicatie via LDAP

ISE zoekt naar een machine of gebruiker in AD met een van deze zoekformaten. Als het zoeken naar een machine was, voegt ISE "$" toe aan het einde van de machinenaam. Dit is een lijst met identiteitstypen die wordt gebruikt om een gebruiker in AD te identificeren:

---

• SAM-naam: Gebruikersnaam of systeemnaam zonder domeinmarkering, dit is de gebruikersnaam voor aanmelden in AD. Voorbeeld: sajeda of sajeda$

• CN: Dit is de gebruikersnaam die wordt weergegeven op AD, het mag niet hetzelfde zijn als de SAM. Voorbeeld: sajeda Ahmed

• Gebruikersnaam (UPN): Dit is een combinatie van de SAM-naam en domeinnaam (SAM_NAME@domian). Voorbeeld: sajeda@cisco.com of sajeda$@cisco.com

• Alternatieve UPN: Dit is een aanvullend/alternatief UPN-achtervoegsel dat is geconfigureerd in het AD anders dan de domeinnaam. Deze configuratie wordt wereldwijd toegevoegd in AD (niet geconfigureerd per gebruiker) en is niet nodig om een echt achtervoegsel voor domeinnamen te zijn.
  • Elke advertentie kan meerdere UPN-achtervoegsels hebben (@alt1.com,@alt2.com, enzovoort). Bijvoorbeeld hoofd UPN (sajeda@cisco.com), alternatief UPN :sajeda@domain1, sajeda@domain2

• NetBIOS Prefixed Name: Dit is de domeinnaam/gebruikersnaam van de systeemnaam. Bijvoorbeeld CISCO\sajeda of CISCO\machine$

• Host/Prefix met een niet-gekwalificeerde machine: Dit wordt gebruikt voor machineverificatie wanneer de machinenaam alleen wordt gebruikt en het alleen de host/machinenaam is. Bijvoorbeeld host/machine.

• Host/Prefix met volledig gekwalificeerde machine: Dit wordt gebruikt voor machineverificatie wanneer de machine FQDN wordt gebruikt, meestal in het geval van certificaatverificatie. Het is de host/FQDN van de machine. Bijvoorbeeld host/machine.cisco.com.

• SPN-naam: De naam van een client identificeert op unieke wijze een instantie van een service (bijvoorbeeld HTTP, LDAP, SSH) die alleen voor de machine wordt gebruikt.

---

Gebruikersverificatie tegen AD-stroom:

1. Los identiteit op en bepaal het identiteitstype - SAM, UPN, SPN. Als ISE de identiteit alleen als gebruikersnaam ontvangt, zoekt het naar een geassocieerd SAM-account in AD. Als ISE de identiteit als een username@domain ontvangt, zoekt het naar een overeenkomende UPN of e-mail in AD. In beide scenario's gebruikt ISE extra filters voor een machine of een gebruikersnaam. 
2. Zoek in het domein of het forest (afhankelijk van het identiteitstype).
3. Bewaar informatie over alle bijbehorende accounts (JP, DN, UPN, Domain.)
4. Als er geen gekoppelde account wordt gevonden, is het niet bekend welke antwoorden met de gebruiker zijn ontvangen.
5. Voer MS-RPC (of Kerberos)-verificatie uit voor elke gekoppelde account.
6. Als slechts één account overeenkomt met de ingevoerde identiteit en het wachtwoord, is de verificatie geslaagd.
7. Als meerdere accounts overeenkomen met de inkomende identiteit, gebruikt ISE het wachtwoord om de dubbelzinnigheid op te lossen en wordt het account met een geassocieerd wachtwoord geverifieerd terwijl de andere accounts de onjuiste wachtwoordteller met 1 verhogen.
8. Als er geen account overeenkomt met de inkomende identiteit en het wachtwoord, antwoordt AD met een verkeerd wachtwoord.

---

ISE-zoekfilters

Filters worden gebruikt om een entiteit te identificeren om met AD te communiceren. ISE zoekt altijd naar een entiteit in de groep gebruikers en machines. Voorbeelden van zoekfilters:

1. SAM-zoekopdracht: Als de ISE alleen een identiteit als gebruikersnaam ontvangt zonder domeinmarkering, behandelt ISE de gebruikersnaam als een SAM en zoekt in AD naar alle machinegebruikers of machines die de identiteit als een SAM-naam hebben.
2. Als de SAM-naam niet uniek is, gebruikt ISE het wachtwoord om onderscheid te maken tussen gebruikers en is ISE geconfigureerd om een wachtwoordloos protocol zoals EAP-TLS te gebruiken.
3. Er zijn geen andere criteria om de juiste gebruiker te vinden, dus ISE faalt de verificatie met een "Ambiguous Identity" -fout. Als het gebruikerscertificaat echter aanwezig is in Active Directory, gebruikt Cisco ISE een binaire vergelijking om de identiteit op te lossen.

---

---

2. UPN of MAIL Search: Als ISE een identiteit als username@domain ontvangt, zoekt ISE in de algemene catalogus van het forest naar een overeenkomst met de UPN-identiteit of Mail-identiteit "identity=matched UPN or email". Als er een unieke overeenkomst is, gaat Cisco ISE verder met de AAA-stroom. Als er meerdere aanmeldpunten zijn met dezelfde UPN en een wachtwoord, of dezelfde UPN en Mail, mislukt de verificatie door Cisco ISE met een "Ambiguous Identity"-fout.

---

---

3. NetBIOS Search: Als ISE een identiteit ontvangt met een NetBIOS-domeinprefix (bijvoorbeeld CISCO\sajedah), zoekt ISE in de bossen naar het NetBIOS-domein. Eenmaal gevonden, zoekt het naar de meegeleverde SAM-naam (sajeda bijvoorbeeld).

---

---

4. Zoeken op basis van machines: als ISE een machineverificatie met een host/prefix-identiteit ontvangt, zoekt ISE in het forest naar een overeenkomend kenmerk van servicePrincipalName. Als een volledig gekwalificeerd domeinachtervoegsel in de identiteit is opgegeven, zoals host/machine.domain.com. Cisco ISE doorzoekt het bos waar het domein bestaat. Als de identiteit in de vorm van een host/machine is, zoekt Cisco ISE in alle bossen naar de naam van de servicepresident. Als er meer dan één overeenkomst is, mislukt de verificatie door Cisco ISE met een "Ambiguous Identity"-fout.

---

Opmerking: Dezelfde filters worden weergegeven in de bestanden ISE ad-agent.log.

Opmerking: ISE 2.2-patch 4, 2.3-patch, 1 en eerdere geïdentificeerde gebruikers met de kenmerken SAM, CN of beide. Cisco ISE, versie 2.2 Patch 5 en hoger en 2.3 Patch 2 en hoger, gebruiken alleen het attribuut sAMAccountName als standaardattribuut.

---

Revisiegeschiedenis

Revisie	Publicatiedatum	Opmerkingen
3.0	04-Aug-2026	Bijgewerkte inleiding, titel, spelling, grammatica, ingevoegde horizontale regels om secties/leesbaarheid te scheiden, bijgewerkte alt-tekst.
2.0	03-Aug-2022	Grammatica, structuur, machinevertaling, stijl, indeling
1.0	06-Feb-2020	Eerste vrijgave