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 procedures voor probleemoplossing voor de RSA-verificatie Manager, die kan worden geïntegreerd met de Cisco adaptieve security applicatie (ASA) en de Cisco Secure Access Control Server (ACS).
De RSA Verification Manager is een oplossing die voorziet in het eenmalige wachtwoord voor verificatie. Dat wachtwoord wordt om de 60 seconden gewijzigd en kan maar één keer worden gebruikt. Het ondersteunt zowel hardware als software tokens.
Cisco raadt u aan een basiskennis te hebben van deze onderwerpen:
De informatie in dit document is gebaseerd op de volgende softwareversies:
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 RSA server kan worden benaderd met RADIUS of het bedrijfseigen RSA-protocol: SDI. Zowel de ASA als de ACS kunnen beide protocollen (RADIUS, SDI) gebruiken om toegang te krijgen tot de RSA.
Vergeet niet dat de RSA kan worden geïntegreerd met de Cisco AnyConnect Secure Mobility Client wanneer een softwaretoken wordt gebruikt. Dit document richt zich uitsluitend op ASA- en ACS-integratie. Raadpleeg voor meer informatie over AnyConnect de sectie SDI-verificatie gebruiken van de Cisco AnyConnect Secure Mobility Client Administrator-handleiding, release 3.1.
RADIUS heeft één groot voordeel ten opzichte van SDI. Op de RSA is het mogelijk om specifieke profielen (groepen op ACS) toe te wijzen aan gebruikers. Deze profielen hebben specifieke gedefinieerde RADIUS-kenmerken. Na succesvolle verificatie bevat het RADIUS-Accept-bericht dat van de RSA is geretourneerd, deze kenmerken. Op basis van deze eigenschappen neemt het ACS aanvullende beslissingen. Het meest voorkomende scenario is de beslissing om ACS-groepstoewijzing te gebruiken om specifieke RADIUS-kenmerken, gerelateerd aan het profiel op de RSA, aan een specifieke groep op de ACS in kaart te brengen. Met deze logica is het mogelijk om het hele vergunningsproces van de RSA naar de ACS te verplaatsen en nog steeds de granulaire logica te behouden, zoals bij de RSA.
SDI heeft twee belangrijke voordelen ten opzichte van RADIUS. De eerste is dat de hele sessie versleuteld is. Het tweede is de interessante opties die de SDI-agent biedt: het is in staat om te bepalen of de fout is gemaakt omdat de verificatie of autorisatie is mislukt of omdat de gebruiker niet is gevonden.
Deze informatie wordt gebruikt door de ACS in actie voor identiteit. Bijvoorbeeld, het kon voor "niet gevonden gebruiker"maar verwerpen voor "ontbroken authentificatie voortzetten."
Er is nog een verschil tussen RADIUS en SDI. Wanneer een Netwerktoegangsapparaat zoals ASA SDI gebruikt, voert ACS alleen verificatie uit. Wanneer het RADIUS gebruikt, voert ACS verificatie, autorisatie, accounting (AAA) uit. Dit is echter geen groot verschil. Het is mogelijk om SDI voor verificatie en RADIUS voor accounting voor dezelfde sessies te configureren.
Standaard gebruikt SDI User Datagram Protocol (UDP) 5500. SDI gebruikt een symmetrische coderingssleutel die vergelijkbaar is met de RADIUS-toets om sessies te versleutelen. Die sleutel wordt opgeslagen in een knooppunt geheim bestand en is anders voor elke SDI-client. Dat bestand wordt handmatig of automatisch geïmplementeerd.
Opmerking: ACS/ASA ondersteunt handmatige implementatie niet.
Voor de automatische implementatieknooppunt wordt het geheime bestand automatisch gedownload na de eerste succesvolle verificatie. Het knoopgeheim wordt versleuteld met een sleutel die is afgeleid van het wachtwoord van de gebruiker en andere informatie. Dit leidt tot sommige mogelijke veiligheidskwesties, zodat moet de eerste authentificatie plaatselijk worden uitgevoerd en het gebruik versleutelde protocol (Secure Shell [SSH], niet telnet) om ervoor te zorgen dat de aanvaller niet dat dossier kan onderscheppen en decrypteren.
Opmerkingen:
Gebruik de Command Lookup Tool (alleen voor geregistreerde gebruikers) voor meer informatie over de opdrachten die in deze sectie worden gebruikt.
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.
Raadpleeg Important Information on Debug Commands (Belangrijke informatie over opdrachten met debug) voordat u opdrachten met debug opgeeft.
Het is ingesteld in Gebruikers en Identity Store > Externe Identity Store > RSA Secure ID Token Servers.
De RSA heeft meerdere replicaservers, zoals de secundaire servers voor de ACS. Het is niet nodig om alle adressen daar te plaatsen, alleen het sdconf.rec bestand geleverd door de RSA beheerder. Dit bestand bevat het IP-adres van de primaire RSA-server. Na de eerste succesvolle authenticatie knooppunt, wordt het geheime bestand gedownload samen met de IP-adressen van alle RSA-replica's.
Kies instellingen in het tabblad Geavanceerd om "gebruiker niet gevonden" te onderscheiden van "verificatiefout":
Het is ook mogelijk om de standaardroutingmechanismen (taakverdeling) tussen meerdere RSA-servers (primaire en replica's) te wijzigen. Verander het met het sdopts.rec-bestand dat door de RSA-beheerder wordt geleverd. In ACS wordt het geüpload in Gebruikers en Identity Stores > Externe Identity Store > RSA Secure ID Token Servers > ACS-instantiesinstellingen.
Voor clusterimplementatie moet de configuratie worden gerepliceerd. Na de eerste succesvolle verificatie gebruikt elke ACS-knooppunt zijn eigen knooppunt van de primaire RSA-server. Het is belangrijk te onthouden dat u de RSA voor alle ACS-knooppunten in het cluster moet configureren.
ASA staat geen uploaden van het sdconf.rec-bestand toe. En, net als de ACS, staat het automatische plaatsing slechts toe. De ASA moet handmatig worden geconfigureerd om naar de primaire RSA-server te wijzen. Er is geen wachtwoord nodig. Na de eerste succesvolle authenticatie knooppunt, wordt het geheime bestand geïnstalleerd (.sdi bestand op flash) en verdere authenticatie sessies worden beveiligd. Ook het IP-adres van andere RSA-servers wordt gedownload.
Hierna volgt een voorbeeld:
aaa-server SDI protocol sdi
aaa-server SDI (backbone) host 1.1.1.1
debug sdi 255
test aaa auth SDI host 1.1.1.1 user test pass 321321321
Na succesvolle verificatie toont de opdracht show aaa-server protocol sdi of show aaa-server <aaa-server-group> alle RSA-servers (indien er meer dan één server is), terwijl de opdracht show run alleen het primaire IP-adres toont:
bsns-asa5510-17# show aaa-server RSA
Server Group: RSA
Server Protocol: sdi
Server Address: 10.0.0.101
Server port: 5500
Server status: ACTIVE (admin initiated), Last transaction at
10:13:55 UTC Sat Jul 27 2013
Number of pending requests 0
Average round trip time 706ms
Number of authentication requests 4
Number of authorization requests 0
Number of accounting requests 0
Number of retransmissions 0
Number of accepts 1
Number of rejects 3
Number of challenges 0
Number of malformed responses 0
Number of bad authenticators 0
Number of timeouts 0
Number of unrecognized responses 0
SDI Server List:
Active Address: 10.0.0.101
Server Address: 10.0.0.101
Server port: 5500
Priority: 0
Proximity: 2
Status: OK
Number of accepts 0
Number of rejects 0
Number of bad next token codes 0
Number of bad new pins sent 0
Number of retries 0
Number of timeouts 0
Active Address: 10.0.0.102
Server Address: 10.0.0.102
Server port: 5500
Priority: 8
Proximity: 2
Status: OK
Number of accepts 1
Number of rejects 0
Number of bad next token codes 0
Number of bad new pins sent 0
Number of retries 0
Number of timeouts 0
Deze sectie bevat informatie die u kunt gebruiken om problemen met de configuratie te troubleshooten.
In veel gevallen nadat u een nieuwe ASA hebt geïnstalleerd of het ASA IP-adres hebt gewijzigd, is het gemakkelijk om te vergeten dezelfde wijzigingen aan te brengen op de RSA. Het IP-adres van de agent op de RSA moet worden bijgewerkt voor alle clients die toegang hebben tot de RSA. Vervolgens wordt het nieuwe knoopgeheim gegenereerd. Hetzelfde geldt voor de ACS, vooral voor secundaire knooppunten omdat ze verschillende IP-adressen hebben en de RSA ze moet vertrouwen.
Soms wordt het geheime knooppunt bestand op de ASA of de RSA beschadigd. Dan is het best om de agent configuratie op de RSA te verwijderen en het opnieuw toe te voegen. U moet ook hetzelfde proces op de ASA/ACS doen - verwijder en voeg opnieuw configuratie toe. Verwijdert ook het .sdi bestand op de flitser, zodat bij de volgende verificatie een nieuw .sdi bestand is geïnstalleerd. Zodra dit is voltooid, moet de automatische geheime plaatsing van de knoop plaatsvinden.
Soms bevindt een van de knooppunten zich in de hangmodus, die wordt veroorzaakt door het uitblijven van een reactie van die server:
asa# show aaa-server RSA
<.....output ommited"
SDI Server List:
Active Address: 10.0.0.101
Server Address: 10.0.0.101
Server port: 5500
Priority: 0
Proximity: 2
Status: SUSPENDED
In de opgeschorte modus probeert de ASA geen pakketten naar dat knooppunt te verzenden. daar moet een OK status voor zijn. De mislukte server wordt na de dode timer weer in de actieve modus gezet. Raadpleeg voor meer informatie de sectie over de reactiveringsmodus in de Cisco ASA Series Command Reference, 9.1 Guide.
In dergelijke scenario's is het het beste om de AAA-serverconfiguratie voor die groep te verwijderen en toe te voegen om die server opnieuw in de actieve modus te activeren.
Nadat meerdere herhalingen zijn uitgevoerd, kan de RSA zich uitsluiten van het account. Het wordt gemakkelijk gecontroleerd op de RSA met rapporten. Voor ASA/ACS, tonen de rapporten slechts "ontbroken authentificatie."
SDI gebruikt UDP als transport en niet MTU-paddetectie. Ook het UDP-verkeer bevat de standaard Don't Fragment (DF)-bit. Soms kunnen er voor grotere pakketten fragmentatieproblemen optreden. Het is eenvoudig om verkeer op de RSA te controleren (zowel het apparaat als de virtuele machine [VM] gebruiken Windows en gebruiken Wireshark). Voltooi hetzelfde proces op de ASA/ACS en vergelijk. Test ook RADIUS of WebAuthentication op de RSA om het te vergelijken met SDI (om het probleem te versmallen).
Omdat de payload van SDI versleuteld is, is de enige manier om problemen op te lossen de opnamen door de grootte van de respons te vergelijken. Als het kleiner is dan 200 bytes, kan er een probleem zijn. Een typische SDI-uitwisseling omvat vier pakketten, die elk 550 bytes bevatten, maar die kunnen veranderen met de RSA-serverversie:
In het geval van problemen, is het gewoonlijk meer dan vier uitgewisselde pakketten en kleinere grootte:
Ook de ACS-logs zijn vrij duidelijk. Hier zijn de typische SDI logboeken op ACS:
EventHandler,11/03/2013,13:47:58:416,DEBUG,3050957712,Stack: 0xa3de560
Calling backRSAIDStore: Method MethodCaller<RSAIDStore, RSAAgentEvent> in
thread:3050957712,EventStack.cpp:242
AuthenSessionState,11/03/2013,13:47:58:416,DEBUG,3050957712,cntx=0000146144,
sesn=acs-01/150591921/1587,user=mickey.mouse,[RSACheckPasscodeState
::onEnterState],RSACheckPasscodeState.cpp:23
EventHandler,11/03/2013,13:47:58:416,DEBUG,3002137488,Stack: 0xa3de560
Calling RSAAgent:Method MethodCaller<RSAAgent, RSAAgentEvent> in thread:
3002137488,EventStack.cpp:204
RSAAgent,11/03/2013,13:47:58:416,DEBUG,3002137488,cntx=0000146144,sesn=
acs-01/150591921/1587,user=mickey.mouse,[RSAAgent::handleCheckPasscode],
RSAAgent.cpp:319
RSASessionHandler,11/03/2013,13:47:58:416,DEBUG,3002137488,[RSASessionHandler::
checkPasscode] call AceCheck,RSASessionHandler.cpp:251
EventHandler,11/03/2013,13:48:00:417,DEBUG,2965347216,Stack: 0xc14bba0
Create newstack, EventStack.cpp:27
EventHandler,11/03/2013,13:48:00:417,DEBUG,3002137488,Stack: 0xc14bba0 Calling
RSAAgent: Method MethodCaller<RSAAgent, RSAServerResponseEvent> in
thread:3002137488,EventStack.cpp:204
RSAAgent,11/03/2013,13:48:00:417,DEBUG,3002137488,cntx=0000146144,sesn=acs-01
/150591921/1587,user=mickey.mouse,[RSAAgent::handleResponse] operation completed
with ACM_OKstatus,RSAAgent.cpp:237
EventHandler,11/03/2013,13:48:00:417,DEBUG,3002137488,Stack: 0xc14bba0
EventStack.cpp:37
EventHandler,11/03/2013,13:48:00:417,DEBUG,3049905040,Stack: 0xa3de560 Calling
back RSAIDStore: Method MethodCaller<RSAIDStore, RSAAgentEvent> in thread:
3049905040,EventStack.cpp:242
AuthenSessionState,11/03/2013,13:48:00:417,DEBUG,3049905040,cntx=0000146144,sesn=
acs-01/150591921/1587,user=mickey.mouse,[RSACheckPasscodeState::onRSAAgentResponse]
Checkpasscode succeeded, Authentication passed,RSACheckPasscodeState.cpp:55
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
1.0 |
13-Jun-2013 |
Eerste vrijgave |