RSA-Token-Server und SDI-Protokollnutzung für ASA und ACS
Inhalt
Einleitung
In diesem Dokument werden die Fehlerbehebungsverfahren für den RSA Authentication Manager beschrieben, der in die Cisco Adaptive Security Appliance (ASA) und den Cisco Secure Access Control Server (ACS) integriert werden kann.
Der RSA Authentication Manager ist eine Lösung, die das One Time Password (OTP) für die Authentifizierung bereitstellt. Dieses Kennwort wird alle 60 Sekunden geändert und kann nur einmal verwendet werden. Es unterstützt sowohl Hardware- als auch Software-Token.
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über Grundkenntnisse in diesen Themen verfügen:
- Konfiguration der Cisco ASA CLI
- Cisco ACS-Konfiguration
Verwendete Komponenten
Die Informationen in diesem Dokument basieren auf folgenden Software-Versionen:
- Cisco ASA Software, Version 8.4 und höher
- Cisco Secure ACS, Version 5.3 und höher
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Theorie
Auf den RSA-Server kann mit RADIUS oder dem proprietären RSA-Protokoll zugegriffen werden: SDI Sowohl die ASA als auch der ACS können beide Protokolle (RADIUS, SDI) verwenden, um auf die RSA zuzugreifen.
Denken Sie daran, dass die RSA in den Cisco AnyConnect Secure Mobility Client integriert werden kann, wenn ein Softwaretoken verwendet wird. Dieses Dokument behandelt ausschließlich die ASA- und ACS-Integration. Weitere Informationen zu AnyConnect finden Sie im Abschnitt Using SDI Authentication im Cisco AnyConnect Secure Mobility Client Administrator Guide, Release 3.1.
RSA über RADIUS
RADIUS hat einen großen Vorteil gegenüber SDI. Auf dem RSA ist es möglich, Benutzern bestimmte Profile (im ACS Gruppen genannt) zuzuweisen. Für diese Profile sind spezifische RADIUS-Attribute definiert. Nach erfolgreicher Authentifizierung enthält die vom RSA zurückgegebene RADIUS-Accept-Nachricht diese Attribute. Auf der Grundlage dieser Attribute trifft der ACS zusätzliche Entscheidungen. Das häufigste Szenario ist die Entscheidung, ACS-Gruppenzuordnung zu verwenden, um bestimmte RADIUS-Attribute, die sich auf das Profil im RSA beziehen, einer bestimmten Gruppe im ACS zuzuordnen. Mit dieser Logik ist es möglich, den gesamten Autorisierungsprozess vom RSA zum ACS zu verschieben und dabei wie beim RSA eine granulare Logik beizubehalten.
RSA über SDI
SDI hat gegenüber RADIUS zwei Hauptvorteile. Die erste besteht darin, dass die gesamte Sitzung verschlüsselt ist. Der zweite sind die interessanten Optionen, die der SDI-Agent bietet: kann sie feststellen, ob der Fehler aufgrund eines Fehlers bei der Authentifizierung oder Autorisierung oder aufgrund eines nicht gefundenen Benutzers aufgetreten ist.
Diese Informationen werden vom ACS in Aktion für die Identität verwendet. Sie kann z. B. bei "Benutzer nicht gefunden" fortfahren, bei "Authentifizierung fehlgeschlagen" jedoch zurückweisen.
Es gibt noch einen Unterschied zwischen RADIUS und SDI. Wenn ein Netzwerkzugriffsgerät wie ASA SDI verwendet, führt der ACS nur eine Authentifizierung durch. Bei Verwendung von RADIUS führt der ACS AAA (Authentication, Authorization, Accounting) durch. Dies ist jedoch kein großer Unterschied. Es ist möglich, SDI für die Authentifizierung und RADIUS für die Abrechnung derselben Sitzungen zu konfigurieren.
SDI-Protokoll
SDI verwendet standardmäßig das User Datagram Protocol (UDP) 5500. SDI verwendet einen symmetrischen Verschlüsselungsschlüssel, ähnlich dem RADIUS-Schlüssel, um Sitzungen zu verschlüsseln. Dieser Schlüssel wird in einer geheimen Knotendatei gespeichert und ist für jeden SDI-Client anders. Diese Datei wird manuell oder automatisch bereitgestellt.
Für den automatischen Bereitstellungsknoten wird die geheime Datei nach der ersten erfolgreichen Authentifizierung automatisch heruntergeladen. Der geheime Schlüssel des Knotens wird mit einem Schlüssel verschlüsselt, der aus dem Passcode des Benutzers und anderen Informationen abgeleitet wird. Dies führt zu einigen möglichen Sicherheitsproblemen. Daher muss die erste Authentifizierung lokal durchgeführt werden und ein verschlüsseltes Protokoll (Secure Shell [SSH], nicht Telnet) verwenden, um sicherzustellen, dass der Angreifer diese Datei nicht abfangen und entschlüsseln kann.
Konfiguration
SDI auf ACS
Sie wird unter Benutzer und Identitätsdaten > Externer Identitätsspeicher > RSA-Token-Server für sichere ID konfiguriert.
Die RSA verfügt über mehrere Replikatserver, z. B. die sekundären Server für den ACS. Es ist nicht erforderlich, alle Adressen dort abzulegen, nur die vom RSA-Administrator bereitgestellte Datei sdconf.rec. Diese Datei enthält die IP-Adresse des primären RSA-Servers. Nach dem ersten erfolgreichen Authentifizierungsknoten wird die geheime Datei zusammen mit den IP-Adressen aller RSA-Replikate heruntergeladen.
Um zwischen "user not found" und "authentication failure" zu unterscheiden, wählen Sie die Einstellungen auf der Registerkarte "Advanced" aus:
Es ist auch möglich, die Standardroutingmechanismen (Lastenausgleich) zwischen mehreren RSA-Servern (primär und Replikate) zu ändern. Ändern Sie sie mit der Datei sdopts.rec, die vom RSA-Administrator bereitgestellt wird. In ACS wird sie unter Benutzer und Identitätsdaten > Externer Identitätsspeicher > RSA-Token-Server > ACS-Instanzeinstellungen hochgeladen.
Bei der Clusterbereitstellung muss die Konfiguration repliziert werden. Nach der ersten erfolgreichen Authentifizierung verwendet jeder ACS-Knoten seinen eigenen, vom primären RSA-Server heruntergeladenen Knotenschlüssel. Denken Sie daran, die RSA für alle ACS-Knoten im Cluster zu konfigurieren.
SDI auf ASA
Die ASA lässt das Hochladen der Datei sdconf.rec nicht zu. Und wie der ACS ermöglicht er nur die automatische Bereitstellung. Die ASA muss manuell konfiguriert werden, damit sie auf den primären RSA-Server verweist. Ein Kennwort ist nicht erforderlich. Nach dem ersten erfolgreichen Authentifizierungsknoten wird die geheime Datei (SDI-Datei im Flash) installiert und weitere Authentifizierungssitzungen werden geschützt. Außerdem werden die IP-Adressen anderer RSA-Server heruntergeladen.
Hier ein Beispiel:
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
Nach erfolgreicher Authentifizierung zeigt der Befehl show aaa-server protocol sdi oder show aaaa-server <aaa-server-group> alle RSA-Server an (falls mehrere vorhanden sind), während der Befehl show run nur die primäre IP-Adresse anzeigt:
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
Fehlerbehebung
In diesem Abschnitt erhalten Sie Informationen zur Behebung von Fehlern in Ihrer Konfiguration.
Keine Agent-Konfiguration auf RSA
In vielen Fällen ist es nach der Installation einer neuen ASA oder der Änderung der ASA-IP-Adresse leicht zu vergessen, die gleichen Änderungen an der RSA vorzunehmen. Die IP-Adresse des Agenten auf der RSA muss für alle Clients aktualisiert werden, die auf die RSA zugreifen. Anschließend wird der neue Knotenschlüssel generiert. Dasselbe gilt für den ACS, insbesondere für sekundäre Knoten, da diese unterschiedliche IP-Adressen haben und der RSA ihnen vertrauen muss.
Fehlerhafter geheimer Knoten
Manchmal wird die Datei des geheimen Knotens auf der ASA oder der RSA beschädigt. Anschließend sollte die Agentenkonfiguration aus dem RSA entfernt und erneut hinzugefügt werden. Sie müssen den gleichen Prozess auch auf der ASA/ACS durchführen - Konfiguration entfernen und hinzufügen. Löschen Sie außerdem die .sdi-Datei im Flash, sodass bei der nächsten Authentifizierung eine neue .sdi-Datei installiert wird. Die automatische, geheime Bereitstellung des Knotens muss nach Abschluss dieses Vorgangs erfolgen.
Knoten im angehaltenen Modus
Manchmal befindet sich einer der Knoten im ausgesetzten Modus, was darauf zurückzuführen ist, dass dieser Server nicht reagiert:
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
Im ausgesetzten Modus versucht die ASA nicht, Pakete an diesen Knoten zu senden. Dazu muss er den Status OK haben. Der ausgefallene Server wird nach dem Dead-Timer wieder in den aktiven Modus versetzt. Weitere Informationen finden Sie im Abschnitt zu den Befehlen für den Reaktivierungsmodus in der Cisco ASA Series Command Reference, 9.1.-Anleitung.
In solchen Szenarien ist es am besten, die AAA-Serverkonfiguration für diese Gruppe zu entfernen und hinzuzufügen, um den Server wieder in den aktiven Modus zu versetzen.
Konto gesperrt
Nach mehreren Versuchen kann sich die RSA vom Konto abmelden. Er lässt sich auf einfache Weise mithilfe von Berichten auf dem RSA überprüfen. Auf ASA/ACS zeigen Berichte nur "fehlgeschlagene Authentifizierung" an.
Maximum Transition Unit (MTU)-Probleme und -Fragmentierung
SDI verwendet UDP als Transport, nicht MTU-Pfaderkennung. Auch für UDP-Datenverkehr ist standardmäßig nicht das Don't Fragment (DF)-Bit festgelegt. Manchmal kann es bei größeren Paketen zu Fragmentierungsproblemen kommen. Es ist einfach, Datenverkehr auf der RSA zu erkennen (sowohl die Appliance als auch die virtuelle Maschine [VM] verwenden Windows und Wireshark). Führen Sie auf der ASA/ACS den gleichen Prozess aus, und vergleichen Sie. Testen Sie RADIUS oder WebAuthentication auf dem RSA, um es mit SDI zu vergleichen (um das Problem einzugrenzen).
Pakete und Debugs für ACS
Da die SDI-Nutzlast verschlüsselt ist, besteht die einzige Möglichkeit zur Fehlerbehebung bei den Erfassungen darin, die Größe der Antwort zu vergleichen. Wenn sie kleiner als 200 Bytes ist, kann es ein Problem geben. Ein typischer SDI-Austausch besteht aus vier Paketen mit jeweils 550 Byte, die sich jedoch mit der RSA-Serverversion ändern können:
Bei Problemen werden in der Regel mehr als vier Pakete ausgetauscht und kleinere Größen verwendet:
Auch die ACS-Protokolle sind eindeutig. Hier sind die typischen SDI-Protokolle auf dem 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
Zugehörige Informationen
- RSA Authentication Manager-Ressourcen
- RSA-/SDI-Server-Support im Konfigurationsleitfaden für die Cisco Serie ASA 5500 unter Verwendung der CLI, 8.4 und 8.6
- RSA SecurID Server-Abschnitt des Benutzerhandbuchs für Cisco Secure Access Control System 5.4
- Technischer Support und Dokumentation für Cisco Systeme
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
13-Jun-2013 |
Erstveröffentlichung |
Feedback