Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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

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.

HINWEIS:

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 ist interface-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.

Tabelle 1: Berechtigungsflags für Anmeldeklassen

Berechtigungs-Flag

Beschreibung

access

Kann die Zugriffskonfiguration im Betriebsmodus oder Konfigurationsmodus anzeigen.

access-control

Kann Zugriffsinformationen auf Hierarchieebene [edit access] anzeigen und konfigurieren.

admin

Kann Benutzerkontoinformationen im Betriebsmodus oder Konfigurationsmodus anzeigen.

admin-control

Kann Benutzerkontoinformationen anzeigen und auf Hierarchieebene [edit system] konfigurieren.

all

Kann auf alle Betriebsmodusbefehle und Konfigurationsmodusbefehle zugreifen. Kann die Konfiguration in allen Konfigurationshierarchieebenen ändern.

clear

Kann Informationen löschen (löschen), die das Gerät aus dem Netzwerk lernt und in verschiedenen Netzwerkdatenbanken speichert (mithilfe der clear Befehle).

configure

Kann in den Konfigurationsmodus wechseln (mit dem configure Befehl) und Konfigurationen bestätigen (mit dem commit Befehl).

control

Kann alle Vorgänge auf Steuerungsebene ausführen – alle Vorgänge, die mit den -control Berechtigungsflags konfiguriert sind.

field

Kann Felddebugbefehle anzeigen. Reserviert für die Unterstützung beim Debuggen.

firewall

Kann die Firewall-Filterkonfiguration im Betriebsmodus oder Konfigurationsmodus anzeigen.

firewall-control

Kann Firewallfilterinformationen auf Hierarchieebene [edit firewall] anzeigen und konfigurieren.

floppy

Kann von Wechselmedien lesen und darauf schreiben.

flow-tap

Kann die Flow-Tap-Konfiguration im Betriebsmodus oder Konfigurationsmodus anzeigen.

flow-tap-control

Kann Flow-Tap-Informationen auf Hierarchieebene [edit services flow-tap] anzeigen und konfigurieren.

flow-tap-operation

Kann Flow-Tap-Anfragen an den Router oder Switch stellen. Beispielsweise muss ein DTCP-Client (Dynamic Tasking Control Protocol) über die Berechtigung verfügen flow-tap-operation , sich Junos OS als Administratorbenutzer zu authentifizieren.

HINWEIS:

Die flow-tap-operation Option ist nicht im all-control Berechtigungsflag enthalten.

idp-profiler-operation

Kann Profilerdaten anzeigen.

interface

Kann die Schnittstellenkonfiguration im Betriebsmodus und Konfigurationsmodus anzeigen.

interface-control

Kann Informationen zu Chassis, Class-of-Service (CoS), Gruppen, Weiterleitungsoptionen und Schnittstellenkonfigurationsinformationen anzeigen. Kann die Konfiguration auf den folgenden Hierarchieebenen ändern:

  • [edit chassis]

  • [edit class-of-service]

  • [edit groups]

  • [edit forwarding-options]

  • [edit interfaces]

maintenance

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 su root Befehl) und des Anhaltens und Neustartens des Geräts (mit den request system Befehlen).

network

Kann mit den Befehlen ping, ssh, telnetund traceroute auf das Netzwerk zugreifen.

pgcp-session-mirroring

Kann die pgcp Sitzungsspiegelungskonfiguration anzeigen.

pgcp-session-mirroring-control

Die Konfiguration der pgcp Sitzungsspiegelung kann geändert werden.

reset

Kann Softwareprozesse mithilfe des restart Befehls neu starten.

rollback

Kann den rollback Befehl verwenden, um zu einer zuvor festgeschriebenen Konfiguration zurückzukehren.

routing

Kann allgemeine Routing-, Routingprotokoll- und Routingrichtlinien-Konfigurationsinformationen im Konfigurationsmodus und Betriebsmodus anzeigen.

routing-control

Kann allgemeines Routing auf Hierarchieebene, Routingprotokolle auf Hierarchieebene [edit protocols] und Routingrichtlinieninformationen auf Hierarchieebene [edit routing-options][edit policy-options] anzeigen und konfigurieren.

secret

Kann Kennwörter und andere Authentifizierungsschlüssel in der Konfiguration anzeigen.

secret-control

Kann Kennwörter und andere Authentifizierungsschlüssel in der Konfiguration anzeigen und ändern.

security

Kann Sicherheitskonfigurationsinformationen im Betriebsmodus und Konfigurationsmodus anzeigen.

security-control

Kann Sicherheitsinformationen auf Hierarchieebene [edit security] anzeigen und konfigurieren.

shell

Kann mit dem start shell Befehl eine lokale Shell auf dem Router oder Switch starten.

snmp

Kann SNMP-Konfigurationsinformationen (Simple Network Management Protocol) im Betriebsmodus oder Konfigurationsmodus anzeigen.

snmp-control

Kann SNMP-Konfigurationsinformationen auf Hierarchieebene [edit snmp] anzeigen und ändern.

Kann Informationen zur Fibre Channel-Speicherkonfiguration auf Hierarchieebene [edit fc-fabrics] anzeigen.

Kann Konfigurationsinformationen des Fibre Channel-Speichers auf Hierarchieebene [edit fc-fabrics] ändern.

system

Kann Informationen auf Systemebene im Betriebsmodus oder Konfigurationsmodus anzeigen.

system-control

Kann Konfigurationsinformationen auf Systemebene auf Hierarchieebene [edit system] anzeigen und ändern.

trace

Kann Ablaufverfolgungsdateieinstellungen anzeigen und Ablaufverfolgungsdateieigenschaften konfigurieren.

trace-control

Kann Ablaufverfolgungsdateieinstellungen ändern und Ablaufverfolgungsdateieigenschaften konfigurieren.

Kann die einheitliche Edge-Konfiguration in der Hierarchie [edit unified-edge] anzeigen.

Kann die einheitliche Edge-bezogene Konfiguration in der Hierarchie [edit unified-edge] ändern.

view

Kann verschiedene Befehle verwenden, um aktuelle systemweite, Routing-Tabellen- und protokollspezifische Werte und Statistiken anzuzeigen. Die geheime Konfiguration kann nicht angezeigt werden.

view-configuration

Kann die gesamte Konfiguration mit Ausnahme von Geheimnissen, Systemskripts und Ereignisoptionen anzeigen.

HINWEIS:

Nur Benutzer mit der maintenance entsprechenden Berechtigung können die Konfiguration des Commit-Skripts, des Op-Skripts oder des Ereignisskripts anzeigen.

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-commandsdeny-commands, , allow-configurationund - 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.

HINWEIS:

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:

Tipp:

Um die verfügbaren Berechtigungen anzuzeigen, verwenden Sie die kontextsensitive Hilfe der CLI, und geben Sie nach der permissions Anweisung ein Fragezeichen (?) ein:

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:

  1. Konfigurieren Sie die snmp-admin Anmeldeklasse mit den configureBerechtigungsflags , snmpund 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.

  2. Erstellen Sie die Benutzerkonten, die der snmp-admin Anmeldeklasse zugewiesen sind.

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.

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] .

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.

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

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 and deny-commands—Erlauben oder verweigern Sie den Zugriff auf Befehle für den Betriebsmodus und den Konfigurationsmodus.

  • allow-configuration and deny-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 and deny-commands-regexps—Erlaubt oder verweigert den Zugriff auf bestimmte Befehle mithilfe von Zeichenketten regulärer Ausdrücke.

  • allow-configuration-regexps and deny-configuration-regexps—Erlaubt oder verweigert den Zugriff auf bestimmte Konfigurationshierarchien mithilfe von Zeichenketten regulärer Ausdrücke.

HINWEIS:

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.

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:

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-configurationallow-configuration-regexps in derselben Anmeldeklasse konfigurieren.

Um Zugriffsrechte für Befehle zu definieren, geben Sie erweiterte reguläre Ausdrücke mit der allow-commandsdeny-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.

Beispiele:

Sie müssen Anker verwenden, wenn Sie komplexe reguläre Ausdrücke mit der allow-commands Anweisung angeben. Beispiele:

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.

Beispiele:

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:

Modifizierer wie set, logund 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:

Falsche Konfiguration:

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-commandsdeny-commands and-Anweisung konfigurieren, hat der allow-Vorgang Vorrang vor dem deny-Vorgang. Wenn Sie dieselbe Anweisung für die allow-configurationdeny-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:

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:

Wenn die and-Anweisungen allow-commandsdeny-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 synchronizeist und für allow-commandsangegeben ist.

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 synchronizeist und für deny-commandsangegeben ist.

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-configurationallow/deny-commands-regexpsDie 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-Anweisungen deny-commands können auch die commitBefehle , load, rollback, save, statusund update enthalten.

  • Die Berechtigungsbits der all Anmeldeklasse haben Vorrang vor erweiterten regulären Ausdrücken, wenn ein Benutzer den rollback Befehl mit rollback aktiviertem Berechtigungsflag ausgibt.

  • Benutzer können den Befehl nicht ausgeben, load override wenn sie einen erweiterten regulären Ausdruck angeben. Benutzer können nur die mergeKonfigurationsbefehle , replaceund patch 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 die allow-configuration Anweisung nicht mit einem Ausdruck wie , (interfaces (description (|.*))konfigurieren, da dies zu allow-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.

    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.

    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-configurationdeny-configuration-regexps in verschiedenen Konfigurationen, um das gleiche Ergebnis der Beschränkung des Zugriffs auf eine bestimmte Konfiguration zu erzielen.

Tabelle 2: Einschränken des Konfigurationszugriffs mithilfe der Anweisungen deny-configuration und deny-configuration-regexps

Konfiguration verweigert

Benutzend: deny-configuration

Benutzend: deny-configuration-regexps

Ergebnis

xnm-ssl

[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:

  • Systemdienste XNM-SSL

ssh

[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:

  • System-Hostname Hostname-SSH

  • Systemdienste SSH

  • Systemdienste ausgehend-ssh

  • sicherheit ssh-known-host

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-commandsAnweisungen , allow/deny-configurationund allow/deny-configuration-regexpsallow/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.

HINWEIS:

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-commandsdeny-commandsallow-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:

Der RADIUS-Autorisierungsserver verwendet die folgenden Attribute und Syntax:

Der TACACS+-Autorisierungsserver verwendet die folgenden Attribute und Syntax:

Wenn Sie mehrere reguläre Ausdrücke in einer lokalen Konfiguration mit der allow-commands-regexpsdeny-commands-regexpsallow-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:

Der RADIUS-Autorisierungsserver verwendet die folgenden Attribute und Syntax:

Der TACACS+-Autorisierungsserver verwendet die folgenden Attribute und Syntax:

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:

In ähnlicher Weise lautet die vereinfachte Syntax des TACACS+-Servers:

Tabelle 3 unterscheidet die lokale Autorisierungskonfiguration und die TACACS+-Serverautorisierungskonfiguration mithilfe regulärer Ausdrücke.

Tabelle 3: Beispiel für eine lokale und Remote-Autorisierungskonfiguration mit 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"
    }
}
HINWEIS:
  • 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, netconfund need-trailer.

  • Wenn Sie die deny-configuration = ".*" Anweisung verwenden, müssen Sie alle gewünschten Konfigurationen mithilfe der allow-configuration Anweisung zulassen. Diese Konfiguration kann sich jedoch auf den zulässigen Puffergrenzwert für reguläre Ausdrücke für die allow-configuration Anweisung auswirken. Wenn dieser Grenzwert überschritten wird, funktioniert die zulässige Konfiguration möglicherweise nicht.

Reguläre Ausdrücke angeben

WARNUNG:

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.

Tabelle 4: Reguläre Ausdrücke angeben

Aussage

Regulärer Ausdruck

Konfigurationshinweise

[edit interfaces]

Der set Befehl für Schnittstellen wird wie folgt ausgeführt:

[edit]
user@host# set interfaces interface-name unit interface-unit-number

Die set interfaces Anweisung ist an sich unvollständig und erfordert die unit Option zum Ausführen der Anweisung.

Daher muss der reguläre Ausdruck, der zum Verweigern der set interfaces Konfiguration erforderlich ist, die gesamte ausführbare Zeichenfolge mit dem .* Operator anstelle von Anweisungsvariablen angeben:

[edit system login class class-name]
user@host# set permissions configure
user@host# set deny-configuration "interfaces .* unit .*"
  • Der .* Operator bezeichnet alles ab dem angegebenen Punkt für diesen bestimmten Befehl oder diese bestimmte Anweisung. In diesem Beispiel bezeichnet es einen beliebigen Schnittstellennamen mit einem beliebigen Einheitenwert.

  • Die Angabe nur der deny-configuration "interfaces .*" Anweisung ist falsch und verweigert nicht den Zugriff auf die Schnittstellenkonfiguration für die angegebene Anmeldeklasse.

  • Andere gültige Optionen können in den regulären Ausdruck aufgenommen werden. Beispiele:

    [edit system login class class-name]
    user@host# set permissions configure
    user@host# set deny-configuration "interfaces .* description .*"
    
    [edit system login class class-name]
    user@host# set permissions configure
    user@host# set allow-configuration-regexps [ "interfaces .* description .*" "interfaces .* unit .* description .*" "interfaces .* unit .* family inet address .*" "interfaces.* disable" ]
    
    [edit system login class class-name]
    user@host# set permissions configure
    user@host# set allow-configuration "interfaces .* unit 0 family ethernet-switching vlan mem.* .*"
    

    Hinweis: Der mem.* reguläre Ausdruck in diesem Beispiel wird verwendet, wenn erwartet wird, dass mehrere Zeichenfolgen, die mit dem mem Schlüsselwort beginnen, im angegebenen regulären Ausdruck enthalten sind. Wenn erwartet wird, dass nur eine member Zeichenfolge enthalten ist, wird der member .* reguläre Ausdruck verwendet.

[edit vlans]

Der set Befehl für VLANs wird wie folgt ausgeführt:

[edit]
user@host# set vlans vlan-name vlan-id vlan-id

Hier ist die set vlans Anweisung an sich unvollständig und erfordert die vlan-id Option zum Ausführen der Anweisung.

Daher muss der reguläre Ausdruck, der zum Zulassen der set vlans Konfiguration erforderlich ist, die gesamte ausführbare Zeichenfolge mit dem .* Operator anstelle von Anweisungsvariablen angeben:

[edit system login class class-name]
user@host# set permissions configure
user@host# set allow-configuration "vlans .* vlan-id .*"
  • Der .* Operator bezeichnet alles ab dem angegebenen Punkt für diesen bestimmten Befehl oder diese bestimmte Anweisung. In diesem Beispiel bezeichnet es einen beliebigen VLAN-Namen mit einer beliebigen VLAN-ID.

  • Andere gültige Optionen in der [edit vlans] Anweisungshierarchie können in den regulären Ausdruck aufgenommen werden. Beispiele:

    [edit system login class class-name]
    user@host# set permissions configure
    user@host# set allow-configuration-regexps [ "vlans .* vlan-id .*" "vlans .* vlan-id .* description .*" "vlans .* vlan-id .* filter .*" ]
    

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.

Tabelle 5: Allgemeine Operatoren für reguläre Ausdrücke

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 allow-commands Anweisung angegebenen Befehle beschränkt ist. Sie haben auch Zugriff auf den Konfigurationsmodus, mit Ausnahme der in der deny-configuration Anweisung angegebenen Hierarchieebenen.

^

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 allow-commands Anweisung gewährt Zugriff auf Befehle, die mit den show Schlüsselwörtern and monitor beginnen.

Für den ersten Filter umfassen die angegebenen Befehle die show logBefehle , show interfacesund show policer . Der zweite Filter gibt alle Befehle an, die mit dem monitor Schlüsselwort beginnen, z. B. das monitor interfaces oder die monitor traffic Befehle.

$

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 show configuration Befehl Betriebsmodus anzeigen. Der in der allow-commands Anweisung angegebene reguläre Ausdruck schränkt die Benutzer jedoch ein, nur den show interfaces Befehl auszuführen, und verweigert den Zugriff auf die Befehlserweiterungen wie show interfaces detail oder show interfaces extensive.

[ ]

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 allow-commands Anweisung angegebenen Befehle.

*

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 m beginnt, der Konfigurationszugriff verweigert.

+

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 m beginnt, der Konfigurationszugriff verweigert.

.

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 m beginnt, der Konfigurationszugriff verweigert.

.*

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 m beginnt, der Konfigurationszugriff verweigert.

Ebenso verweigert die deny-configuration "protocols .*" Anweisung den gesamten Konfigurationszugriff auf der Hierarchieebene [edit protocols] .

HINWEIS:
  • Die *Vorgänge , +und . können mithilfe von .*.

  • Die deny-commands .* and-Anweisungen deny-configuration .* verweigern den Zugriff auf alle Betriebsmodusbefehle bzw. Konfigurationshierarchien.

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.

HINWEIS:

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.

Tabelle 6: Beispiele für reguläre Ausdrücke

Anweisungshierarchie

Reguläre Ausdrücke

Zulässige Konfiguration

Verweigerte Konfiguration

[edit system ntp server]

     

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" ]
  • Server-IP

  • Server-IP und -Schlüssel

  • Version

  • vorziehen

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" ]
  • Server-IP

  • Server-IP und -Version

  • Schlüssel

  • vorziehen

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 .*" ]
  • Server-IP

  • Server-IP und bevorzugen

  • Schlüssel

  • Version

[edit protocols rip]

     

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 .*" ]
  • message-size

  • Metrik in

  • route-timeout

  • update-intervall

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 .*" ]
  • Metrik in

  • message-size

  • route-timeout

  • update-intervall

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 .*" ]
  • route-timeout

  • message-size

  • Metrik in

  • update-intervall

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 .*" ]
  • update-intervall

  • message-size

  • Metrik in

  • route-timeout

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 und deny-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:

  1. Legen Sie die Anmeldeklassenberechtigungen des Benutzers auf allfest.
  2. Fügen Sie die folgende deny-configuration Anweisung hinzu.

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:

  1. Legen Sie die Anmeldeklassenberechtigungen des Benutzers auf allfest.

  2. Fügen Sie die folgende deny-configuration Anweisung hinzu.

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:

  1. Legen Sie die Anmeldeklassenberechtigungen des Benutzers auf allfest.

  2. Fügen Sie die folgende deny-configuration Anweisung hinzu:

Die folgenden Beispiele zeigen, wie Sie mit der and-Anweisung allow-configurationdeny-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:

  1. Legen Sie die Anmeldeklassenberechtigungen des Benutzers auf configurefest.

  2. Fügen Sie die folgende allow-configuration Anweisung hinzu:

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:

  1. Legen Sie die Anmeldeklassenberechtigungen des Benutzers auf allfest.

  2. Fügen Sie die folgende deny-configuration Anweisung hinzu.

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:

  1. Fügen Sie die Anweisung ein, und verweigern Sie explizit deny-configuration-regexps den Zugriff auf Konfigurationshierarchien.

    Beispiele:

  2. 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.

    Beispiele:

  3. Aktivieren Sie die additive Logik für die allow-configuration-regexps und deny-configuration-regexps reguläre Ausdrücke.

  4. Weisen Sie die Anmeldeklasse einem oder mehreren Benutzern zu.

  5. 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 der deny-configuration-regexps Anweisung angegebenen Hierarchien.

HINWEIS:

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-1z. B. , CUST-VRF-25, CUST-VRF-100usw. Das Beispiel enthält auch einen regulären Ausdruck, der die Konfiguration von Routinginstanzen verhindert.

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.

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:

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.

Verifizierung

So überprüfen Sie, ob Sie die Zugriffsrechte richtig festgelegt haben:

  1. Konfigurieren Sie eine Anmeldeklasse, und führen Sie einen Commit für die Änderungen aus.

  2. Weisen Sie die Anmeldeklasse einer username.

  3. Melden Sie sich als zugewiesene username mit der neuen login-Klasse an.

  4. 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.

Abbildung 1: TopologieTopologie

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-commandsallow-commandsand-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 auf set Befehle.

  • Class3– Definiert die Zugriffsrechte für den Benutzer mit den allow-commands Anweisungen "und deny-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 die edit Befehle und configure 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

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

Konfigurieren der Authentifizierungsparameter für Router R1

Schritt-für-Schritt-Anleitung

So konfigurieren Sie die Router R1-Authentifizierung:

  1. 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.

  2. Konfigurieren Sie den TACACS+-Server.

  3. Konfigurieren Sie den RADIUS-Server.

  4. Konfigurieren Sie R1-Abrechnungsparameter.

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:

  1. Konfigurieren Sie die Anmeldeklasse Class1, und weisen Sie Benutzerberechtigungen auf Operatorebene zu.

  2. Konfigurieren Sie den allow-commands regulären Ausdruck so, dass Benutzer in der Klasse das Gerät neu starten können.

  3. Konfigurieren Sie das Benutzerkonto für die Anmeldeklasse Class1.

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:

  1. Konfigurieren Sie die Class2-Anmeldeklasse, und weisen Sie Benutzerberechtigungen auf Operatorebene zu.

  2. Konfigurieren Sie den deny-commands regulären Ausdruck so, dass Benutzer in der Klasse keine Befehle ausführen set können.

  3. Konfigurieren Sie das Benutzerkonto für die Anmeldeklasse Class2.

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-commandsdeny-commands an:

  1. Konfigurieren Sie die Class3-Anmeldeklasse, und weisen Sie Berechtigungen auf Superuser-Ebene zu.

  2. Konfigurieren Sie den deny-commands regulären Ausdruck, um zu verhindern, dass Benutzer in der Klasse Befehle ausführen.

  3. Konfigurieren Sie den regulären Ausdruck so, dass Benutzer in den allow-commands Konfigurationsmodus wechseln können.

  4. Konfigurieren Sie das Benutzerkonto für die Class3-Anmeldeklasse.

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.

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

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.

Führen Sie den request system reboot Befehl im Betriebsmodus aus.

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 pingBefehlen , ssh, telnetund traceroute 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.

Überprüfen Sie an der CLI-Eingabeaufforderung die verfügbaren Befehle.

Führen Sie an der CLI-Eingabeaufforderung einen beliebigen set-Befehl aus.

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.

Wechseln Sie in den Konfigurationsmodus.

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.

Abbildung 2: TopologieTopologie

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-configurationAnweisungen , deny-configuration, allow-configuration-regexpsund deny-configuration-regexps definiert.

Der Zweck jeder Anmeldeklasse ist wie folgt:

  • Class1– Definiert die Zugriffsrechte für den Benutzer mit der allow-configurationdeny-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 umfassen configure die Benutzerberechtigungen den Konfigurationszugriff. Darüber hinaus erlaubt die allow-configuration Anweisung den Zugriff auf die Schnittstellenkonfiguration und verweigert deny-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-regexpsdeny-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

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

Konfigurieren der Authentifizierungsparameter für Router R1

Schritt-für-Schritt-Anleitung

So konfigurieren Sie die Router R1-Authentifizierung:

  1. 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.

  2. Konfigurieren Sie den TACACS+-Server.

  3. Konfigurieren Sie den RADIUS-Server.

  4. Konfigurieren Sie die R1-Abrechnungsparameter.

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-configurationdeny-configuration and-Anweisungen an:

  1. Konfigurieren Sie die Anmeldeklasse Class1 mit configure Berechtigungen.

  2. 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.

  3. Konfigurieren Sie den deny-configuration regulären Ausdruck so, dass der Zugriff auf alle Konfigurationshierarchien verweigert wird.

  4. Konfigurieren Sie das Benutzerkonto für die Anmeldeklasse Class1.

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-regexpsdeny-configuration-regexps and-Anweisungen an:

  1. Konfigurieren Sie die Class2-Anmeldeklasse, und weisen Sie Superuser-Berechtigungen (alle) zu.

  2. 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.

  3. 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.

  4. Konfigurieren Sie das Benutzerkonto für die Anmeldeklasse Class2.

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.

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.

Überprüfen Sie im Konfigurationsmodus die verfügbaren Konfigurationsberechtigungen.

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.

Greifen Sie im Konfigurationsmodus auf die system Konfigurationshierarchien und protocols zu.

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.

Release
Beschreibung
18.1
Ab Junos OS Version 18.1 werden die und-Anweisungen deny-commands-regexps für die allow-commands-regexps TACACS+-Autorisierung unterstützt.