Utilisation du serveur de jetons RSA et du protocole SDI pour ASA et ACS
Table des matières
Introduction
Ce document décrit les procédures de dépannage pour RSA Authentication Manager, qui peut être intégré avec Cisco Adaptive Security Appliance (ASA) et Cisco Secure Access Control Server (ACS).
RSA Authentication Manager est une solution qui fournit le mot de passe à usage unique (OTP) pour l'authentification. Ce mot de passe est modifié toutes les 60 secondes et ne peut être utilisé qu'une seule fois. Il prend en charge les jetons matériels et logiciels.
Conditions préalables
Exigences
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Configuration CLI de Cisco ASA
- Configuration de Cisco ACS
Composants utilisés
Les informations contenues dans ce document sont basées sur les versions de logiciel suivantes :
- Logiciel Cisco ASA, versions 8.4 et ultérieures
- Cisco Secure ACS, versions 5.3 et ultérieures
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Théorie
Le serveur RSA est accessible avec RADIUS ou le protocole propriétaire RSA : SDI. L'ASA et l'ACS peuvent utiliser les deux protocoles (RADIUS, SDI) afin d'accéder au RSA.
N'oubliez pas que le RSA peut être intégré au client Cisco AnyConnect Secure Mobility lorsqu'un jeton logiciel est utilisé. Ce document se concentre uniquement sur l'intégration ASA et ACS. Pour plus d'informations sur AnyConnect, référez-vous à la section Utilisation de l'authentification SDI du Guide de l'administrateur du client Cisco AnyConnect Secure Mobility, version 3.1.
RSA via RADIUS
RADIUS a un grand avantage sur SDI. Sur RSA, il est possible d'attribuer des profils spécifiques (appelés groupes sur ACS) aux utilisateurs. Des attributs RADIUS spécifiques sont définis pour ces profils. Une fois l'authentification réussie, le message RADIUS-Accept renvoyé par le RSA contient ces attributs. En fonction de ces attributs, l'ACS prend des décisions supplémentaires. Le scénario le plus courant est la décision d'utiliser le mappage de groupe ACS afin de mapper des attributs RADIUS spécifiques, liés au profil sur le RSA, à un groupe spécifique sur le ACS. Avec cette logique, il est possible de déplacer l'ensemble du processus d'autorisation du RSA vers l'ACS tout en conservant une logique granulaire, comme sur le RSA.
RSA via SDI
SDI présente deux avantages principaux par rapport à RADIUS. La première est que toute la session est chiffrée. La deuxième est l'offre intéressante de l'agent SDI : il peut déterminer si l'échec est dû à l'échec de l'authentification ou de l'autorisation, ou si l'utilisateur est introuvable.
Ces informations sont utilisées par l'ACS en action pour l'identité. Par exemple, il peut continuer pour « utilisateur introuvable » mais être rejeté pour « échec de l'authentification ».
RADIUS et SDI présentent une autre différence. Lorsqu'un périphérique d'accès réseau tel qu'ASA utilise SDI, l'ACS effectue uniquement l'authentification. Lorsqu'il utilise RADIUS, l'ACS effectue l'authentification, l'autorisation et la comptabilité (AAA). Cependant, ce n'est pas une grande différence. Il est possible de configurer SDI pour l'authentification et RADIUS pour la gestion des comptes pour les mêmes sessions.
Protocole SDI
Par défaut, SDI utilise le protocole UDP (User Datagram Protocol) 5500. SDI utilise une clé de chiffrement symétrique, similaire à la clé RADIUS, afin de chiffrer les sessions. Cette clé est enregistrée dans un fichier secret de noeud et est différente pour chaque client SDI. Ce fichier est déployé manuellement ou automatiquement.
Pour le noeud de déploiement automatique, le fichier secret est téléchargé automatiquement après la première authentification réussie. Le secret de noeud est chiffré avec une clé dérivée du code secret de l'utilisateur et d'autres informations. Cela crée des problèmes de sécurité possibles, de sorte que la première authentification doit être effectuée localement et utiliser un protocole chiffré (Secure Shell [SSH], pas telnet) afin de s'assurer que le pirate ne peut pas intercepter et déchiffrer ce fichier.
Configuration
SDI sur ACS
Il est configuré dans Utilisateurs et magasins d'identités > Magasin d'identités externe > Serveurs de jetons RSA Secure ID.
Le RSA comporte plusieurs serveurs de réplication, tels que les serveurs secondaires pour ACS. Il n'est pas nécessaire d'y placer toutes les adresses, juste le fichier sdconf.rec fourni par l'administrateur RSA. Ce fichier contient l'adresse IP du serveur RSA principal. Une fois le premier noeud d’authentification réussi, le fichier secret est téléchargé avec les adresses IP de tous les réplicas RSA.
Afin de différencier « utilisateur introuvable » de « échec d'authentification », choisissez les paramètres dans l'onglet Avancé :
Il est également possible de modifier les mécanismes de routage par défaut (équilibrage de charge) entre plusieurs serveurs RSA (principaux et réplicas). Modifiez-le avec le fichier sdopts.rec fourni par l'administrateur RSA. Dans ACS, il est chargé dans Users and Identity Stores > External Identity Store > RSA Secure ID Token Servers > ACS Instance Settings.
Pour le déploiement en cluster, la configuration doit être répliquée. Après la première authentification réussie, chaque noeud ACS utilise son propre secret de noeud téléchargé à partir du serveur RSA principal. Il est important de se rappeler de configurer le RSA pour tous les noeuds ACS dans le cluster.
SDI sur ASA
L'ASA n'autorise pas le téléchargement du fichier sdconf.rec. Et, comme l'ACS, il ne permet que le déploiement automatique. L'ASA doit être configuré manuellement afin de pointer vers le serveur RSA principal. Un mot de passe n'est pas nécessaire. Une fois le premier noeud d'authentification réussi, le fichier secret est installé (fichier .sdi sur la mémoire flash) et les autres sessions d'authentification sont protégées. L’adresse IP des autres serveurs RSA est également téléchargée.
Voici un exemple :
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
Après une authentification réussie, la commande show aaa-server protocol sdi ou show aaa-server <aaa-server-group> affiche tous les serveurs RSA (s'il y en a plusieurs), tandis que la commande show run affiche uniquement l'adresse IP principale :
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
Dépannage
Cette section fournit des informations que vous pouvez utiliser pour dépanner votre configuration.
Aucune configuration d'agent sur RSA
Dans de nombreux cas, après avoir installé un nouvel ASA ou modifié l'adresse IP ASA, il est facile d'oublier d'effectuer les mêmes modifications sur le RSA. L'adresse IP de l'agent sur le RSA doit être mise à jour pour tous les clients qui accèdent au RSA. Ensuite, le nouveau secret de noeud est généré. Il en va de même pour l’ACS, en particulier pour les noeuds secondaires, car ils ont des adresses IP différentes et le RSA doit leur faire confiance.
Noeud secret corrompu
Parfois, le fichier de noeud secret sur l'ASA ou le RSA est corrompu. Ensuite, il est préférable de supprimer la configuration de l'agent sur le RSA et de l'ajouter à nouveau. Vous devez également effectuer le même processus sur l'ASA/ACS : supprimer et ajouter à nouveau la configuration. Supprimez également le fichier .sdi sur la mémoire flash, de sorte que lors de la prochaine authentification, un nouveau fichier .sdi soit installé. Le déploiement automatique du secret de noeud doit avoir lieu une fois que cette opération est terminée.
Noeud en mode suspendu
Parfois, l'un des noeuds est en mode suspendu, ce qui est dû à l'absence de réponse de ce serveur :
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
En mode suspendu, l'ASA n'essaie pas d'envoyer des paquets à ce noeud ; il doit avoir un état OK pour cela. Le serveur défaillant est remis en mode actif après le minuteur d'arrêt. Pour plus d'informations, référez-vous à la section commande de mode de réactivation dans le guide Référence des commandes de la gamme Cisco ASA, 9.1.
Dans de tels scénarios, il est préférable de supprimer et d'ajouter la configuration de serveur AAA pour ce groupe afin de déclencher ce serveur en mode actif à nouveau.
Compte verrouillé
Après plusieurs tentatives, le RSA peut verrouiller le compte. Elle est facilement vérifiée sur le RSA avec des rapports. Sur l'ASA/ACS, les rapports affichent uniquement « failed authentication ».
Problèmes et fragmentation de l'unité de transition maximale (MTU)
Le SDI utilise le protocole UDP comme transport et non comme découverte de chemin MTU. En outre, le trafic UDP n'a pas le bit Ne pas fragmenter (DF) défini par défaut. Parfois, pour des paquets plus importants, il peut y avoir des problèmes de fragmentation. Il est facile de détecter le trafic sur le RSA (l'appliance et la machine virtuelle [VM] utilisent Windows et Wireshark). Effectuez le même processus sur l'ASA/ACS et comparez. Testez également RADIUS ou WebAuthentication sur RSA afin de le comparer à SDI (afin de réduire le problème).
Paquets et débogages pour ACS
Étant donné que la charge utile SDI est chiffrée, la seule façon de dépanner les captures est de comparer la taille de la réponse. S'il est inférieur à 200 octets, il peut y avoir un problème. Un échange SDI typique implique quatre paquets, chacun de 550 octets, mais qui peuvent changer avec la version du serveur RSA :
En cas de problème, il s’agit généralement de plus de quatre paquets échangés et de tailles plus petites :
En outre, les journaux ACS sont assez clairs. Voici les journaux SDI typiques sur l'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
Informations connexes
- Ressources RSA Authentication Manager
- Section Prise en charge des serveurs RSA/SDI du Guide de configuration de la gamme Cisco ASA 5500 utilisant l'interface de ligne de commande, 8.4 et 8.6
- Section Serveur RSA SecurID du Guide de l'utilisateur de Cisco Secure Access Control System 5.4
- Assistance et documentation techniques - Cisco Systems
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
13-Jun-2013 |
Première publication |
Commentaires