In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument werden zwei bekannte Sicherheitsprotokolle für die Zugriffskontrolle in Netzwerken beschrieben: Cisco TACACS+ und Cisco RADIUS.
Es gibt keine spezifischen Anforderungen für dieses Dokument.
Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.
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.
Weitere Informationen zu Dokumentkonventionen finden Sie in den technischen Tipps von Cisco zu Formatkonventionen.
Die RADIUS-Spezifikation wird in RFC 2865 beschrieben. RFC 2138 ist damit obsolet. Cisco unterstützt beide Protokolle. Cisco beabsichtigt nicht, mit RADIUS zu konkurrieren oder BenutzerInnen von der Verwendung von TACACS + zu überzeugen. Sie müssen selbst die für Ihre Anforderungen am besten geeignete Lösung auswählen. In diesem Dokument werden die Unterschiede zwischen TACACS+ und RADIUS erläutert, damit Sie eine fundierte Entscheidung treffen können.
Cisco unterstützt das RADIUS-Protokoll seit der Veröffentlichung von Cisco IOS®-Software-Release 11.1 (Februar 1996). Cisco unterstützt RADIUS weiterhin und wird es auch künftig um neue Funktionen erweitern.
Cisco hat RADIUS vor der Entwicklung von TACACS+ eingehend als Sicherheitsprotokoll bewertet. Das TACACS+-Protokoll enthält viele Funktionen, die auf die neuen Anforderungen am Markt für Sicherheitslösungen abgestimmt sind. Das Protokoll wurde entwickelt, um eine Skalierung bei wachsenden Netzwerken und eine Anpassung an die mit fortschreitender Marktreife entstehenden neuen Sicherheitstechnologien zu ermöglichen. Die zugrunde liegende Architektur des TACACS+-Protokolls ergänzt die unabhängige Architektur für Authentifizierung, Autorisierung und Abrechnung (AAA).
RADIUS ist ein Zugriffsserver, der das AAA-Protokoll verwendet. Es handelt sich um ein System der verteilten Sicherheit, das vor unbefugtem Remote-Zugriff auf Netzwerke und Netzwerkservices schützt. RADIUS besteht aus drei Komponenten:
Protokoll mit einem Frame-Format, das UDP (User Datagram Protocol)/IP verwendet
Server
Client
Der Server wird auf einem zentralen Computer ausgeführt, der sich in der Regel am Client-Standort befindet, während sich die Clients auf den DFÜ-Zugriffsservern befinden und über das Netzwerk verteilt sein können. Cisco hat den RADIUS-Client in Cisco IOS-Software-Release 11.1 und höher sowie in andere Gerätesoftware integriert.
Ein Netzwerkzugriffsserver (Network Access Server, NAS) fungiert als Client von RADIUS. Der Client leitet Benutzerinformationen an bestimmte RADIUS-Server weiter und reagiert dann auf die Antwort, die zurückgegeben wird. RADIUS-Server empfangen Verbindungsanfragen von BenutzerInnen, authentifizieren die BenutzerInnen und geben alle Konfigurationsinformationen zurück, die der Client benötigt, um Services für die BenutzerInnen bereitzustellen. Die RADIUS-Server können als Proxy-Clients für andere Arten von Authentifizierungsservern fungieren.
Transaktionen zwischen dem Client und dem RADIUS-Server werden mithilfe eines gemeinsamen geheimen Schlüssels authentifiziert, der niemals über das Netzwerk gesendet wird. Darüber hinaus werden alle Benutzerkennwörter nur in verschlüsselter Form zwischen dem Client und dem RADIUS-Server übertragen. Dadurch wird ausgeschlossen, dass Angreifer, die ein ungesichertes Netzwerk ausspionieren, Benutzerkennwörter auslesen.
Der RADIUS-Server unterstützt eine Vielzahl von Methoden zur Benutzerauthentifizierung. Wenn der Benutzername und das ursprüngliche Kennwort von den BenutzerInnen angegeben werden, kann der Server PPP, Password Authentication Protocol (PAP) oder Challenge Handshake Authentication Protocol (CHAP), die UNIX-Anmeldung und andere Authentifizierungsmechanismen unterstützen.
Es gibt eine Reihe von kommerziell und frei erhältlichen Servercode-Distributionen. Zu den Cisco Servern zählen Cisco Secure ACS für Windows, Cisco Secure ACS für UNIX und Cisco Access Registrar.
In den folgenden Abschnitten werden verschiedene Funktionen von TACACS+ und RADIUS miteinander verglichen.
RADIUS verwendet UDP, TACACS+ hingegen verwendet TCP. TCP bietet gegenüber UDP mehrere Vorteile. TCP ermöglicht eine verbindungsorientierte Übertragung, während UDP Best-Effort-Übertragung unterstützt. RADIUS erfordert zusätzliche programmierbare Variablen wie Neuübertragungsversuche und Timeouts, um die Best-Effort-Übertragung zu kompensieren. Es fehlt die integrierte Unterstützung, die eine TCP-Übermittlung bietet:
Bei TCP-Nutzung wird separat bestätigt, dass eine Anfrage innerhalb einer (ungefähren) Round-Trip-Zeit im Netzwerk empfangen wurde – unabhängig davon, wie belastet und langsam der Back-End-Authentifizierungsmechanismus (eine TCP-Bestätigung) ist.
Wenn ein Server abgestürzt ist oder angehalten wurde, weist TCP durch einen Reset (RST) sofort darauf hin. Bei Verwendung langlebiger TCP-Verbindungen können Sie ermitteln, wann ein Server abgestürzt ist und wann er wieder verfügbar war. Bei UDP besteht nicht die Möglichkeit, zwischen einem ausgefallenem, einem langsamen und einem nicht vorhandenen Server zu unterscheiden.
Mit TCP-Keepalives können Serverabstürze Out-of-Band mit tatsächlichen Anfragen erkannt werden. Verbindungen zu mehreren Servern können parallel aufrechterhalten werden. Nachrichten müssen nur an die Server gesendet werden, von denen bekannt ist, dass sie aktiv sind und ausgeführt werden.
TCP ist besser skalierbar und passt sich somit Netzwerken an, die wachsen und/oder zu Überlastung neigen.
RADIUS verschlüsselt in dem vom Client an den Server gesendeten Access-Request-Paket nur das Kennwort. Der Rest des Pakets bleibt unverschlüsselt. Andere Informationen, beispielsweise zu Benutzernamen, autorisierten Services und Abrechnung, können von Dritten ausgelesen werden.
TACACS+ verschlüsselt den gesamten Hauptteil des Pakets, nutzt jedoch einen Standard-TACACS+-Header. Ein Feld in diesem Header gibt an, ob der Hauptteil verschlüsselt ist. Für Debugging-Zwecke ist es hilfreich, wenn der Hauptteil der Pakete unverschlüsselt vorliegt. Während des normalen Betriebs wird der Hauptteil eines Pakets jedoch für eine sicherere Kommunikation vollständig verschlüsselt.
RADIUS kombiniert Authentifizierung und Autorisierung miteinander. Die vom RADIUS-Server an den Client gesendeten Access-Accept-Pakete enthalten Autorisierungsinformationen. Dies erschwert die Entkopplung von Authentifizierung und Autorisierung.
TACACS+ verwendet die AAA-Architektur, die AAA voneinander trennt. Dies ermöglicht separate Authentifizierungslösungen, die TACACS+ weiterhin für Autorisierung und Abrechnung verwenden können. Beispielsweise ist es mit TACACS+ möglich, die Kerberos-Authentifizierung und die TACACS+-Autorisierung und -Abrechnung zu verwenden. Nachdem sich ein NAS auf einem Kerberos-Server authentifiziert hat, fordert er von einem TACACS+-Server Autorisierungsinformationen an, ohne sich erneut authentifizieren zu müssen. Der NAS teilt dem TACACS+-Server mit, dass er sich erfolgreich auf einem Kerberos-Server authentifiziert hat, woraufhin der Server Autorisierungsinformationen bereitstellt.
Wenn während einer Sitzung zusätzliche Autorisierungsprüfungen erforderlich sind, hakt der Zugriffsserver bei einem TACACS+-Server nach, ob die BenutzerInnen zur Verwendung eines bestimmten Befehls berechtigt sind. Dies bietet bei getrenntem Authentifizierungsmechanismus eine bessere Kontrolle über die Befehle, die auf dem Zugriffsserver ausgeführt werden können.
RADIUS bietet für folgende Protokolle keine Unterstützung:
AppleTalk Remote Access (ARA)
NetBIOS Frames Control Protocol (NBFCP)
Novell NetWare Asynchronous Services Interface (NASI)
X.25-PAD-Verbindung
TACACS+ bietet Multiprotokoll-Unterstützung.
Bei RADIUS können BenutzerInnen nicht steuern, welche Befehle auf einem Router ausgeführt werden können und welche nicht. Daher ist RADIUS für das Routermanagement weniger nützlich und für Terminal-Services weniger flexibel.
TACACS+ bietet zwei Methoden, um die Autorisierung von Routerbefehlen pro BenutzerIn oder pro Gruppe zu steuern. Bei der ersten Methode werden Befehlen Berechtigungsstufen zugewiesen, und der Router muss sich beim TACACS+-Server vergewissern, dass die BenutzerInnen auf der angegebenen Berechtigungsstufe autorisiert sind. Bei der zweiten Methode werden auf dem TACACS+-Server explizit die zulässigen Befehle pro BenutzerIn oder Gruppe festgelegt.
Aufgrund unterschiedlicher Interpretationen der RADIUS-RFCs (Request for-Comments) garantiert die Einhaltung der RADIUS-RFCs keine Interoperabilität. Obwohl mehrere Anbieter RADIUS-Clients implementieren, bedeutet dies nicht, dass diese interoperabel sind. Cisco implementiert die meisten RADIUS-Attribute und fügt immer wieder weitere hinzu. Wenn bei Clients nur die Standard-RADIUS-Attribute auf den Servern verwendet werden, ist Interoperabilität zwischen mehreren Anbietern gegeben, solange diese Anbieter dieselben Attribute implementieren. Viele Anbieter implementieren jedoch Erweiterungen, bei denen es sich um proprietäre Attribute handelt. Wenn ein Client eines dieser anbieterspezifischen erweiterten Attribute verwendet, ist keine Interoperabilität möglich.
Aufgrund der zuvor genannten Unterschiede zwischen TACACS+ und RADIUS wird zwischen Client und Server unterschiedlich viel Datenverkehr generiert. Diese Beispiele veranschaulichen den Datenverkehr zwischen Client und Server bei TACACS+ und RADIUS, wenn sie für das Routermanagement mit Authentifizierung, Exec-Autorisierung, Befehlsautorisierung (bei RADIUS nicht möglich), Exec-Abrechnung und Befehlsabrechnung (bei RADIUS nicht möglich) verwendet werden.
In diesem Beispiel wird davon ausgegangen, dass Anmeldeauthentifizierung, Exec-Autorisierung, Befehlsautorisierung, Start-Stopp-Exec-Abrechnung und Befehlsabrechnung mit TACACS+ implementiert werden, wenn BenutzerInnen eine Telnet-Verbindung zu einem Router herstellen, einen Befehl ausführen und den Router verlassen:
In diesem Beispiel wird davon ausgegangen, dass Anmeldeauthentifizierung, Exec-Autorisierung und Start-Stopp-Exec-Abrechnung mit RADIUS implementiert werden, wenn BenutzerInnen eine Telnet-Verbindung zu einem Router herstellen, einen Befehl ausführen und den Router verlassen. (Andere Managementservices sind nicht verfügbar.)
In dieser Tabelle ist die AAA-Unterstützung bei TACACS+ und RADIUS nach Gerätetyp für ausgewählte Plattformen aufgeführt. Dies umfasst die Softwareversion, mit der die Unterstützung hinzugefügt wurde. Wenn Ihr Produkt nicht in dieser Liste enthalten ist, finden Sie weitere Informationen in den Versionshinweisen zum Produkt.
Cisco Gerät | TACACS+-Authentisierung | TACACS+-Autorisierung | TACACS+-Abrechnung | RADIUS-Authentifizierung | RADIUS-Autorisierung | RADIUS-Abrechnung |
---|---|---|---|---|---|---|
Cisco Aironet1 | 12.2(4)JA | 12.2(4)JA | 12.2(4)JA | alle Access Points | alle Access Points | alle Access Points |
Cisco IOS®-Software2 | 10.33 | 10.33 | 10.333 | 11.1.1 | 11.1.14 | 11.1.15 |
Cisco Cache Engine | — | — | — | 1.5 | 1.56 | — |
Cisco Catalyst Switches | 2.2 | 5.4.1 | 5.4.1 | 5.1 | 5.4.14 | 5.4.15 |
Cisco CSS 11000 Content Services Switch | 5.03 | 5.03 | 5.03 | 5.0 | 5.04 | — |
Cisco CSS 11500 Content Services Switch | 5.20 | 5.20 | 5.20 | 5.20 | 5.204 | — |
Cisco PIX Firewall | 4.0 | 4.07 | 4.28,5 | 4.0 | 5.27 | 4.28,5 |
Cisco Catalyst 1900/2820 Switches | 8.x Enterprise9 | — | — | — | — | — |
Cisco Catalyst 2900XL/3500XL Switches | 11.2.(8)SA610 | 11.2.(8)SA610 | 11.2.(8)SA610 | 12.0(5)WC511 | 12.0(5)WC511, 4 | 12.0(5)WC511, 5 |
Cisco VPN 3000 Concentrator6 | 3.0 | 3.0 | — | 2.012 | 2.0 | 2.012 |
Cisco VPN 5000 Concentrator | — | — | — | 5.2X12 | 5.2X12 | 5.2X12 |
Beendigung nur für Wireless-Clients, nicht für Managementdatenverkehr bei anderen Versionen als Cisco IOS-Software-Release 12.2(4)JA oder höher. Bei Cisco IOS-Software-Release 12.2.(4)JA und höher ist eine Authentifizierung sowohl für die Beendigung von Wireless-Clients als auch für den Managementdatenverkehr möglich.
Informationen zur Plattformunterstützung bei der Cisco IOS-Software finden Sie in Software Advisor.
Die Befehlsabrechnung wird erst mit der Cisco IOS Software-Version implementiert. 11.1.6.3.
Keine Befehlsautorisierung.
Keine Befehlsabrechnung.
Nur URL-Blockierung, kein administrativer Datenverkehr.
Autorisierung für Nicht-VPN-Datenverkehr über die PIX.
Hinweis: Release 5.2 – Zugriffslistenunterstützung für Zugriffskontrollliste (ACL) mit RADIUS Vendor-Specific Attribute (VSA) oder TACACS+-Autorisierung für VPN-Datenverkehr eingestellt in PIX Release 6.1 – Unterstützung für ACL-RADIUS-Attribut 11-Autorisierung für VPN-Datenverkehr eingestellt in PIX Release 6.2.2 – Unterstützung für herunterladbare ACLs mit RADIUS-Autorisierung für VPN-Datenverkehr eingestellt in PIX Release 6.2 – Unterstützung für Autorisierung für PIX-Managementdatenverkehr über TACACS+.<
Abrechnung nur für Nicht-VPN-Datenverkehr über die PIX, nicht für Managementdatenverkehr.
Hinweis: Version 5.2 bietet Unterstützung für die Abrechnung von VPN-Client-TCP-Paketen über die PIX.
Nur Enterprise-Software.
8 MB Flash für das Image erforderlich.
Nur VPN-Beendigung.
Hinweis: Nur registrierte Cisco BenutzerInnen können auf interne Cisco Tools und Informationen zugreifen.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
2.0 |
02-Feb-2023 |
Aktualisiertes Format, korrigierte CCW-Warnungen, Neuzertifizierung. |
1.0 |
10-Dec-2001 |
Erstveröffentlichung |