Identity Service Engine (ISE) en Active Directory (AD) begrijpen

Inleiding

In dit document wordt beschreven hoe Identity Service Engine (ISE) en Active Directory (AD) communiceren, welke protocollen worden gebruikt, welke AD-filters worden gebruikt en hoe stromen worden gegenereerd.

Voorwaarden

Vereisten

Cisco adviseert een basiskennis van:

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

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

protocol van Kerberos  

De drie hoofden van Kerberos omvatten het Key Distribution Center (KDC), de clientgebruiker en de server die toegang heeft.

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 betrokken wanneer de client in eerste instantie toegang krijgt tot een serverbron:

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

• Domeincontroller = KDC (AS + TGS).
• Authenticeer naar AS (het SSO-portaal) met uw wachtwoord.
• Krijg een Ticket Granting Ticket (TGT) (een sessie cookie).
• Aanvraag inloggen bij een dienst (SRV01).
• SRV01 leidt u door naar KDC.
• TGT aan KDC tonen – (ik ben al geauthenticeerd)
• KDC geeft u TGS voor SRV01.
• Doorverwijzen naar SRV01.
• Toon serviceticket naar SRV01.
• SRV01 verifieert/vertrouwt serviceticket.
• Het 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 om te worden geverifieerd door het AS-gedeelte van een KDC binnen hun domein.

De KDC heeft toegang tot Active Directory-gebruikersaccountgegevens. Eenmaal geverifieerd, 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 tijdens de aanmeldingssessie van de gebruiker verlengd zonder dat de gebruiker zijn wachtwoord opnieuw hoeft in te voeren.

De TGT wordt in de cache van de lokale machine opgeslagen in een vluchtige geheugenruimte 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 van de gebruiker en maakt een ticket en sessiesleutel voor zowel de client als de externe server. Deze informatie (het serviceticket) wordt vervolgens lokaal opgeslagen op het clientsysteem.

De TGS ontvangt de client TGT en leest deze met zijn 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 zijn gedeelte met de TGS-sessiesleutel die eerder is opgehaald uit het AS-antwoord.

De client presenteert het servergedeelte van het TGS-antwoord aan de doelserver in de volgende client/server-uitwisseling.

Voorbeeld:

Pakketopnames van ISE voor een geverifieerde gebruiker:

De AS-REQ bevat de gebruikersnaam. Als het wachtwoord juist is, biedt de AS-service een TGT die is gecodeerd met het gebruikerswachtwoord. De TGT wordt vervolgens verstrekt aan de TGT-service om een sessieticket te krijgen.

Verificatie is succesvol wanneer een sessieticket is ontvangen.

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

Als het wachtwoord verkeerd is, mislukt het AS-verzoek en wordt er geen TGT ontvangen:


Meld u aan bij 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(), lwadvapi/threaded/lwkrb5.c:1325

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

2020-01-14 13:36:05,444 DEBUG ,140574072981248,krb5: Preauth tryAgain invoertypen: 16, 14, 19, 2,LwKrb5TraceCallback(), 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 gebruikt MS-RPC over SMB, SMB biedt de verificatie en vereist geen afzonderlijke 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.

• Maak een SMB-sessieverbinding.
• RPC-berichten transporteren via SMB/CIFS.TCP poort 445 als transport 
• SMB-sessie identificeert welke poort een bepaalde RPC-service uitvoert en verwerkt gebruikersverificatie.
• Verbinding maken met verborgen share IPC$ voor communicatie tussen processen.
• Open een toepasselijke named pipe voor de gewenste RPC-bron/functie.

Transacteer de RPC-uitwisseling via SMB.

De lijn negotiate protocol request/response onderhandelt over het dialect van het MKB. Het session setup request/response systeem voert de authenticatie uit.

Verbindingsverzoek en -reactie met de aangevraagde bron verbinden. U bent verbonden met een speciaal aandeel IPC$.

Dit interprocescommunicatie-aandeel biedt de communicatiemiddelen tussen hosts en ook als transport voor MSRPC-functies.

Bij pakket 77 is Create Request File en de bestandsnaam is de naam van de verbonden service (de netlogon-service in dit voorbeeld).

Bij pakketten 83 en 86 is het verzoek van NetrlogonSamLogonEX de plaats waar u de gebruikersnaam voor de clientverificatie op ISE naar de AD in het veld Network_INFO verzendt.

Het NetrlogonSamLogonEX-antwoordpakket reageert met de resultaten.

Enkele vlagwaarden voor de reactie van NetrlogonSamLogonEX:
0xc000006a is STATUS_WRONG_PASSWORD
0x00000000 is STATUS_SUCCES
0x00000103 is STATUS_IN BEHANDELING

ISE-integratie met Active Directory (AD)

ISE gebruikt LDAP, KRB en MSRBC om met AD te communiceren tijdens het join / leave- en authenticatieproces.

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.

In het geval dat de DC om welke reden dan ook offline raakt, mislukt ISE 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.

De Global Catalog stelt gebruikers en toepassingen in staat om objecten te vinden in elk domein van het huidige forest met een zoekopdracht naar attributen die zijn opgenomen in GC.

De globale catalogus bevat een basisset (maar onvolledige) kenmerken voor elk bosobject in elk domein (partiële kenmerkset, PAT).

De GC ontvangt gegevens van alle domeinmappartities in het forest. Ze worden gekopieerd met de standaard AD-replicatieservice.

ISE toevoegen aan AD

Voorwaarden voor Active Directory- en ISE-integratie

1. Controleer of u de rechten van een superbeheerder of systeembeheerder in ISE hebt.
2. Gebruik de NTP-serverinstellingen (Network Time Protocol) om de tijd tussen de Cisco-server en Active Directory te synchroniseren. Het maximaal toegestane tijdsverschil tussen ISE en AD is 5 minuten
3. De geconfigureerde DNS op ISE moet SRV-query's voor DC's, GC's en KDC's kunnen beantwoorden met of zonder aanvullende locatiegegevens.
4. Zorg ervoor dat alle DNS-servers DNS-query's kunnen doorsturen en omkeren voor elk mogelijk Active Directory DNS-domein.
5. AD moet ten minste één wereldwijde catalogusserver hebben die operationeel en toegankelijk is voor Cisco, in het domein waarbij u zich aansluit bij Cisco.

AD-domein toevoegen

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

1. Query's samengevoegd met domeinen—Hiermee worden domeinen uit het forest en domeinen die extern vertrouwd zijn met het samengevoegde domein, ontdekt.
2. Zoekt naar hoofddomeinen in het forest — Vertrouwt met het forest.
3. Zoekt naar hoofddomeinen in vertrouwde bossen: hiermee worden domeinen uit de vertrouwde bossen ontdekt.

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

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

1. Het join-proces begint met de invoerreferenties van super admin op AD die in het domein zelf bestaan. Als het bestaat in een ander domein of subdomein, 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 niet één van hen in het antwoord had, mislukt de integratie met DNS-gerelateerde fout.
3. ISE gebruikt de CLDAP-ping om alle DC's en GC's te ontdekken via verzonden CLDAP-verzoeken aan de DC's die overeenkomen met hun prioriteiten in het SRV-record. De eerste DC-respons wordt gebruikt en ISE wordt vervolgens op die DC aangesloten.

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.

Opmerking: CLDAP is het mechanisme dat ISE gebruikt om connectiviteit met de DC's tot stand te brengen en te onderhouden.  Het meet de responstijd tot het eerste DC-antwoord. Het faalt als je geen antwoord van DC ziet. Waarschuw als de responstijd groter is dan 2,5 seconden. CLDAP ping van alle DC's in de site (als er geen site is, dan alle DC's in het domein). De CLDAP-respons bevat de DC-site en de Client-site (de site waaraan de ISE-machine is toegewezen).

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

AD-domein verlaten

Wanneer ISE vertrekt, moet de AD rekening houden met:

1. Gebruik een volledige AD admin-gebruiker 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 is 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, wordt een leave-bewerking uitgevoerd en wordt de ISE-node losgekoppeld van het Active Directory-domein. (indien aangesloten). De ISE-nodeaccount wordt echter niet verwijderd uit het Active Directory-domein.
4. Het wordt aanbevolen om een leave-bewerking uit te voeren vanuit het Admin-portaal met de Active Directory-referenties, omdat hiermee ook de node-account uit het Active Directory-domein wordt verwijderd. Dit wordt ook aanbevolen wanneer u de ISE-hostnaam wijzigt.

DC-failover

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

1. De AD-connector detecteert dat de momenteel geselecteerde gelijkstroom niet beschikbaar was tijdens een CLDAP-, LDAP-, RPC- of Kerberos-communicatiepoging. In dergelijke gevallen initieert de AD-connector DC-selectie en loopt deze over naar de nieuw geselecteerde DC.
2. DC is ingeschakeld en reageert op CLDAP-ping, maar AD Connector kan om de een of andere reden niet communiceren (voorbeelden: RPC-poort is geblokkeerd, DC bevindt zich in 'kapotte replicatie'-status, DC is niet goed uit bedrijf genomen).

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 is geselecteerd in de lijst met geblokkeerde bestanden, wordt niet in de cache opgeslagen.

AD-connector moet failover binnen een redelijke termijn voltooien (of uitvallen als dit niet mogelijk is). Om deze reden probeert de AD-connector een beperkt aantal DC's tijdens failover.

ISE blokkeert AD Domain Controllers als er een niet-herstelbare netwerk- of serverfout is om te voorkomen dat ISE een slechte DC gebruikt. DC wordt niet toegevoegd aan de geblokkeerde lijst als deze niet reageert op CLDAP-pings. ISE verlaagt alleen de prioriteit van de DC die niet reageert.

ISE-AD-communicatie via LDAP

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

• SAM-naam: gebruikersnaam of systeemnaam zonder domeinopmaak, dit is de aanmeldingsnaam van de gebruiker in AD. Voorbeeld: sajeda of sajeda$

• CN: is de naam van de gebruikersweergave op AD, deze mag niet hetzelfde zijn als de SAM. Voorbeeld: sajeda Ahmed.

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

• Alternatief UPN: is een extra / alternatieve UPN-achtervoegsels die in de AD zijn geconfigureerd, met uitzondering van de domeinnaam. Deze configuratie wordt globaal toegevoegd in de AD (niet geconfigureerd per gebruiker) en het is niet nodig om een echt achtervoegsel voor de domeinnaam te zijn.

   Elke advertentie kan meerdere UPN-suffix (@alt1.com,@alt2.com,…, etc) hebben. Voorbeeld: hoofd-UPN (sajeda@cisco.com), alternatief-UPN :sajeda@domain1 , sajeda@domain2

• NetBIOS prefix naam: is de domeinnaam\username van de machine naam. Voorbeeld: CISCO\sajeda of CISCO\machine$

• Host/prefix met niet-gekwalificeerde machine: dit wordt gebruikt voor machineverificatie als alleen de naam van de machine wordt gebruikt, maar alleen de naam van de host/machine. Voorbeeld: host/machine

• Host / prefix met volledig gekwalificeerde machine: dit wordt gebruikt voor machine-authenticatie wanneer de Machine FQDN wordt gebruikt, meestal in het geval van certificaatauthenticatie, het is host / FQDN van de machine.  Voorbeeld: host/machine.cisco.com

• SPN-naam: de naam waarmee een client een instantie van een service uniek identificeert (voorbeelden: HTTP, LDAP, SSH) die alleen voor Machine wordt gebruikt.

Gebruikersverificatie tegen AD-stroom:

1. Identificatie oplossen en identiteitstype bepalen - SAM, UPN, SPN. Als ISE de identiteit alleen als gebruikersnaam ontvangt, wordt gezocht naar een gekoppelde SAM-account in de advertentie. Als ISE de identiteit ontvangt als een username@domain, zoekt het naar een overeenkomende UPN of e-mail in het AD. In beide scenario's gebruikt ISE extra filters voor machine of gebruikersnaam. 
2. Zoekdomein of forest (afhankelijk van identiteitstype)
3. Bewaar informatie over alle bijbehorende accounts (JP, DN, UPN, Domein)
4. Als er geen gekoppelde account wordt gevonden, is het antwoord van de gebruiker op de advertentie niet bekend.
5. Voer MS-RPC (of Kerberos)-verificatie uit voor elk gekoppeld account
6. Als slechts één account overeenkomt met de ingevoerde identiteit en het wachtwoord, is de verificatie succesvol
7. Als meerdere accounts overeenkomen met de inkomende identiteit, gebruikt ISE het wachtwoord om de dubbelzinnigheid op te lossen, zodat de account met een gekoppeld wachtwoord wordt geverifieerd en de andere accounts de onjuiste wachtwoordteller met 1 verhogen.
8. Als 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 die met AD wil communiceren. ISE zoekt altijd naar die entiteit in de groepen gebruikers en machines.

Voorbeelden van zoekfilters:

1. SAM-zoekopdracht: Als ISE alleen een identiteit als gebruikersnaam ontvangt zonder domeinopmaak, behandelt ISE deze gebruikersnaam als een SAM en zoekt in AD naar alle systeemgebruikers of machines die die identiteit als een SAM-naam hebben.

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.

Er zijn geen andere criteria om de juiste gebruiker te vinden, dus ISE faalt de authenticatie met een "dubbelzinnige identiteit" -fout.

Als het gebruikerscertificaat echter aanwezig is in Active Directory, gebruikt Cisco ISE binaire vergelijking om de identiteit op te lossen.

2. UPN- of MAIL-zoekopdracht: Als ISE een identiteit als username@domain ontvangt, zoekt ISE in elk forest in globale catalogi naar een overeenkomst met die UPN-identiteit of Mail-identiteit "identity=matched UPN or email".

Als er een unieke match is, gaat Cisco ISE verder met de AAA-stroom.

Als er meerdere join-punten zijn met hetzelfde UPN en een wachtwoord of hetzelfde UPN en Mail, mislukt Cisco ISE de verificatie met een fout "ambigue identiteit".

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

4. Zoeken op systeembasis: Als ISE een systeemverificatie ontvangt met een host-/prefix-identiteit, zoekt ISE in het forest naar een overeenkomend servicePrincipalName-kenmerk.

Als in de identiteit een volledig gekwalificeerd domeinsuffix is opgegeven, bijvoorbeeld host/machine.domain.com, zoekt Cisco ISE in het forest waar dat domein bestaat.

Als de identiteit zich in de vorm van een host/machine bevindt, zoekt Cisco ISE in alle bossen naar de hoofdnaam van de service.

Als er meer dan één overeenkomst is, mislukt Cisco ISE de verificatie met een foutmelding "Dubbelzinnige identiteit".

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

Opmerking: ISE 2.2 patch 4 en eerdere en 2.3 patch 1 en eerdere geïdentificeerde gebruikers met de attributen SAM, CN of beide. Cisco ISE, versie 2.2 Patch 5 en hoger, en 2.3 Patch 2 en hoger, gebruiken alleen het kenmerk sAMAaccountName als standaardkenmerk.