Konfigurieren von Cisco Secure UNIX und Secure ID (SDI-Client)

Einleitung

Um die Konfiguration in diesem Dokument zu implementieren, benötigen Sie eine beliebige Cisco Secure-Version, die die Secure ID von Security Dynamics Incorporated (SDI) unterstützt.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).

Installieren eines SDI-Clients (Secure ID) auf einem Cisco Secure UNIX-System

Hinweis: Secure ID wird in der Regel installiert, bevor Cisco Secure UNIX (CSUnix) installiert wurde. Diese Anleitung beschreibt, wie der SDI-Client nach der Installation von CSUnix installiert wird.

1. Führen Sie auf dem SDI-Server sdadmin aus. Informieren Sie den SDI-Server, dass der CSUnix-Rechner ein Client ist, und geben Sie an, dass die betreffenden SDI-Benutzer auf dem CSUnix-Client aktiviert sind.

2. Verwenden Sie den Befehl nslookup #.#.#.# oder den Befehl nslookup <hostname>, um sicherzustellen, dass der CSUnix-Client und der SDI-Server ein gegenseitiges Forward- und Reverse-Lookup durchführen können.

3. Kopieren Sie die Datei /etc/sdace.txt des SDI-Servers in die Datei /etc/sdace.txt des CSUnix-Clients.

4. Kopieren Sie die Datei sdconf.rec des SDI-Servers auf den CSUnix-Client. Diese Datei kann sich auf dem CSUnix-Client befinden. Wenn sie jedoch in derselben Verzeichnisstruktur auf dem CSUnix-Client wie auf dem SDI-Server platziert wird, muss sdace.txt nicht geändert werden.

5. Entweder /etc/sdace.txt oder VAR_ACE muss auf den Pfad verweisen, unter dem sich die Datei sdconf.rec befindet. Führen Sie hierzu cat /etc/sdace.txt aus, oder überprüfen Sie die Ausgabe von env, um sicherzustellen, dass VAR_ACE beim Start des Roots im Profil des Roots definiert ist.

6. Sichern Sie die Datei CSU.cfg des CSUnix-Clients, und ändern Sie dann den Abschnitt AUTHEN config_external_authen_symbols mit den folgenden Zeilen:

   

7. Recycling von CSUnix durch die Ausführung von K80CiscoSecure und S80CiscoSecure.

8. Wenn $BASE/utils/psg zeigt, dass der Cisco Secure AAA Server-Prozess vor der Änderung der Datei CSU.cfg aktiv war, aber nicht danach, dann wurden Fehler in der Revision der Datei CSU.cfg gemacht. Stellen Sie die ursprüngliche CSU.cfg-Datei wieder her, und versuchen Sie erneut, die in Schritt 6 beschriebenen Änderungen vorzunehmen.

Erster Test der sicheren ID und CSUnix

So testen Sie Secure ID und CSUnix:

1. Stellen Sie sicher, dass ein Nicht-SDI-Benutzer eine Telnet-Verbindung zum Router herstellen und sich mit CSUnix authentifizieren kann. Wenn das nicht funktioniert, wird SDI nicht funktionieren.

2. Testen Sie die grundlegende SDI-Authentifizierung im Router, und führen Sie den folgenden Befehl aus:

   aaa new-model
   
   aaa authentication login default tacacs+ none
   

   Hinweis: Hierbei wird davon ausgegangen, dass die TACACS-Server-Befehle bereits im Router aktiv sind.

3. Fügen Sie einen SDI-Benutzer aus der CSUnix-Befehlszeile hinzu, um diesen Befehl einzugeben.

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

4. Versuchen Sie, sich als Benutzer zu authentifizieren. . Wenn dieser Benutzer funktioniert, ist SDI betriebsbereit, und Sie können den Benutzerprofilen zusätzliche Informationen hinzufügen.

5. SDI-Benutzer können mit dem Profil unknown_user in CSUnix getestet werden. (Benutzer müssen nicht explizit in CSUnix aufgeführt werden, wenn sie alle an SDI übergeben werden und alle dasselbe Profil haben.) Wenn bereits ein unbekanntes Benutzerprofil vorhanden ist, löschen Sie es mithilfe des folgenden Befehls:

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

6. Verwenden Sie diesen Befehl, um ein weiteres unbekanntes Benutzerprofil hinzuzufügen:

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

   Dieser Befehl übergibt alle unbekannten Benutzer an SDI.

Secure ID und CSUnix: TACACS+-Profil

1. Führen Sie einen ersten Test ohne SDI durch. Wenn dieses Benutzerprofil ohne ein SDI-Kennwort für die Anmeldeauthentifizierung, das Challenge Handshake Authentication Protocol (CHAP) und das Password Authentication Protocol (PAP) nicht funktioniert, funktioniert es nicht mit einem SDI-Kennwort:

   # ./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. Wenn das Profil funktioniert, fügen Sie "sdi" anstelle von "clear" zum Profil hinzu, wie in diesem Beispiel gezeigt:

   # ./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 {
   } 
   } 
    
   }

Funktionsweise des Profils

Dieses Profil ermöglicht es dem Benutzer, sich mit den folgenden Kombinationen anzumelden:

• Telnet an den Router senden und SDI verwenden. (Dabei wird davon ausgegangen, dass der standardmäßige Befehl aaa authentication login tacacs+ auf dem Router ausgeführt wurde.)

• DFÜ-Netzwerk PPP-Verbindung und PAP. (Dies setzt voraus, dass die AAA-Authentifizierung ppp default if-need tacacs und ppp authen pap Befehle auf dem Router ausgeführt wurden.)

  Hinweis: Stellen Sie auf dem PC unter DFÜ-Netzwerk sicher, dass die Option "Authentifizierung akzeptieren, einschließlich Klartext" aktiviert ist. Geben Sie vor dem Wählen eine der folgenden Kombinationen von Benutzername und Kennwort in das Terminalfenster ein:

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

• DFÜ-PPP-Netzwerkverbindung und CHAP. (Dabei wird davon ausgegangen, dass die AAA-Authentifizierungs-ppp-Standard-TACACS und PPP-Authentifizierungs-CHAP-Befehle auf dem Router ausgeführt wurden.)

  Hinweis: Auf dem PC muss im DFÜ-Netzwerk entweder "Beliebige Authentifizierung einschließlich Klartext akzeptieren" oder "Nur verschlüsselte Authentifizierung akzeptieren" aktiviert sein. Geben Sie vor dem Wählen folgenden Benutzernamen und das folgende Kennwort in das Terminalfenster ein:

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

Nicht funktionierende Kombination von CSUnix TACACS+-Kennwort

Diese Kombinationen führen zu folgenden CSUnix-Debugfehlern:

• CHAP und kein "Klartext"-Kennwort im Kennwortfeld. Der Benutzer gibt Code+Karte anstelle des "Klartext"-Passworts ein. RFC 1994 auf CHAP erfordert eine unverschlüsselte Kennwortspeicherung.

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

• CHAP und ein ungültiges CHAP-Kennwort.

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

  (Der Benutzer wird an SDI übergeben, und SDI übergibt den Benutzer, aber CSUnix schlägt beim Benutzer fehl, weil das CHAP-Kennwort ungültig ist.)

  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 und ein ungültiges PAP-Kennwort.

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

  (Der Benutzer wird an SDI übergeben, und SDI übergibt den Benutzer, aber CSUnix schlägt beim Benutzer fehl, weil das CHAP-Kennwort ungültig ist.)

  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; 

Debuggen von CSUnix TACACS+ SDI-Beispielprofilen

• Der Benutzer muss CHAP durchführen und sich anmelden. PAP schlägt fehl.

  # ./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 {
  } 
  } 

• Der Benutzer muss PAP- und Anmeldeauthentifizierung durchführen; CHAP schlägt fehl.

  # ./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

Diese Abschnitte enthalten CSUnix RADIUS-Prozeduren.

Anmeldeauthentifizierung mit CSUnix und RADIUS

Führen Sie die folgenden Schritte aus, um die Authentifizierung zu testen:

1. Führen Sie einen ersten Test ohne SDI durch. Wenn dieses Benutzerprofil ohne ein SDI-Kennwort für die Anmeldeauthentifizierung nicht funktioniert, funktioniert es nicht mit einem SDI-Kennwort:

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

2. Wenn dieses Profil funktioniert, ersetzen Sie "was auch immer" durch "sdi", wie in diesem Beispiel gezeigt:

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

PPP- und PAP-Authentifizierung mit CSUnix und RADIUS

Führen Sie die folgenden Schritte aus, um die Authentifizierung zu testen:

Hinweis: PPP-CHAP-Authentifizierung mit CSUnix und RADIUS wird nicht unterstützt.

1. Führen Sie einen ersten Test ohne SDI durch. Wenn dieses Benutzerprofil ohne ein SDI-Kennwort für die PPP/PAP-Authentifizierung und den dedizierten asynchronen Modus nicht funktioniert, funktioniert es nicht mit einem SDI-Kennwort:

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

2. Sobald das obige Profil funktioniert, fügen Sie password = sdi zum Profil hinzu und fügen das Attribut 200=1 hinzu, wie in diesem Beispiel gezeigt (dadurch wird Cisco_Token_Immediate auf yes gesetzt):

   # ./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. Stellen Sie im Abschnitt "Erweiterte GUI, Server" sicher, dass "Token-Caching aktivieren" eingestellt ist. Dies kann über die Befehlszeilenschnittstelle (CLI) bestätigt werden:

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

DFÜ-Netzwerk PPP-Verbindung und PAP

Es wird davon ausgegangen, dass aaa authentication ppp default if-required tacacs und PPP authen PAP-Befehle auf dem Router ausgeführt wurden. Geben Sie diesen Benutzernamen und dieses Kennwort im Terminalfenster ein, bevor Sie wählen.:

username: cse
password: code+card

Hinweis: Vergewissern Sie sich, dass auf dem PC unter DFÜ-Netzwerk das Kontrollkästchen "Authentifizierung akzeptieren, einschließlich Klartext" aktiviert ist.

Debug- und Verifizierungstipps

Diese Abschnitte enthalten Tipps zum Debuggen und Überprüfen.

Cisco Secure RADIUS, PPP und PAP

Dies ist ein Beispiel für ein gutes Debugging:

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)

Sichere ID und CSUnix

Das Debugging wird in der Datei gespeichert, die unter /etc/syslog.conf für local0.debug angegeben ist.

Keine Benutzer können sich authentifizieren - SDI oder andere:

Nachdem Sie die sichere ID hinzugefügt haben, stellen Sie sicher, dass beim Ändern der Datei CSU.cfg keine Fehler aufgetreten sind. Korrigieren Sie die Datei CSU.cfg, oder kehren Sie zur Backup-Datei CSU.cfg zurück.

Dies ist ein Beispiel für ein gutes Debugging:

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

Dies ist ein Beispiel für ein fehlerhaftes Debugging:

CSUnix findet das Benutzerprofil und sendet es an den SDI-Server, aber der SDI-Server schlägt beim Benutzer fehl, weil der Passcode ungültig ist.

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;

Das folgende Beispiel zeigt, dass der ACE-Server ausgefallen ist:

Geben Sie ./aceserver stop auf dem SDI-Server ein. Der Benutzer erhält die Meldung "Enter PASSCODE" (Passcode eingeben) nicht.

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

Zugehörige Informationen

• Cisco Secure ACS für UNIX - Support-Seite
• Praktische Hinweise zu Cisco Secure ACS für UNIX
• Technischer Support – Cisco Systems