Configuration de Cisco Secure UNIX et de Secure ID (client SDI)

Introduction

Pour mettre en oeuvre la configuration de ce document, vous avez besoin de toute version de Cisco Secure prenant en charge l'ID sécurisé de Security Dynamics Incorporated (SDI).

Conditions préalables

Exigences

Aucune exigence spécifique n'est associée à ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Installation d'un client SDI (ID sécurisé) sur une machine UNIX sécurisée Cisco

Remarque : Secure ID est généralement installé avant Cisco Secure UNIX (CSUnix). Ces instructions décrivent comment installer le client SDI après l'installation de CSUnix.

1. Sur le serveur SDI, exécutez sdadmin. Indiquez au serveur SDI que la machine CSUnix est un client et spécifiez que les utilisateurs SDI en question sont activés sur le client CSUnix.

2. Utilisez la commande nslookup #.#.#.# ou nslookup <nom d'hôte> pour vous assurer que le client CSUnix et le serveur SDI peuvent effectuer une recherche directe et inversée l'un de l'autre.

3. Copiez le fichier /etc/sdace.txt du serveur SDI dans le fichier /etc/sdace.txt du client CSUnix.

4. Copiez le fichier sdconf.rec du serveur SDI sur le client CSUnix ; ce fichier peut résider n'importe où sur le client CSUnix. Cependant, s'il est placé dans la même structure de répertoires sur le client CSUnix que sur le serveur SDI, sdace.txt n'a pas besoin d'être modifié.

5. /etc/sdace.txt ou VAR_ACE doit pointer vers le chemin d'accès du fichier sdconf.rec. Pour vérifier cela, exécutez cat /etc/sdace.txt ou vérifiez le résultat de env pour vous assurer que VAR_ACE est défini dans le profil de la racine au démarrage de la racine.

6. Sauvegardez le fichier CSU.cfg du client CSUnix, puis modifiez la section AUTHEN config_external_authen_symbol avec les lignes suivantes :

   

7. Recycler CSUnix par l'exécution de K80CiscoSecure et S80CiscoSecure.

8. Si $BASE/utils/psg indique que le processus du serveur AAA sécurisé Cisco était actif avant la modification du fichier CSU.cfg, mais pas après, des erreurs se sont produites lors de la révision du fichier CSU.cfg. Restaurez le fichier CSU.cfg d'origine et réessayez d'apporter les modifications indiquées à l'étape 6.

Test initial de l'ID sécurisé et de CSUnix

Pour tester Secure ID et CSUnix, procédez comme suit :

1. Assurez-vous qu'un utilisateur non SDI peut établir une connexion Telnet avec le routeur et être authentifié avec CSUnix. Si cela ne fonctionne pas, le SDI ne fonctionnera pas.

2. Testez l'authentification SDI de base dans le routeur et exécutez la commande suivante :

   aaa new-model
   
   aaa authentication login default tacacs+ none
   

   Remarque : cela suppose que les commandes tacacs-server sont déjà actives dans le routeur.

3. Ajoutez un utilisateur SDI à partir de la ligne de commande CSUnix pour entrer cette commande

   $BASE/CLI/AddProfile -p 9900 -u sdi_user -pw sdi
   

4. Essayez de vous authentifier en tant qu'utilisateur. . Si cet utilisateur fonctionne, SDI est opérationnel et vous pouvez ajouter des informations supplémentaires aux profils utilisateur.

5. Les utilisateurs SDI peuvent être testés avec le profil unknown_user dans CSUnix. (Les utilisateurs n'ont pas besoin d'être explicitement répertoriés dans CSUnix s'ils sont tous transmis à SDI et ont tous le même profil.) Si un profil utilisateur inconnu existe déjà, supprimez-le à l'aide de cette commande :

   $BASE/CLI/DeleteProfile -p 9900 -u unknown_user
   

6. Utilisez cette commande pour ajouter un autre profil utilisateur inconnu :

   $BASE/CLI/AddProfile -p 9900 -u unknown_user -pw sdi
   

   Cette commande transmet tous les utilisateurs inconnus à SDI.

ID sécurisé et CSUnix : profil TACACS+

1. Effectuez un test initial sans SDI. Si ce profil utilisateur ne fonctionne pas sans mot de passe SDI pour l'authentification de connexion, le protocole CHAP (Challenge Handshake Authentication Protocol) et le protocole PAP (Password Authentication Protocol), il ne fonctionne pas avec un mot de passe SDI :

   # ./ViewProfile -p 9900 -u cse
   User Profile Information
   user = cse{
   password = chap "chappwd"
   password = pap "pappwd"
   password = clear,"clearpwd" 
   default service=permit
   service=shell {
   }
   service=ppp {
   protocol=lcp {
   }
   protocol=ip {
   }
   }
   }

2. Une fois que le profil fonctionne, ajoutez « sdi » au profil à la place de « clear », comme indiqué dans cet exemple :

   # ./ViewProfile -p 9900 -u cse
   User Profile Information
   user = cse{
   password = chap "chappwd"
   password = pap "pappwd"
   password = sdi
   default service=permit
   service=shell {
   } 
   service=ppp {
   protocol=lcp {
   } 
   protocol=ip {
   } 
   } 
    
   }

Fonctionnement du profil

Ce profil permet à l'utilisateur de se connecter avec les combinaisons suivantes :

• Établissez une connexion Telnet avec le routeur et utilisez SDI. (Cela suppose que la commande aaa authentication login default tacacs+ a été exécutée sur le routeur.)

• Connexion PPP d’accès réseau à distance et PAP. (Cela suppose que les commandes aaa authentication ppp default if-needed tacacs et ppp authen pap ont été exécutées sur le routeur).

  Remarque : sur le PC, dans Dial-Up Networking, assurez-vous que l'option « Accept any authentication include clear text » est cochée. Avant de composer le numéro, saisissez l'une des combinaisons nom d'utilisateur/mot de passe suivantes dans la fenêtre du terminal :

  username: cse*code+card
  password: pap (must agree with profile)
  
  username: cse
  password: code+card

• Connexion PPP d’accès réseau à distance et CHAP. (Cela suppose que les commandes aaa authentication ppp default if-needed tacacs et ppp authen chap ont été exécutées sur le routeur.)

  Remarque : sur l'ordinateur, dans l'accès réseau à distance, vous devez cocher la case « Accepter toute authentification, y compris en texte clair » ou « Accepter uniquement l'authentification chiffrée ». Avant de composer le numéro, saisissez le nom d'utilisateur et le mot de passe suivants dans la fenêtre du terminal :

  username: cse*code+card
  password: chap (must agree with profile)

Combinaisons de mots de passe CSUnix TACACS+ qui ne fonctionnent pas

Ces combinaisons produisent ces erreurs de débogage CSUnix :

• CHAP et aucun mot de passe « en clair » dans le champ du mot de passe. L'utilisateur saisit code+card au lieu du mot de passe « cleartext ». La RFC 1994 sur CHAP nécessite un stockage de mot de passe en texte clair.

  username: cse
  password: code+card
  
  CiscoSecure INFO - User cse, No tokencard password received
  CiscoSecure NOTICE - Authentication - Incorrect password; 

• CHAP et mot de passe CHAP incorrect.

  username: cse*code+card
  password: wrong chap password
  

  (L'utilisateur passe à SDI, et SDI passe à l'utilisateur, mais CSUnix échoue à l'utilisateur parce que le mot de passe CHAP est incorrect.)

  CiscoSecure INFO - The character * was found in username: 
     username=cse,passcode=1234755962
  CiscoSecure INFO - sdi_challenge: rtn 1, state=GET_PASSCODE, user=cse
  CiscoSecure INFO - sdi_verify: cse authenticated by ACE Srvr
  CiscoSecure INFO - sdi: cse free external_data memory,state=GET_PASSCODE
  CiscoSecure INFO - sdi_verify: rtn 1
  CiscoSecure NOTICE - Authentication - Incorrect password; 

• PAP et mot de passe PAP incorrect.

  username: cse*code+card
  password: wrong pap password
  

  (L'utilisateur passe à SDI, et SDI passe à l'utilisateur, mais CSUnix échoue à l'utilisateur parce que le mot de passe CHAP est incorrect.)

  CiscoSecure INFO - 52 User Profiles and 8 Group Profiles loaded into Cache.
  CiscoSecure INFO - The character * was found in username: 
     username=cse,passcode=1234651500
  CiscoSecure INFO - sdi_challenge: rtn 1, state=GET_PASSCODE, user=cse
  CiscoSecure INFO - sdi_verify: cse authenticated by ACE Srvr
  CiscoSecure INFO - sdi: cse free external_data memory,state=GET_PASSCODE
  CiscoSecure INFO - sdi_verify: rtn 1
  CiscoSecure NOTICE - Authentication - Incorrect password; 

Débogage des exemples de profils CSUnix TACACS+ SDI

• L’utilisateur doit effectuer l’authentification CHAP et de connexion ; le protocole PAP échoue.

  # ./ViewProfile -p 9900 -u cse
  User Profile Information
  user = cse{
  password = chap "********" 
  password = sdi 
  default service=permit
  service=shell {
  } 
  service=ppp {
  protocol=lcp {
  } 
  protocol=ip {
  } 
  } 

• L’utilisateur doit effectuer l’authentification PAP et de connexion ; le protocole CHAP échoue.

  # ./ViewProfile -p 9900 -u cse
  User Profile Information
  user = cse{
  member = admin 
  password = pap "********" 
  password = sdi 
  default service=permit
  service=shell {
  } 
  service=ppp {
  protocol=lcp {
  } 
  protocol=ip {
  } 
  } 
  }

CSUnix RADIUS

Ces sections contiennent des procédures CSUnix RADIUS.

Authentification de connexion avec CSUnix et RADIUS

Pour tester l'authentification, procédez comme suit :

1. Effectuez un test initial sans SDI. Si ce profil utilisateur ne fonctionne pas sans mot de passe SDI pour l'authentification de connexion, il ne fonctionne pas avec un mot de passe SDI :

   # ./ViewProfile -p 9900 -u cse
   User Profile Information
   user = cse{
   radius=Cisco {
   check_items= {
   2="whatever"
   } 
   reply_attributes= {
   6=6
   } 
   } 
   }

2. Une fois que ce profil fonctionne, remplacez "what" par "sdi" comme indiqué dans cet exemple :

   # ./ViewProfile -p 9900 -u cse
   User Profile Information
   user = cse{
   radius=Cisco {
   check_items= {
   2=sdi
   } 
   reply_attributes= {
   6=6
   
   } 
   } 
   }

Authentification PPP et PAP avec CSUnix et RADIUS

Pour tester l'authentification, procédez comme suit :

Remarque : l'authentification PPP CHAP avec CSUnix et RADIUS n'est pas prise en charge.

1. Effectuez un test initial sans SDI. Si ce profil utilisateur ne fonctionne pas sans mot de passe SDI pour l'authentification PPP/PAP et « mode asynchrone dédié », il ne fonctionne pas avec un mot de passe SDI :

   # ./ViewProfile -p 9900 -u cse
   
   user = cse {
   password = pap "pappass"
   radius=Cisco {
   check_items = {
   }
   reply_attributes= {
   6=2
   7=1
   }
   }
   }

2. Une fois que le profil ci-dessus fonctionne, ajoutez password = sdi au profil et ajoutez attribute 200=1 comme indiqué dans cet exemple (ceci définit Cisco_Token_Immediate sur yes.) :

   # ./ViewProfile -p 9900 -u cse
   user = cse {
   password = pap "pappass"
   password = sdi
   radius=Cisco {
   check_items = {
   200=1
   }
   reply_attributes= {
   6=2
   7=1
   }
   }
   }

3. Dans la section « Advanced GUI, server », assurez-vous que « Enable Token Caching » est défini. Ceci peut être confirmé à partir de l'interface de ligne de commande (CLI) avec :

   $BASE/CLI/ViewProfile -p 9900 -u SERVER.#.#.#.#
   
   !--- Where #.#.#.# is the IP address of the CSUnix server.
   
   
   TokenCachingEnabled="yes"

Connexion PPP d'accès à distance et PAP

Il est supposé que les commandes aaa authentication ppp default if-needed tacacs et PPP authen PAP ont été exécutées sur le routeur. Saisissez ce nom d'utilisateur et ce mot de passe dans la fenêtre du terminal avant de composer le numéro.

username: cse
password: code+card

Remarque : sur le PC, dans Dial-Up Networking, assurez-vous que l'option « Accept any authentication include clear text » est cochée.

Conseils de débogage et de vérification

Ces sections contiennent des conseils de débogage et de vérification.

Cisco Secure RADIUS, PPP et PAP

Voici un exemple d'un bon débogage :

CiscoSecure DEBUG - RADIUS ; Outgoing Accept Packet id=133 (10.31.1.6)
    User-Service-Type = Framed-User
    Framed-Protocol = PPP
CiscoSecure DEBUG - RADIUS ; Request from host a1f0106 nas (10.31.1.6) 
    code=1 id=134 length=73
CiscoSecure DEBUG - RADIUS ; Incoming Packet id=134 (10.31.1.6)
    Client-Id = 10.31.1.6
    Client-Port-Id = 1
    NAS-Port-Type = Async
    User-Name = "cse"
    Password = "?\235\306"
    User-Service-Type = Framed-User
    Framed-Protocol = PPP
CiscoSecure DEBUG - RADIUS ; Authenticate (10.31.1.6)
CiscoSecure DEBUG - RADIUS ; checkList: ASCEND_TOKEN_IMMEDIATE = 1
CiscoSecure DEBUG - RADIUS ; User PASSWORD type is Special
CiscoSecure DEBUG - RADIUS ; authPapPwd (10.31.1.6)
CiscoSecure INFO - sdi_challenge: rtn 1, state=GET_PASSCODE, user=cse
CiscoSecure DEBUG - profile_valid_tcaching FALSE ending.
CiscoSecure DEBUG - Token Caching.  IGNORE.
CiscoSecure INFO - sdi_verify: cse authenticated by ACE Srvr
CiscoSecure INFO - sdi: cse free external_data memory,state=GET_PASSCODE
CiscoSecure INFO - sdi_verify: rtn 1
CiscoSecure DEBUG - RADIUS ; Sending Ack of id 134 to a1f0106 (10.31.1.6)

ID sécurisé et CSUnix

Le débogage est stocké dans le fichier spécifié dans /etc/syslog.conf pour local0.debug.

Aucun utilisateur ne peut s'authentifier - SDI ou autre :

Après avoir ajouté l'ID sécurisé, assurez-vous qu'aucune erreur n'a été faite lorsque vous modifiez le fichier CSU.cfg. Corrigez le fichier CSU.cfg ou revenez au fichier CSU.cfg de sauvegarde.

Voici un exemple d'un bon débogage :

Dec 13 11:24:22 rtp-evergreen.rtp.cisco.com CiscoSecure: 
   INFO - sdi_challenge: rtn 1, state=GET_PASSCODE, user=cse
Dec 13 11:24:22 rtp-evergreen.rtp.cisco.com CiscoSecure: 
   INFO - sdi_challenge: rtn 1, state=GET_PASSCODE, user=cse
Dec 13 11:24:31 rtp-evergreen.rtp.cisco.com CiscoSecure:  
   INFO - sdi_verify: cse authenticated by ACE Srvr
Dec 13 11:24:31 rtp-evergreen.rtp.cisco.com CiscoSecure:  
   INFO - sdi_verify: cse authenticated by ACE Srvr
Dec 13 11:24:31 rtp-evergreen.rtp.cisco.com CiscoSecure:  
   INFO - sdi: cse free external_data memory,state=GET_PASSCODE
Dec 13 11:24:31 rtp-evergreen.rtp.cisco.com CiscoSecure:  
   INFO - sdi: cse free external_data memory,state=GET_PASSCODE
Dec 13 11:24:31 rtp-evergreen.rtp.cisco.com CiscoSecure:  
   INFO - sdi_verify: rtn 1
Dec 13 11:24:31 rtp-evergreen.rtp.cisco.com CiscoSecure:  
   INFO - sdi_verify: rtn 1

Voici un exemple d'un mauvais débogage :

CSUnix recherche le profil utilisateur et l'envoie au serveur SDI, mais le serveur SDI échoue car le code secret est incorrect.

Dec 13 11:26:22 rtp-evergreen.rtp.cisco.com CiscoSecure:  
   INFO - sdi_challenge: rtn 1, state=GET_PASSCODE, user=cse
Dec 13 11:26:22 rtp-evergreen.rtp.cisco.com CiscoSecure:  
   INFO - sdi_challenge: rtn 1, state=GET_PASSCODE, user=cse
Dec 13 11:26:26 rtp-evergreen.rtp.cisco.com CiscoSecure:  
   WARNING - sdi_verify: cse denied access by ACE Srvr
Dec 13 11:26:26 rtp-evergreen.rtp.cisco.com CiscoSecure:  
   WARNING - sdi_verify: cse denied access by ACE Srvr
Dec 13 11:26:26 rtp-evergreen.rtp.cisco.com CiscoSecure:  
   INFO - sdi: cse free external_data memory,state=GET_PASSCODE
Dec 13 11:26:26 rtp-evergreen.rtp.cisco.com CiscoSecure:  
   INFO - sdi: cse free external_data memory,state=GET_PASSCODE
Dec 13 11:26:26 rtp-evergreen.rtp.cisco.com CiscoSecure:  
   INFO - sdi_verify: rtn 0
Dec 13 11:26:26 rtp-evergreen.rtp.cisco.com CiscoSecure:  
   INFO - sdi_verify: rtn 0
Dec 13 11:26:26 rtp-evergreen.rtp.cisco.com CiscoSecure:  
   NOTICE - Authentication - Incorrect password; 
Dec 13 11:26:26 rtp-evergreen.rtp.cisco.com CiscoSecure:  
   NOTICE - Authentication - Incorrect password;

Voici un exemple montrant que le serveur Ace est en panne :

Saisissez ./aceserver stop sur le serveur SDI. L'utilisateur ne reçoit pas le message « Enter PASSCODE ».

Dec 13 11:33:42 rtp-evergreen.rtp.cisco.com CiscoSecure:  
   ERROR - sdi_challenge error: sd_init failed cli/srvr comm init (cse)
Dec 13 11:33:42 rtp-evergreen.rtp.cisco.com CiscoSecure:  
   ERROR - sdi_challenge error: sd_init failed cli/srvr comm init (cse)
Dec 13 11:33:42 rtp-evergreen.rtp.cisco.com CiscoSecure:  
   INFO - sdi: cse free external_data memory,state=RESET
Dec 13 11:33:42 rtp-evergreen.rtp.cisco.com CiscoSecure:  
   INFO - sdi: cse free external_data memory,state=RESET

Informations connexes

• Page d'assistance Cisco Secure ACS pour UNIX
• Notes de champs pour Cisco Secure ACS pour UNIX
• Support technique - Cisco Systems