De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
Dit document beschrijft hoe Identity Service Engine (ISE) en Active Directory (AD) communiceren, gebruikte protocollen, AD-filters en stromen.
Cisco adviseert een basiskennis van:
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.
De drie koppen van Kerberos bestaan uit het Key Distribution Center (KDC), de clientgebruiker en de server die toegang moet krijgen.
De KDC wordt geïnstalleerd als onderdeel van de Domain Controller (DC) en heeft twee servicefuncties: de Verificatiedienst (AS) en de Ticket-Granting Service (TGS).
Drie uitwisselingen zijn betrokken wanneer de client in eerste instantie toegang heeft tot een serverbron:
Wanneer gebruikers zich voor het eerst aanmelden bij een netwerk, 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 de informatie van de Active Directory-gebruikersaccount. 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 tijdens de aanmeldingssessie vernieuwd zonder dat de gebruiker zijn wachtwoord opnieuw moet invoeren.
De TGT wordt op de lokale machine in vluchtige geheugenruimte gecachet en wordt gebruikt om sessies aan te vragen met diensten door het hele netwerk.
De gebruiker legt de TGT voor aan het TGS-gedeelte van de KDC wanneer toegang tot een serverservice nodig is.
De TGS op de KDC verifieert de gebruiker TGT en maakt een ticket en sessiesleutel voor zowel de client als de externe server. Deze informatie (het servicekaartje) wordt vervolgens lokaal op de clientmachine gecachet.
De TGS ontvangt de client TGT en leest deze met een eigen sleutel. Als de TGS het cliëntverzoek goedkeurt, wordt een dienstkaartje geproduceerd voor zowel de cliënt als de doelserver.
De client leest zijn deel 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/server-uitwisseling.
Voorbeeld:
Packet-opnamen van ISE voor een geverifieerde gebruiker:
De AS-REQ bevat de gebruikersnaam. Als het wachtwoord juist is, biedt de AS-service een TGT die met het gebruikerswachtwoord is versleuteld. De TGT wordt vervolgens aan de TGT-dienst geleverd om een sessieticket te krijgen.
Verificatie is succesvol wanneer een sessieticket is ontvangen.
Dit is een voorbeeld waarbij het wachtwoord gegeven door client onjuist is:
Als het wachtwoord niet goed is, wordt de AS-aanvraag mislukt en wordt er geen TGT ontvangen:
Logt het bestand ad_agent.log in als het wachtwoord onjuist is:
2020-01-14 13:36:05,442 DEBUG,140574072981248,krb5: Verzend verzoek (276 bytes) naar RALMAAIT.COM,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325
2020-01-14 13:36:05,444 DEBUG,140574072981248,krb5: Ontvangen fout van KDC: -1765328360/Preauthenticatie mislukt,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325
2020-01-14 13:36:05,444 DEBUG,140574072981248,krb5: Preauth probeer opnieuw 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: voorverificatie mislukt), LwTranslateKrb5Error(),lwadvapi/threaded/lwkrb5.c:892
2020-01-14 13:36:05,444 DEBUG ,140574072981248,[wKrb5InitializeUserLoginCredentials()] Foutcode: 40022 (symbool: LW_ERROR_PASSWORD_MISMATCH), LwKrb5InitializeUserLoginCredentials(), lwadvapi/threaded/lwkrb5.c:1453
ISE maakt gebruik van MS-RPC via 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 "met name pipe" om te communiceren tussen de client en server.
Transformeer de RPC exchange via SMB.
Het negotiate protocol request/response
De lijn onderhandelt over het dialect van SMB. Het session setup request/response
voert de verificatie uit.
Tree Connect-verzoek en -antwoord maken verbinding met de gevraagde bron. U bent verbonden met een speciaal gedeelde IPC$.
Dit interprocescommunicatie-aandeel biedt de communicatiemiddelen tussen hosts en ook als transport voor MSRPC-functies.
Bij pakket 77 wordt Create Request File
en de bestandsnaam is de naam van de aangesloten service (de netwerkservice in dit voorbeeld).
Bij de pakketten 83 en 86, is het NetrlogonSamLogonEX verzoek waar u de gebruikersnaam voor de cliëntauthentificatie op ISE naar de advertentie bij het gebied Network_INFO verzendt.
Het NetlogonSamLogonEX reactiepakket antwoordt met de resultaten.
Sommige vlaggenwaarden voor de reactie van NetrlogonSamLogonEX:
0xc000006a is STATUS_FOUT_WACHTWOORD
0x00000000 is STATUS_SUCCES
0x00000103 is STATUS_PENDING
ISE gebruikt LDAP, KRB en MSRBC om te communiceren met AD tijdens het toetreden/verlaten en authenticatieproces.
De volgende secties verstrekken de protocollen, het onderzoeksformaat, en de mechanismen die worden gebruikt om met een specifieke DC op AD en gebruikersauthentificatie tegen dat DC te verbinden.
In het geval dat de DC om welke reden dan ook offline wordt, gaat ISE over naar de volgende beschikbare DC en wordt het authenticatieproces niet beïnvloed.
Een Global Catalog Server (GC) is een domeincontroller die kopieën van alle Active Directory-objecten in het bos opslaat.
Het slaat een volledige kopie van alle objecten op in de map van uw domein en een gedeeltelijke kopie van alle objecten van alle andere bosdomeinen.
De Global Catalog stelt gebruikers en applicaties in staat om objecten te vinden in elk domein van het huidige bos met een zoektocht naar attributen opgenomen in GC.
De Global Catalog bevat een basis (maar onvolledige) reeks attributen voor elk bosobject in elk domein (Partial Attribute Set, PAT).
De GC ontvangt gegevens van alle domeindirectory partities in het bos. Ze worden gekopieerd met de standaard AD replicatieservice.
Voorwaarden voor Active Directory en ISE-integratie
ISE past Domain Discovery toe om informatie te verkrijgen over het Joed-domein in drie fasen:
Daarnaast detecteert Cisco ISE DNS-domeinnamen (UPN-achtervoegsels), alternatieve UPN-achtervoegsels en NTLM-domeinnamen.
ISE past een DC-ontdekking toe om alle informatie over de beschikbare DC’s en GC’s te krijgen.
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 de verbinding met de DC’s tot stand te brengen en te onderhouden. Het meet de reactietijd tot het eerste DC antwoord. Het mislukt als je geen antwoord van DC ziet. Waarschuwen als de responstijd groter is dan 2,5 seconden. CLDAP pingt alle DC's in de site (als er geen site is, dan alle DC's in het domein). De CLDAP-respons bevat DC-site en clientsite (de site waaraan ISE-machine is toegewezen).
Wanneer ISE vertrekt, moet de AD rekening houden met:
Wanneer de DC verbonden met ISE offline of onbereikbaar wordt om welke reden dan ook, wordt DC failover automatisch geactiveerd op ISE. DC failover kan worden geactiveerd door de volgende omstandigheden:
In dergelijke gevallen start de AD-connector DC-selectie met een geblokkeerde lijst ("slechte" DC wordt in de geblokkeerde lijst geplaatst) en probeert hij te communiceren met de geselecteerde DC. DC die in de geblokkeerde lijst is geselecteerd, wordt niet gecached.
De AD-connector moet de failover binnen een redelijke tijd voltooien (of falen 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 onherstelbare 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 zoekt naar machine of gebruiker in AD met een van deze zoekformaten. Als de zoekactie op een machine is uitgevoerd, voegt ISE "$" toe aan het einde van de naam van de machine. Dit is een lijst van identiteitstypen die wordt gebruikt om een gebruiker in AD te identificeren:
Elke AD kan meerdere UPN-achtervoegsels hebben (@alt1.com,@alt2.com,..., etc). Voorbeeld: belangrijkste UPN (sajeda@cisco.com), alternatief UPN:sajeda@domain1 , sajeda@domain2
Filters worden gebruikt om een entiteit te identificeren die met AD wil communiceren. ISE zoekt altijd naar die entiteit in de gebruikers- en machinegroepen.
Voorbeelden van zoekfilters:
Als de SAM-naam niet uniek is, gebruikt ISE het wachtwoord om onderscheid te maken tussen gebruikers en wordt ISE geconfigureerd om een wachtwoordloos protocol te gebruiken zoals EAP-TLS.
Er zijn geen andere criteria om de juiste gebruiker te vinden, dus ISE faalt de authenticatie met een "Ambiguous Identity" fout.
Als het gebruikerscertificaat echter in Active Directory aanwezig is, gebruikt Cisco ISE binaire vergelijking om de identiteit op te lossen.
Als er een unieke overeenkomst is, gaat Cisco ISE verder met de AAA-stroom.
Als er meerdere samengevoegde punten zijn met hetzelfde UPN en een wachtwoord of dezelfde UPN en Mail, mislukt Cisco ISE de verificatie met een fout in "Ambiguous Identity".
Als een volledig-gekwalificeerd domeinachtervoegsel in de identiteit werd gespecificeerd, bijvoorbeeld host/machine.domain.com, zoekt Cisco ISE in het bos waar dat domein bestaat.
Als de identiteit de vorm heeft van een host/machine, zoekt Cisco ISE alle bossen naar de naam van het onderhoudspersoneel.
Als er meer dan één overeenkomst is, faalt Cisco ISE-verificatie met een fout in "Ambiguous Identity".
Opmerking: dezelfde filters worden weergegeven in ISE ad-agent.log-bestanden
Opmerking: ISE 2.2 patch 4 en Prior en 2.3 patch 1 en eerdere geïdentificeerde gebruikers met de kenmerken SAM, CN, of beide. Cisco ISE, release 2.2 Patch 5 en hoger, en 2.3 Patch 2 en hoger, gebruiken alleen het kenmerk AccountName als het standaardkenmerk.
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
2.0 |
03-Aug-2022 |
Grammatica, structuur, machinevertaling, stijl, formaat |
1.0 |
06-Feb-2020 |
Eerste vrijgave |