Configuratievoorbeeld van ISR IP-
toegangsrechten en LDAP voor webomleiding naar ScanSafe/Cloud Web Security
Inhoud
Inleiding Voorwaarden Vereisten
Gebruikte componenten Achtergrondinformatie Configureren
Netwerkdiagram LDAP configureren AAA configureren
IP-toegang configureren IP-toegang inschakelen
Vrijstellen van verificatie in hosts HTTP-server op ISR inschakelen CWS-omleiding configureren
Configuratie van volledige steekproef LDAP
AAA
IP-toegang HTTP-server
Content Scan en CWS
Bepaal de DNS-objecten in de AD - ADSI-bewerking Verificatiemethoden
Active NTLM
Transparante NTLM
Basis verificatie (via HTTP in duidelijke tekst) Passive NTLM
Berichtreeks voor actieve NTLM-verificatie Verifiëren
Problemen oplossen Opdrachten weergeven Opdrachten debug
Veelvoorkomende problemen
IP-toegangsrechten onderscheppen geen HTTP-aanvragen Mogelijke oplossingen
Gebruikers ontvangen een 404 niet gevonden fout Mogelijke oplossing
Gebruikersverificatie faalt wanneer hierom wordt gevraagd Vaak voorkomende oorzaken
Probleemoplossing LDAP
Stappen op hoog niveau voor LBP-verificatie LDAP debug uitvoer
RFC 4511
Inleiding
Dit document beschrijft hoe u de Cisco G2 Series geïntegreerde services routers (ISR’s) kunt configureren. Terwijl de configuratie van IP Admission and Lichtgewicht Directory Access Protocol (LDAP) eenvoudig kan worden gebruikt voor verificatieproxy op ISR, wordt deze doorgaans
gebruikt in combinatie met de Cisco Cloud Web Security (CWS)-omleiding. Als zodanig is dit document bedoeld als referentie ter aanvulling van de CWS-omleidingsdocumentatie en de documentatie bij probleemoplossing op ISR's.
Voorwaarden
Vereisten
Cisco raadt aan dat uw systeem aan deze vereisten voldoet voordat u probeert welke configuraties in dit document worden beschreven:
ISR moet code versie 15.2(1)T1 of hoger uitvoeren.
●
Uw systeem moet beschikken over de afbeeldingen met de security optie ingesteld (SEC) licentie die beschikbaar is in Cisco IOS® (universal).
●
Het werkstation van de client in het AD-domein moet de mogelijkheid hebben om actieve authenticatie via een webbrowser uit te voeren.
●
U moet een CWS-abonnement hebben.
●
Gebruikte componenten
De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:
Internet Explorer, Google Chrome, Mozilla Firefox (vereist extra configuratie voor transparante NT LAN Manager (NTLM)-verificatie)
●
Cisco ASR 900, 1900, 2900 en 3900 Series ISR’s.
●
Microsoft Windows AD Domain Controller (ADDC)
●
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 de potentiële impact van elke opdracht begrijpen.
Opmerking: De routers van Cisco G1 1800, 2800 en 3800 Series worden niet ondersteund.
Achtergrondinformatie
Veel beheerders die de Cisco G2 Series ISR's installeren die geen Cisco adaptieve security applicaties (ASA's) hebben in hun netwerken, kiezen ervoor om de ISR CWS (voorheen
ScanSafe) omleidingsfunctionaliteit te gebruiken om voordeel te halen uit de CWS-oplossing voor webfiltering. Als onderdeel van die oplossing willen de meeste beheerders ook de huidige AD- infrastructuur gebruiken om de identiteitsinformatie van gebruikers naar de CWS-torens te sturen voor op gebruikers of groepen gebaseerde beleidshandhaving voor het webfilterbeleid in het CWS-portaal.
Het algemene concept is vergelijkbaar met de integratie tussen de ASA en Context Directory Agent (CDA), met een paar verschillen. Het meest opmerkelijke verschil is dat ISR feitelijk geen passieve user-to-IP mapping database aanhoudt, zodat gebruikers een of ander type verificatie doorgeven om de ISR te doorsturen en gebruikers of groepen informatie naar het CWS-portaal te sturen.
Tip: Raadpleeg het gedeelte Verificatiemethoden in dit document voor meer informatie over de verschillen tussen de verschillende authenticatiemethoden die beschikbaar zijn.
Terwijl het gedeelte van de configuratie dat door CWS wordt omgeleid dat in dit document wordt beschreven relatief eenvoudig is, kunnen sommige beheerders problemen krijgen met pogingen om het gedeelte van de verificatie te configureren. Dit gedeelte werkt met de ip-toegangsopdracht die verwijst naar de LDAP-servers en verificatie-, autorisatie- en accounting-uitspraken (AAA) die ook moeten worden geconfigureerd. Het doel van dit document is netwerkbeheerders een
uitgebreide referentiebron te bieden om de IP-toegangsrechten en LDAP-delen van deze configuratie op de Cisco G2 Series ISR's te configureren of in te lossen.
Configureren
Gebruik de informatie die in deze sectie wordt beschreven om Cisco ISR te configureren.
Opmerking: Gebruik de Command Lookup Tool (alleen voor geregistreerde gebruikers) voor meer informatie over de opdrachten die in deze sectie worden gebruikt.
Netwerkdiagram
LDAP configureren
Voltooi deze stappen om de LDAP-eigenschappen van de AAA-server(s) te configureren:
Het configureren van een LBP-attributenkaart om de gebruikersnaam te forceren die door de gebruiker wordt ingevoerd om de eigenschap sAMAAccountName in de AD aan te passen:
C-881(config)#ldap attribute-map ldap-username-map map type sAMAccountName username
C-881(config-attr-map)#map type sAMAccountName username
Opmerking: Deze configuratie is vereist omdat de eigenschap sAMAAccountName een unieke waarde is in de AD, in tegenstelling tot de eigenschap Common Name (CN), die anders wordt gebruikt om standaard te matchen. Bijvoorbeeld, er kunnen meerdere gevallen van John Smith in de AD zijn, maar er kan slechts één gebruiker zijn met de sAMAcount van Jsmith, dat ook de aanmelding van de gebruikersaccount is. Andere John Smith-accounts hebben sAMAaccountNamen zoals jsmith1 of jsmith2.
De opdracht kenmerken tonen kan ook worden gebruikt om een lijst van de LDAP- eigenschappen en de bijbehorende AAA-eigenschappen weer te geven.
1.
Configuratie van de LDP-servergroep:
C-881(config)#aaa group server ldap LDAP_GROUP C-881(config-ldap-sg)#server DC01
2.
Configuratie van de LDAP-servers:
C-881(config)#ldap server DC01
C-881(config-ldap-server)# ipv4 10.10.10.150
C-881(config-ldap-server)#attribute map ldap-username-map
C-881(config-ldap-server)# bind authenticate root-dn CN=Csco_Service,CN=Users, DC=lab,DC=cisco,DC=com password Cisco12345!
3.
C-881(config-ldap-server)#base-dn DC=lab,DC=cisco,DC=com C-881(config-ldap-server)#search-filter user-object-type top C-881(config-ldap-server)#authentication bind-first
Deze configuratie vereist over het algemeen geen aanpassing, tenzij er een behoefte is om een aangepaste zoekfilter uit te voeren. Alleen beheerders die goed geverteerd zijn in LDAP en weten hoe deze informatie goed moet worden ingevoerd, moeten aangepaste zoekfilters gebruiken. Als u niet zeker weet welk zoekfilter moet worden gebruikt, gebruikt u het beschreven filter dan eenvoudigweg. de gebruiker bevindt zich in een normale AD-omgeving.
Een ander deel van de LDAP-configuratie dat ook zorgvuldige aandacht aan details vereist is de welbekende Names (DNs) die vereist zijn in de bind-authenticate-root-dn en base-dn opdrachten.
Deze moeten precies worden ingevoerd zoals ze in de LDAP server verschijnen, of de LDAP vragen mislukken. Bovendien moet de basis-dn opdracht het laagste deel van de LDAP-boom zijn, waar alle echt gewaarmerkte gebruikers wonen.
Denk aan het scenario waarin de basis-dn opdracht in de vorige configuratie zo wordt aangepast:
base-dn OU=TestCompany,DC=lab,DC=cisco,DC=com
In dit geval geeft de query voor de gebruikers die zijn opgenomen in CN=Gebruikers, DC=lab,DC=cisco,DC=com geen resultaten terug, aangezien de LDAP server alleen de
TestCompany Organisational Unit (OU) en de kindobjecten daarin doorzoekt. Als resultaat hiervan faalt de authenticatie altijd voor die gebruikers tot ze in de TestCompany OU of de subboom ervan worden verplaatst, of als de basis-dn opdracht wordt gewijzigd om deze in de query op te nemen.
Tip: Raadpleeg het gedeelte DNA-objecten bepalen in de sectie AD - ADSI van dit document voor meer informatie over het bepalen van de juiste DNSs voor de basis- en
wortelopdrachten.
AAA configureren
Nu de LDAP-servers zijn ingesteld, dient u ze te verwijzen naar de corresponderende AAA- verklaringen die worden gebruikt door het IP-toegangsproces:
C-881(config)#aaa authentication login SCANSAFE_AUTH group LDAP_GROUP C-881(config)#aaa authorization network SCANSAFE_AUTH group LDAP_GROUP
Opmerking: Als deze opdrachten niet beschikbaar zijn, moet de opdracht van het nieuwe model mogelijk worden ingevoerd om de AAA-functie in te schakelen, omdat deze standaard niet ingeschakeld is.
IP-toegang configureren
Het IP Admission-gedeelte leidt een proces in dat de gebruiker om verificatie vraagt (of transparante verificatie uitvoert) en dat vervolgens LDAP-vragen uitvoert op basis van de gebruikersreferenties en AAA-servers die in de configuratie zijn gedefinieerd. Als de gebruikers echt bevonden zijn, wordt de informatie over de gebruikersidentiteit vervolgens door het content- scan proces opgehaald en naar de CWS-torens verzonden, samen met de hergeleiding. Het IP- toegangsproces wordt niet geactiveerd totdat het commando van de IP-toegangsnaam op de
inkomende interface van de router is ingevoerd. Daarom kan dit gedeelte van de configuratie worden uitgevoerd zonder een impact op het verkeer.
C-881(config)#ip admission virtual-ip 1.1.1.1 virtual-host ISR_PROXY C-881(config)#ip admission name SCANSAFE_ADMISSION ntlm
C-881(config)#ip admission name SCANSAFE_ADMISSION method-list authentication SCANSAFE_AUTH authorization SCANSAFE_AUTH
IP-toegang inschakelen
Hier is de configuratie die wordt gebruikt om IP-toegang in te schakelen:
Opmerking: Dit dwingt de gebruikers om echt te worden gemaakt, wat verkeersstroomonderbreking veroorzaakt als authenticatie mislukt.
C-881(config)#int vlan301 (internal LAN-facing interface) C-881(config-if)#ip admission SCANSAFE_ADMISSION
Vrijstellen van verificatie in hosts
Sommige beheerders zouden bepaalde binnenhosts om verschillende redenen willen vrijstellen van het verificatieproces. Bijvoorbeeld, het kan onwenselijk zijn dat interne servers of apparaten die niet in staat zijn NTLM te gebruiken of basisauthenticatie door het IP-toegangsproces worden beïnvloed. In deze gevallen kan een toegangscontrolelijst (ACL) worden toegepast op de IP- toegangsconfiguratie om te voorkomen dat specifieke IP-telefoons of subnetwerken IP- toegangsrechten activeren.
In dit voorbeeld is de interne gastheer 10.10.10.150 vrijgesteld van de verplichting tot echtheidscontrole, terwijl voor alle andere hosts nog steeds echtheidscontrole vereist is:
C-881(config)#ip access-list extended NO_ADMISSION C-881(config-ext-nacl)#deny ip host 10.10.10.150 any C-881(config-ext-nacl)#permit ip any any
C-881(config)#ip admission name SCANSAFE_ADMISSION ntlm list NO_ADMISSION
HTTP-server op ISR inschakelen
Vereist wordt dat u de HTTP server inschakelen om de HTTP sessies te onderscheppen en het authenticatieproces te starten:
Ip http server
Ip http secure-server
Opmerking: De IP http Secure-server is alleen nodig als er een omleiding naar HTTPS voor verificatie is vereist.
CWS-omleiding configureren
Hier is een basisconfiguratie voor de omleiding van CWS:
parameter-map type content-scan global
server scansafe primary name proxy139.scansafe.net port http 8080 https 8080 server scansafe secondary name proxy187.scansafe.net port http 8080 https 8080 license 0 DE749585HASDH83HGA94EA8C369
source interface Vlan302
user-group DEFAULT_GROUP username DEFAULT_USER server scansafe on-failure allow-all
interface Vlan302 (egress interface towards Internet) content-scan out
Configuratie van volledige steekproef
Deze sectie verschaft volledige voorbeeldconfiguraties voor de vorige secties.
LDAP
aaa group server ldap LDAP_GROUP server DC01
ldap attribute-map ldap-username-map map type sAMAccountName username ldap server DC01
ipv4 10.10.10.150
attribute map ldap-username-map
bind authenticate root-dn CN=Csco_Service,CN=Users,DC=lab,DC=cisco,DC=com password Cisco12345!
base-dn dc=lab,dc=cisco,dc=com search-filter user-object-type top authentication bind-first
AAA
aaa new-model
aaa authentication login SCANSAFE_AUTH group LDAP_GROUP aaa authorization network SCANSAFE_AUTH group LDAP_GROUP
IP-toegang
ip admission virtual-ip 1.1.1.1 virtual-host ISR_PROXY ip admission name SCANSAFE_ADMISSION ntlm
ip admission name SCANSAFE_ADMISSION method-list authentication SCANSAFE_AUTH authorization SCANSAFE_AUTH
interface Vlan301
ip admission SCANSAFE_ADMISSION
HTTP-server
ip http server
Content Scan en CWS
parameter-map type content-scan global
server scansafe primary name proxy139.scansafe.net port http 8080 https 8080 server scansafe secondary name proxy187.scansafe.net port http 8080 https 8080 license 0 DE13621993BD87B306B5A5607EA8C369
source interface Vlan302
user-group DEFAULT_GROUP username DEFAULT_USER server scansafe on-failure allow-all
interface Vlan302 content-scan out
Bepaal de DNS-objecten in de AD - ADSI-bewerking
Indien nodig, is het mogelijk om door een AD-structuur te bladeren om DNA's op te zoeken voor gebruik met de gebruiker of de groepszoekbasis. De beheerders kunnen een gereedschap gebruiken dat ADSI heet, bewerken dat in AD-domeincontrollers is ingebouwd. Om ADSI te openen Bewerken, kies Start > Start > Run in de AD domein controller en voer adsidit.msc in.
Zodra ADSI Bewerken open is, klik om het even welk object, zoals een OU, groep of gebruiker, met de rechtermuisknop en kies Eigenschappen om de DNA van dat object te bekijken. Het DNS string kan dan makkelijk gekopieerd en geplakt worden naar de routerconfiguratie om
typografische fouten te vermijden. Dit beeld illustreert het proces:
Verificatiemethoden
Er zijn vier verschillende soorten authenticatiemethoden beschikbaar die IP Admission gebruiken en die vaak verkeerd worden begrepen, vooral het verschil tussen transparant en passief NTLM.
In de volgende paragrafen worden de verschillen tussen deze soorten authenticatie beschreven.
Active NTLM
De actieve NTLM-authenticatiemethode leidt gebruikers tot authenticatie wanneer transparante NTLM-verificatie faalt. Dit is meestal te wijten aan het feit dat de client-browser geen
geïntegreerde Microsoft Windows-verificatie ondersteunt of omdat de gebruiker zich in het
werkstation heeft aangemeld met lokale (niet-domein) aanmeldingsgegevens. De actieve NTLM- verificatie voert LDAP-vragen uit aan de domeincontroller om ervoor te zorgen dat de verstrekte aanmeldingsgegevens juist zijn.
Opmerking: Met alle typen NTLM-verificatie worden de referenties niet via duidelijke tekst doorgegeven. NTLM versie 1 (NTLMv1) heeft echter goed gedocumenteerde
kwetsbaarheden. ISR is geschikt voor NTLMv2, hoewel oudere versies van Microsoft Windows standaard kunnen onderhandelen via NTLMv1. Dit gedrag is afhankelijk van het AD-authenticatiebeleid.
Transparante NTLM
De transparante NTLM-verificatie treedt op wanneer een gebruiker met
domeinaanmeldingsgegevens op het werkstation inlogt, en deze aanmeldingsgegevens worden op transparante wijze door de browser aan de IOS-router doorgegeven. De IOS router voert dan een LDAP vraag uit om de gebruikersgeloofsbrieven te valideren. Dit is meestal de meest
gewenste vorm van authenticatie voor deze functie.
Basis verificatie (via HTTP in duidelijke tekst)
Deze vorm van authenticatie wordt doorgaans gebruikt als een back-upmechanisme wanneer NTLM-verificatie mislukt of niet mogelijk is voor klanten zoals Macintosh, Linux-gebaseerde apparaten of mobiele apparaten. Als HTTP Secure-server niet is ingeschakeld, dan worden deze referenties doorgegeven via HTTP in duidelijke tekst (zeer onveilig).
Passive NTLM
Passive NTLM authenticatie vraagt geloofsbrieven van gebruikers maar echt authenticeert de gebruiker niet tegen de domeincontroller. Hoewel dit problemen met de LGO kan vermijden wanneer de vragen niet beantwoorden aan de domeincontroller, brengt dit ook gebruikers in de omgeving bloot aan een veiligheidsrisico. Indien transparante authenticatie mislukt of niet mogelijk is, worden de gebruikers opgeroepen voor geloofsbrieven. De gebruiker kan echter alle door hem gekozen aanmeldingsgegevens invoeren, die naar de CWS-toren worden doorgegeven. Als gevolg daarvan wordt het beleid mogelijk niet op de juiste manier toegepast.
Gebruiker A kan bijvoorbeeld Firefox gebruiken (dat standaard geen transparante NTLM zonder extra configuratie toestaat) en de gebruikersnaam van Gebruiker B met om het even welk wachtwoord invoeren, en het beleid voor gebruiker B wordt toegepast op Gebruiker A. De risicoblootstelling kan worden beperkt als gebruikers allemaal gedwongen worden browsers te gebruiken die transparante NTLM-authenticatie ondersteunen, maar in de meeste gevallen wordt het gebruik van passieve authenticatie niet aanbevolen.
Berichtreeks voor actieve NTLM-verificatie
Hier is de volledige berichtvolgorde voor de actieve NTLM-authenticatiemethode:
Browser --> ISR : GET / google.com
Browser <-- ISR : 302 Page moved http://1.1.1.1/login.html Browser --> ISR : GET /login.html 1.1.1.1
Browser <-- ISR : 401 Unauthorized..Authenticate using NTLM Browser --> ISR : GET /login.html + NTLM Type-1 msg
ISR --> AD : LDAP Bind Request + NTLM Type-1 msg
ISR kopieert het type-1 bericht van HTTP naar de LDAP, byte-byte zonder veranderingen in gegevens.
ISR <-- AD : LDAP Bind Response + NTLM Type-2 msg Browser <-- ISR : 401 Unauthorized + NTLM Type-2 msg
Het type-2 bericht wordt ook per byte gekopieerd van LDAP naar HTTP. In het PCAP lijkt de inhoud dus te zijn gebaseerd op 1.1.1.1, maar de inhoud van het document is afkomstig van het AD.
Browser --> ISR : GET /login.html + NTLM Type-3 msg ISR --> AD : LDAP Bind Request + NTLM Type-3 msg ISR <-- AD : LDAP Bind response - Success
Browser <-- ISR : 200OK + redirect to google.com
Wanneer actief NTLM is geconfigureerd, interfereert ISR niet tijdens de NTLM-uitwisseling. Als echter passief NTLM is geconfigureerd, genereert ISR zijn eigen Type-2-bericht.
Verifiëren
Er is momenteel geen verificatieprocedure beschikbaar voor deze configuratie.
Problemen oplossen
Deze sectie verschaft informatie die u kunt gebruiken om problemen met uw configuratie op te lossen.
Opdrachten weergeven
Opmerking: De Output Interpreter Tool (alleen voor geregistreerde klanten) ondersteunt
bepaalde opdrachten met show. Gebruik de Output Interpreter Tool om een analyse te bekijken van de output van de opdracht show.
U kunt deze opdrachten tonen gebruiken om problemen met uw configuratie op te lossen:
ip-toegangscache weergeven
●
zie ip-toegangsstatus
●
zie ip - toegangsstatistieken
●
ldap server all tonen
●
Opdrachten debug
Opmerking: Raadpleeg Important Information on Debug Commands (Belangrijke informatie over opdrachten met debug) voordat u opdrachten met debug opgeeft.
Hier zijn een aantal nuttige debug-opdrachten die u kunt gebruiken om problemen met uw configuratie op te lossen:
debug ldap all - Deze opdracht kan worden gebruikt om de reden te ontdekken dat verificatie mislukt.
●
IP-toegangsdetails debug - Deze opdracht is zeer uitgebreid en CPU-intensief. Cisco raadt u aan het enkel te gebruiken met enkele testcliënten die IP-toelating activeren.
●
debug ip access ntlm - Deze opdracht kan worden gebruikt om de reden te ontdekken dat het IP Admission-proces is geactiveerd.
●
debug ip-opname httpd
●
debug ip-transactie
●
debug van verificatie door middel van autorisatie
●
Veelvoorkomende problemen
In dit gedeelte worden een aantal gebruikelijke problemen beschreven die worden aangetroffen bij de configuratie die in dit document is beschreven.
IP-toegangsrechten onderscheppen geen HTTP-aanvragen
Deze kwestie wordt duidelijk als je de opdrachtoutput van de show ip access statistics bekijkt. De output laat de interceptie van HTTP-verzoeken niet zien:
C-881#show ip admission statistics Webauth HTTPd statistics:
HTTPd process 1
Intercepted HTTP requests: 0
Mogelijke oplossingen
Er zijn twee mogelijke oplossingen voor deze kwestie. De eerste is te verifiëren dat ip http server is ingeschakeld.
Als de HTTP server voor ISR niet is ingeschakeld, dan worden IP Admission triggers geactiveerd, maar nooit de HTTP sessie onderschept. Daarom wordt gevraagd om authenticatie. In deze situatie is er geen output voor de show ip access cache opdracht, maar veel terugkeringen van deze lijnen worden gezien in de output van de debug ip access details opdracht:
*Jan 30 20:49:35.726: ip_admission_det:proceed with process path authentication
*Jan 30 20:49:35.726: AUTH-PROXY auth_proxy_find_conn_info : find srcaddr - 10.10.10.152, dstaddr - 192.168.1.1
ip-srcaddr 10.20.10.1 pak-srcaddr 10.10.10.152
De tweede oplossing voor dit probleem is te verifiëren dat het IP-adres van de gebruiker niet van de ACL in de configuratie van de IP-toegangsvergunning is vrijgesteld.
Gebruikers ontvangen een 404 niet gevonden fout
Dit probleem wordt waargenomen wanneer gebruikers voor authenticatie worden omgeleid, en 404 Not Found error doet zich voor in de browser.
Mogelijke oplossing
Zorg ervoor dat de naam in de IP-toegangsserver virtueel-ip 1.1.1.1 virtueel-host ISR_PROXY met succes kan worden opgelost met de DNS-server (client Domain Name System). In dit geval voert de client een DNS query uit voor ISR_PROXY.lab.cisco.com aangezien lab.cisco.com de Full Qualified Domain Name (FQDN) is van het domein waar het werkstation aangesloten is. Als de DNS query faalt, verstuurt de client een Link-Local Multicast Name Resolutie (LLMNR) query, gevolgd door een NETPDS query die wordt uitgezonden naar het lokale net.
Als al deze pogingen om de resolutie te annuleren mislukt, wordt er een 404 Not found of Internet Explorer Cannot Display (404) fout in de browser weergegeven.
Gebruikersverificatie faalt wanneer hierom wordt gevraagd
Dit kan om verschillende redenen worden veroorzaakt, maar is gewoonlijk gerelateerd aan de LDP-configuratie op de ISR of communicatie tussen de ISR en de LDAP-server. Op ISR wordt het symptoom over het algemeen waargenomen wanneer gebruikers vastzitten in de INIT-status nadat de IP-toelating is geactiveerd:
C-881(config)#do show ip admi cac Authentication Proxy Cache
Client Name N/A, Client IP 10.10.10.152, Port 56674, timeout 60, Time Remaining 2, state INIT
Vaak voorkomende oorzaken
Dit zijn de gemeenschappelijke oorzaken van deze kwestie:
De gebruiker voert een ongeldige gebruikersnaam en/of wachtwoord in voor actieve verificatie.
●
Een ongeldige base-dn wordt gebruikt in de LDAP-configuratie, wat resulteert in zoekresultaten zonder resultaat.
●
Een ongeldige bindt authenticatie root-dn wordt ingesteld voor de gebruikersnaam of het wachtwoord, waardoor de LDAP-verbinding mislukt.
●
De communicatie tussen de ISR- en de LDAP-server is mislukt. Controleer dat de LDAP server luistert op de gespecificeerde TCP poort voor LDAP communicatie en dat alle firewalls tussen de twee het verkeer toestaan.
●
Een ongeldig zoekfilter levert geen resultaten op voor de LDAP-zoekfunctie.
●
Probleemoplossing LDAP
De beste manier om de reden te bepalen dat de authenticatie mislukt, is gebruik te maken van de LDAP debug opdrachten in ISR. Houd in gedachten dat apparaten duur en gevaarlijk kunnen zijn om op een ISR te lopen wanneer er een buitensporige productie is, en zij kunnen de router veroorzaken om op te hangen en een harde motor nodig hebben. Dit geldt in het bijzonder voor lagere platforms.
Om problemen op te lossen, raadt Cisco u aan om ACL op de IP Admission Rule toe te passen om slechts één enkel testwerkstation op het netwerk aan authenticatie te onderwerpen. Op deze manier kunnen debugs worden geactiveerd met een minimaal risico op negatieve impact op de mogelijkheid van de router om verkeer door te geven.
Tip: Raadpleeg het gedeelte Vrijgestelde binnenhosts van verificatie van dit document voor meer informatie over de toepassing van een ACL op de configuratie van IP-
toegangsrechten.
Wanneer u problemen met de LBP-gerelateerde problemen oplossen, is het nuttig om de stappen te begrijpen waarin LDAP verzoeken van ISR verwerkt.
Stappen op hoog niveau voor LBP-verificatie
Hier zijn de stappen op hoog niveau voor de LDAP-verificatie:
Open de verbinding met de LDAP-server op de gespecificeerde poort. De standaardpoort is TCP 389.
1.
Bind aan de LDAP server met bindt authenticate root-dn gebruiker en wachtwoord.
2.
De LDAP-zoekfunctie uitvoeren, met behulp van de basis-dn- en zoekfilters die in de LDAP- configuratie zijn gedefinieerd, voor de gebruiker die probeert te authenticeren.
3.
Verkrijg de LDAP resultaten van de LDAP server en creëer een IP Admission cache voor de gebruiker als de authenticatie succesvol is, of opnieuw voor referenties in geval van een echtheidsstoring.
4.
LDAP debug uitvoer
Deze processen kunnen worden bekeken in de uitvoer van de debug ldap opdracht. Deze sectie verschaft een voorbeeld van de LDAP debug uitvoer voor een authenticatie die mislukt vanwege een ongeldige basis-dn. Review de debug uitvoer en bijbehorende opmerkingen, die de
gedeelten van de uitvoer beschrijven die aangeven waar de bovengenoemde stappen mogelijk een storing veroorzaken.
*Jan 30 20:51:50.818: LDAP: LDAP: Queuing AAA request 23 for processing
*Jan 30 20:51:50.818: LDAP: Received queue event, new AAA request
*Jan 30 20:51:50.818: LDAP: LDAP authentication request
*Jan 30 20:51:50.818: LDAP: Username sanity check failed
*Jan 30 20:51:50.818: LDAP: Invalid hash index 512, nothing to remove
*Jan 30 20:51:50.818: LDAP: New LDAP request
*Jan 30 20:51:50.818: LDAP: Attempting first next available LDAP server
*Jan 30 20:51:50.818: LDAP: Got next LDAP server :DC01
*Jan 30 20:51:50.818: LDAP: Free connection not available. Open a new one.
*Jan 30 20:51:50.818: LDAP: Opening ldap connection ( 10.10.10.150, 389 )ldap_open
Het gedeelte van de uitvoer dat vet wordt weergegeven, geeft aan dat dit geen probleem is met de netwerklaag, omdat de verbinding met succes is geopend.
*Jan 30 20:51:50.822: LDAP: Root Bind on CN=Csco_Service,CN=Users,DC=lab, DC=cisco,DC=com initiated.
*Jan 30 20:51:51.330: LDAP: Ldap Result Msg: SUCCESS, Result code =0
*Jan 30 20:51:51.330: LDAP: Root DN bind Successful on :CN=Csco_Service, CN=Users,DC=lab,DC=cisco,DC=com
De Bind authenticate-dn is correct in deze uitvoer. Als de configuratie hier niet correct voor is, wordt er melding gemaakt van een storing.
*Jan 30 20:51:51.846: LDAP: Received Bind Responseldap_parse_sasl_bind_result
*Jan 30 20:51:51.846: LDAP: Ldap SASL Result Msg: SUCCESS, Result code =14 sasLres_code =14
*Jan 30 20:51:51.846: LDAP: SASL NTLM authentication do not require further tasks
*Jan 30 20:51:51.846: LDAP: Next Task: All authentication task completed
*Jan 30 20:51:51.846: LDAP: Transaction context removed from list [ldap reqid=14]
*Jan 30 20:51:51.846: LDAP: * * AUTHENTICATION COMPLETED SUCCESSFULLY * *
*Jan 30 20:51:51.846: LDAP: Notifying AAA: REQUEST CHALLENGED
Het gedeelte van de output dat in vet wordt weergegeven geeft aan dat alle bind operaties succesvol zijn en dat het op zoek gaat naar de eigenlijke gebruiker.
*Jan 30 20:51:51.854: LDAP: SASL NTLM authentication done..Execute search
*Jan 30 20:51:51.854: LDAP: Next Task: Send search req
*Jan 30 20:51:51.854: LDAP: Transaction context removed from list[ldap reqid=15]
*Jan 30 20:51:51.854: LDAP: Dynamic map configured
*Jan 30 20:51:51.854: LDAP: Dynamic map found for aaa type=username
*Jan 30 20:51:51.854: LDAP: Ldap Search Req sent ld 2293572544
base dn dc=lab1,dc=cisco,dc=comscope 2 filter (&(objectclass=top)(sAMAccountName=testuser5)) ldap_req_encode
put_filter "(&(objectclass=top)(sAMAccountName=testuser5))"
put_filter: AND
put_filter_list "(objectclass=top)(sAMAccountName=testuser5)"
put_filter "(objectclass=top)"
put_filter: simple
put_filter "(sAMAccountName=testuser5)"
put_filter: simple Doing socket write
*Jan 30 20:51:51.854: LDAP: lctx conn index = 2
De eerste regel (vet weergegeven) geeft aan dat de LDAP zoekuitvoer start. Merk ook op dat de basis-dn domeincontroller voor lab zou moeten worden geconfigureerd, en niet lab1.
*Jan 30 20:51:52.374: LDAP: LDAP Messages to be processed: 1
*Jan 30 20:51:52.374: LDAP: LDAP Message type: 101
*Jan 30 20:51:52.374: LDAP: Got ldap transaction context from reqid 16ldap_parse_result
*Jan 30 20:51:52.374: LDAP: resultCode: 10 (Referral)
*Jan 30 20:51:52.374: LDAP: Received Search Response resultldap_parse_result ldap_err2string
*Jan 30 20:51:52.374: LDAP: Ldap Result Msg: FAILED:Referral, Result code =10
*Jan 30 20:51:52.374: LDAP: LDAP Search operation result : failedldap_msgfree
*Jan 30 20:51:52.374: LDAP: Closing transaction and reporting error to AAA
*Jan 30 20:51:52.374: LDAP: Transaction context removed from list [ldap reqid=16]
*Jan 30 20:51:52.374: LDAP: Notifying AAA: REQUEST FAILED
Het gedeelte van de in vet weergegeven uitvoer geeft aan dat de zoekopdracht geen resultaten heeft opgeleverd. In dit geval is dit te wijten aan een ongeldig base-dn.
RFC 4511
RFC 4511 (Lichtgewicht Directory Access Protocol (LDAP): Het Protocol) bevat informatie over de resultaten van de codeberichten voor LDAP en andere informatie over het protocol van de LDAP, die kan worden verwezen via de IETF-website.
