AAA auf Cisco konfigurieren: Local, RADIUS und TACACS+

Wer Cisco Router und Switches professionell betreibt, kommt an AAA kaum vorbei. Mit AAA auf Cisco konfigurieren schaffen Sie eine saubere Basis für sichere Zugriffe, nachvollziehbare Änderungen und zentrale Benutzerverwaltung. AAA steht für Authentication (Authentifizierung), Authorization (Autorisierung) und Accounting (Protokollierung). In der Praxis beantwortet AAA drei Fragen: Wer darf sich anmelden? Was darf diese Person danach tun? Und was hat sie konkret gemacht? Gerade in Unternehmensnetzwerken ist das entscheidend – nicht nur aus Sicherheitsgründen, sondern auch für Compliance, Audits und einen stabilen Betrieb. Cisco IOS/IOS XE bietet mehrere AAA-Modelle: einen lokalen Benutzerbestand (Local AAA) sowie die Integration in zentrale Systeme über RADIUS oder TACACS+. Während RADIUS häufig für Netzwerkzugang (z. B. WLAN/802.1X) eingesetzt wird, ist TACACS+ im Geräte-Management (Router/Switch-Login und Command Authorization) besonders beliebt, weil es granular steuern kann, welche Befehle ein Nutzer ausführen darf. Dieser Leitfaden zeigt Ihnen, wie Sie Local, RADIUS und TACACS+ sauber konfigurieren, welche Best Practices sich bewährt haben (inklusive Fallback-Strategien, SSH, Rollenmodellen und Accounting) und wie Sie typische Fehler vermeiden, die im schlimmsten Fall zu einem Lockout führen.

Table of Contents

AAA Grundlagen: Authentication, Authorization, Accounting

AAA ist weniger „ein Feature“ als ein Rahmenwerk, das verschiedene Zugriffspfade (Console, SSH, VTY, HTTP(S), SNMP, PPP/802.1X) konsistent absichert. Für den Gerätebetrieb sind vor allem Console und VTY (SSH) relevant.

  • Authentication: Prüfung der Identität (Benutzername/Passwort, Schlüssel, Token).
  • Authorization: Festlegung, welche Privilegien und Befehle nach erfolgreicher Anmeldung erlaubt sind.
  • Accounting: Protokollierung von Logins, Sessions und optional von Befehlen (Command Accounting).

Ein sinnvolles AAA-Design vermeidet „Shared Accounts“, nutzt Rollen (z. B. Read-Only vs. Admin) und stellt sicher, dass immer ein Notfallzugang möglich bleibt, selbst wenn ein zentraler AAA-Server ausfällt.

Local, RADIUS oder TACACS+: Welche Variante wofür?

Viele Umgebungen nutzen nicht „entweder oder“, sondern eine Kombination: zentral, aber mit lokalem Fallback. Entscheidend ist, wofür Sie AAA einsetzen.

  • Local AAA: Einfach, unabhängig von Servern, ideal als Fallback oder für kleine Umgebungen.
  • RADIUS: Häufig für Netzwerkzugangskontrolle (z. B. 802.1X, VPN, WLAN), weniger ideal für detaillierte Command Authorization im Geräte-CLI.
  • TACACS+: Sehr gut für Geräte-Administration (Router/Switch), weil Authorization pro Befehl und pro Rollenprofil möglich ist.

Für technische Hintergründe und Standardisierung ist der Anchor-Text RFC 2865 (RADIUS) hilfreich. Für Cisco-spezifische AAA-Konfigurationen und Beispiele eignet sich der Anchor-Text Cisco AAA Installations- und Konfigurationsguides. Für TACACS+ als Cisco-zentriertes Protokoll ist der Anchor-Text Cisco TACACS+ Dokumentation ein guter Einstieg.

Vorbereitung: SSH, lokale Notfallkonten und sichere Basiskonfiguration

Bevor Sie AAA umstellen, sollten Sie die Management-Basics sauber haben. Das reduziert das Risiko, sich aus dem Gerät auszusperren.

  • SSH statt Telnet: Telnet ist unverschlüsselt, SSH ist Standard.
  • Lokales Break-Glass-Konto: Ein lokaler Admin-User mit starkem Passwort für Serverausfälle.
  • Console-Zugriff absichern: Console sollte nicht „offen“ sein, aber als Rettungsweg nutzbar bleiben.
  • Konfiguration dokumentieren: Vor Änderungen Running-Config sichern und Rollback-Plan bereithalten.

Beispiel: Lokaler Admin-User und SSH-Basics

configure terminal
hostname SW-CORE-01
ip domain-name firma.local
username breakglass privilege 15 secret <STARKES_PASSWORT>
crypto key generate rsa modulus 2048
ip ssh version 2
end

Best Practice: Nutzen Sie secret statt password, damit Passwörter nicht im Klartext gespeichert sind.

AAA aktivieren: Der zentrale Schalter

In Cisco IOS/IOS XE wird AAA über aaa new-model aktiviert. Ab diesem Moment greifen AAA-Method-Lists, und falsche Einstellungen können Zugriffe blockieren. Deshalb ist ein kontrolliertes Vorgehen wichtig.

Beispiel: AAA new-model aktivieren

configure terminal
aaa new-model
end

Praxis-Tipp: Aktivieren Sie AAA nicht „auf Verdacht“ auf produktiven Systemen ohne vorherige Method-Lists und ohne getestete lokale Fallbacks.

Local AAA: Lokale Authentifizierung und Privilegien sauber setzen

Local AAA ist die Basis, um auch ohne Serverzugriff administrieren zu können. Es eignet sich für kleine Netze oder als Notfallpfad in großen Netzen. Für den Alltag ist wichtig: Sie wollen lokale User nicht als einzige Quelle nutzen, aber als zuverlässige Rückfallebene.

VTY (SSH) mit Local Login absichern

configure terminal
line vty 0 4
transport input ssh
login local
exec-timeout 10 0
end

Console ebenfalls kontrollieren

configure terminal
line console 0
login local
exec-timeout 10 0
end

Best Practice: Setzen Sie sinnvolle Timeouts, um offene Sessions zu vermeiden. Zusätzlich können Sie per ACL Managementzugriff auf bestimmte Admin-Netze begrenzen.

RADIUS auf Cisco konfigurieren: Zentrale Authentifizierung für Login und Netzwerkzugang

RADIUS ist ein verbreitetes AAA-Protokoll, vor allem im Kontext von Netzwerkzugang (802.1X, VPN, WLAN). Für Geräte-Login (SSH/VTY) ist RADIUS ebenfalls möglich, aber bei der Autorisierung von CLI-Befehlen oft weniger granular als TACACS+. Dennoch ist RADIUS in vielen Unternehmen Standard, weil es eng in Identity-Systeme integriert ist.

RADIUS-Server definieren

Je nach IOS/IOS XE-Version finden Sie klassische Syntax (radius-server host) oder das modernere radius server-Format. Ein praxistaugliches Beispiel (modernes Format):

configure terminal
aaa new-model
radius server RAD1
address ipv4 10.0.0.10 auth-port 1812 acct-port 1813
key <SHARED_SECRET>
exit
aaa group server radius RAD-GRP
server name RAD1
end

Method-List: Login über RADIUS mit Local Fallback

configure terminal
aaa authentication login VTY-AUTH group RAD-GRP local
line vty 0 4
login authentication VTY-AUTH
transport input ssh
end

Die Logik ist bewusst: Erst RADIUS, wenn nicht erreichbar oder abgelehnt, dann local. Damit vermeiden Sie Lockouts bei RADIUS-Ausfällen.

Accounting: Logins protokollieren

configure terminal
aaa accounting exec VTY-ACCT start-stop group RAD-GRP
line vty 0 4
accounting exec VTY-ACCT
end

Accounting ist eine der wichtigsten E-E-A-T-Komponenten im Betrieb: Sie können nachweisen, wer wann eingeloggt war.

TACACS+ auf Cisco konfigurieren: Best Practice für Geräte-Administration

TACACS+ wird häufig bevorzugt, wenn es um Router- und Switch-Administration geht. Der Grund: TACACS+ trennt Authentication und Authorization sehr sauber und erlaubt in vielen Umgebungen eine feingranulare Command Authorization. So können Sie z. B. festlegen, dass ein Operator nur Show-Befehle ausführen darf, während Admins Konfiguration ändern dürfen.

TACACS+ Server definieren und Gruppen anlegen

configure terminal
tacacs server TAC1
address ipv4 10.0.0.20
key <SHARED_SECRET>
exit
aaa group server tacacs+ TAC-GRP
server name TAC1
end

Login über TACACS+ mit Local Fallback

configure terminal
aaa authentication login VTY-TAC group TAC-GRP local
line vty 0 4
login authentication VTY-TAC
transport input ssh
end

Enable/Privileged EXEC absichern

In vielen Designs wird zusätzlich der Enable-Zugang über AAA geregelt:

configure terminal
aaa authentication enable default group TAC-GRP enable
enable secret <FALLBACK_ENABLE_SECRET>
end

Damit können Sie im Notfall immer noch über das lokale Enable-Secret arbeiten, falls TACACS+ nicht verfügbar ist.

Authorization: Exec und Commands steuern

Die eigentliche Stärke von TACACS+ zeigt sich bei Authorization. Beispiel: Exec-Authorization (welcher Privilege-Level nach Login gesetzt wird) und Command Authorization für Privilege-Level 15:

configure terminal
aaa authorization exec VTY-EXEC group TAC-GRP local
aaa authorization commands 15 VTY-CMD group TAC-GRP local
line vty 0 4
authorization exec VTY-EXEC
authorization commands 15 VTY-CMD
end

Wichtig: Command Authorization kann sehr strikt sein. Wenn der TACACS+ Server keine passenden Policies liefert, können selbst Admins plötzlich keine Befehle ausführen. Deshalb unbedingt im Pilot testen.

Accounting: Exec und Commands protokollieren

Für Audits und Nachvollziehbarkeit ist Command Accounting besonders wertvoll:

configure terminal
aaa accounting exec VTY-EXEC-ACCT start-stop group TAC-GRP
aaa accounting commands 15 VTY-CMD-ACCT start-stop group TAC-GRP
line vty 0 4
accounting exec VTY-EXEC-ACCT
accounting commands 15 VTY-CMD-ACCT
end

Method-Lists verstehen: So bauen Sie sichere Fallbacks

AAA-Method-Lists sind das Herzstück: Sie definieren Reihenfolgen. Eine robuste Reihenfolge im Enterprise ist meist:

  • Primär: TACACS+ oder RADIUS (zentral)
  • Fallback: Local (Break-Glass)
  • Optional: Enable-Secret als letzter Notnagel

Wichtig ist, dass Ihr Fallback auch dann funktioniert, wenn DNS oder Routing zum AAA-Server gestört ist. Der lokale Break-Glass-User sollte daher unabhängig funktionieren und sicher verwahrt werden.

Rollenmodell und Least Privilege: Mehr Sicherheit ohne Produktivitätsverlust

AAA ist nicht nur „Login zentral“. Der eigentliche Mehrwert entsteht durch Rollen: Nicht jeder braucht Privilege 15. Ein praxistaugliches Rollenmodell kann z. B. so aussehen:

  • Read-Only: darf nur Show-Kommandos, Logs und Status sehen.
  • Operator: darf bestimmte Betriebsbefehle ausführen (z. B. Interface bounce nach Prozess), aber keine grundlegenden Policies ändern.
  • Admin: darf Konfiguration ändern, aber Änderungen sind vollständig accounted.

Dieses Prinzip passt zu gängigen Sicherheitsstandards und reduziert das Risiko von Fehlkonfigurationen. Als herstellerneutrale Orientierung für Rollen, Zugriffsmanagement und Logging eignet sich der Anchor-Text CIS Controls.

Best Practices für sichere AAA-Implementierung

  • Immer SSH nutzen: transport input ssh, Telnet deaktivieren.
  • Lokales Break-Glass-Konto: Starker Local-User mit Privilege 15, sicher dokumentiert.
  • AAA-Server redundant: Mindestens zwei Server, wenn möglich über verschiedene Pfade.
  • Method-List mit Fallback: zentral zuerst, lokal als Rückfall.
  • Command Accounting: Besonders bei Admin-Rechten aktivieren.
  • Management-Zugriff begrenzen: VTY per ACL nur aus Admin-Netzen erlauben.
  • Timeouts und Login-Policies: Exec-Timeouts setzen, brute-force erschweren (plattformabhängig).
  • Änderungen testen: erst auf einem Pilotgerät oder in Wartungsfenstern.

Verifikation: So prüfen Sie AAA ohne sich auszusperren

AAA-Konfigurationen sollten Sie schrittweise prüfen. Ein bewährtes Vorgehen ist: Erst neue Method-List definieren, dann auf nur eine VTY-Line oder ein Testgerät anwenden, während eine zweite Session offen bleibt.

  • show running-config | section aaa (AAA-Konfiguration prüfen)
  • show running-config | section line vty (welche Method-Lists sind gebunden?)
  • test aaa group tacacs+ <server-ip> <username> <password> (plattformabhängig)
  • show logging (Fehler, Auth-Fails, Server-Unreachables)

Zusätzlich ist es sinnvoll, Accounting-Einträge auf dem AAA-Server zu prüfen (Login, Commands), um sicherzustellen, dass Audit-Trails wirklich entstehen.

Typische Fehler und wie Sie sie vermeiden

Lockout durch falsche Method-List oder fehlenden Fallback

  • AAA-Server nicht erreichbar, aber kein Local-Fallback konfiguriert.
  • VTY auf AAA gebunden, Console ebenfalls, ohne Notweg.

Best Practice: Local-Fallback immer in der Method-List und mindestens Console als Rettungsweg.

Command Authorization blockiert legitime Admins

  • TACACS+ Policy liefert keine passenden Command-Rechte.
  • Command Authorization aktiviert, aber Server-Rollen sind unvollständig.

Best Practice: Erst Exec Authorization testen, dann Command Authorization im Pilot ausrollen.

Accounting fehlt oder ist unzuverlässig

  • Accounting nicht konfiguriert oder falsche Method-List gebunden.
  • Firewall blockiert Accounting Ports, oder Server-Definitionen sind inkonsistent.

Best Practice: Exec Accounting mindestens aktivieren, Command Accounting für Admins ergänzen, Logs und Counters prüfen.

RADIUS für Geräte-Administration ohne klare Rollensteuerung

  • RADIUS kann je nach Setup weniger granular für CLI-Befehle sein.
  • Fehlende Rollen/Privilegien führen zu zu viel oder zu wenig Zugriff.

Best Practice: Für Geräte-CLI oft TACACS+ bevorzugen, RADIUS eher für Network Access nutzen.

Praxis-Checkliste: AAA sauber einführen

  • SSH ist aktiv, Telnet deaktiviert, Managementzugriff ist auf Admin-Netze beschränkt.
  • Lokaler Break-Glass-User existiert und ist getestet.
  • AAA new-model ist aktiv, Method-Lists sind definiert und korrekt gebunden.
  • TACACS+ oder RADIUS Server sind redundant erreichbar und getestet.
  • Exec Authorization funktioniert, Command Authorization ist pilotiert (wenn genutzt).
  • Accounting (Exec und optional Commands) ist aktiv und auf dem Server sichtbar.
  • Rollback-Plan liegt vor (Console-Zugang, lokale Credentials, Wartungsfenster).

Konfiguration speichern und Betrieb absichern

Nachdem AAA für VTY/SSH erfolgreich getestet wurde, sollten Sie die Konfiguration speichern, damit sie nach einem Neustart erhalten bleibt:

copy running-config startup-config

Für vertiefende Cisco-spezifische Beispiele und Plattformunterschiede sind die Anchor-Texte Cisco AAA Konfigurationsguides sowie Cisco TACACS+ Dokumentation besonders hilfreich. Für den Standardkontext von RADIUS ist der Anchor-Text RFC 2865 eine solide Grundlage.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

  • Netzwerkdesign & Topologie-Planung

  • Router- & Switch-Konfiguration (Cisco IOS)

  • VLAN, Inter-VLAN Routing

  • OSPF, RIP, EIGRP (Grundlagen & Implementierung)

  • NAT, ACL, DHCP, DNS-Konfiguration

  • Troubleshooting & Netzwerkoptimierung

  • Packet Tracer Projektentwicklung & Dokumentation

  • CCNA Lern- & Praxisunterstützung

Lieferumfang:

  • Konfigurationsdateien

  • Packet-Tracer-Dateien (.pkt)

  • Netzwerkdokumentation

  • Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.

 

Related Articles