Benutzerzugriffsrechte
Sie (der Systemadministrator) gewähren Benutzern Zugriff oder Berechtigungen für Befehle und Konfigurationshierarchieebenen und -anweisungen. Benutzer können nur diese Befehle ausführen und nur die Anweisungen anzeigen und konfigurieren, für die sie Zugriffsrechte haben. Sie können auch erweiterte reguläre Ausdrücke verwenden, um anzugeben, welche Betriebsmodusbefehle, Konfigurationsanweisungen und Hierarchien für Benutzer zulässig oder verweigert werden. Diese Praxis hindert unbefugte Benutzer daran, sensible Befehle auszuführen oder Anweisungen zu konfigurieren, die das Netzwerk beschädigen könnten.
Übersicht über Zugriffsberechtigungsstufen
Jede Cli-Befehls- und Konfigurationsaussage auf der obersten Ebene verfügt über eine zugehörige Zugriffsberechtigungsstufe. Benutzer können nur diese Befehle ausführen und nur die Anweisungen konfigurieren und anzeigen, für die sie Zugriffsrechte haben. Ein oder mehrere Berechtigungsflags definieren die Zugriffsrechte für jede Anmeldeklasse.
Für jede Anmeldeklasse können Sie auch die Verwendung von Betriebs- und Konfigurationsmodusbefehlen und Anweisungshierarchien explizit zulassen oder ablehnen, die andernfalls durch eine in der permissions
Anweisung angegebene Berechtigungsstufe zulässig oder verweigert werden würden.
- Berechtigungsflaggen der Anmeldeklasse
- Zulassen und Verweigern einzelner Befehle und Auszugshierarchien für Anmeldeklassen
Berechtigungsflaggen der Anmeldeklasse
Sie verwenden Berechtigungsflags, um einem Benutzer Zugriff auf Betriebsmodusbefehle und Konfigurationshierarchieebenen und -anweisungen zu gewähren. Sie konfigurieren Berechtigungsflags für die Anmeldeklasse des Benutzers auf [edit system login class]
Hierarchieebene. Wenn Sie ein bestimmtes Berechtigungs-Flag angeben, erhält der Benutzer Zugriff auf die Befehle sowie auf die Konfigurationshierarchieebenen und Anweisungen, die diesem Flag entsprechen. Um Zugriff auf alle Befehle und Konfigurationsanweisungen zu gewähren, verwenden Sie das Berechtigungs-Flag all
.
Jeder aufgeführte Befehl repräsentiert diesen Befehl und alle Unterlizenzen mit diesem Befehl als Präfix. Jede aufgeführte Konfigurationsaussage stellt den Obersten der Konfigurationshierarchie dar, der dieses Flag Zugriff gewährt.
Die permissions
Anweisung gibt eine oder mehrere der in Tabelle 1. Berechtigungs-Flags sind nicht kumulierbar. Für jede Klasse müssen Sie alle erforderlichen Berechtigungs-Flags auflisten, einschließlich view
zum Anzeigen von Informationen und configure
zum Eintritt in den Konfigurationsmodus. Zwei Arten von Berechtigungen steuern den Zugriff eines Benutzers auf die einzelnen Teile der Konfiguration:
-
Formular "Plain": Bietet schreibgeschützte Funktionen für diesen Berechtigungstyp. Ein Beispiel ist
interface
. -
-control
form: Bietet Lese- und Schreibfunktionen für diesen Berechtigungstyp. Ein Beispiel istinterface-control
.
Für Berechtigungsflags, die Zugriff auf Konfigurationshierarchieebenen und -anweisungen gewähren, gewähren die einfachen Formular-Flags schreibgeschützte Berechtigungen für diese Konfiguration. Das Berechtigungs-Flag interface
gewährt beispielsweise schreibgeschützten Zugriff auf die [edit interfaces]
Hierarchieebene. Das -control
Flag-Formular gewährt Lese-/Schreibzugriff auf diese Konfiguration. Das Flag gewährt beispielsweise interface-control
Lese-/Schreibzugriff auf die [edit interfaces]
Hierarchieebene.
Tabelle 1 listet die Berechtigungsflags der Anmeldeklasse auf, die Sie konfigurieren können, indem sie die permissions
Anweisung auf Hierarchieebene [edit system login class class-name]
einschl.
Die Berechtigungs-Flags gewähren eine bestimmte Reihe von Zugriffsrechten. Jedes Berechtigungsflaggen wird mit den Befehlen im Betriebs- oder Konfigurationsmodus und der Konfigurationshierarchieebenen und -anweisungen aufgeführt, auf die dieses Flag Zugriff gewährt.
Berechtigungsflagge |
Beschreibung |
---|---|
Kann die Zugriffskonfiguration im Betriebs- oder Konfigurationsmodus anzeigen. |
|
Kann Zugriffsinformationen auf |
|
Kann Benutzerkontoinformationen im Betriebs- oder Konfigurationsmodus anzeigen. |
|
Kann Benutzerkontoinformationen anzeigen und auf |
|
Kann auf alle Betriebsmodusbefehle und Konfigurationsmodusbefehle zugreifen. Kann die Konfiguration in allen Konfigurationshierarchieebenen ändern. |
|
Kann Informationen löschen (löschen), die das Gerät aus dem Netzwerk lernt und (mithilfe der |
|
Kann in den Konfigurationsmodus (mit dem |
|
Kann alle Vorgänge auf Steuerungsebene durchführen – alle Vorgänge, die mit den |
|
Kann Befehle zum Debuggen von Felden anzeigen. Für Debugging-Unterstützung reserviert. |
|
Kann die Firewall-Filterkonfiguration im Betriebs- oder Konfigurationsmodus anzeigen. |
|
Kann Firewall-Filterinformationen auf |
|
Kann von den Wechselmedien lesen und darauf schreiben. |
|
Kann die Fluss-Tap-Konfiguration im Betriebs- oder Konfigurationsmodus anzeigen. |
|
Kann Datenfluss-Tap-Informationen auf |
|
Kann Datenstrom-Tap-Anforderungen an den Router oder Switch stellen. Ein DTCP-Client (Dynamic Tasking Control Protocol) muss beispielsweise über HINWEIS:
Die |
|
Kann Profiler-Daten anzeigen. |
|
Kann die Schnittstellenkonfiguration im Betriebs- und Konfigurationsmodus anzeigen. |
|
Kann Gehäuse, Class of Service (CoS), Gruppen, Weiterleitungsoptionen und Konfigurationsinformationen für Schnittstellen anzeigen. Kann die Konfiguration auf den folgenden Hierarchieebenen ändern:
|
|
Kann Systemwartung durchführen, einschließlich des Startens einer lokalen Shell auf dem Gerät und der Superuser in der Shell (mit dem |
|
Kann mithilfe von , |
|
Kann die Sitzungsspiegelungskonfiguration |
|
Kann die Konfiguration der Sitzungsspiegelung |
|
Kann Softwareprozesse mit dem |
|
Kann den |
|
Kann allgemeine Routing-, Routing-Protokoll- und Routingrichtlinienkonfigurationsinformationen im Konfigurations- und Betriebsmodus anzeigen. |
|
Kann allgemeines Routing auf Hierarchieebene |
|
Kann Passwörter und andere Authentifizierungsschlüssel in der Konfiguration anzeigen. |
|
Kann Passwörter und andere Authentifizierungsschlüssel in der Konfiguration anzeigen und ändern. |
|
Kann Sicherheitskonfigurationsinformationen im Betriebs- und Konfigurationsmodus anzeigen. |
|
Kann Sicherheitsinformationen auf |
|
Kann eine lokale Shell auf dem Router oder Switch mit dem |
|
Kann SNMP-Konfigurationsinformationen (Simple Network Management Protocol) im Betriebs- oder Konfigurationsmodus anzeigen. |
|
Kann SNMP-Konfigurationsinformationen auf |
|
Kann Informationen auf Systemebene im Betriebs- oder Konfigurationsmodus anzeigen. |
|
Kann Konfigurationsinformationen auf Systemebene auf |
|
Kann Trace-Dateieinstellungen anzeigen und Trace-Dateieigenschaften konfigurieren. |
|
Kann Trace-Dateieinstellungen ändern und Trace-Dateieigenschaften konfigurieren. |
|
Kann verschiedene Befehle verwenden, um die aktuelle systemweite Routing-Tabelle sowie protokollspezifische Werte und Statistiken anzuzeigen. Die geheime Konfiguration kann nicht angezeigt werden. |
|
Kann alle Konfigurationen mit Ausnahme von geheimnissen, Systemskripten und Ereignisoptionen anzeigen. HINWEIS:
Nur Benutzer mit der |
Zulassen und Verweigern einzelner Befehle und Auszugshierarchien für Anmeldeklassen
Standardmäßig verfügen alle CLI-Befehle der obersten Ebene und Konfigurationshierarchieebenen über entsprechende Zugriffsberechtigungsstufen. Benutzer können nur diese Befehle ausführen und nur die Anweisungen anzeigen und konfigurieren, für die sie Zugriffsrechte haben. Für jede Anmeldeklasse können Sie die Verwendung von Betriebs- und Konfigurationsmodusbefehlen und Anweisungshierarchien explizit zulassen und ablehnen, die andernfalls durch eine in der permissions
Anweisung angegebene Berechtigungsstufe zulässig oder verweigert werden würden.
Berechtigungs-Flags gewähren einem Benutzer Zugriff auf Betriebs- und Konfigurationsmodusbefehle sowie auf Konfigurationshierarchieebenen und -anweisungen. Indem Sie ein bestimmtes Berechtigungs-Flag für die Anmeldeklasse des Benutzers auf Hierarchieebene [edit system login class]
angeben, gewähren Sie dem Benutzer Zugriff auf die entsprechenden Befehle und Konfigurationshierarchieebenen und -anweisungen. Um Zugriff auf alle Befehle und Konfigurationsanweisungen zu gewähren, verwenden Sie das Berechtigungs-Flag all
.
Sie können die Verwendung von Befehlen und Anweisungen explizit zulassen oder ablehnen, indem Sie die allow-commands
, deny-commands
, , allow-configuration
und deny-configuration
Anweisungen für eine Anmeldeklasse konfigurieren. In den Anweisungen verwenden Sie erweiterte reguläre Ausdrücke, um zu definieren, welche Befehle und Anweisungen für Benutzer, die der Klasse zugewiesen sind, zulassen oder ablehnen.
Beispiel: Konfigurieren von Benutzerberechtigungen mit Zugriffsrechten
In diesem Beispiel werden die Benutzerberechtigungen für eine Anmeldeklasse konfiguriert. Sie konfigurieren Benutzerberechtigungen für eine Anmeldeklasse, um zu verhindern, dass Benutzer nicht autorisierte Netzwerkaktionen ausführen. Benutzer können nur diese Befehle ausführen und nur die Anweisungen anzeigen und ändern, für die sie Zugriffsrechte haben. Diese Einschränkung hindert unbefugte Benutzer daran, sensible Befehle oder Konfiguration von Anweisungen auszuführen, die das Netzwerk beschädigen könnten.
Anforderungen
Vor der Konfiguration dieses Beispiels ist keine spezielle Konfiguration erforderlich, die über die Geräteinitialisierung hinausgeht.
Überblick
Jedem CLI-Befehl der obersten Ebene und jeder Konfigurationsaussage ist eine Zugriffsberechtigungsstufe zugeordnet. Wenn Sie eine Anmeldeklasse konfigurieren, können Sie die Verwendung von Betriebsmodus- und Konfigurationsmodusbefehlen und Konfigurationsanweisungen explizit zulassen oder ablehnen. Benutzer können nur diese Befehle ausführen und nur die Anweisungen anzeigen und konfigurieren, für die sie Zugriffsrechte haben.
Sie definieren die Zugriffsrechte für jede Anmeldeklasse, indem Sie ein oder mehrere Berechtigungsflags in der permissions
Anweisung angeben. Berechtigungs-Flags gewähren einem Benutzer Zugriff auf Befehle, Anweisungen und Hierarchien. Berechtigungs-Flags sind nicht kumulierbar. Für jede Anmeldeklasse müssen Sie alle erforderlichen Berechtigungs-Flags auflisten, einschließlich view
der Anzeige von Informationen und configure
zum Eintritt in den Konfigurationsmodus. Indem Sie ein bestimmtes Berechtigungs-Flag in der Anmeldeklasse des Benutzers angeben, gewähren Sie dem Benutzer Zugriff auf die entsprechenden Befehle, Anweisungen und Hierarchien. Um Zugriff auf alle Befehle und Konfigurationsanweisungen zu gewähren, verwenden Sie das Berechtigungs-Flag all
. Die Berechtigungsflaggen bieten schreibgeschützte ("einfaches" Formular) und Lese- und Schreibfunktionen (Formular, das mit -control endet) für einen Berechtigungstyp.
Die all
Berechtigungsbits für die Anmeldeklasse haben Vorrang vor erweiterten regulären Ausdrücken, wenn ein Benutzer einen rollback
Befehl mit aktivierter rollback
Berechtigungsflagge aus gibt.
Um Benutzerzugriffsberechtigungen für eine Anmeldeklasse zu konfigurieren, fügen Sie die permissions
Anweisung auf Hierarchieebene [edit system login class class-name]
und gefolgt von den Berechtigungs-Flags ein. Konfigurieren Sie mehrere Berechtigungen als durch Leerzeichen getrennte Liste, die in eckigen Klammern eingeschlossen ist:
[edit system login] user@host# set class class-name permissions permission-flag user@host# set class class-name permissions [flag1 flag2 flag3]
Um die verfügbaren Berechtigungen anzuzeigen, verwenden Sie die kontextsensitive Hilfe der CLI und geben ein Fragezeichen (?) nach der permissions
Anweisung ein:
[edit system login] user@host# set class class-name permissions ?
Konfiguration
In diesem Beispiel wird die snmp-admin
Anmeldeklasse konfiguriert. Benutzer in dieser Anmeldeklasse können nur SNMP-Parameter konfigurieren und anzeigen.
Konfigurieren von Benutzerberechtigungen mit Zugriffsrechten
Schritt-für-Schritt-Verfahren
So konfigurieren Sie Zugriffsrechte für die Anmeldeklasse:
-
Konfigurieren Sie die
snmp-admin
Anmeldeklasse mit denconfigure
,snmp
undsnmp-control
Berechtigungsflaggen.[edit system login] user@host# set class snmp-admin permissions [configure snmp snmp-control]
Die konfigurierten Berechtigungs-Flags bieten sowohl Lese- (SNMP) als auch Snmp-Schreibfunktion (SNMP-Control), und dies ist die einzige zulässige Zugriffsrechte für diese Anmeldeklasse. Alle anderen Zugriffsrechte werden verweigert.
-
Erstellen Sie die Benutzerkonten, die der
snmp-admin
Anmeldeklasse zugewiesen sind.[edit system login] user@host# set user snmpuser class snmp-admin authentication plain-text-password New password: Retype new password:
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie den show system login
Befehl eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@host# show system login class snmp-admin { permissions [ configure snmp snmp-control ]; } user snmpuser { class snmp-admin; authentication { encrypted-password "$ABC123"; ## SECRET-DATA } }
Gehen Sie commit
nach der Konfiguration des Geräts in den Konfigurationsmodus.
Überprüfung
Melden Sie sich mit einem Benutzernamen an, der der neuen Anmeldeklasse zugewiesen ist, und bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
SNMP-Konfiguration überprüfen
Zweck
Stellen Sie sicher, dass ein Benutzer in der snmp-admin
Anmeldeklasse SNMP konfigurieren kann.
Aktion
Konfigurieren Sie im Konfigurationsmodus SNMP-Anweisungen auf [edit snmp]
Hierarchieebene.
[edit snmp] user@host# set name device1 user@host# set description switch1 user@host# set location Lab1 user@host# set contact example.com user@host# commit
Bedeutung
Der Benutzer in der snmp-admin
Anmeldeklasse kann SNMP-Parameter konfigurieren. Der Benutzer kann diese Parameter konfigurieren, da die für diese Klasse angegebenen Berechtigungs-Flags sowohl SNMP -Berechtigungsbits (Lesefunktionen) als auch snmp-control (Lese- und Schreibfunktionen) enthalten.
Überprüfen der Nicht-SNMP-Konfiguration
Zweck
Stellen Sie sicher, dass ein Benutzer in der snmp-admin
Anmeldeklasse Nicht-SNMP-Konfigurationsanweisungen ändern kann.
Aktion
Versuchen Sie im Konfigurationsmodus, jede Nicht-SNMP-Anweisung zu konfigurieren, z. B. eine Anweisung in der interfaces
Hierarchie.
[edit] user@host# edit interfaces Syntax error, expecting <statement> or <identifier>.
Bedeutung
Der Benutzer in der snmp-admin
Anmeldeklasse ist nicht in der Lage, die [edit interfaces]
Hierarchie zu konfigurieren, da die für diese Klasse angegebenen Berechtigungs-Flags dies nicht zulassen. In diesem Fall gibt die CLI eine Fehlermeldung aus.
Reguläre Ausdrücke zum Zulassen und Ablehnen von Befehlen im Betriebsmodus, Konfigurationsanweisungen und Hierarchien
Dieses Thema enthält die folgenden Abschnitte:
- Grundlegendes zu Deny- und Zulassen-Aussagen
- Grundlegendes zur Syntax der Anweisung Zulassen und Ablehnen
- Grundlegendes zur Rangfolge und Demy-Anweisung "Allow and Deny Statement" (Rangfolge und Abgleich)
- Grundlegendes zu Deny- und Allowy Statement-Regeln
- Unterschiede für die *-regexps-Aussagen verstehen
- Verwenden von regulären Ausdrücken auf Remote-Autorisierungsservern
- Angeben regulärer Ausdrücke
- Operatoren regulärer Ausdrücke
- Beispiele für reguläre Ausdrücke
Grundlegendes zu Deny- und Zulassen-Aussagen
Jeder Cli-Befehls- und Konfigurations-Anweisungshierarchie auf der obersten Ebene ist eine Zugriffsberechtigungsstufe zugeordnet. Jede Anmeldeklasse kann explizit die Verwendung von Betriebs- und Konfigurationsmodusbefehlen sowie Konfigurationshierarchien und Anweisungen zulassen oder ablehnen, die andernfalls durch eine Berechtigungsebene zulässig oder verweigert werden würden. Benutzer können nur diese Befehle ausführen und nur die Anweisungen anzeigen und konfigurieren, für die sie Zugriffsrechte haben.
Die Zugriffsrechte für jede Anmeldeklasse werden durch ein oder mehrere Berechtigungsflags definiert, die in der permissions
Anweisung auf Hierarchieebene [edit system login class class-name]
angegeben sind. Darüber hinaus können Sie die Verwendung bestimmter Befehle und Konfigurationshierarchien zulassen oder ablehnen, indem Sie erweiterte reguläre Ausdrücke definieren. Sie können die regulären Ausdrücke angeben, indem Sie die folgenden Anweisungen für eine Anmeldeklasse konfigurieren:
-
allow-commands
unddeny-commands
— Erlauben oder verweigern Sie den Zugriff auf Betriebs- und Konfigurationsmodusbefehle. -
allow-configuration
unddeny-configuration
— Erlauben oder verweigern Sie den Zugriff auf bestimmte Konfigurationshierarchien.HINWEIS:Diese Aussagen führen langsamere Übereinstimmungen durch und bieten mehr Flexibilität, insbesondere beim Wildcard-Matching. Es kann jedoch sehr lange dauern, alle möglichen Aussagen zu bewerten, wenn eine große Anzahl von regulären Ausdrücken mit vollem Pfad oder Platzhalterausdrücken konfiguriert ist, was sich möglicherweise negativ auf die Leistung auswirkt.
-
allow-commands-regexps
unddeny-commands-regexps
— Erlauben oder verweigern Sie den Zugriff auf bestimmte Befehle mithilfe von Zeichenfolgen regulärer Ausdrücke. -
allow-configuration-regexps
unddeny-configuration-regexps
— Erlauben oder verweigern Sie den Zugriff auf bestimmte Konfigurationshierarchien mithilfe von Zeichenfolgen regulärer Ausdrücke.
Wenn Ihre vorhandenen Konfigurationen die allow/deny-commands
oder allow/deny-configuration
Anweisungen verwenden, führen die Verwendung derselben Konfigurationsoptionen mit den allow/deny-commands-regexps
oder allow/deny-configuration-regexps
Anweisungen möglicherweise nicht zu den gleichen Ergebnissen. Die Such- und Abgleichmethoden unterscheiden sich in den beiden Formen dieser Aussagen.
Das explizite Zulassen von Befehlen und Konfigurationsanweisungenhierarchien mithilfe der allow/deny-*
Anweisungen fügt den Berechtigungen hinzu, die in der permissions
Anweisung bereits definiert werden. Ebenso entfernt das explizite Ablehnen von Befehlen und Konfigurationsanweisungenhierarchien mithilfe der Anweisungen berechtigungen allow/deny-*
, die bereits in der permissions
Anweisung definiert werden.
In der folgenden Konfiguration ermöglicht die configure
Berechtigung beispielsweise Benutzern in der Anmeldeklasse den Eintritt in den Konfigurationsmodus. Darüber hinaus ermöglicht der allow-configuration
Ausdruck Benutzern, die Konfiguration auf [edit system services]
Hierarchieebene zu ändern und zu bestätigen.
[edit system login class test] user@host# set permissions configure allow-configuration "system services"
Ebenso kann der Benutzer der Anmeldeklasse in der folgenden Konfiguration alle Vorgänge ausführen, die das all
Berechtigungs-Flag zulässt, es sei denn, der Benutzer kann die Konfiguration nicht auf [edit system services]
Hierarchieebene anzeigen oder ändern:
[edit system login class test] user@host# set permissions all deny-configuration "system services"
Grundlegendes zur Syntax der Anweisung Zulassen und Ablehnen
Sie können eine allow/deny-*
Anweisung nur einmal in jeder Anmeldeklasse konfigurieren. Wenn Sie eine Anweisung konfigurieren,
-
Sie können so viele reguläre Ausdrücke konfigurieren, wie sie benötigt werden.
-
Bei regulären Ausdrücken wird die Groß- und Kleinschreibung nicht berücksichtigt.
Die allow/deny-commands
Aussagen schließen sich gegenseitig mit den allow/deny-commands-regexps
Aussagen aus, und die allow/deny-configuration
Aussagen schließen sich gegenseitig mit den allow/deny-configuration-regexps
Aussagen aus. Sie können beispielsweise nicht beides allow-configuration
und allow-configuration-regexps
in derselben Anmeldeklasse konfigurieren.
Um Zugriffsberechtigungen für Befehle zu definieren, geben Sie erweiterte reguläre Ausdrücke mithilfe von und allow-commands
deny-commands
Anweisungen an. Schließen Sie jeden vollständigen eigenständigen Ausdruck in Klammern ( ) ein und verwenden Sie das Pipe-Symbol (|), um die Ausdrücke zu trennen. Verwenden Sie keine Leerzeichen zwischen regulären Ausdrücken, die mit dem Pipe-Symbol verbunden sind. Der vollständige Ausdruck ist in doppelte Anführungszeichen eingeschlossen.
allow-commands "(cmd1)|(cmd2)|(cmdn)" allow-configuration "(config1)|(config2)|(confign)"
Zum Beispiel:
[edit system login class test] user@host# set allow-commands "(ping .*)|(traceroute .*)|(show .*)|(configure .*)|(edit)|(exit)|(commit)|(rollback .*)"
Wenn Sie komplexe reguläre Ausdrücke mit der allow-commands
Anweisung angeben, müssen Sie Anker verwenden. Zum Beispiel:
[edit system login] user@host# set class test allow-commands "(^monitor)|(^ping)|(^show)|(^exit)"
Um Zugriffsberechtigungen für Teile der Konfigurationshierarchie zu definieren, geben Sie erweiterte reguläre Ausdrücke in der und deny-configuration
den allow-configuration
Anweisungen an. Schließen Sie die vollständigen Pfade in Klammern ( ) ein und verwenden Sie das Pipe -Symbol (|), um die Ausdrücke zu trennen. Verwenden Sie keine Leerzeichen zwischen regulären Ausdrücken, die mit dem Pipe-Symbol verbunden sind. Der vollständige Ausdruck ist in doppelte Anführungszeichen eingeschlossen.
allow-configuration "(config1)|(config2)|(confign)"
Zum Beispiel:
[edit system login class test] user@host# set deny-configuration "(system login class)|(system services)"
Wenn Sie erweiterte reguläre Ausdrücke mit dem oder allow/deny-configuration-regexps
Anweisungen allow/deny-commands-regexps
angeben, schließen Sie jeden Ausdruck in Anführungszeichen (" ") ein und trennen Sie die Ausdrücke mithilfe eines Leerzeichens. Schließen Sie mehrere Ausdrücke in eckige Klammern [ ]. Zum Beispiel:
[edit system login class test] user@host# set allow-configuration-regexps ["interfaces .* description .*" "interfaces .* unit .* description .*" “interfaces .* unit .* family inet address .*" "interfaces.* disable"]
Modifizierer wie set
, log
und count
werden innerhalb der Zeichenfolge mit regulären Ausdrücken, die abgeglichen werden soll, nicht unterstützt. Wenn Sie einen Modifizierer verwenden, wird nichts abgeglichen.
Korrekte Konfiguration:
[edit system login class test] user@host# set deny-commands protocols
Falsche Konfiguration:
[edit system login class test] user@host# set deny-commands "set protocols"
Grundlegendes zur Rangfolge und Demy-Anweisung "Allow and Deny Statement" (Rangfolge und Abgleich)
Standardmäßig haben die allow-commands
ausdrücken und allow-configuration
die regulären Ausdrücke Vorrang vor den Ausdrücken deny-commands
deny-configuration
. Wenn Sie also denselben Befehl für die allow-commands
Und-Anweisungen deny-commands
konfigurieren, hat der Allow-Vorgang Vorrang vor dem Vorgang deny. Ebenso hat der Allow-Vorgang Vorrang vor dem Vorgang ablehnen, wenn Sie dieselbe Anweisung sowohl für die allow-configuration
deny-configuration
als auch für die Anweisungen konfigurieren.
Die folgende Konfiguration ermöglicht es beispielsweise einem Benutzer in der test
Anmeldeklasse, Software mit dem request system software add
Befehl zu installieren, obwohl die deny-commands
Anweisung den gleichen Befehl enthält:
[edit system login class test] user@host# set allow-commands "request system software add" user@host# set deny-commands "request system software add"
Ebenso ermöglicht die folgende Konfiguration einem Benutzer im Anmeldeklassentest, test
die [edit system services]
Konfigurationshierarchie anzuzeigen und zu ändern, obwohl die deny-configuration
Anweisung dieselbe Hierarchie enthält:
[edit system login class test] user@host# set allow-configuration "system services" user@host# set deny-configuration "system services"
Wenn die allow-commands
Anweisungen deny-commands
zwei verschiedene Varianten eines Befehls haben, wird immer die längste Übereinstimmung ausgeführt. Die folgende Konfiguration ermöglicht es einem Benutzer in der test
Anmeldeklasse, den commit synchronize
Befehl auszuführen, aber nicht den commit
Befehl. Dies liegt daran, dass commit synchronize
die längste Übereinstimmung zwischen commit
und und commit synchronize
, und sie für angegeben ist.allow-commands
[edit system login class test] user@host# set allow-commands "commit synchronize" user@host# set deny-commands commit
Die folgende Konfiguration ermöglicht es einem Benutzer in der test
Anmeldeklasse, den commit
Befehl auszuführen, aber nicht den commit synchronize
Befehl. Dies liegt daran, dass commit synchronize
die längste Übereinstimmung zwischen commit
und und commit synchronize
, und sie für angegeben ist.deny-commands
[edit system login class test] user@host# set allow-commands commit user@host# set deny-commands "commit synchronize"
Im Gegensatz zu den anderen Anweisungen besteht das Standardverhalten für die *-regexps
Anweisungen darin, dass die und deny-configuration-regexps
die deny-commands-regexps
regulären Ausdrücke Vorrang vor ausdrücken allow-commands-regexps
habenallow-configuration-regexps
. Sie können die regex-additive-logic
Anweisung auf Hierarchieebene [edit system]
konfigurieren, um zu erzwingen, dass die allow-configuration-regexps
regulären Ausdrücke Vorrang vor den deny-configuration-regexps
Anweisungen haben. Wenn Sie die Anweisung konfigurieren, können Sie Konfigurationshierarchien auf einer höheren Ebene verweigern und dem Benutzer dann nur den Zugriff auf bestimmte Unterhierarchien gewähren.
Grundlegendes zu Deny- und Allowy Statement-Regeln
Der allow/deny-commands
, , allow/deny-configuration
, , allow/deny-commands-regexps
und allow/deny-configuration-regexps
die Anweisungen haben Vorrang vor den Berechtigungen der Anmeldeklasse. Wenn Sie diese Anweisungen konfigurieren, gelten die folgenden Regeln:
-
Reguläre Ausdrücke
allow-commands
unddeny-commands
Anweisungen können auch diecommit
Befehle ,load
, ,rollback
,save
,status
undupdate
Befehle umfassen. -
Die
all
Berechtigungsbits für die Anmeldeklasse haben Vorrang vor erweiterten regulären Ausdrücken, wenn ein Benutzer denrollback
Befehl mit aktivierterrollback
Berechtigungsflagge aus gibt. -
Benutzer können den
load override
Befehl nicht ausstellen, wenn sie einen erweiterten regulären Ausdruck angeben. Benutzer können nur diemerge
Befehle undreplace
patch
Konfigurationsbefehle ausstellen. -
Beim Ablehnen von regulären Ausdrücken können Sie das Wildcard-Zeichen * verwenden. Sie müssen ihn jedoch als Teil eines regulären Ausdrucks verwenden. Sie können den einzigen Ausdruck nicht verwenden
[ * ]
.[ .* ]
Darüber hinaus können Sie dieallow-configuration
Anweisung nicht mit einem Ausdruck wie(interfaces (description (|.*))
, konfigurieren, da dieser aufallow-configuration .*
.
Unterschiede für die *-regexps-Aussagen verstehen
In diesem Abschnitt werden die Unterschiede zwischen den allow/deny-configuration
Aussagen und den allow/deny-configuration-regexps
Aussagen beschrieben.
Die allow/deny-configuration-regexps
Anweisungen teilen den regulären Ausdruck in Token auf und gleichen jedes Stück mit jedem Teil des vollständigen Pfads der angegebenen Konfiguration, während die allow/deny-configuration
Anweisungen mit der vollständigen Zeichenfolge übereinstimmen. Für allow/deny-configuration-regexps
Anweisungen konfigurieren Sie eine Reihe von Zeichenfolgen, in denen jede Zeichenfolge ein regulärer Ausdruck ist, mit Leerzeichen zwischen den Begriffen der Zeichenfolge. Diese Syntax ermöglicht eine sehr schnelle Übereinstimmung, bietet jedoch weniger Flexibilität. Zum Festlegen von Platzhalterausdrücken müssen Sie Platzhalter für jedes Token der Zeichenfolge mit Leerzeichen, die Sie abgleichen möchten, einrichten, was die Verwendung von Platzhalterausdrücken für diese Anweisungen erschwert.
Zum Beispiel:
-
Regulärer Ausdruck, der ein Token unter Verwendung von allow-configuration-regexps abgleicht
In diesem Beispiel wird
options
der einzige Ausdruck mit dem ersten Token der Anweisung abgeglichen.[edit system] login { class test { permissions configure; allow-configuration-regexps .*options; } }
Die vorhergehende Konfiguration entspricht den folgenden Anweisungen:
-
Festlegen der Bedingung condition für Richtlinienoptionen dynamic-db
-
Festlegen von Routing-Optionen statische Route static-route Next-Hop next-hop
-
Setzen Sie ereignisbasierte Optionen , Zeitintervalle für ereignisgeneriere event Ereignisse seconds
Die vorhergehende Konfiguration entspricht nicht den folgenden Anweisungen:
-
System-Host-Name-Host-Optionen
-
Schnittstellenbeschreibungsoptioneninterface-name
-
-
Regulärer Ausdruck, der drei Token unter Verwendung von allow-configuration-regexps abgleicht
In diesem Beispiel wird
ssh
der einzige Ausdruck mit dem dritten Token der Anweisung abgeglichen.[edit system] login { class test { permissions configure; allow-configuration-regexps ".* .* .*ssh"; } }
Im vorhergehenden Beispiel umfassen
.*
die drei Token ,.*
und.*ssh
.Die vorhergehende Konfiguration entspricht den folgenden Anweisungen:
-
Host-Name des Systems hostname-ssh
-
Systemservices ssh
-
Systemservices outbound-ssh
Die vorhergehende Konfiguration entspricht nicht der folgenden Anweisung:
-
Schnittstellenbeschreibung interface-namessh
-
Es ist einfacher, die Anweisung zur Einschränkung des deny-configuration
Konfigurationszugriffs zu verwenden, als die deny-configuration-regexps
Anweisung zu verwenden. Tabelle 2 Veranschaulicht die Verwendung sowohl der Anweisungen als deny-configuration-regexps
auch der deny-configuration
Anweisungen in verschiedenen Konfigurationen, um dasselbe Ergebnis der Zugriffsbeschränkung auf eine bestimmte Konfiguration zu erzielen.
Konfiguration verweigert |
Mit: |
Mit: |
Ergebnis |
|
[edit system] login { class test { permissions configure; allow-configuration .*; deny-configuration .*xnm-ssl; } } |
[edit system] login { class test { permissions configure; allow-configuration .*; deny-configuration-regexps ".* .* .*-ssl""; } } |
Die folgende Konfigurationsaussage wird abgelehnt:
|
|
[edit system] login { class test { permissions configure; allow-configuration .*; deny-configuration ".*ssh"; } } |
[edit system] login { class test { permissions configure; allow-configuration .*; deny-configuration-regexps ".*ssh"; deny-configuration-regexps ".* .*ssh"; deny-configuration-regexps ".* .* .*ssh"; } } |
Die folgenden Konfigurationsanweisungen werden abgelehnt:
|
Obwohl die allow/deny-configuration
Anweisungen auch nützlich sind, wenn Sie eine einfache Konfiguration wünschen, bieten die allow/deny-configuration-regexps
Anweisungen eine bessere Leistung und überwinden die Unklarheit, die beim Kombinieren von Ausdrücken in den allow/deny-configuration
Anweisungen vorhanden war.
Verwenden von regulären Ausdrücken auf Remote-Autorisierungsservern
Sie können erweiterte reguläre Ausdrücke verwenden, um anzugeben, welche Betriebs- und Konfigurationsmodusbefehle sowie Konfigurationsanweisungen und Hierarchien für bestimmte Benutzer zulässig oder verweigert werden. Sie geben diese regulären Ausdrücke lokal in der allow/deny-commands
, und allow/deny-commands-regexps
allow/deny-configuration
allow/deny-configuration-regexps
Anweisungen auf [edit system login class class-name]
Hierarchieebene an. Sie geben diese regulären Ausdrücke remote an, indem Sie in der Konfiguration des Autorisierungsservers anbieterspezifische TACACS+ oder RADIUS-Attribute von Juniper Networks angeben. Wenn Sie Autorisierungsparameter sowohl lokal als auch remote konfigurieren, führt das Gerät die regulären Ausdrücke, die während der TACACS+- oder RADIUS-Autorisierung empfangen werden, mit beliebigen regulären Ausdrücken zusammen, die auf dem lokalen Gerät definiert sind.
Ab Junos OS Version 18.1 werden die Anweisungen und deny-commands-regexps
Anweisungen für die allow-commands-regexps
TACACS+-Autorisierung unterstützt.
Wenn Sie mehrere reguläre Ausdrücke in einer lokalen Konfiguration mithilfe von allow-commands
, , deny-commands
oder allow-configuration
deny-configuration
Anweisungen angeben, konfigurieren Sie reguläre Ausdrücke in Klammern und trennen sie mithilfe des Pipe-Symbols. Sie schließen den vollständigen Ausdruck in doppelte Anführungszeichen ein. Sie können beispielsweise mehrere allow-commands
Parameter mit der folgenden Syntax angeben:
allow-commands "(cmd1)|(cmd2)|(cmdn)"
Der RADIUS-Autorisierungsserver verwendet die folgenden Attribute und die folgende Syntax:
Juniper-Allow-Commands += "(cmd1)|(cmd2)|(cmd3)", Juniper-Deny-Commands += "(cmd1)|(cmd2)", Juniper-Allow-Configuration += "(config1)|(config2)", Juniper-Deny-Configuration += "(config1)|(config2)",
Der TACACS+-Autorisierungsserver verwendet die folgenden Attribute und die folgende Syntax:
allow-commands = "(cmd1)|(cmd2)|(cmdn)" deny-commands = "(cmd1)|(cmd2)|(cmdn)" allow-configuration = "(config1)|(config2)|(confign)" deny-configuration = "(config1)|(config2)|(confign)"
Wenn Sie mehrere reguläre Ausdrücke in einer lokalen Konfiguration mit dem allow-commands-regexps
, , deny-commands-regexps
, allow-configuration-regexps
oder deny-configuration-regexps
Anweisungen angeben, konfigurieren Sie reguläre Ausdrücke in doppelten Anführungszeichen und trennen sie mit dem Leerzeichenoperator. Sie schließen den vollständigen Ausdruck in eckige Klammern ein. Sie können z. B. mehrere Allow-Commands-Parameter mit der folgenden Syntax angeben:
allow-commands-regexps [ "cmd1" "cmd2" "cmdn" ]
Der RADIUS-Autorisierungsserver verwendet die folgenden Attribute und die folgende Syntax:
Juniper-Allow-Configuration-Regexps += "(config1)|(config2)|(confign)", Juniper-Deny-Configuration-Regexps += "(config1)|(config2)|(confign)",
Der TACACS+-Autorisierungsserver verwendet die folgenden Attribute und die folgende Syntax:
allow-commands-regexps = "(cmd1)|(cmd2)|(cmdn)" deny-commands-regexps = "(cmd1)|(cmd2)|(cmdn)" allow-configuration-regexps = "(config1)|(config2)|(confign)" deny-configuration-regexps = "(config1)|(config2)|(confign)"
RADIUS- und TACACS+-Server unterstützen außerdem eine vereinfachte Syntax, bei der Sie jeden einzelnen Ausdruck in einer separaten Zeile angeben. Die vereinfachte Syntax des RADIUS-Servers lautet beispielsweise:
Juniper-Allow-Commands += "cmd1", Juniper-Allow-Commands += "cmd2", Juniper-Allow-Commands += "cmdn",
Ebenso lautet die vereinfachte TACACS+-Serversyntax:
allow-commands-regexps1 = "cmd1" allow-commands-regexps2 = "cmd2" allow-commands-regexpsn = "cmdn"
Tabelle 3 Unterscheidet die lokale Autorisierungskonfiguration und die TACACS+-Serverautorisierungskonfiguration mithilfe von regulären Ausdrücken.
Lokale Konfiguration |
Remote TACACS+-Konfiguration |
---|---|
login { class local { permissions configure; allow-commands "(ping .*)|(traceroute .*)|(show .*)|(configure .*)|(edit)|(exit)|(commit)|(rollback .*)"; deny-commands .*; allow-configuration "(interfaces .* unit 0 family ethernet-switching vlan mem.* .*)|(interfaces .* native.* .*)|(interfaces .* unit 0 family ethernet-switching interface-mo.* .*)|(interfaces .* unit .*)|(interfaces .* disable)|(interfaces .* description .*)|(vlans .* vlan-.* .*)" deny-configuration .*; } } |
user = remote { login = username service = junos-exec { allow-commands1 = "ping .*" allow-commands2 = "traceroute .*" allow-commands3 = "show .*" allow-commands4 = "configure" allow-commands5 = "edit" allow-commands6 = "exit" allow-commands7 = "commit" allow-commands8 = ".*xml-mode" allow-commands9 = ".*netconf.*" allow-commands10 = ".*need-trailer" allow-commands11 = "rollback.*" allow-commands12 = "junoscript" deny-commands1 = ".*" allow-configuration1 = "interfaces .* unit 0 family ethernet-switching vlan mem.* .*" allow-configuration2 = "interfaces .* native.* .*" allow-configuration3 = "interfaces .* unit 0 family ethernet-switching interface-mo.* .*" allow-configuration4 = "interfaces .* unit .*" allow-configuration5 = "interfaces .* disable" allow-configuration6 = "interfaces .* description .*" allow-configuration7 = "interfaces .*" allow-configuration8 = "vlans .* vlan-.* .*" deny-configuration1 = ".*" local-user-name = local-username user-permissions = "configure" } } |
-
Sie müssen den Zugriff auf den NETCONF-Modus explizit zulassen, entweder lokal oder per Fernzugriff, indem Sie die folgenden drei Befehle ausstellen:
xml-mode
,netconf
undneed-trailer
. -
Wenn Sie die
deny-configuration = ".*"
Anweisung verwenden, müssen Sie alle gewünschten Konfigurationen mit derallow-configuration
Anweisung zulassen. Diese Konfiguration kann sich jedoch auf die Puffergrenze der zulässigen regulären Ausdrücke für dieallow-configuration
Anweisung auswirken. Wenn diese Grenze überschritten wird, funktioniert die zulässige Konfiguration möglicherweise nicht.
Angeben regulärer Ausdrücke
Achten Sie beim Angeben regulärer Ausdrücke für Befehle und Konfigurationsanweisungen auf die folgenden Beispiele. Ein regulärer Ausdruck mit ungültiger Syntax liefert möglicherweise nicht die gewünschten Ergebnisse, selbst wenn die Konfiguration ohne Fehler festgelegt wird.
Sie sollten reguläre Ausdrücke für Befehle und Konfigurationsanweisungen auf die gleiche Weise angeben wie die Ausführung des vollständigen Befehls oder der vollständigen Anweisung. Tabelle 4 listet die regulären Ausdrücke für die Konfiguration von Zugriffsrechten für die [edit interfaces]
Hierarchien und [edit vlans]
Anweisungshierarchien auf.
Anweisung |
Regulärer Ausdruck |
Konfigurationshinweise |
---|---|---|
[edit interfaces] Der [edit] user@host# set interfaces interface-name unit interface-unit-number |
Die Daher muss der reguläre Ausdruck, der für das Ablehnen der [edit system login class class-name] user@host# set permissions configure user@host# set deny-configuration "interfaces .* unit .*" |
|
[edit vlans] Der [edit] user@host# set vlans vlan-name vlan-id vlan-id |
Hier ist die Daher muss der reguläre Ausdruck, der für die Genehmigung der [edit system login class class-name] user@host# set permissions configure user@host# set allow-configuration "vlans .* vlan-id .*" |
|
Operatoren regulärer Ausdrücke
Tabelle 5 listet Operatoren mit regulären Ausdrücken auf, die Sie zum Zulassen oder Ablehnen von Betriebs- und Konfigurationsmodi verwenden können.
Reguläre Befehlsausdrücke implementieren die erweiterten (modernen) regulären Ausdrücke, wie in POSIX 1003.2 definiert.
Betreiber |
Match |
Beispiel |
---|---|---|
| |
Einer von zwei oder mehr Begriffen, die durch die Pipe getrennt sind. Jeder Begriff muss ein vollständiger eigenständiger Ausdruck sein, der in Klammern ( ) eingeschlossen ist, ohne Leerzeichen zwischen der Pipe und den angrenzenden Klammern. |
[edit system login class test] user@host# set permissions configure user@host# set allow-commands "(ping)|(traceroute)|(show system alarms)|(show system software)" user@host# set deny-configuration "(access)|(access-profile)|(accounting-options)|(applications)|(apply-groups)|(bridge-domains)|(chassis)|(class-of-service)" In der vorhergehenden Konfiguration haben die Benutzer, die der Testanmeldungsklasse zugewiesen sind, den Betriebsmodus-Zugriff nur auf die in der |
^ |
Zu Beginn eines Ausdrucks, der verwendet wird, um zu bezeichnen, wo der Befehl beginnt, wo es unklar sein kann. |
[edit system login class test] user@host# set permissions interface user@host# set permissions interface-control user@host# set allow-commands "(^show) (log|interfaces|policer))|(^monitor)" Mit der vorherigen Konfiguration haben die Benutzer, die der Testanmeldungsklasse zugewiesen sind, Zugriff auf die Anzeige und Konfiguration der Schnittstellenkonfiguration. Die Für den ersten Filter umfassen die angegebenen Befehle den |
$ |
Zeichen am Ende eines Befehls. Wird verwendet, um einen Befehl anzugeben, der bis zu diesem Punkt genau abgeglichen werden muss. |
[edit system login class test] user@host# set permissions interface user@host# set allow-commands "(show interfaces$)" Mit der vorherigen Konfiguration können die Benutzer, die der Testanmeldungsklasse zugewiesen sind, die Schnittstellenkonfiguration im Konfigurationsmodus anzeigen. Die Benutzer können die Schnittstellenkonfiguration auch mit dem |
[ ] |
Bereich von Buchstaben oder Ziffern. Um den Anfang und das Ende eines Bereichs zu trennen, verwenden Sie einen Bindestrich ( - |
[edit system login class test] user@host# set permissions clear user@host# set permissions configure user@host# set permissions network user@host# set permissions trace user@host# set permissions view user@host# set allow-configuration-regexps [ "interfaces [gx]e-.* unit [0-9]* description .*" ] In der vorherigen Konfiguration verfügen die Benutzer, die der Testanmeldungsklasse zugewiesen sind, über Benutzerberechtigungen auf Betreiberebene. Diese Benutzer haben auch Zugriff auf Die Konfiguration von Schnittstellen innerhalb des angegebenen Bereichs von Schnittstellenname und Einheitennummer (0 bis 9). |
( ) |
Eine Gruppe von Befehlen, die einen vollständigen, eigenständigen Ausdruck anzeigen, der ausgewertet werden soll. Das Ergebnis wird dann als Teil des Gesamtausdrucks ausgewertet. Wie erläutert, müssen Klammern zusammen mit Leitungsbetreibern verwendet werden. |
[edit system login class test] user@host# set permissions all user@host# set allow-commands "(clear)|(configure)" user@host# deny-commands "(mtrace)|(start)|(delete)" Mit der obigen Konfiguration haben Benutzer, die der Testanmeldungsklasse zugewiesen sind, Berechtigungen auf Superbenutzerebene und Zugriff auf die in der |
* |
Keine oder mehr Begriffe. |
[edit system login class test] user@host# set permissions configure user@host# set deny-configuration "(system login class m*)" Mit der obigen Konfiguration wird Benutzern, die der Testanmeldungsklasse zugewiesen sind, deren Anmeldename beginnt |
+ |
Ein oder mehrere Begriffe. |
[edit system login class test] user@host# set permissions configure user@host# set deny-configuration "(system login class m+)" Mit der obigen Konfiguration wird Benutzern, die der Testanmeldungsklasse zugewiesen sind, deren Anmeldename beginnt |
. |
Alle Zeichen mit Ausnahme von Leerzeichen ". |
[edit system login class test] user@host# set permissions configure user@host# set deny-configuration "(system login class m.)" Mit der obigen Konfiguration wird Benutzern, die der Testanmeldungsklasse zugewiesen sind, deren Anmeldename beginnt |
.* |
Alles vom angegebenen Punkt an. |
[edit system login class test] user@host# set permissions configure user@host# set deny-configuration "(system login class m .*)" Mit der obigen Konfiguration wird Benutzern, die der Testanmeldungsklasse zugewiesen sind, deren Anmeldename beginnt Ebenso verweigert die HINWEIS:
|
Der !
Operator für reguläre Ausdrücke wird nicht unterstützt.
Beispiele für reguläre Ausdrücke
Tabelle 6 listet die regulären Ausdrücke auf, die verwendet werden, um Konfigurationsoptionen in zwei Konfigurationshierarchien zuzulassen –[edit system ntp server]
und [edit protocols rip]
– als Beispiel für das Angeben regulärer Ausdrücke.
Tabelle 6 bietet keine umfassende Liste aller regulären Ausdrücke und Schlüsselwörter für alle Konfigurationsanweisungen und Hierarchien. Die in der Tabelle aufgeführten regulären Ausdrücke werden nur für die Anweisungshierarchien und [edit protocols rip]
-[edit system ntp server]
hierarchien validiert.
Anweisungshierarchie |
Reguläre Ausdrücke |
Zulässige Konfiguration |
Konfiguration verweigert |
---|---|---|---|
|
|||
Schlüssel key-number |
[edit system login class test] set permissions configure set allow-configuration-regexps [ "system ntp server .*" "system ntp server .* key .*" ] set deny-configuration-regexps [ "system ntp server .* version .*" "system ntp server .* prefer" ] |
|
|
Version version-number |
[edit system login class test] set permissions configure set allow-configuration-regexps [ "system ntp server .*" "system ntp server .* version .*" ] set deny-configuration-regexps [ "system ntp server .* key .*" "system ntp server .* prefer" ] |
|
|
Bevorzugen |
[edit system login class test] set permissions configure set allow-configuration-regexps [ "system ntp server .*" "system ntp server .* prefer" ]; set deny-configuration-regexps [ "system ntp server .* key .*" "system ntp server .* version .*" ] |
|
|
|
|||
Nachrichtengröße message-size |
[edit system login class test] set permissions configure set allow-configuration-regexps "protocols rip message-size .*" set deny-configuration-regexps [ "protocols rip metric-in .*" "protocols rip route-timeout .*" "protocols rip update-interval .*" ] |
|
|
metric-in metric-in |
[edit system login class test] set permissions configure set allow-configuration-regexps "protocols rip metric-in .*" set deny-configuration-regexps [ "protocols rip message-size .*" "protocols rip route-timeout .*" "protocols rip update-interval .*" ] |
|
|
Route-Timeout route-timeout |
[edit system login class test] set permissions configure set allow-configuration-regexps "protocols rip route-timeout .*" set deny-configuration-regexps [ "protocols rip metric-in .*" "protocols rip message-size .*" "protocols rip update-interval .*" ] |
|
|
Update-Intervall update-interval |
[edit system login class test] set permissions configure set allow-configuration-regexps "protocols rip update-interval .*" set deny-configuration-regexps [ "protocols rip metric-in .*" "protocols rip route-timeout .*" "protocols rip message-size .*" ] |
|
|
So definieren Sie Zugriffsberechtigungen mit Anweisungen zur Zulassen-Konfiguration und Konfiguration verweigern
Sie können Zugriffsberechtigungen für Konfigurationsanweisungenhierarchien definieren, indem Sie eine Kombination der folgenden Arten von Anweisungen verwenden:
Berechtigungs-Flags
allow-configuration
unddeny-configuration
Aussagen
Die Berechtigungs-Flags definieren die größeren Grenzen, auf die eine Person oder Anmeldeklasse zugreifen und kontrollieren kann. Die allow-configuration
Anweisungen enthalten deny-configuration
einen oder mehrere reguläre Ausdrücke, die bestimmte Konfigurationshierarchien und -anweisungen zulassen oder ablehnen. deny-configuration
Die allow-configuration
Anweisungen haben Vorrang vor Berechtigungs-Flags und geben dem Administrator eine detailliertere Kontrolle darüber, welche Hierarchien und Anweisungen der Benutzer anzeigen und konfigurieren kann.
In diesem Thema wird erläutert, wie Sie Zugriffsrechte mithilfe allow-configuration
und deny-configuration
Anweisungen definieren, indem Sie Beispiele für Konfigurationen von Anmeldeklassen sehen, die diese Anweisungen verwenden. Die Beispiele 1 bis 3 erstellen Anmeldeklassen, die Benutzern den Zugriff auf alle Befehle und Anweisungen mit Ausnahme der in der deny-configuration
Anweisung definierten ermöglichen.
Beachten Sie, dass Berechtigungsbit und Berechtigungsflagge austauschbar verwendet werden.
Beispiel 1
So erstellen Sie eine Anmeldeklasse, die es dem Benutzer ermöglicht, alle Befehle auszuführen und alles außer Telnet-Parametern zu konfigurieren:
Beispiel 2
So erstellen Sie eine Anmeldeklasse, die es dem Benutzer ermöglicht, alle Befehle auszuführen und alle außer Anweisungen innerhalb einer Anmeldeklasse zu konfigurieren, deren Name mit "m" beginnt:
-
Legen Sie die Anmeldeklassenberechtigungen des Benutzers auf
all
.[edit system login] user@host# set class all-except-login-class-m permissions all
-
Fügen Sie die folgende
deny-configuration
Anweisung ein.[edit system login class all-except-login-class-m] user@host# set deny-configuration "system login class m.*"
Beispiel 3
So erstellen Sie eine Anmeldeklasse, die es dem Benutzer ermöglicht, alle Befehle auszuführen und alles mit Ausnahme der Hierarchieebene oder [edit system services]
der [edit system login class]
Hierarchieebene zu konfigurieren:
-
Legen Sie die Anmeldeklassenberechtigungen des Benutzers auf
all
.[edit system login] user@host# set class all-except-login-class-or-system-services permissions all
-
Fügen Sie die folgende
deny-configuration
Aussage bei:[edit system login class all-except-login-class-or-system-services] user@host# set deny-configuration "(system login class) | (system services)"
Die folgenden Beispiele zeigen, wie Sie die anweisungen und deny-configuration
die allow-configuration
Anweisungen verwenden, um die Berechtigungen für die [edit system services]
Hierarchieebene zueinander zu bestimmen.
Beispiel 4
So erstellen Sie eine Anmeldeklasse, die es dem Benutzer ermöglicht, vollständige Konfigurationsberechtigungen nur auf [edit system services]
Hierarchieebene zu haben:
-
Legen Sie die Anmeldeklassenberechtigungen des Benutzers auf
configure
.[edit system login] user@host# set class configure-only-system-services permissions configure
-
Fügen Sie die folgende
allow-configuration
Aussage bei:[edit system login class configure-only-system-services] user@host# set allow-configuration "system services"
Beispiel 5
So erstellen Sie eine Anmeldeklasse, die dem Benutzer vollständige Berechtigungen für alle Befehle und alle Konfigurationshierarchien außer der [edit system services]
Hierarchieebene ermöglicht:
-
Legen Sie die Anmeldeklassenberechtigungen des Benutzers auf
all
.[edit system login] user@host# set class all-except-system-services permissions all
-
Fügen Sie die folgende
deny-configuration
Anweisung ein.[edit system login class all-except-system-services] user@host# set deny-configuration "system services"
Beispiel: Verwenden Sie additive Logik mit regulären Ausdrücken, um Zugriffsrechte zu spezifizieren
In diesem Beispiel wird gezeigt, wie Sie additive Logik verwenden, wenn Sie reguläre Ausdrücke zum Einrichten von Konfigurationszugriffsrechten verwenden.
Anforderungen
In diesem Beispiel wird ein Gerät verwendet, auf dem Junos OS Version 16.1 oder höher ausgeführt wird.
Überblick
Sie können reguläre Ausdrücke definieren, um zu steuern, wer Änderungen an der Konfiguration vornehmen darf und was sie ändern können. Diese regulären Ausdrücke geben spezifische Konfigurationshierarchien an, auf die Benutzer in einer Anmeldeklasse zugreifen dürfen. Sie können beispielsweise reguläre Ausdrücke definieren, mit denen Benutzer eine Gruppe von Routing-Instanzen ändern können, und reguläre Ausdrücke definieren, die benutzer daran hindern, Änderungen an anderen Routing-Instanzen oder an anderen Konfigurationsebenen vorzunehmen. Sie definieren die regulären Ausdrücke, indem Sie die und deny-configuration-regexps
die allow-configuration-regexps
Anweisungen für eine Anmeldeklasse konfigurieren.
Standardmäßig hat die deny-configuration-regexps
Anweisung Vorrang vor der allow-configuration-regexps
Anweisung. Wenn eine Konfigurationshierarchie in einer deny-configuration-regexps
Anweisung für eine Anmeldeklasse angezeigt wird, ist sie unabhängig vom Inhalt der Anweisung für die Benutzer in dieser allow-configuration-regexps
Klasse nicht sichtbar. Wenn eine Konfigurationshierarchie in einer deny-configuration-regexps
Anweisung nicht angezeigt wird, ist sie für die Benutzer in dieser Klasse sichtbar, wenn sie in einer allow-configuration-regexps
Anweisung angezeigt wird.
Sie können dieses Standardverhalten ändern, indem Sie die additive Logik für die *-configuration-regexps
Anweisungen aktivieren. Wenn Sie die additive Logik aktivieren, hat die allow-configuration-regexps
Anweisung Vorrang vor der deny-configuration-regexps
Anweisung.
Wenn also die Anweisung den deny-configuration-regexps
Zugriff auf alle Konfigurationshierarchien auf einer bestimmten Ebene (Protokolle .*) verweigert, die Anweisung aber den allow-configuration-regexps
Zugriff auf eine Unterhierarchie (Protokolle bgp .*) zulässt, verweigert das Gerät standardmäßig den Zugriff auf die Hierarchien für Benutzer in dieser Anmeldeklasse, da die deny-configuration-regexps
Anweisung Vorrang hat. Wenn Sie jedoch die additive Logik aktivieren, ermöglicht das Gerät den Zugriff auf die angegebene Unterhierarchie für Benutzer in dieser Anmeldeklasse, da dies allow-configuration-regexps
in diesem Fall Vorrang hat.
Konfiguration
Schritt-für-Schritt-Verfahren
So aktivieren Sie eine additive Logik, die Benutzern in einer bestimmten Anmeldeklasse explizit den Zugriff auf eine oder mehrere individuelle Konfigurationshierarchien erlaubt:
-
Fügen Sie die Anweisung ein
deny-configuration-regexps
, und verweigern Sie explizit den Zugriff auf Konfigurationshierarchien.[edit system login class class-name] user@host# set deny-configuration-regexps ["regular expression 1" "regular expression 2" "regular expression 3"]
Zum Beispiel:
[edit system login class class-name] user@host# set deny-configuration-regexps "protocols .*"
-
Schließen Sie die Anweisung ein
allow-configuration-regexps
, und definieren Sie reguläre Ausdrücke für die bestimmten Hierarchien, die zulässig sind.[edit system login class class-name] user@host# set allow-configuration-regexps ["regular expression 1" "regular expression 2" "regular expression 3"]
Zum Beispiel:
[edit system login class class-name] user@host# set allow-configuration-regexps ["protocols bgp .*" "protocols ospf .*"]
-
Aktivieren Sie die additive Logik für die
allow-configuration-regexps
unddeny-configuration-regexps
reguläre Ausdrücke.[edit system] user@host# set regex-additive-logic
-
Weisen Sie die Anmeldeklasse einem oder mehreren Benutzern zu.
[edit system login] user@host# set user username class class-name
-
Übernehmen Sie Ihre Änderungen.
Benutzer, die dieser Anmeldeklasse zugewiesen sind, haben Zugriff auf die Konfigurationshierarchien, die in der
allow-configuration-regexps
Anweisung enthalten sind, haben jedoch keinen Zugriff auf die anderen Hierarchien, die in derdeny-configuration-regexps
Anweisung angegeben sind.
Wenn Sie die regex-additive-logic
Anweisung konfigurieren, gilt die Verhaltensänderung für alle allow-configuration-regexps
und deny-configuration-regexps
Anweisungen, die in allen Anmeldeklassen vorhanden sind. Wenn Sie die additive Logik aktivieren, sollten Sie vorhandene Anweisungen auf Auswirkungen auswerten und die regulären Ausdrücke in diesen Anweisungen entsprechend aktualisieren.
Beispiele:
Verwenden von regulären Ausdrücken mit additiver Logik
Zweck
In diesem Abschnitt finden Sie Beispiele für reguläre Ausdrücke, die additive Logik verwenden, um Ideen zum Erstellen von systemgerechten Konfigurationen zu erhalten.
Zulassen spezifischer Routing-Instanzen
Die folgende Beispielanmeldungsklasse enthält einen regulären Ausdruck, der die Konfiguration von Routing-Instanzen ermöglicht, CUST-VRF-1
deren Namen mit CUST-VRF-
beginnen, z. B. , CUST-VRF-25
, CUST-VRF-100
usw. Das Beispiel enthält auch einen regulären Ausdruck, der die Konfiguration von Routing-Instanzen verhindert.
[edit system login class class-name] user@host# set permissions [configure routing-control view view-configuration] user@host# set deny-configuration-regexps "routing-instances .*" user@host# set allow-configuration-regexps "routing-instances CUST-VRF-.* .*"
Standardmäßig hat die deny-configuration-regexps
Anweisung Vorrang, und die vorherige Konfiguration verhindert, dass die Benutzer in der Anmeldeklasse unabhängig vom Namen Routing-Instanzen konfigurieren.
Wenn Sie jedoch die folgende Anweisung konfigurieren, hat die allow-configuration-regexps
Anweisung Vorrang. So können die Benutzer Routing-Instanzen konfigurieren, deren Namen mit CUST-VRF-
beginnen, aber die Benutzer können keine anderen Routing-Instanzen konfigurieren.
[edit system] user@host# set regex-additive-logic
Nur BGP-Peer-Konfiguration zulassen
Die folgende Beispielanmeldungsklasse enthält reguläre Ausdrücke, die die Konfiguration auf [edit protocols]
Hierarchieebene verhindern, aber die Konfiguration von BGP-Peers ermöglichen:
[edit system login class class-name] user@host# set permissions [configure routing-control view view-configuration] user@host# set deny-configuration-regexps "protocols .*" user@host# set allow-configuration-regexps "protocols bgp group *"
Standardmäßig verhindert die vorherige Konfiguration, dass die Benutzer in der Anmeldeklasse Änderungen an beliebigen Hierarchien unter [edit protocols]
.
Wenn Sie jedoch die folgende Anweisung konfigurieren, können die Benutzer in der Anmeldeklasse Änderungen an BGP-Peers vornehmen, die Benutzer können jedoch keine anderen Protokolle oder andere BGP-Anweisungen außerhalb der zulässigen Hierarchieebene konfigurieren.
[edit system] user@host# set regex-additive-logic
Überprüfung
So stellen Sie sicher, dass Sie die Zugriffsrechte korrekt festgelegt haben:
-
Konfigurieren Sie eine Anmeldeklasse und übernehmen Sie die Änderungen.
-
Weisen Sie die Anmeldeklasse einer username.
-
Melden Sie sich mit der username neuen Anmeldeklasse als zugewiesen an.
-
Versuchen Sie, die zulässigen Hierarchieebenen zu konfigurieren.
-
Sie sollten in der Lage sein, Anweisungen in Hierarchieebenen zu konfigurieren, die zulässig sind.
-
Hierarchieebenen, die verweigert werden, sollten nicht sichtbar sein.
-
Alle zulässigen oder verweigerten Ausdrücke sollten Vorrang vor den mit der
permissions
Anweisung gewährten Berechtigungen haben.
-
Beispiel: Konfigurieren von Benutzerberechtigungen mit Zugriffsrechten für Betriebsmodusbefehle
Dieses Beispiel zeigt, wie Sie benutzerdefinierte Anmeldeklassen konfigurieren und Zugriffsrechte für Betriebsmodusbefehle zuweisen. Benutzer in der Anmeldeklasse können nur die Befehle ausführen, auf die sie Zugriff haben. Dadurch wird verhindert, dass unbefugte Benutzer sensible Befehle ausführen, die das Netzwerk beschädigen könnten.
Anforderungen
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
-
Ein Gerät von Juniper Networks
-
Ein TACACS+ (oder RADIUS)-Server
Stellen Sie zunächst eine TCP-Verbindung zwischen dem Gerät und dem TACACS+-Server her. Stellen Sie im Fall des RADIUS-Servers eine UDP-Verbindung zwischen dem Gerät und dem RADIUS-Server her.
Übersicht und Topologie
Abbildung 1 veranschaulicht eine einfache Topologie, bei der Router R1 ein Gerät von Juniper Networks ist und über eine TCP-Verbindung mit einem TACACS+-Server verfügt.

In diesem Beispiel wird R1 mit drei angepassten Anmeldeklassen konfiguriert: Klasse1, Klasse2 und Klasse3. Jede Klasse definiert Zugriffsrechte für den Benutzer, indem sie die permissions
Anweisung konfigurieren und erweiterte reguläre Ausdrücke mithilfe von und allow-commands
deny-commands
Anweisungen definieren.
Der Zweck jeder Login-Klasse ist wie folgt:
-
Class1– Definiert Zugriffsberechtigungen für den Benutzer nur mit der
allow-commands
Anweisung. Diese Anmeldeklasse bietet Benutzerberechtigungen auf Betreiberebene und Autorisierung für den Neustart des Geräts. -
Class2– Definiert Zugriffsberechtigungen für den Benutzer nur mit der
deny-commands
Anweisung. Diese Anmeldeklasse bietet Benutzerberechtigungen auf Betreiberebene und verweigert den Zugriff aufset
Befehle. -
Class3– Definiert Zugriffsrechte für den Benutzer mit beiden
allow-commands
Anweisungen.deny-commands
Diese Anmeldeklasse bietet Benutzerberechtigungen auf Superbenutzerebene und Autorisierung für den Zugriff auf Schnittstellen und das Anzeigen von Geräteinformationen. Außerdem wird der Zugriff auf die Befehle undconfigure
dieedit
Befehle verweigert.
Router R1 verfügt über drei verschiedene Benutzer, Benutzer1, Benutzer2 und Benutzer3, die den Anmeldeklassen Class1, Class2 und Class3 zugewiesen sind.
Konfiguration
- CLI-Schnellkonfiguration
- Konfigurieren von Authentifizierungsparametern für Router R1
- Konfigurieren von Zugriffsrechten mit der Allow-Commands-Anweisung (Class1)
- Konfigurieren von Zugriffsrechten mit der Anweisung deny-commands (Class2)
- Konfigurieren von Zugriffsrechten mit den Anweisungen "allow-commands" und "Deny-commands" (Class3)
- Ergebnisse
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, kopieren Sie die Befehle, fügen Sie sie auf Hierarchieebene in die [edit]
CLI ein, und geben Sie dann im Konfigurationsmodus ein commit
.
R1
set system authentication-order tacplus set system authentication-order radius set system authentication-order password set system radius-server 10.209.1.66 secret "$ABC123" set system tacplus-server 10.209.1.66 secret "$ABC123" set system radius-options enhanced-accounting set system tacplus-options enhanced-accounting set system accounting events login set system accounting events change-log set system accounting events interactive-commands set system accounting traceoptions file auditlog set system accounting traceoptions flag all set system accounting destination tacplus server 10.209.1.66 secret "$ABC123" set system login class Class1 permissions clear set system login class Class1 permissions network set system login class Class1 permissions reset set system login class Class1 permissions trace set system login class Class1 permissions view set system login class Class1 allow-commands "request system reboot" set system login class Class2 permissions clear set system login class Class2 permissions network set system login class Class2 permissions reset set system login class Class2 permissions trace set system login class Class2 permissions view set system login class Class2 deny-commands set set system login class Class3 permissions all set system login class Class3 allow-commands configure set system login class Class3 deny-commands .* set system login user User1 uid 2001 set system login user User1 class Class1 set system login user User1 authentication encrypted-password "$ABC123" set system login user User2 uid 2002 set system login user User2 class Class2 set system login user User2 authentication encrypted-password "$ABC123" set system login user User3 uid 2003 set system login user User3 class Class3 set system login user User3 authentication encrypted-password "$ABC123" set system syslog file messages any any
Konfigurieren von Authentifizierungsparametern für Router R1
Schritt-für-Schritt-Verfahren
So konfigurieren Sie die Router R1-Authentifizierung:
-
Konfigurieren Sie die Reihenfolge, in der R1 versucht, den Benutzer zu authentifizieren. In diesem Beispiel wird zuerst die TACACS+-Serverauthentifizierung, gefolgt von der RADIUS-Serverauthentifizierung und dann das lokale Kennwort.
[edit system] user@R1# set authentication-order tacplus user@R1# set authentication-order radius user@R1# set authentication-order password
-
Konfigurieren Sie den TACACS+-Server.
[edit system] user@R1# set tacplus-server 10.209.1.66 secret "$ABC123" user@R1# set tacplus-options enhanced-accounting user@R1# set accounting destination tacplus server 10.209.1.66 secret "$ABC123"
-
Konfigurieren Sie den RADIUS-Server.
[edit system] user@R1# set radius-server 10.209.1.66 secret "$ABC123" user@R1# set radius-options enhanced-accounting
-
Konfigurieren Sie R1-Buchhaltungsparameter.
[edit system] user@R1# set accounting events login user@R1# set accounting events change-log user@R1# set accounting events interactive-commands user@R1# set accounting traceoptions file auditlog user@R1# set accounting traceoptions flag all
Konfigurieren von Zugriffsrechten mit der Allow-Commands-Anweisung (Class1)
Schritt-für-Schritt-Verfahren
So geben Sie reguläre Ausdrücke mithilfe der allow-commands
Anweisung an:
-
Konfigurieren Sie die Anmeldeklasse Class1 und weisen Sie Benutzerberechtigungen auf Betreiberebene zu.
[edit system login] user@R1# set class Class1 permissions [clear network reset trace view]
-
Konfigurieren Sie den
allow-commands
regulären Ausdruck, damit Benutzer in der Klasse das Gerät neu starten können.[edit system login] user@R1# set class Class1 allow-commands "request system reboot"
-
Konfigurieren Sie das Benutzerkonto für die Anmeldeklasse Class1.
[edit system login] user@R1# set user User1 uid 2001 user@R1# set user User1 class Class1 user@R1# set user User1 authentication encrypted-password "$ABC123"
Konfigurieren von Zugriffsrechten mit der Anweisung deny-commands (Class2)
Schritt-für-Schritt-Verfahren
So geben Sie reguläre Ausdrücke mithilfe der deny-commands
Anweisung an:
-
Konfigurieren Sie die Class2-Anmeldeklasse und weisen Sie Benutzerberechtigungen auf Betreiberebene zu.
[edit system login] user@R1# set class Class1 permissions [clear network reset trace view]
-
Konfigurieren Sie den
deny-commands
regulären Ausdruck, um zu verhindern, dass Benutzer in der Klasse Befehle ausführenset
.[edit system login] user@R1# set class Class1 deny-commands "set"
-
Konfigurieren Sie das Benutzerkonto für die Class2-Anmeldeklasse.
[edit system login] user@R1# set user User2 uid 2002 user@R1# set user User2 class Class2 user@R1# set user User2 authentication encrypted-password "$ABC123"
Konfigurieren von Zugriffsrechten mit den Anweisungen "allow-commands" und "Deny-commands" (Class3)
Schritt-für-Schritt-Verfahren
So geben Sie reguläre Ausdrücke mit den allow-commands
anweisungen und deny-commands
-
Konfigurieren Sie die Class3-Anmeldeklasse und weisen Sie Berechtigungen auf Superbenutzerebene zu.
[edit system login] user@R1# set class Class3 permissions all
-
Konfigurieren Sie den
deny-commands
regulären Ausdruck, um zu verhindern, dass Benutzer in der Klasse Befehle ausführen.[edit system login] user@R1# set class Class3 deny-commands ".*"
-
Konfigurieren Sie den
allow-commands
regulären Ausdruck so, dass Benutzer in den Konfigurationsmodus wechseln können.[edit system login] user@R1# set class Class3 allow-commands configure
-
Konfigurieren Sie das Benutzerkonto für die Class3-Anmeldeklasse.
[edit system login] user@R1# set user User3 uid 2003 user@R1# set user User3 class Class3 user@R1# set user User3 authentication encrypted-password "$ABC123"
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie den show system
Befehl eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@R1# show system authentication-order [ tacplus radius password ]; radius-server { 10.209.1.66 secret "$ABC123"; } tacplus-server { 10.209.1.66 secret "$ABC123"; } radius-options { enhanced-accounting; } tacplus-options { enhanced-accounting; } accounting { events [ login change-log interactive-commands ]; traceoptions { file auditlog; flag all; } destination { tacplus { server { 10.209.1.66 secret "$ABC123"; } } } } login { class Class1 { permissions [ clear network reset trace view ]; allow-commands "request system reboot"; } class Class2 { permissions [ clear network reset trace view ]; deny-commands set; } class Class3 { permissions all; allow-commands configure; deny-commands .*; } user User1 { uid 2001; class Class1; authentication { encrypted-password "$ABC123"; } } user User2 { uid 2002; class Class2; authentication { encrypted-password "$ABC123"; } } user User3 { uid 2003; class Class3; authentication { encrypted-password “$ABC123”; } } } syslog { file messages { any any; } }
Überprüfung
Melden Sie sich als Benutzername an, der der neuen Anmeldeklasse zugewiesen ist, und bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfen der Class1-Konfiguration
- Überprüfung der Class2-Konfiguration
- Überprüfen der Class3-Konfiguration
Überprüfen der Class1-Konfiguration
Zweck
Stellen Sie sicher, dass die Berechtigungen und Befehle, die in der Anmeldeklasse Class1 zulässig sind, funktionieren.
Aktion
Führen Sie den Befehl im show system users
Betriebsmodus aus.
User1@R1> show system users 12:39PM up 6 days, 23 mins, 6 users, load averages: 0.00, 0.01, 0.00 USER TTY FROM LOGIN@ IDLE WHAT User1 p0 abc.example.net 12:34AM 12:04 cli User2 p1 abc.example.net 12:36AM 12:02 -cli (cli) User3 p2 abc.example.net 10:41AM 11 -cli (cli)
Führen Sie den Befehl im request system reboot
Betriebsmodus aus.
User1@R1> request system ? Possible completions: reboot Reboot the system
Bedeutung
Die Anmeldeklasse Class1, der Benutzer1 zugewiesen ist, verfügt über Benutzerberechtigungen auf Betreiberebene und ermöglicht benutzern in der Klasse die Ausführung des request system reboot
Befehls.
Für die vordefinierte Anmeldeklasse des Betreibers sind die folgenden Berechtigungs-Flags angegeben:
clear— Kann Befehle verwenden
clear
, um Informationen zu löschen (zu löschen), die das Gerät aus dem Netzwerk lernt und in verschiedenen Netzwerkdatenbanken speichert.network— Zugriff auf das Netzwerk mithilfe von
ping
,ssh
, undtelnet
traceroute
Befehlen.reset— Kann Softwareprozesse mithilfe des
restart
Befehls neu starten.trace— Kann Trace-Dateieinstellungen anzeigen und Trace-Dateieigenschaften konfigurieren.
view— Kann verschiedene Befehle verwenden, um die aktuelle systemweite Routing-Tabelle sowie protokollspezifische Werte und Statistiken anzuzeigen. Die geheime Konfiguration kann nicht angezeigt werden.
Für die Class1-Anmeldeklasse kann Benutzer1 zusätzlich zu den oben genannten Benutzerberechtigungen den request system reboot
Befehl ausführen. Die erste Ausgabe zeigt die Ansichtsberechtigungen als Operator an, und die zweite Ausgabe zeigt, dass der einzige request system
Befehl, den Benutzer1 als Operator ausführen kann, der request system reboot
Befehl ist.
Überprüfung der Class2-Konfiguration
Zweck
Stellen Sie sicher, dass die Berechtigungen und Befehle, die für die Class2-Anmeldeklasse zulässig sind, funktionieren.
Aktion
Führen Sie den Befehl im ping
Betriebsmodus aus.
User2@R1> ping 10.209.1.66 ping 10.209.1.66 PING 10.209.1.66 (10.209.1.66): 56 data bytes 64 bytes from 10.209.1.66: icmp_seq=0 ttl=52 time=212.521 ms 64 bytes from 10.209.1.66: icmp_seq=1 ttl=52 time=212.844 ms 64 bytes from 10.209.1.66: icmp_seq=2 ttl=52 time=211.304 ms 64 bytes from 10.209.1.66: icmp_seq=3 ttl=52 time=210.963 ms ^C --- 10.209.1.66 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 210.963/211.908/212.844/0.792 ms
Überprüfen Sie an der CLI-Eingabeaufforderung die verfügbaren Befehle.
User2@R1> ? Possible completions: clear Clear information in the system file Perform file operations help Provide help information load Load information from file monitor Show real-time debugging information mtrace Trace multicast path from source to receiver op Invoke an operation script ping Ping remote target quit Exit the management session request Make system-level requests restart Restart software process save Save information to file show Show system information ssh Start secure shell on another host start Start shell telnet Telnet to another host test Perform diagnostic debugging traceroute Trace route to remote host
Führen Sie über die CLI-Eingabeaufforderung einen beliebigen Set-Befehl aus.
User2@R1> set ^ unknown command.
Bedeutung
Die Class2-Anmeldeklasse, der Benutzer2 zugewiesen ist, verfügt über Benutzerberechtigungen auf Betreiberebene und verweigert den Zugriff auf alle set
Befehle.
Die für die vordefinierte Anmeldeklasse des Betreibers angegebenen Berechtigungs-Flags sind identisch mit den für Class1 angegebenen Berechtigungen.
Überprüfen der Class3-Konfiguration
Zweck
Stellen Sie sicher, dass die Berechtigungen und Befehle, die für die Class3-Anmeldeklasse zulässig sind, funktionieren.
Aktion
Überprüfen Sie im Betriebsmodus die verfügbaren Befehle.
User3@R1> ? Possible completions: configure Manipulate software configuration information
Gehen Sie in den Konfigurationsmodus.
User3@R1> configure Entering configuration mode [edit] User3@R1#
Bedeutung
Die Class3-Anmeldeklasse, der Benutzer3 zugewiesen ist, verfügt über Superuser-Berechtigungen (alle), aber diese Klasse erlaubt benutzern nur die Ausführung des configure
Befehls. Die Klasse verweigert den Zugriff auf alle anderen Befehle im Betriebsmodus. Da die in den allow/deny-commands
Anweisungen angegebenen regulären Ausdrücke Vorrang vor den Benutzerberechtigungen haben, hat Benutzer3 auf R1 nur Zugriff auf den Konfigurationsmodus und wird der Zugriff auf alle anderen Befehle im Betriebsmodus verweigert.
Beispiel: Konfigurieren von Benutzerberechtigungen mit Zugriffsrechten für Konfigurationsanweisungen und Hierarchien
Dieses Beispiel zeigt, wie Sie benutzerdefinierte Anmeldeklassen konfigurieren und bestimmten Konfigurationshierarchien Zugriffsrechte zuweisen. Benutzer in der Anmeldeklasse können nur die Konfigurationsanweisungen und Hierarchien anzeigen und ändern, auf die sie Zugriff haben. Dadurch wird verhindert, dass unbefugte Benutzer Gerätekonfigurationen ändern, die das Netzwerk beschädigen könnten.
Anforderungen
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
-
Ein Gerät von Juniper Networks
-
Ein TACACS+ (oder RADIUS)-Server
Stellen Sie zunächst eine TCP-Verbindung zwischen dem Gerät und dem TACACS+-Server her. Stellen Sie im Fall des RADIUS-Servers eine UDP-Verbindung zwischen dem Gerät und dem RADIUS-Server her.
Übersicht und Topologie
Abbildung 2 veranschaulicht eine einfache Topologie, bei der Router R1 ein Gerät von Juniper Networks ist und über eine TCP-Verbindung mit einem TACACS+-Server verfügt.

In diesem Beispiel wird R1 mit zwei angepassten Anmeldeklassen konfiguriert: Klasse1 und Klasse2. Jede Klasse definiert Zugriffsrechte für den Benutzer, indem sie die permissions
Anweisung konfigurieren und erweiterte reguläre Ausdrücke mithilfe von allow-configuration
, , deny-configuration
und allow-configuration-regexps
deny-configuration-regexps
Anweisungen definieren.
Der Zweck jeder Login-Klasse ist wie folgt:
-
Class1– Definiert Zugriffsrechte für den Benutzer mit den
allow-configuration
unddeny-configuration
Anweisungen. Diese Anmeldeklasse bietet Zugriff, um nur die[edit interfaces]
Hierarchie zu konfigurieren, und verweigert alle anderen Zugriffe auf dem Gerät. Dazu gehören die Benutzerberechtigungen,configure
um Konfigurationszugriff bereitzustellen. Darüber hinaus ermöglicht die Anweisung denallow-configuration
Zugriff auf die Schnittstellenkonfiguration, und die Anweisung verweigert dendeny-configuration
Zugriff auf alle anderen Konfigurationshierarchien. Da die Allow-Anweisung Vorrang vor der Anweisung deny hat, können die Benutzer, die der Class1-Anmeldeklasse zugewiesen sind, nur auf die[edit interfaces]
Hierarchieebene zugreifen. -
Class2– Definiert Zugriffsrechte für den Benutzer mit den
allow-configuration-regexps
unddeny-configuration-regexps
Anweisungen. Diese Anmeldeklasse bietet Benutzerberechtigungen auf Superbenutzerebene und erlaubt explizit die Konfiguration auf mehreren Hierarchieebenen für Schnittstellen. Außerdem wird der Zugriff auf die Hierarchieebene und[edit protocols]
die[edit system]
Hierarchieebene verweigert.
Router R1 verfügt über zwei Benutzer, Benutzer1 und Benutzer2, die den Anmeldeklassen Class1 bzw. Class2 zugewiesen sind.
Konfiguration
- CLI-Schnellkonfiguration
- Konfigurieren von Authentifizierungsparametern für Router R1
- Konfigurieren von Zugriffsrechten mit den Anweisungen "Allow-Configuration" und "Konfigurationsverweigerung" (Class1)
- Konfigurieren Sie Zugriffsberechtigungen mit den Anweisungen allow-configuration-regexps und Deny-configuration-regexps (Class2)
- Ergebnisse
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, kopieren Sie die Befehle, fügen Sie sie auf Hierarchieebene in die [edit]
CLI ein, und geben Sie dann im Konfigurationsmodus ein commit
.
R1
set system authentication-order tacplus set system authentication-order radius set system authentication-order password set system radius-server 10.209.1.66 secret "$ABC123" set system tacplus-server 10.209.1.66 secret "$ABC123" set system radius-options enhanced-accounting set system tacplus-options enhanced-accounting set system accounting events login set system accounting events change-log set system accounting events interactive-commands set system accounting traceoptions file auditlog set system accounting traceoptions flag all set system accounting destination tacplus server 10.209.1.66 secret "$ABC123" set system login class Class1 permissions configure set system login class Class1 allow-configuration "interfaces .* unit .*" set system login class Class1 deny-configuration .* set system login class Class2 permissions all set system login class Class2 allow-configuration-regexps [ "interfaces .* description .*" "interfaces .* unit .* description .*" "interfaces .* unit .* family inet address .*" "interfaces.* disable" ] set system login class Class2 deny-configuration-regexps [ "system" "protocols" ] set system login user User1 uid 2004 set system login user User1 class Class1 set system login user User1 authentication encrypted-password "$ABC123" set system login user User2 uid 2006 set system login user User2 class Class2 set system login user User2 authentication encrypted-password "$ABC123" set system syslog file messages any any
Konfigurieren von Authentifizierungsparametern für Router R1
Schritt-für-Schritt-Verfahren
So konfigurieren Sie die Router R1-Authentifizierung:
-
Konfigurieren Sie die Reihenfolge, in der R1 versucht, den Benutzer zu authentifizieren. In diesem Beispiel wird zuerst die TACACS+-Serverauthentifizierung, gefolgt von der RADIUS-Serverauthentifizierung und dann das lokale Kennwort.
[edit system] user@R1# set authentication-order tacplus user@R1# set authentication-order radius user@R1# set authentication-order password
-
Konfigurieren Sie den TACACS+-Server.
[edit system] user@R1# set tacplus-server 10.209.1.66 secret "$ABC123" user@R1# set tacplus-options enhanced-accounting user@R1# set accounting destination tacplus server 10.209.1.66 secret "$ABC123"
-
Konfigurieren Sie den RADIUS-Server.
[edit system] user@R1# set radius-server 10.209.1.66 secret "$ABC123" user@R1# set radius-options enhanced-accounting
-
Konfigurieren Sie die R1-Buchhaltungsparameter.
[edit system] user@R1# set accounting events login user@R1# set accounting events change-log user@R1# set accounting events interactive-commands user@R1# set accounting traceoptions file auditlog user@R1# set accounting traceoptions flag all
Konfigurieren von Zugriffsrechten mit den Anweisungen "Allow-Configuration" und "Konfigurationsverweigerung" (Class1)
Schritt-für-Schritt-Verfahren
So geben Sie reguläre Ausdrücke mit den allow-configuration
Anweisungen an deny-configuration
:
-
Konfigurieren Sie die Class1-Anmeldeklasse mit
configure
Berechtigungen.[edit system login] user@R1# set class Class1 permissions configure
-
Konfigurieren Sie den
allow-configuration
regulären Ausdruck, damit Benutzer in der Klasse einen Teil der[edit interfaces]
Hierarchieebene anzeigen und ändern können.[edit system login] user@R1# set class Class1 allow-configuration "interfaces .* unit .*"
-
Konfigurieren Sie den
deny-configuration
regulären Ausdruck, um den Zugriff auf alle Konfigurationshierarchien zu verweigern.[edit system login] user@R1# set class Class1 deny-configuration .*
-
Konfigurieren Sie das Benutzerkonto für die Anmeldeklasse Class1.
[edit system login] user@R1# set user User1 uid 2004 user@R1# set user User1 class Class1 user@R1# set user User1 authentication encrypted-password "$ABC123"
Konfigurieren Sie Zugriffsberechtigungen mit den Anweisungen allow-configuration-regexps und Deny-configuration-regexps (Class2)
Schritt-für-Schritt-Verfahren
So geben Sie reguläre Ausdrücke mit den allow-configuration-regexps
Anweisungen an deny-configuration-regexps
:
-
Konfigurieren Sie die Class2-Anmeldeklasse und weisen Sie Superuser-Berechtigungen (alle) zu.
[edit system login] user@R1# set class Class2 permissions all
-
Konfigurieren Sie den
allow-configuration-regexps
regulären Ausdruck, damit Benutzer in der Klasse auf mehrere Hierarchien unter der[edit interfaces]
Hierarchieebene zugreifen können.[edit system login] user@R1# set class Class2 allow-configuration-regexps [ "interfaces .* description .*" "interfaces .* unit .* description .*" "interfaces .* unit .* family inet address .*" "interfaces.* disable" ]
-
Konfigurieren Sie den
deny-configuration-regexps
regulären Ausdruck, um zu verhindern, dass Benutzer in der Klasse die Konfiguration auf der Hierarchieebene und[edit protocols]
auf[edit system]
Hierarchieebene anzeigen oder ändern.[edit system login] user@R1# set class Class2 deny-configuration-regexps [ "system" "protocols" ]
-
Konfigurieren Sie das Benutzerkonto für die Class2-Anmeldeklasse.
[edit system login] user@R1# set user User2 uid 2006 user@R1# set user User2 class Class2 user@R1# set user User2 authentication encrypted-password "$ABC123"
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie den show system
Befehl eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@R1# show system authentication-order [ tacplus radius password ]; radius-server { 10.209.1.66 secret "$ABC123"; } tacplus-server { 10.209.1.66 secret "$ABC123"; } radius-options { enhanced-accounting; } tacplus-options { enhanced-accounting; } accounting { events [ login change-log interactive-commands ]; traceoptions { file auditlog; flag all; } destination { tacplus { server { 10.209.1.66 secret "$ABC123"; } } } } login { class Class1 { permissions configure; allow-configuration "interfaces .* unit .*"; deny-configuration .*; } class Class2 { permissions all; allow-configuration-regexps [ "interfaces .* description .*" "interfaces .* unit .* description .*" "interfaces .* unit .* family inet address .*" "interfaces.* disable" ]; deny-configuration-regexps [ "system" "protocols" ]; } user User1 { uid 2001; class Class1; authentication { encrypted-password "$ABC123"; } } user User2 { uid 2002; class Class2; authentication { encrypted-password "$ABC123"; } } } syslog { file messages { any any; } }
Überprüfung
Melden Sie sich als Benutzername an, der der neuen Anmeldeklasse zugewiesen ist, und bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
Überprüfen der Class1-Konfiguration
Zweck
Stellen Sie sicher, dass die Berechtigungen, die in der Anmeldeklasse Class1 zulässig sind, funktionieren.
Aktion
Überprüfen Sie im Betriebsmodus die verfügbaren Befehle.
User1@R1> ? Possible completions: clear Clear information in the system configure Manipulate software configuration information file Perform file operations help Provide help information load Load information from file op Invoke an operation script quit Exit the management session request Make system-level requests save Save information to file set Set CLI properties, date/time, craft interface message start Start shell test Perform diagnostic debugging
Überprüfen Sie im Konfigurationsmodus die verfügbaren Konfigurationsberechtigungen.
User1@R1# edit ? Possible completions: > interfaces Interface configuration
Bedeutung
Benutzer1 verfügt über configure
Benutzerberechtigungen, wie in der ersten Ausgabe zu sehen. Darüber hinaus hat Benutzer1 im Konfigurationsmodus Zugriff auf die interfaces
Hierarchieebene, aber nur auf diese Hierarchieebene, wie in der zweiten Ausgabe zu sehen ist.
Überprüfen der Class2-Konfiguration
Zweck
Stellen Sie sicher, dass die Class2-Konfiguration wie erwartet funktioniert.
Aktion
Greifen Sie im Konfigurationsmodus auf die interfaces
Konfiguration zu.
[edit interfaces] User2@R1# set ? Possible completions: <interface-name> Interface name + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups ge-0/0/3 Interface name > interface-range Interface ranges configuration > interface-set Logical interface set configuration > traceoptions Interface trace options
Greifen Sie im Konfigurationsmodus auf die system
Hierarchien und protocols
Konfigurationshierarchien zu.
User2@R1# edit system ^ Syntax error, expecting <statement> or <identifier>. User2@R1# edit protocols ^ Syntax error, expecting <statement> or <identifier>.
Bedeutung
Benutzer2 verfügt über Berechtigungen zur Konfiguration von Schnittstellen auf R1, aber der Benutzer verfügt nicht über die Berechtigung zum Anzeigen oder Ändern der Hierarchieebene oder [edit protocols]
der [edit system]
Hierarchieebene.
deny-commands-regexps
Anweisungen für die allow-commands-regexps
TACACS+-Autorisierung unterstützt.