Auf dieser Seite
Beispiel: Konfigurieren von Benutzerberechtigungen mit Zugriffsberechtigungsstufen
So definieren Sie Zugriffsrechte mit allow-configuration- und deny-configuration-Anweisungen
Beispiel: Verwenden Sie additive Logik mit regulären Ausdrücken, um Zugriffsrechte anzugeben
Beispiel: Konfigurieren von Benutzerberechtigungen mit Zugriffsrechten für Betriebsmodusbefehle
Zugriffsrechte des Benutzers
Sie (der Systemadministrator) gewähren Benutzern Zugriff oder Berechtigungen für Befehle und Konfigurationshierarchieebenen und -anweisungen. Benutzer können nur die Befehle ausführen und nur die Anweisungen anzeigen und konfigurieren, für die sie über Zugriffsrechte verfügen. 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. Dadurch wird verhindert, dass nicht autorisierte Benutzer vertrauliche Befehle ausführen oder Anweisungen konfigurieren, die das Netzwerk beschädigen könnten.
Übersicht über Zugriffsberechtigungsstufen
Jedem CLI-Befehl und jeder Konfigurationsanweisung der obersten Ebene ist eine Zugriffsberechtigungsstufe zugeordnet. 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 explizit die Verwendung von Befehlen und Anweisungshierarchien im Betriebsmodus und Konfigurationsmodus zulassen oder verweigern, die andernfalls durch eine in der permissions
Anweisung angegebene Berechtigungsstufe zugelassen oder verweigert würden.
- Berechtigungsflags für Anmeldeklassen
- Zulassen und Verweigern einzelner Befehle und Anweisungshierarchien für Anmeldeklassen
Berechtigungsflags für Anmeldeklassen
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 Hierarchieebene [edit system login class]
. Wenn Sie ein bestimmtes Berechtigungsflag 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 all
Berechtigungsflag.
Jeder aufgeführte Befehl stellt diesen Befehl und alle Unterbefehle mit diesem Befehl als Präfix dar. Jede aufgeführte Konfigurationsanweisung stellt die Spitze der Konfigurationshierarchie dar, auf die dieses Flag Zugriff gewährt.
Die permissions
Anweisung gibt eines oder mehrere der Berechtigungsflags an, die in aufgeführt sind Tabelle 1. Berechtigungsflags sind nicht kumulativ. Für jede Klasse müssen Sie alle erforderlichen Berechtigungsflags auflisten, einschließlich view
der Anzeige von Informationen und configure
des Zugriffs in den Konfigurationsmodus. Zwei Arten von Berechtigungen steuern den Zugriff eines Benutzers auf die einzelnen Teile der Konfiguration:
-
"Einfaches" Formular: 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
.
Bei Berechtigungsflags, die Zugriff auf Konfigurationshierarchieebenen und -anweisungen gewähren, gewähren die einfachen Formularflags Leseberechtigung für diese Konfiguration. Das Berechtigungskennzeichen gewährt z.B interface
. schreibgeschützten Zugriff auf die Hierarchieebene [edit interfaces]
. Die -control
Form des Flags gewährt Lese-/Schreibzugriff auf diese Konfiguration. Das Kennzeichen interface-control
gewährt z.B. Lese-/Schreibzugriff auf die Hierarchieebene [edit interfaces]
.
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]
einschließen.
Die Berechtigungsflags gewähren einen bestimmten Satz von Zugriffsberechtigungen. Jedes Berechtigungsflag wird mit den Befehlen für den Betriebsmodus oder Konfigurationsmodus sowie den Konfigurationshierarchieebenen und -anweisungen aufgeführt, für die dieses Flag Zugriff gewährt.
Berechtigungs-Flag |
Beschreibung |
---|---|
Kann die Zugriffskonfiguration im Betriebsmodus oder Konfigurationsmodus anzeigen. |
|
Kann Zugriffsinformationen auf Hierarchieebene |
|
Kann Benutzerkontoinformationen im Betriebsmodus oder Konfigurationsmodus anzeigen. |
|
Kann Benutzerkontoinformationen anzeigen und auf Hierarchieebene |
|
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 in verschiedenen Netzwerkdatenbanken speichert (mithilfe der |
|
Kann in den Konfigurationsmodus wechseln (mit dem |
|
Kann alle Vorgänge auf Steuerungsebene ausführen – alle Vorgänge, die mit den |
|
Kann Felddebugbefehle anzeigen. Reserviert für die Unterstützung beim Debuggen. |
|
Kann die Firewall-Filterkonfiguration im Betriebsmodus oder Konfigurationsmodus anzeigen. |
|
Kann Firewallfilterinformationen auf Hierarchieebene |
|
Kann von Wechselmedien lesen und darauf schreiben. |
|
Kann die Flow-Tap-Konfiguration im Betriebsmodus oder Konfigurationsmodus anzeigen. |
|
Kann Flow-Tap-Informationen auf Hierarchieebene |
|
Kann Flow-Tap-Anfragen an den Router oder Switch stellen. Beispielsweise muss ein DTCP-Client (Dynamic Tasking Control Protocol) über die Berechtigung verfügen HINWEIS:
Die |
|
Kann Profilerdaten anzeigen. |
|
Kann die Schnittstellenkonfiguration im Betriebsmodus und Konfigurationsmodus anzeigen. |
|
Kann Informationen zu Chassis, Class-of-Service (CoS), Gruppen, Weiterleitungsoptionen und Schnittstellenkonfigurationsinformationen 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 des Werdens zum Superuser in der Shell (mit dem |
|
Kann mit den Befehlen |
|
Kann die |
|
Die Konfiguration der |
|
Kann Softwareprozesse mithilfe des |
|
Kann den |
|
Kann allgemeine Routing-, Routingprotokoll- und Routingrichtlinien-Konfigurationsinformationen im Konfigurationsmodus und Betriebsmodus anzeigen. |
|
Kann allgemeines Routing auf Hierarchieebene, Routingprotokolle auf Hierarchieebene |
|
Kann Kennwörter und andere Authentifizierungsschlüssel in der Konfiguration anzeigen. |
|
Kann Kennwörter und andere Authentifizierungsschlüssel in der Konfiguration anzeigen und ändern. |
|
Kann Sicherheitskonfigurationsinformationen im Betriebsmodus und Konfigurationsmodus anzeigen. |
|
Kann Sicherheitsinformationen auf Hierarchieebene |
|
Kann mit dem |
|
Kann SNMP-Konfigurationsinformationen (Simple Network Management Protocol) im Betriebsmodus oder Konfigurationsmodus anzeigen. |
|
Kann SNMP-Konfigurationsinformationen auf Hierarchieebene |
|
|
Kann Informationen zur Fibre Channel-Speicherkonfiguration auf Hierarchieebene |
|
Kann Konfigurationsinformationen des Fibre Channel-Speichers auf Hierarchieebene |
Kann Informationen auf Systemebene im Betriebsmodus oder Konfigurationsmodus anzeigen. |
|
Kann Konfigurationsinformationen auf Systemebene auf Hierarchieebene |
|
Kann Ablaufverfolgungsdateieinstellungen anzeigen und Ablaufverfolgungsdateieigenschaften konfigurieren. |
|
Kann Ablaufverfolgungsdateieinstellungen ändern und Ablaufverfolgungsdateieigenschaften konfigurieren. |
|
|
Kann die einheitliche Edge-Konfiguration in der Hierarchie |
|
Kann die einheitliche Edge-bezogene Konfiguration in der Hierarchie |
Kann verschiedene Befehle verwenden, um aktuelle systemweite, Routing-Tabellen- und protokollspezifische Werte und Statistiken anzuzeigen. Die geheime Konfiguration kann nicht angezeigt werden. |
|
Kann die gesamte Konfiguration mit Ausnahme von Geheimnissen, Systemskripts und Ereignisoptionen anzeigen. HINWEIS:
Nur Benutzer mit der |
Zulassen und Verweigern einzelner Befehle und Anweisungshierarchien für Anmeldeklassen
Standardmäßig verfügen alle CLI-Befehle und Konfigurationshierarchieebenen der obersten Ebene über zugeordnete Zugriffsberechtigungsebenen. Benutzer können nur die Befehle ausführen und nur die Anweisungen anzeigen und konfigurieren, für die sie über Zugriffsrechte verfügen. Für jede Anmeldeklasse können Sie die Verwendung von Befehlen und Anweisungshierarchien für den Betriebsmodus und Konfigurationsmodus, die andernfalls durch eine in der permissions
Anweisung angegebene Berechtigungsstufe zugelassen oder verweigert würden, explizit zulassen oder verweigern.
Berechtigungsflags gewähren einem Benutzer Zugriff auf Betriebsmodus- und Konfigurationsmodusbefehle sowie auf Konfigurationshierarchieebenen und -anweisungen. Durch die Angabe eines bestimmten Berechtigungsflags für die Anmeldeklasse des Benutzers auf Hierarchieebene [edit system login class]
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 all
Berechtigungsflag.
Sie können die Verwendung von Befehlen und Anweisungen explizit zulassen oder verweigern, indem Sie die allow-commands
deny-commands
, , allow-configuration
und - deny-configuration
Anweisungen für eine login-Klasse 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, zugelassen oder verweigert werden sollen.
Beispiel: Konfigurieren von Benutzerberechtigungen mit Zugriffsberechtigungsstufen
In diesem Beispiel werden die Benutzerberechtigungen für eine login-Klasse 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 über Zugriffsrechte verfügen. Diese Einschränkung verhindert, dass nicht autorisierte Benutzer vertrauliche Befehle ausführen oder Anweisungen konfigurieren, 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 Konfigurationsanweisung ist eine Zugriffsberechtigungsstufe zugeordnet. Wenn Sie eine Anmeldeklasse konfigurieren, können Sie die Verwendung von Befehlen und Konfigurationsanweisungen für den Betriebsmodus und den Konfigurationsmodus explizit zulassen oder verweigern. Benutzer können nur die Befehle ausführen und nur die Anweisungen anzeigen und konfigurieren, für die sie über Zugriffsrechte verfügen.
Sie definieren die Zugriffsrechte für jede Anmeldeklasse, indem Sie ein oder mehrere Berechtigungsflags in der permissions
Anweisung angeben. Berechtigungsflags gewähren einem Benutzer Zugriff auf Befehle, Anweisungen und Hierarchien. Berechtigungsflags sind nicht kumulativ. Für jede Anmeldeklasse müssen Sie alle erforderlichen Berechtigungsflags auflisten, einschließlich view
der Anzeige von Informationen und configure
des Zugriffs in den Konfigurationsmodus. Durch Angeben eines bestimmten Berechtigungsflags für die Anmeldeklasse des Benutzers 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 all
Berechtigungsflag. Die Berechtigungsflags bieten schreibgeschützte ("einfache" Form) und Lese- und Schreibfunktionen (Formulare, die auf -control enden) für einen Berechtigungstyp.
Die all
Berechtigungsbits der Anmeldeklasse haben Vorrang vor erweiterten regulären Ausdrücken, wenn ein Benutzer einen rollback
Befehl mit rollback
aktiviertem Berechtigungsflag ausgibt.
Um Benutzerzugriffsberechtigungsstufen für eine Anmeldeklasse zu konfigurieren, fügen Sie die permissions
Anweisung auf Hierarchieebene [edit system login class class-name]
ein, gefolgt von den Berechtigungsflags. Konfigurieren Sie mehrere Berechtigungen als durch Leerzeichen getrennte Liste in eckigen Klammern:
[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 Sie nach der permissions
Anweisung ein Fragezeichen (?) ein:
[edit system login] user@host# set class class-name permissions ?
Konfiguration
In diesem Beispiel wird die login-Klasse snmp-admin
konfiguriert. Benutzer in dieser Anmeldeklasse können nur SNMP-Parameter konfigurieren und anzeigen.
Konfigurieren von Benutzerberechtigungen mit Zugriffsberechtigungsstufen
Schritt-für-Schritt-Anleitung
So konfigurieren Sie Zugriffsrechte für die login-Klasse:
-
Konfigurieren Sie die
snmp-admin
Anmeldeklasse mit denconfigure
Berechtigungsflags ,snmp
undsnmp-control
.[edit system login] user@host# set class snmp-admin permissions [configure snmp snmp-control]
Die konfigurierten Berechtigungsflags bieten sowohl Lese- (snmp) als auch Lese- und Schreibfunktionen (snmp-control) für SNMP, und dies ist die einzige zulässige Zugriffsberechtigung 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 im Konfigurationsmodus Ihre Konfiguration, indem Sie den show system login
Befehl eingeben. Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, 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 } }
Nachdem Sie das Gerät konfiguriert haben, wechseln Sie commit
in den Konfigurationsmodus.
Verifizierung
Melden Sie sich mit einem Benutzernamen an, der der neuen Anmeldeklasse zugewiesen ist, und vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.
Überprüfen der SNMP-Konfiguration
Zweck
Stellen Sie sicher, dass ein Benutzer in der snmp-admin
Anmeldeklasse SNMP konfigurieren kann.
Action!
Konfigurieren Sie im Konfigurationsmodus SNMP-Anweisungen auf Hierarchieebene [edit snmp]
.
[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 login-Klasse snmp-admin
kann SNMP-Parameter konfigurieren. Der Benutzer kann diese Parameter konfigurieren, da die für diese Klasse angegebenen Berechtigungsflags sowohl snmp- (Lesefunktionen) als auch snmp-control-Berechtigungsbits (Lese- und Schreibfunktionen) enthalten.
Überprüfen der Nicht-SNMP-Konfiguration
Zweck
Stellen Sie sicher, dass ein Benutzer in der snmp-admin
login-Klasse Nicht-SNMP-Konfigurationsanweisungen nicht ändern kann.
Action!
Versuchen Sie im Konfigurationsmodus, eine 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 login-Klasse ist nicht in der snmp-admin
Lage, die Hierarchie [edit interfaces]
zu konfigurieren, da die für diese Klasse angegebenen Berechtigungsflags dies nicht zulassen. In diesem Fall gibt die CLI eine Fehlermeldung aus.
Reguläre Ausdrücke zum Zulassen und Verweigern von Befehlen im Betriebsmodus, Konfigurationsanweisungen und Hierarchien
Dieses Thema enthält die folgenden Abschnitte:
- Grundlegendes zu den allow- und deny-Anweisungen
- Grundlegendes zur Syntax von Allow- und Deny-Anweisungen
- Grundlegendes zur Rangfolge und zum Abgleich von allow- und deny-Anweisungen
- Grundlegendes zu den Regeln für die Anweisung "Zulassen" und "Verweigern"
- Grundlegendes zu den Unterschieden für die *-regexps-Anweisungen
- Verwenden regulärer Ausdrücke auf Remoteautorisierungsservern
- Reguläre Ausdrücke angeben
- Operatoren für reguläre Ausdrücke
- Beispiele für reguläre Ausdrücke
Grundlegendes zu den allow- und deny-Anweisungen
Jeder CLI-Befehls- und Konfigurationsanweisungshierarchie der obersten Ebene ist eine Zugriffsberechtigungsebene zugeordnet. Jede Anmeldeklasse kann die Verwendung von Befehlen für den Betriebsmodus und Konfigurationsmodus sowie von Konfigurationshierarchien und -anweisungen, die andernfalls durch eine Berechtigungsstufe zugelassen oder verweigert würden, explizit zulassen oder verweigern. Benutzer können nur die Befehle ausführen und nur die Anweisungen anzeigen und konfigurieren, für die sie über Zugriffsrechte verfügen.
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 verweigern, 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 login-Klasse konfigurieren:
-
allow-commands
anddeny-commands
—Erlauben oder verweigern Sie den Zugriff auf Befehle für den Betriebsmodus und den Konfigurationsmodus. -
allow-configuration
anddeny-configuration
—Erlauben oder verweigern Sie den Zugriff auf bestimmte Konfigurationshierarchien.HINWEIS:Diese Anweisungen führen einen langsameren Abgleich mit mehr Flexibilität durch, insbesondere beim Platzhalterabgleich. Es kann jedoch sehr lange dauern, alle möglichen Anweisungen auszuwerten, wenn eine große Anzahl von regulären Ausdrücken für den gesamten Pfad oder Platzhalterausdrücke konfiguriert sind, was sich möglicherweise negativ auf die Leistung auswirkt.
-
allow-commands-regexps
anddeny-commands-regexps
—Erlaubt oder verweigert den Zugriff auf bestimmte Befehle mithilfe von Zeichenketten regulärer Ausdrücke. -
allow-configuration-regexps
anddeny-configuration-regexps
—Erlaubt oder verweigert den Zugriff auf bestimmte Konfigurationshierarchien mithilfe von Zeichenketten regulärer Ausdrücke.
Wenn Ihre vorhandenen Konfigurationen die allow/deny-commands
oder-Anweisungen allow/deny-configuration
verwenden, führt die Verwendung derselben Konfigurationsoptionen mit den allow/deny-commands-regexps
oder-Anweisungen allow/deny-configuration-regexps
möglicherweise nicht zu denselben Ergebnissen. Die Such- und Übereinstimmungsmethoden unterscheiden sich in den beiden Formen dieser Anweisungen.
Durch das explizite Zulassen von Befehlen und Konfigurationsanweisungshierarchien mithilfe der allow/deny-*
Anweisungen werden die bereits in der permissions
Anweisung definierten Berechtigungen erweitert. Ebenso werden durch das explizite Verweigern von Befehlen und Konfigurationsanweisungshierarchien mithilfe der allow/deny-*
Anweisungen Berechtigungen entfernt, die in der permissions
Anweisung bereits definiert sind.
In der folgenden Konfiguration ermöglicht die Berechtigung configure
Benutzern in der login-Klasse beispielsweise, in den Konfigurationsmodus zu wechseln. Darüber hinaus ermöglicht der allow-configuration
Ausdruck Benutzern, die Konfiguration auf Hierarchieebene [edit system services]
zu ändern und zu bestätigen.
[edit system login class test] user@host# set permissions configure allow-configuration "system services"
In ähnlicher Weise kann der Benutzer der Anmeldeklasse in der folgenden Konfiguration alle Vorgänge ausführen, die das all
Berechtigungsflag zulässt, mit der Ausnahme, dass der Benutzer die Konfiguration auf Hierarchieebene [edit system services]
nicht anzeigen oder ändern kann:
[edit system login class test] user@host# set permissions all deny-configuration "system services"
Grundlegendes zur Syntax von Allow- und Deny-Anweisungen
Sie können eine allow/deny-*
Anweisung nur einmal in jeder Anmeldeklasse konfigurieren. Wenn Sie eine Anweisung konfigurieren:
-
Sie können beliebig viele reguläre Ausdrücke konfigurieren.
-
Bei regulären Ausdrücken wird nicht zwischen Groß- und Kleinschreibung unterschieden
Die allow/deny-commands
Aussagen schließen sich gegenseitig mit den allow/deny-commands-regexps
Anweisungen aus, und die allow/deny-configuration
Aussagen schließen sich gegenseitig mit den allow/deny-configuration-regexps
Anweisungen aus. Sie können z. B. nicht sowohl als auch allow-configuration
allow-configuration-regexps
in derselben Anmeldeklasse konfigurieren.
Um Zugriffsrechte für Befehle zu definieren, geben Sie erweiterte reguläre Ausdrücke mit der allow-commands
deny-commands
and-Anweisung 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 wird in doppelte Anführungszeichen gesetzt.
allow-commands "(cmd1)|(cmd2)|(cmdn)" allow-configuration "(config1)|(config2)|(confign)"
Beispiele:
[edit system login class test] user@host# set allow-commands "(ping .*)|(traceroute .*)|(show .*)|(configure .*)|(edit)|(exit)|(commit)|(rollback .*)"
Sie müssen Anker verwenden, wenn Sie komplexe reguläre Ausdrücke mit der allow-commands
Anweisung angeben. Beispiele:
[edit system login] user@host# set class test allow-commands "(^monitor)|(^ping)|(^show)|(^exit)"
Um Zugriffsrechte für Teile der Konfigurationshierarchie zu definieren, geben Sie erweiterte reguläre Ausdrücke in der allow-configuration
and-Anweisung deny-configuration
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 wird in doppelte Anführungszeichen gesetzt.
allow-configuration "(config1)|(config2)|(confign)"
Beispiele:
[edit system login class test] user@host# set deny-configuration "(system login class)|(system services)"
Wenn Sie erweiterte reguläre Ausdrücke mit der allow/deny-commands-regexps
oder-Anweisung allow/deny-configuration-regexps
angeben, schließen Sie jeden Ausdruck in Anführungszeichen (" ") ein, und trennen Sie die Ausdrücke durch ein Leerzeichen. Schließen Sie mehrere Ausdrücke in eckige Klammern [ ] ein. Beispiele:
[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 in der Zeichenfolge für reguläre Ausdrücke, die abgeglichen werden soll, nicht unterstützt. Wenn Sie einen Modifikator 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 zum Abgleich von allow- und deny-Anweisungen
Standardmäßig haben die allow-commands
regulären Ausdrücke und allow-configuration
Vorrang vor deny-commands
und deny-configuration
Ausdrücken. Wenn Sie also denselben Befehl für die allow-commands
deny-commands
and-Anweisung konfigurieren, hat der allow-Vorgang Vorrang vor dem deny-Vorgang. Wenn Sie dieselbe Anweisung für die allow-configuration
deny-configuration
and-Anweisung konfigurieren, hat der allow-Vorgang Vorrang vor dem deny-Vorgang.
Die folgende Konfiguration ermöglicht es z. B. einem Benutzer in der test
login-Klasse, Software mit dem request system software add
Befehl zu installieren, obwohl die deny-commands
Anweisung denselben 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"
Auf ähnliche Weise ermöglicht die folgende Konfiguration einem Benutzer im test
Anmeldeklassentest, 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 and-Anweisungen allow-commands
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
login-Klasse, den commit synchronize
Befehl, aber nicht den commit
Befehl auszuführen. Dies liegt daran, dass commit synchronize
die längste Übereinstimmung zwischen commit
und commit synchronize
ist und für allow-commands
angegeben ist.
[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
login-Klasse, den commit
Befehl, aber nicht den commit synchronize
Befehl auszuführen. Dies liegt daran, dass commit synchronize
die längste Übereinstimmung zwischen commit
und commit synchronize
ist und für deny-commands
angegeben ist.
[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 deny-commands-regexps
regulären Ausdrücke und deny-configuration-regexps
Vorrang vor allow-commands-regexps
den Ausdrücken und allow-configuration-regexps
haben. 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 ablehnen und dem Benutzer dann nur den Zugriff auf bestimmte Unterhierarchien gewähren.
Grundlegendes zu den Regeln für die Anweisung "Zulassen" und "Verweigern"
allow/deny-configuration
allow/deny-commands-regexps
Die allow/deny-commands
, , und allow/deny-configuration-regexps
-Anweisungen haben Vorrang vor den Berechtigungen der Anmeldeklasse. Wenn Sie diese Anweisungen konfigurieren, gelten die folgenden Regeln:
-
Reguläre Ausdrücke für
allow-commands
and-Anweisungendeny-commands
können auch diecommit
Befehle ,load
,rollback
,save
,status
undupdate
enthalten. -
Die Berechtigungsbits der
all
Anmeldeklasse haben Vorrang vor erweiterten regulären Ausdrücken, wenn ein Benutzer denrollback
Befehl mitrollback
aktiviertem Berechtigungsflag ausgibt. -
Benutzer können den Befehl nicht ausgeben,
load override
wenn sie einen erweiterten regulären Ausdruck angeben. Benutzer können nur diemerge
Konfigurationsbefehle ,replace
undpatch
ausführen. -
Sie können das Platzhalterzeichen * verwenden, wenn Sie reguläre Ausdrücke kennzeichnen. Sie müssen es jedoch als Teil eines regulären Ausdrucks verwenden. Sie können oder
[ .* ]
nicht als einzigen Ausdruck verwenden[ * ]
. Darüber hinaus können Sie dieallow-configuration
Anweisung nicht mit einem Ausdruck wie ,(interfaces (description (|.*))
konfigurieren, da dies zuallow-configuration .*
.
Grundlegendes zu den Unterschieden für die *-regexps-Anweisungen
In diesem Abschnitt werden die Unterschiede zwischen den allow/deny-configuration
Anweisungen und den allow/deny-configuration-regexps
Anweisungen beschrieben.
Die allow/deny-configuration-regexps
Anweisungen teilen den regulären Ausdruck in Token auf und gleichen jedes Teil mit jedem Teil des vollständigen Pfads der angegebenen Konfiguration ab, während die allow/deny-configuration
Anweisungen mit der vollständigen Zeichenfolge übereinstimmen. Für allow/deny-configuration-regexps
Anweisungen konfigurieren Sie einen Satz von Zeichenfolgen, in denen jede Zeichenfolge ein regulärer Ausdruck mit Leerzeichen zwischen den Begriffen der Zeichenfolge ist. Diese Syntax ermöglicht einen sehr schnellen Abgleich, bietet jedoch weniger Flexibilität. Zum Angeben von Platzhalterausdrücken müssen Sie Platzhalter für jedes Token der durch Leerzeichen getrennten Zeichenfolge einrichten, die Sie abgleichen möchten, wodurch die Verwendung von Platzhalterausdrücken für diese Anweisungen erschwert wird.
Beispiele:
-
Reguläre Ausdrücke, die mit einem Token übereinstimmen, indem sie allow-configuration-regexps verwenden
Dieses Beispiel zeigt, dass dies
options
der einzige übereinstimmende Ausdruck für das erste Token der Anweisung ist.[edit system] login { class test { permissions configure; allow-configuration-regexps .*options; } }
Die obige Konfiguration stimmt mit den folgenden Anweisungen überein:
-
Bedingung condition für Richtlinienoptionen festlegen dynamic-db
-
setrouting-options static route static-route next-hop next-hop
-
setevent-options generate-event event time-interval seconds
Die obige Konfiguration stimmt nicht mit den folgenden Anweisungen überein:
-
host-optionen für den System-Hostnamen
-
Schnittstellenbeschreibungsoptioneninterface-name
-
-
Regulärer Ausdruck, der mit drei Token übereinstimmt, indem allow-configuration-regexps verwendet wird
Dieses Beispiel zeigt, dass dies
ssh
der einzige übereinstimmende Ausdruck für das dritte Token der Anweisung ist.[edit system] login { class test { permissions configure; allow-configuration-regexps ".* .* .*ssh"; } }
Im vorherigen Beispiel enthalten
.*
die drei Token ,.*
bzw. . . . und.*ssh
.Die obige Konfiguration stimmt mit den folgenden Anweisungen überein:
-
System-HostnameHostname-SSH
-
Systemdienste SSH
-
Systemdiensteausgehend-ssh
Die obige Konfiguration stimmt nicht mit der folgenden Anweisung überein:
-
Schnittstellen interface-name Beschreibung SSH
-
Es ist einfacher, die deny-configuration
Anweisung zum Einschränken des Konfigurationszugriffs zu verwenden, als die deny-configuration-regexps
Anweisung zu verwenden. Tabelle 2 veranschaulicht die Verwendung der and-Anweisung deny-configuration
deny-configuration-regexps
in verschiedenen Konfigurationen, um das gleiche Ergebnis der Beschränkung des Zugriffs auf eine bestimmte Konfiguration zu erzielen.
Konfiguration verweigert |
Benutzend: |
Benutzend: |
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 Konfigurationsanweisung wird verweigert:
|
|
[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 Mehrdeutigkeit, die beim Kombinieren von Ausdrücken in den allow/deny-configuration
Anweisungen bestand.
Verwenden regulärer Ausdrücke auf Remoteautorisierungsservern
Sie können erweiterte reguläre Ausdrücke verwenden, um anzugeben, welche Befehle im Betriebsmodus und Konfigurationsmodus sowie Konfigurationsanweisungen und -hierarchien für bestimmte Benutzer zulässig oder verweigert werden. Diese regulären Ausdrücke geben Sie lokal in den allow/deny-commands
Anweisungen , allow/deny-configuration
und allow/deny-configuration-regexps
allow/deny-commands-regexps
auf Hierarchieebene [edit system login class class-name]
an. Sie können diese regulären Ausdrücke remote angeben, indem Sie in der Konfiguration Ihres Autorisierungsservers herstellerspezifische 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 wurden, mit allen regulären Ausdrücken zusammen, die auf dem lokalen Gerät definiert sind.
Ab Junos OS Version 18.1 werden die und-Anweisungen deny-commands-regexps
für die allow-commands-regexps
TACACS+-Autorisierung unterstützt.
Wenn Sie mehrere reguläre Ausdrücke in einer lokalen Konfiguration mit der allow-commands
deny-commands
allow-configuration
, , oder deny-configuration
-Anweisung angeben, konfigurieren Sie reguläre Ausdrücke in Klammern und trennen sie durch das Pipe-Symbol. Sie schließen den vollständigen Ausdruck in doppelte Anführungszeichen ein. Sie können z. B. mehrere allow-commands
Parameter mit der folgenden Syntax angeben:
allow-commands "(cmd1)|(cmd2)|(cmdn)"
Der RADIUS-Autorisierungsserver verwendet die folgenden Attribute und 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 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 der allow-commands-regexps
deny-commands-regexps
allow-configuration-regexps
, , oder deny-configuration-regexps
-Anweisung 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 Parameter für Zulassungsbefehle mit der folgenden Syntax angeben:
allow-commands-regexps [ "cmd1" "cmd2" "cmdn" ]
Der RADIUS-Autorisierungsserver verwendet die folgenden Attribute und Syntax:
Juniper-Allow-Configuration-Regexps += "(config1)|(config2)|(confign)", Juniper-Deny-Configuration-Regexps += "(config1)|(config2)|(confign)",
Der TACACS+-Autorisierungsserver verwendet die folgenden Attribute und 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 auch 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",
In ähnlicher Weise lautet die vereinfachte Syntax des TACACS+-Servers:
allow-commands-regexps1 = "cmd1" allow-commands-regexps2 = "cmd2" allow-commands-regexpsn = "cmdn"
Tabelle 3 unterscheidet die lokale Autorisierungskonfiguration und die TACACS+-Serverautorisierungskonfiguration mithilfe regulärer Ausdrücke.
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 remote, indem Sie die folgenden drei Befehle ausführen:
xml-mode
,netconf
undneed-trailer
. -
Wenn Sie die
deny-configuration = ".*"
Anweisung verwenden, müssen Sie alle gewünschten Konfigurationen mithilfe derallow-configuration
Anweisung zulassen. Diese Konfiguration kann sich jedoch auf den zulässigen Puffergrenzwert für reguläre Ausdrücke für dieallow-configuration
Anweisung auswirken. Wenn dieser Grenzwert überschritten wird, funktioniert die zulässige Konfiguration möglicherweise nicht.
Reguläre Ausdrücke angeben
Wenn Sie reguläre Ausdrücke für Befehle und Konfigurationsanweisungen angeben, achten Sie genau auf die folgenden Beispiele. Ein regulärer Ausdruck mit ungültiger Syntax führt möglicherweise nicht zu den gewünschten Ergebnissen, selbst wenn für die Konfiguration ein Fehler ausgeführt wird.
Sie sollten reguläre Ausdrücke für Befehle und Konfigurationsanweisungen auf die gleiche Weise angeben wie beim Ausführen des vollständigen Befehls oder der vollständigen Anweisung. Tabelle 4 Listet die regulären Ausdrücke zum Konfigurieren von Zugriffsrechten für die AND-Anweisungshierarchien [edit interfaces]
[edit vlans]
auf.
Aussage |
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 zum Verweigern 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 zum Zulassen der [edit system login class class-name] user@host# set permissions configure user@host# set allow-configuration "vlans .* vlan-id .*" |
|
Operatoren für reguläre Ausdrücke
Tabelle 5 Listet allgemeine Operatoren für reguläre Ausdrücke auf, die Sie zum Zulassen oder Verweigern von Betriebs- und Konfigurationsmodi verwenden können.
Reguläre Ausdrücke für Befehle implementieren die erweiterten (modernen) regulären Ausdrücke, wie sie in POSIX 1003.2 definiert sind.
Betreiber |
Streichholz |
Beispiel |
---|---|---|
| |
Einer von zwei oder mehr Begriffen, die durch die Pipe getrennt sind. Jeder Ausdruck muss ein vollständiger, eigenständiger Ausdruck sein, der in Klammern ( ) eingeschlossen ist und keine Leerzeichen zwischen dem senkrechten Strich und den angrenzenden Klammern enthält. |
[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)" Mit der vorhergehenden Konfiguration haben die Benutzer, die der Testanmeldeklasse zugeordnet sind, Zugriff auf den Betriebsmodus, der nur auf die in der |
^ |
Am Anfang eines Ausdrucks, wird verwendet, um anzugeben, wo der Befehl beginnt, wo es möglicherweise Mehrdeutigkeiten gibt. |
[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 vorhergehenden Konfiguration haben die Benutzer, die der Testanmeldeklasse zugewiesen sind, Zugriff auf die Anzeige und Konfiguration der Schnittstellenkonfiguration. Die Für den ersten Filter umfassen die angegebenen Befehle die |
$ |
Zeichen am Ende eines Befehls. Wird verwendet, um einen Befehl zu bezeichnen, der bis zu diesem Punkt genau übereinstimmen muss. |
[edit system login class test] user@host# set permissions interface user@host# set allow-commands "(show interfaces$)" Mit der vorhergehenden Konfiguration können die Benutzer, die der Test-Login-Klasse zugewiesen sind, die Schnittstellenkonfiguration im Konfigurationsmodus anzeigen. Die Benutzer können die Schnittstellenkonfiguration auch mit dem |
[ ] |
Buchstaben- oder Ziffernbereich. 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 .*" ] Bei der obigen Konfiguration verfügen die Benutzer, die der Testanmeldeklasse zugewiesen sind, über Benutzerberechtigungen auf Operatorebene. Diese Benutzer haben auch Zugriff auf die Konfiguration von Schnittstellen innerhalb des angegebenen Bereichs von Schnittstellenname und Gerätenummer (0 bis 9). |
( ) |
Eine Gruppe von Befehlen, die einen vollständigen, eigenständigen Ausdruck angeben, der ausgewertet werden soll. Das Ergebnis wird dann als Teil des Gesamtausdrucks ausgewertet. Klammern müssen, wie erläutert, in Verbindung mit Leitungsoperatoren 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 verfügen Benutzer, die der Testanmeldeklasse zugewiesen sind, über Berechtigungen auf Superuser-Ebene und haben Zugriff auf die in der |
* |
Null 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 Testanmeldeklasse zugewiesen sind, deren Anmeldename mit |
+ |
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 Testanmeldeklasse zugewiesen sind, deren Anmeldename mit |
. |
Ein beliebiges Zeichen mit Ausnahme eines Leerzeichens " ". |
[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 Testanmeldeklasse zugewiesen sind, deren Anmeldename mit |
.* |
Alles ab dem angegebenen Punkt. |
[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 Testanmeldeklasse zugewiesen sind, deren Anmeldename mit 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 unter zwei Konfigurationshierarchien zuzulassen –[edit system ntp server]
und [edit protocols rip]
– als Beispiel für die Angabe 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 [edit system ntp server]
Anweisungshierarchien und [edit protocols rip]
überprüft.
Anweisungshierarchie |
Reguläre Ausdrücke |
Zulässige Konfiguration |
Verweigerte Konfiguration |
---|---|---|---|
|
|||
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" ] |
|
|
vorziehen |
[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 .*" ] |
|
|
|
|||
message-size 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 .*" ] |
|
|
Metrik 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 Zugriffsrechte mit allow-configuration- und deny-configuration-Anweisungen
Sie können Zugriffsberechtigungen für Konfigurationsanweisungshierarchien definieren, indem Sie eine Kombination der folgenden Anweisungstypen verwenden:
Berechtigungs-Flags
allow-configuration
unddeny-configuration
Erklärungen
Die Berechtigungsflags definieren die größeren Grenzen dessen, worauf eine Person oder Anmeldeklasse zugreifen und was sie kontrollieren kann. Die allow-configuration
and-Anweisungen deny-configuration
enthalten einen oder mehrere reguläre Ausdrücke, die bestimmte Konfigurationshierarchien und -anweisungen zulassen oder ablehnen. Die allow-configuration
and-Anweisungen deny-configuration
haben Vorrang vor Berechtigungsflags und geben dem Administrator eine genauere Kontrolle darüber, welche Hierarchien und Anweisungen der Benutzer anzeigen und konfigurieren kann.
In diesem Thema wird erläutert, wie Zugriffsberechtigungen mithilfe von allow-configuration
and-Anweisungen deny-configuration
definiert werden, indem Beispiele für Anmeldeklassenkonfigurationen gezeigt werden, die diese Anweisungen verwenden. In den Beispielen 1 bis 3 werden Anmeldeklassen erstellt, die Benutzern den Zugriff auf alle Befehle und Anweisungen mit Ausnahme der in der deny-configuration
Anweisung definierten ermöglichen.
Beachten Sie, dass das Berechtigungsbit und das Berechtigungsflag synonym 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 Login-Klasse, die es dem Benutzer ermöglicht, alle Befehle auszuführen und alles außer Anweisungen innerhalb einer Login-Klasse zu konfigurieren, deren Name mit "m" beginnt:
-
Legen Sie die Anmeldeklassenberechtigungen des Benutzers auf
all
fest.[edit system login] user@host# set class all-except-login-class-m permissions all
-
Fügen Sie die folgende
deny-configuration
Anweisung hinzu.[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 außer den [edit system login class]
Hierarchieebenen oder [edit system services]
zu konfigurieren:
-
Legen Sie die Anmeldeklassenberechtigungen des Benutzers auf
all
fest.[edit system login] user@host# set class all-except-login-class-or-system-services permissions all
-
Fügen Sie die folgende
deny-configuration
Anweisung hinzu:[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 mit der and-Anweisung allow-configuration
deny-configuration
Berechtigungen für die Hierarchieebene [edit system services]
invers zueinander bestimmen können.
Beispiel 4
So erstellen Sie eine Anmeldeklasse, die dem Benutzer nur auf Hierarchieebene [edit system services]
vollständige Konfigurationsrechte gewährt:
-
Legen Sie die Anmeldeklassenberechtigungen des Benutzers auf
configure
fest.[edit system login] user@host# set class configure-only-system-services permissions configure
-
Fügen Sie die folgende
allow-configuration
Anweisung hinzu:[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 mit Ausnahme der [edit system services]
Hierarchieebene gewährt:
-
Legen Sie die Anmeldeklassenberechtigungen des Benutzers auf
all
fest.[edit system login] user@host# set class all-except-system-services permissions all
-
Fügen Sie die folgende
deny-configuration
Anweisung hinzu.[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 anzugeben
In diesem Beispiel wird gezeigt, wie additive Logik verwendet wird, wenn reguläre Ausdrücke zum Einrichten von Konfigurationszugriffsberechtigungen verwendet werden.
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 kann und was geändert werden kann. Diese regulären Ausdrücke geben bestimmte Konfigurationshierarchien an, auf die Benutzer in einer Anmeldeklasse zugreifen dürfen. Sie können z. B. reguläre Ausdrücke definieren, die es Benutzern ermöglichen, eine Gruppe von Routing-Instanzen zu ändern, und reguläre Ausdrücke definieren, die verhindern, dass Benutzer Änderungen an anderen Routing-Instanzen oder an anderen Konfigurationsebenen vornehmen. Sie definieren die regulären Ausdrücke, indem Sie die allow-configuration-regexps
and-Anweisungen deny-configuration-regexps
für eine login-Klasse 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 für die Benutzer in dieser Klasse nicht sichtbar, unabhängig vom Inhalt der allow-configuration-regexps
Anweisung. Wenn eine Konfigurationshierarchie nicht in einer deny-configuration-regexps
Anweisung 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 deny-configuration-regexps
Anweisung den Zugriff auf alle Konfigurationshierarchien auf einer bestimmten Ebene (protocols .*) verweigert, die allow-configuration-regexps
Anweisung jedoch den Zugriff auf eine Unterhierarchie (protocols 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 Benutzern in dieser Anmeldeklasse den Zugriff auf die angegebene Unterhierarchie, da die allow-configuration-regexps
in diesem Fall Vorrang hat.
Konfiguration
Schritt-für-Schritt-Anleitung
Gehen Sie wie folgt vor, um die additive Logik zu aktivieren, um Benutzern in einer bestimmten Anmeldeklasse explizit den Zugriff auf eine oder mehrere einzelne Konfigurationshierarchien zu ermöglichen:
-
Fügen Sie die Anweisung ein, und verweigern Sie explizit
deny-configuration-regexps
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"]
Beispiele:
[edit system login class class-name] user@host# set deny-configuration-regexps "protocols .*"
-
Fügen Sie die
allow-configuration-regexps
Anweisung ein, und definieren Sie reguläre Ausdrücke für die spezifischen Hierarchien, die zulässig sein sollen.[edit system login class class-name] user@host# set allow-configuration-regexps ["regular expression 1" "regular expression 2" "regular expression 3"]
Beispiele:
[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
-
Bestätigen Sie Ihre Änderungen.
Benutzer, die dieser Anmeldeklasse zugewiesen sind, haben Zugriff auf die in der
allow-configuration-regexps
Anweisung enthaltenen Konfigurationshierarchien, jedoch nicht auf die anderen in derdeny-configuration-regexps
Anweisung angegebenen Hierarchien.
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 etwaige Auswirkungen auswerten und die regulären Ausdrücke in diesen Anweisungen entsprechend aktualisieren.
Beispiele
Verwenden regulärer Ausdrücke mit additiver Logik
Zweck
Dieser Abschnitt enthält Beispiele für reguläre Ausdrücke, die additive Logik verwenden, um Ihnen Ideen zum Erstellen von Konfigurationen zu geben, die für Ihr System geeignet sind.
Bestimmte Routing-Instanzen zulassen
Die folgende Beispiel-Anmeldeklasse enthält einen regulären Ausdruck, der die Konfiguration von Routinginstanzen ermöglicht, deren Namen mit CUST-VRF-
; beginnen, CUST-VRF-1
z. B. , CUST-VRF-25
, CUST-VRF-100
usw. Das Beispiel enthält auch einen regulären Ausdruck, der die Konfiguration von Routinginstanzen 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 login-Klasse Routinginstanzen unabhängig vom Namen konfigurieren können.
Wenn Sie jedoch die folgende Anweisung konfigurieren, hat die allow-configuration-regexps
Anweisung Vorrang. Somit 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 Beispiel-Anmeldeklasse enthält reguläre Ausdrücke, die die Konfiguration auf Hierarchieebene [edit protocols]
verhindern, aber die Konfiguration von BGP-Peers zulassen:
[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 login-Klasse Änderungen an Hierarchien unter [edit protocols]
vornehmen.
Wenn Sie jedoch die folgende Anweisung konfigurieren, können die Benutzer in der login-Klasse Änderungen an BGP-Peers vornehmen, aber die Benutzer können keine anderen Protokolle oder andere BGP-Anweisungen außerhalb der zulässigen Hierarchieebene konfigurieren.
[edit system] user@host# set regex-additive-logic
Verifizierung
So überprüfen Sie, ob Sie die Zugriffsrechte richtig festgelegt haben:
-
Konfigurieren Sie eine Anmeldeklasse, und führen Sie einen Commit für die Änderungen aus.
-
Weisen Sie die Anmeldeklasse einer username.
-
Melden Sie sich als zugewiesene username mit der neuen login-Klasse an.
-
Versuchen Sie, die zulässigen Hierarchieebenen zu konfigurieren.
-
Sie sollten in der Lage sein, Anweisungen in Hierarchieebenen zu konfigurieren, die erlaubt wurden.
-
Hierarchieebenen, die verweigert werden, sollten nicht sichtbar sein.
-
Alle zulässigen oder verweigerten Ausdrücke sollten Vorrang vor allen Berechtigungen haben, die mit der
permissions
Anweisung erteilt werden.
-
Beispiel: Konfigurieren von Benutzerberechtigungen mit Zugriffsrechten für Betriebsmodusbefehle
In diesem Beispiel wird gezeigt, wie benutzerdefinierte Anmeldeklassen konfiguriert und Zugriffsrechte für Betriebsmodusbefehle zugewiesen werden. Benutzer in der login-Klasse können nur die Befehle ausführen, auf die sie Zugriff haben. Dadurch wird verhindert, dass unbefugte Benutzer vertrauliche 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
Bevor Sie beginnen, stellen Sie eine TCP-Verbindung zwischen dem Gerät und dem TACACS+-Server her. Stellen Sie beim RADIUS-Server 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 benutzerdefinierten Anmeldeklassen konfiguriert: Klasse 1, Klasse 2 und Klasse 3. Jede Klasse definiert Zugriffsrechte für den Benutzer, indem sie die permissions
Anweisung konfiguriert und erweiterte reguläre Ausdrücke mit der deny-commands
allow-commands
and-Anweisung definiert.
Der Zweck jeder Anmeldeklasse ist wie folgt:
-
Class1– Definiert Zugriffsrechte für den Benutzer nur mit der
allow-commands
Anweisung. Diese Anmeldeklasse bietet Benutzerberechtigungen auf Bedienerebene und Autorisierung für den Neustart des Geräts. -
Class2– Definiert Zugriffsrechte für den Benutzer nur mit der
deny-commands
Anweisung. Diese login-Klasse stellt Benutzerberechtigungen auf Operatorebene bereit und verweigert den Zugriff aufset
Befehle. -
Class3– Definiert die Zugriffsrechte für den Benutzer mit den
allow-commands
Anweisungen "unddeny-commands
". Diese Anmeldeklasse bietet Benutzerberechtigungen auf Superuser-Ebene und Autorisierung für den Zugriff auf Schnittstellen und das Anzeigen von Geräteinformationen. Außerdem wird der Zugriff auf dieedit
Befehle undconfigure
verweigert.
Router R1 verfügt über drei verschiedene Benutzer, User1, User2 und User3, die den Anmeldeklassen Class1, Class2 bzw. Class3 zugewiesen sind.
Konfiguration
- CLI-Schnellkonfiguration
- Konfigurieren der Authentifizierungsparameter für Router R1
- Konfigurieren von Zugriffsrechten mit der allow-commands-Anweisung (Class1)
- Konfigurieren von Zugriffsrechten mit der deny-commands-Anweisung (Class2)
- Konfigurieren von Zugriffsrechten sowohl mit der allow-commands- als auch mit deny-commands-Anweisung (Class3)
- Ergebnisse
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für Ihre Netzwerkkonfiguration erforderlich sind, kopieren Sie die Befehle, und fügen Sie sie auf Hierarchieebene [edit]
in die CLI ein, und wechseln commit
Sie dann in den Konfigurationsmodus.
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 der Authentifizierungsparameter für Router R1
Schritt-für-Schritt-Anleitung
So konfigurieren Sie die Router R1-Authentifizierung:
-
Konfigurieren Sie die Reihenfolge, in der R1 versucht, den Benutzer zu authentifizieren. In diesem Beispiel steht die TACACS+-Serverauthentifizierung an erster Stelle, gefolgt von der RADIUS-Serverauthentifizierung und dann dem lokalen 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-Abrechnungsparameter.
[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-Anleitung
So geben Sie reguläre Ausdrücke mit der allow-commands
folgenden Anweisung an:
-
Konfigurieren Sie die Anmeldeklasse Class1, und weisen Sie Benutzerberechtigungen auf Operatorebene zu.
[edit system login] user@R1# set class Class1 permissions [clear network reset trace view]
-
Konfigurieren Sie den
allow-commands
regulären Ausdruck so, dass 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 deny-commands-Anweisung (Class2)
Schritt-für-Schritt-Anleitung
So geben Sie reguläre Ausdrücke mit der deny-commands
folgenden Anweisung an:
-
Konfigurieren Sie die Class2-Anmeldeklasse, und weisen Sie Benutzerberechtigungen auf Operatorebene zu.
[edit system login] user@R1# set class Class1 permissions [clear network reset trace view]
-
Konfigurieren Sie den
deny-commands
regulären Ausdruck so, dass Benutzer in der Klasse keine Befehle ausführenset
können.[edit system login] user@R1# set class Class1 deny-commands "set"
-
Konfigurieren Sie das Benutzerkonto für die Anmeldeklasse Class2.
[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 sowohl mit der allow-commands- als auch mit deny-commands-Anweisung (Class3)
Schritt-für-Schritt-Anleitung
So geben Sie reguläre Ausdrücke mit der and-Anweisung allow-commands
deny-commands
an:
-
Konfigurieren Sie die Class3-Anmeldeklasse, und weisen Sie Berechtigungen auf Superuser-Ebene 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 regulären Ausdruck so, dass Benutzer in den
allow-commands
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 im Konfigurationsmodus Ihre Konfiguration, indem Sie den show system
Befehl eingeben. Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, 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; } }
Verifizierung
Melden Sie sich mit dem Benutzernamen an, der der neuen login-Klasse zugewiesen wurde, und vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfen der Class1-Konfiguration
- Überprüfen 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.
Action!
Führen Sie den show system users
Befehl im 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 request system reboot
Befehl im Betriebsmodus aus.
User1@R1> request system ? Possible completions: reboot Reboot the system
Bedeutung
Die Class1-Anmeldeklasse, der User1 zugewiesen ist, verfügt über Benutzerberechtigungen auf Operatorebene und ermöglicht Benutzern in der Klasse die Ausführung des request system reboot
Befehls.
Für die vordefinierte Operator-Anmeldeklasse sind die folgenden Berechtigungsflags angegeben:
clear—Kann Befehle zum Löschen (Löschen) von Informationen verwenden
clear
, die das Gerät aus dem Netzwerk lernt und in verschiedenen Netzwerkdatenbanken speichert.network—Kann mit den
ping
Befehlen ,ssh
,telnet
undtraceroute
auf das Netzwerk zugreifen.reset– Kann Softwareprozesse mithilfe des
restart
Befehls neu starten.trace: Kann Trace-Dateieinstellungen anzeigen und Trace-Dateieigenschaften konfigurieren.
view—Kann verschiedene Befehle verwenden, um aktuelle systemweite, Routing-Tabellen- und protokollspezifische Werte und Statistiken anzuzeigen. Die geheime Konfiguration kann nicht angezeigt werden.
Für die Anmeldeklasse Class1 kann zusätzlich zu den oben genannten Benutzerberechtigungen User1 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 User1 als Operator ausführen kann, der request system reboot
Befehl ist.
Überprüfen der Class2-Konfiguration
Zweck
Stellen Sie sicher, dass die Berechtigungen und Befehle, die für die Class2-Anmeldeklasse zulässig sind, funktionieren.
Action!
Führen Sie den ping
Befehl im 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 an der CLI-Eingabeaufforderung einen beliebigen set-Befehl aus.
User2@R1> set ^ unknown command.
Bedeutung
Die Class2-Anmeldeklasse, der User2 zugewiesen ist, verfügt über Benutzerberechtigungen auf Operatorebene und verweigert den Zugriff auf alle set
Befehle.
Die Berechtigungsflags, die für die vordefinierte Operatoranmeldeklasse angegeben sind, sind identisch mit denen, die für Class1 angegeben sind.
Überprüfen der Class3-Konfiguration
Zweck
Stellen Sie sicher, dass die Berechtigungen und Befehle, die für die Class3-Anmeldeklasse zulässig sind, funktionieren.
Action!
Überprüfen Sie im Betriebsmodus die verfügbaren Befehle.
User3@R1> ? Possible completions: configure Manipulate software configuration information
Wechseln Sie in den Konfigurationsmodus.
User3@R1> configure Entering configuration mode [edit] User3@R1#
Bedeutung
Die Class3-Anmeldeklasse, der User3 zugewiesen ist, verfügt über Superuser-Berechtigungen (alle), aber diese Klasse erlaubt Benutzern nur das Ausführen des configure
Befehls. Die Klasse verweigert den Zugriff auf alle anderen Betriebsmodusbefehle. Da die in den allow/deny-commands
Anweisungen angegebenen regulären Ausdrücke Vorrang vor den Benutzerberechtigungen haben, hat User3 auf R1 nur Zugriff auf den Konfigurationsmodus und wird der Zugriff auf alle anderen Befehle für den Betriebsmodus verweigert.
Beispiel: Konfigurieren von Benutzerberechtigungen mit Zugriffsrechten für Konfigurationsanweisungen und Hierarchien
In diesem Beispiel wird gezeigt, wie benutzerdefinierte Anmeldeklassen konfiguriert und Zugriffsrechte bestimmten Konfigurationshierarchien zugewiesen werden. Benutzer in der login-Klasse 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
Bevor Sie beginnen, stellen Sie eine TCP-Verbindung zwischen dem Gerät und dem TACACS+-Server her. Stellen Sie beim RADIUS-Server 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: Klasse 1 und Klasse 2. Jede Klasse definiert Zugriffsrechte für den Benutzer, indem sie die permissions
Anweisung konfiguriert und erweiterte reguläre Ausdrücke mithilfe der allow-configuration
Anweisungen , deny-configuration
, allow-configuration-regexps
und deny-configuration-regexps
definiert.
Der Zweck jeder Anmeldeklasse ist wie folgt:
-
Class1– Definiert die Zugriffsrechte für den Benutzer mit der
allow-configuration
deny-configuration
und-Anweisung. Diese Anmeldeklasse bietet nur Zugriff zum Konfigurieren der[edit interfaces]
Hierarchie und verweigert alle anderen Zugriffe auf dem Gerät. Zu diesem Zweck umfassenconfigure
die Benutzerberechtigungen den Konfigurationszugriff. Darüber hinaus erlaubt dieallow-configuration
Anweisung den Zugriff auf die Schnittstellenkonfiguration und verweigertdeny-configuration
den Zugriff auf alle anderen Konfigurationshierarchien. Da die allow-Anweisung Vorrang vor der deny-Anweisung hat, können die Benutzer, die der Class1-Anmeldeklasse zugewiesen sind, nur auf die[edit interfaces]
Hierarchieebene zugreifen. -
Class2– Definiert die Zugriffsrechte für den Benutzer mit der
allow-configuration-regexps
deny-configuration-regexps
und-Anweisung. Diese Anmeldeklasse stellt Benutzerberechtigungen auf Superuser-Ebene bereit und ermöglicht explizit die Konfiguration unter mehreren Hierarchieebenen für Schnittstellen. Außerdem wird der Zugriff auf die[edit system]
Hierarchieebenen und[edit protocols]
verweigert.
Router R1 verfügt über zwei Benutzer, User1 und User2, die den Anmeldeklassen Class1 bzw. Class2 zugewiesen sind.
Konfiguration
- CLI-Schnellkonfiguration
- Konfigurieren der Authentifizierungsparameter für Router R1
- Konfigurieren von Zugriffsrechten mit den Anweisungen allow-configuration und deny-configuration (Klasse 1)
- Konfigurieren von Zugriffsrechten 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 sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für Ihre Netzwerkkonfiguration erforderlich sind, kopieren Sie die Befehle, und fügen Sie sie auf Hierarchieebene [edit]
in die CLI ein, und wechseln commit
Sie dann in den Konfigurationsmodus.
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 der Authentifizierungsparameter für Router R1
Schritt-für-Schritt-Anleitung
So konfigurieren Sie die Router R1-Authentifizierung:
-
Konfigurieren Sie die Reihenfolge, in der R1 versucht, den Benutzer zu authentifizieren. In diesem Beispiel steht die TACACS+-Serverauthentifizierung an erster Stelle, gefolgt von der RADIUS-Serverauthentifizierung und dann dem lokalen 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-Abrechnungsparameter.
[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 deny-configuration (Klasse 1)
Schritt-für-Schritt-Anleitung
So geben Sie reguläre Ausdrücke mithilfe der allow-configuration
deny-configuration
and-Anweisungen an:
-
Konfigurieren Sie die Anmeldeklasse Class1 mit
configure
Berechtigungen.[edit system login] user@R1# set class Class1 permissions configure
-
Konfigurieren Sie den
allow-configuration
regulären Ausdruck so, dass 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 so, dass der Zugriff auf alle Konfigurationshierarchien verweigert wird.[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 von Zugriffsrechten mit den Anweisungen allow-configuration-regexps und deny-configuration-regexps (Class2)
Schritt-für-Schritt-Anleitung
So geben Sie reguläre Ausdrücke mithilfe der allow-configuration-regexps
deny-configuration-regexps
and-Anweisungen an:
-
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 so, dass 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[edit system]
Hierarchieebene und[edit protocols]
anzeigen oder ändern.[edit system login] user@R1# set class Class2 deny-configuration-regexps [ "system" "protocols" ]
-
Konfigurieren Sie das Benutzerkonto für die Anmeldeklasse Class2.
[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 im Konfigurationsmodus Ihre Konfiguration, indem Sie den show system
Befehl eingeben. Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, 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; } }
Verifizierung
Melden Sie sich mit dem Benutzernamen an, der der neuen login-Klasse zugewiesen wurde, und vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.
Überprüfen der Class1-Konfiguration
Zweck
Vergewissern Sie sich, dass die in der Anmeldeklasse Class1 zulässigen Berechtigungen funktionieren.
Action!
Ü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
User1 verfügt über configure
Benutzerberechtigungen, wie in der ersten Ausgabe zu sehen ist. 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.
Action!
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
Konfigurationshierarchien und protocols
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 zum Konfigurieren von Schnittstellen auf R1, aber der Benutzer verfügt nicht über die Berechtigung zum Anzeigen oder Ändern der [edit system]
Hierarchieebenen oder [edit protocols]
.
Tabellarischer Änderungsverlauf
Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie Feature Explorer, um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.
deny-commands-regexps
für die allow-commands-regexps
TACACS+-Autorisierung unterstützt.