Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Benutzerzugriffsrechte

Sie (der Systemadministrator) gewähren Benutzern Zugriff oder Berechtigungen für Befehle und Konfigurationshierarchieebenen und -anweisungen. Benutzer können nur diese Befehle ausführen und nur die Anweisungen anzeigen und konfigurieren, für die sie Zugriffsrechte haben. Sie können auch erweiterte reguläre Ausdrücke verwenden, um anzugeben, welche Betriebsmodusbefehle, Konfigurationsanweisungen und Hierarchien für Benutzer zulässig oder verweigert werden. Diese Praxis hindert unbefugte Benutzer daran, sensible Befehle auszuführen oder Anweisungen zu konfigurieren, die das Netzwerk beschädigen könnten.

Übersicht über Zugriffsberechtigungsstufen

Jede Cli-Befehls- und Konfigurationsaussage auf der obersten Ebene verfügt über eine zugehörige Zugriffsberechtigungsstufe. Benutzer können nur diese Befehle ausführen und nur die Anweisungen konfigurieren und anzeigen, für die sie Zugriffsrechte haben. Ein oder mehrere Berechtigungsflags definieren die Zugriffsrechte für jede Anmeldeklasse.

Für jede Anmeldeklasse können Sie auch die Verwendung von Betriebs- und Konfigurationsmodusbefehlen und Anweisungshierarchien explizit zulassen oder ablehnen, die andernfalls durch eine in der permissions Anweisung angegebene Berechtigungsstufe zulässig oder verweigert werden würden.

Berechtigungsflaggen der Anmeldeklasse

Sie verwenden Berechtigungsflags, um einem Benutzer Zugriff auf Betriebsmodusbefehle und Konfigurationshierarchieebenen und -anweisungen zu gewähren. Sie konfigurieren Berechtigungsflags für die Anmeldeklasse des Benutzers auf [edit system login class] Hierarchieebene. Wenn Sie ein bestimmtes Berechtigungs-Flag angeben, erhält der Benutzer Zugriff auf die Befehle sowie auf die Konfigurationshierarchieebenen und Anweisungen, die diesem Flag entsprechen. Um Zugriff auf alle Befehle und Konfigurationsanweisungen zu gewähren, verwenden Sie das Berechtigungs-Flag all .

HINWEIS:

Jeder aufgeführte Befehl repräsentiert diesen Befehl und alle Unterlizenzen mit diesem Befehl als Präfix. Jede aufgeführte Konfigurationsaussage stellt den Obersten der Konfigurationshierarchie dar, der dieses Flag Zugriff gewährt.

Die permissions Anweisung gibt eine oder mehrere der in Tabelle 1. Berechtigungs-Flags sind nicht kumulierbar. Für jede Klasse müssen Sie alle erforderlichen Berechtigungs-Flags auflisten, einschließlich view zum Anzeigen von Informationen und configure zum Eintritt in den Konfigurationsmodus. Zwei Arten von Berechtigungen steuern den Zugriff eines Benutzers auf die einzelnen Teile der Konfiguration:

  • Formular "Plain": Bietet schreibgeschützte Funktionen für diesen Berechtigungstyp. Ein Beispiel ist interface.

  • -control form: Bietet Lese- und Schreibfunktionen für diesen Berechtigungstyp. Ein Beispiel ist interface-control.

Für Berechtigungsflags, die Zugriff auf Konfigurationshierarchieebenen und -anweisungen gewähren, gewähren die einfachen Formular-Flags schreibgeschützte Berechtigungen für diese Konfiguration. Das Berechtigungs-Flag interface gewährt beispielsweise schreibgeschützten Zugriff auf die [edit interfaces] Hierarchieebene. Das -control Flag-Formular gewährt Lese-/Schreibzugriff auf diese Konfiguration. Das Flag gewährt beispielsweise interface-control Lese-/Schreibzugriff auf die [edit interfaces] Hierarchieebene.

Tabelle 1 listet die Berechtigungsflags der Anmeldeklasse auf, die Sie konfigurieren können, indem sie die permissions Anweisung auf Hierarchieebene [edit system login class class-name] einschl.

Die Berechtigungs-Flags gewähren eine bestimmte Reihe von Zugriffsrechten. Jedes Berechtigungsflaggen wird mit den Befehlen im Betriebs- oder Konfigurationsmodus und der Konfigurationshierarchieebenen und -anweisungen aufgeführt, auf die dieses Flag Zugriff gewährt.

Tabelle 1: Berechtigungsflaggen der Anmeldeklasse

Berechtigungsflagge

Beschreibung

access

Kann die Zugriffskonfiguration im Betriebs- oder Konfigurationsmodus anzeigen.

access-control

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

admin

Kann Benutzerkontoinformationen im Betriebs- oder Konfigurationsmodus anzeigen.

admin-control

Kann Benutzerkontoinformationen anzeigen und auf [edit system] Hierarchieebene 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 (mithilfe der clear Befehle) in verschiedenen Netzwerkdatenbanken speichert.

configure

Kann in den Konfigurationsmodus (mit dem configure Befehl) und Commit-Konfigurationen (mit dem commit Befehl) gehen.

control

Kann alle Vorgänge auf Steuerungsebene durchführen – alle Vorgänge, die mit den -control Berechtigungs-Flags konfiguriert sind.

field

Kann Befehle zum Debuggen von Felden anzeigen. Für Debugging-Unterstützung reserviert.

firewall

Kann die Firewall-Filterkonfiguration im Betriebs- oder Konfigurationsmodus anzeigen.

firewall-control

Kann Firewall-Filterinformationen auf [edit firewall] Hierarchieebene anzeigen und konfigurieren.

floppy

Kann von den Wechselmedien lesen und darauf schreiben.

flow-tap

Kann die Fluss-Tap-Konfiguration im Betriebs- oder Konfigurationsmodus anzeigen.

flow-tap-control

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

flow-tap-operation

Kann Datenstrom-Tap-Anforderungen an den Router oder Switch stellen. Ein DTCP-Client (Dynamic Tasking Control Protocol) muss beispielsweise über flow-tap-operation die Berechtigung verfügen, sich Junos OS als Administrator zu authentifizieren.

HINWEIS:

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

idp-profiler-operation

Kann Profiler-Daten anzeigen.

interface

Kann die Schnittstellenkonfiguration im Betriebs- und Konfigurationsmodus anzeigen.

interface-control

Kann Gehäuse, Class of Service (CoS), Gruppen, Weiterleitungsoptionen und Konfigurationsinformationen für Schnittstellen 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 der Superuser in der Shell (mit dem su root Befehl) und Anhalten und Neustart des Geräts (mit den request system Befehlen).

network

Kann mithilfe von , ssh, und traceroutetelnetBefehlen auf das pingNetzwerk zugreifen.

pgcp-session-mirroring

Kann die Sitzungsspiegelungskonfiguration pgcp anzeigen.

pgcp-session-mirroring-control

Kann die Konfiguration der Sitzungsspiegelung pgcp ändern.

reset

Kann Softwareprozesse mit dem restart Befehl neu starten.

rollback

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

routing

Kann allgemeine Routing-, Routing-Protokoll- und Routingrichtlinienkonfigurationsinformationen im Konfigurations- und Betriebsmodus anzeigen.

routing-control

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

secret

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

secret-control

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

security

Kann Sicherheitskonfigurationsinformationen im Betriebs- und Konfigurationsmodus anzeigen.

security-control

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

shell

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

snmp

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

snmp-control

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

system

Kann Informationen auf Systemebene im Betriebs- oder Konfigurationsmodus anzeigen.

system-control

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

trace

Kann Trace-Dateieinstellungen anzeigen und Trace-Dateieigenschaften konfigurieren.

trace-control

Kann Trace-Dateieinstellungen ändern und Trace-Dateieigenschaften konfigurieren.

view

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

view-configuration

Kann alle Konfigurationen mit Ausnahme von geheimnissen, Systemskripten und Ereignisoptionen anzeigen.

HINWEIS:

Nur Benutzer mit der maintenance Berechtigung können Commit-Skript-, Op-Skript- oder Ereignisskriptkonfiguration anzeigen.

Zulassen und Verweigern einzelner Befehle und Auszugshierarchien für Anmeldeklassen

Standardmäßig verfügen alle CLI-Befehle der obersten Ebene und Konfigurationshierarchieebenen über entsprechende Zugriffsberechtigungsstufen. Benutzer können nur diese Befehle ausführen und nur die Anweisungen anzeigen und konfigurieren, für die sie Zugriffsrechte haben. Für jede Anmeldeklasse können Sie die Verwendung von Betriebs- und Konfigurationsmodusbefehlen und Anweisungshierarchien explizit zulassen und ablehnen, die andernfalls durch eine in der permissions Anweisung angegebene Berechtigungsstufe zulässig oder verweigert werden würden.

Berechtigungs-Flags gewähren einem Benutzer Zugriff auf Betriebs- und Konfigurationsmodusbefehle sowie auf Konfigurationshierarchieebenen und -anweisungen. Indem Sie ein bestimmtes Berechtigungs-Flag für die Anmeldeklasse des Benutzers auf Hierarchieebene [edit system login class] angeben, gewähren Sie dem Benutzer Zugriff auf die entsprechenden Befehle und Konfigurationshierarchieebenen und -anweisungen. Um Zugriff auf alle Befehle und Konfigurationsanweisungen zu gewähren, verwenden Sie das Berechtigungs-Flag all .

Sie können die Verwendung von Befehlen und Anweisungen explizit zulassen oder ablehnen, indem Sie die allow-commands, deny-commands, , allow-configurationund deny-configuration Anweisungen für eine Anmeldeklasse konfigurieren. In den Anweisungen verwenden Sie erweiterte reguläre Ausdrücke, um zu definieren, welche Befehle und Anweisungen für Benutzer, die der Klasse zugewiesen sind, zulassen oder ablehnen.

Beispiel: Konfigurieren von Benutzerberechtigungen mit Zugriffsrechten

In diesem Beispiel werden die Benutzerberechtigungen für eine Anmeldeklasse konfiguriert. Sie konfigurieren Benutzerberechtigungen für eine Anmeldeklasse, um zu verhindern, dass Benutzer nicht autorisierte Netzwerkaktionen ausführen. Benutzer können nur diese Befehle ausführen und nur die Anweisungen anzeigen und ändern, für die sie Zugriffsrechte haben. Diese Einschränkung hindert unbefugte Benutzer daran, sensible Befehle oder Konfiguration von Anweisungen auszuführen, die das Netzwerk beschädigen könnten.

Anforderungen

Vor der Konfiguration dieses Beispiels ist keine spezielle Konfiguration erforderlich, die über die Geräteinitialisierung hinausgeht.

Überblick

Jedem CLI-Befehl der obersten Ebene und jeder Konfigurationsaussage ist eine Zugriffsberechtigungsstufe zugeordnet. Wenn Sie eine Anmeldeklasse konfigurieren, können Sie die Verwendung von Betriebsmodus- und Konfigurationsmodusbefehlen und Konfigurationsanweisungen explizit zulassen oder ablehnen. Benutzer können nur diese Befehle ausführen und nur die Anweisungen anzeigen und konfigurieren, für die sie Zugriffsrechte haben.

Sie definieren die Zugriffsrechte für jede Anmeldeklasse, indem Sie ein oder mehrere Berechtigungsflags in der permissions Anweisung angeben. Berechtigungs-Flags gewähren einem Benutzer Zugriff auf Befehle, Anweisungen und Hierarchien. Berechtigungs-Flags sind nicht kumulierbar. Für jede Anmeldeklasse müssen Sie alle erforderlichen Berechtigungs-Flags auflisten, einschließlich view der Anzeige von Informationen und configure zum Eintritt in den Konfigurationsmodus. Indem Sie ein bestimmtes Berechtigungs-Flag in der Anmeldeklasse des Benutzers angeben, gewähren Sie dem Benutzer Zugriff auf die entsprechenden Befehle, Anweisungen und Hierarchien. Um Zugriff auf alle Befehle und Konfigurationsanweisungen zu gewähren, verwenden Sie das Berechtigungs-Flag all . Die Berechtigungsflaggen bieten schreibgeschützte ("einfaches" Formular) und Lese- und Schreibfunktionen (Formular, das mit -control endet) für einen Berechtigungstyp.

HINWEIS:

Die all Berechtigungsbits für die Anmeldeklasse haben Vorrang vor erweiterten regulären Ausdrücken, wenn ein Benutzer einen rollback Befehl mit aktivierter rollback Berechtigungsflagge aus gibt.

Um Benutzerzugriffsberechtigungen für eine Anmeldeklasse zu konfigurieren, fügen Sie die permissions Anweisung auf Hierarchieebene [edit system login class class-name] und gefolgt von den Berechtigungs-Flags ein. Konfigurieren Sie mehrere Berechtigungen als durch Leerzeichen getrennte Liste, die in eckigen Klammern eingeschlossen ist:

Tipp:

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

Konfiguration

In diesem Beispiel wird die snmp-admin Anmeldeklasse konfiguriert. Benutzer in dieser Anmeldeklasse können nur SNMP-Parameter konfigurieren und anzeigen.

Konfigurieren von Benutzerberechtigungen mit Zugriffsrechten

Schritt-für-Schritt-Verfahren

So konfigurieren Sie Zugriffsrechte für die Anmeldeklasse:

  1. Konfigurieren Sie die snmp-admin Anmeldeklasse mit den configure, snmpund snmp-control Berechtigungsflaggen.

    Die konfigurierten Berechtigungs-Flags bieten sowohl Lese- (SNMP) als auch Snmp-Schreibfunktion (SNMP-Control), und dies ist die einzige zulässige Zugriffsrechte für diese Anmeldeklasse. Alle anderen Zugriffsrechte werden verweigert.

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

Ergebnisse

Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie den show system login Befehl eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Gehen Sie commit nach der Konfiguration des Geräts in den Konfigurationsmodus.

Überprüfung

Melden Sie sich mit einem Benutzernamen an, der der neuen Anmeldeklasse zugewiesen ist, und bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.

SNMP-Konfiguration überprüfen

Zweck

Stellen Sie sicher, dass ein Benutzer in der snmp-admin Anmeldeklasse SNMP konfigurieren kann.

Aktion

Konfigurieren Sie im Konfigurationsmodus SNMP-Anweisungen auf [edit snmp] Hierarchieebene.

Bedeutung

Der Benutzer in der snmp-admin Anmeldeklasse kann SNMP-Parameter konfigurieren. Der Benutzer kann diese Parameter konfigurieren, da die für diese Klasse angegebenen Berechtigungs-Flags sowohl SNMP -Berechtigungsbits (Lesefunktionen) als auch snmp-control (Lese- und Schreibfunktionen) enthalten.

Überprüfen der Nicht-SNMP-Konfiguration

Zweck

Stellen Sie sicher, dass ein Benutzer in der snmp-admin Anmeldeklasse Nicht-SNMP-Konfigurationsanweisungen ändern kann.

Aktion

Versuchen Sie im Konfigurationsmodus, jede Nicht-SNMP-Anweisung zu konfigurieren, z. B. eine Anweisung in der interfaces Hierarchie.

Bedeutung

Der Benutzer in der snmp-admin Anmeldeklasse ist nicht in der Lage, die [edit interfaces] Hierarchie zu konfigurieren, da die für diese Klasse angegebenen Berechtigungs-Flags dies nicht zulassen. In diesem Fall gibt die CLI eine Fehlermeldung aus.

Reguläre Ausdrücke zum Zulassen und Ablehnen von Befehlen im Betriebsmodus, Konfigurationsanweisungen und Hierarchien

Dieses Thema enthält die folgenden Abschnitte:

Grundlegendes zu Deny- und Zulassen-Aussagen

Jeder Cli-Befehls- und Konfigurations-Anweisungshierarchie auf der obersten Ebene ist eine Zugriffsberechtigungsstufe zugeordnet. Jede Anmeldeklasse kann explizit die Verwendung von Betriebs- und Konfigurationsmodusbefehlen sowie Konfigurationshierarchien und Anweisungen zulassen oder ablehnen, die andernfalls durch eine Berechtigungsebene zulässig oder verweigert werden würden. Benutzer können nur diese Befehle ausführen und nur die Anweisungen anzeigen und konfigurieren, für die sie Zugriffsrechte haben.

Die Zugriffsrechte für jede Anmeldeklasse werden durch ein oder mehrere Berechtigungsflags definiert, die in der permissions Anweisung auf Hierarchieebene [edit system login class class-name] angegeben sind. Darüber hinaus können Sie die Verwendung bestimmter Befehle und Konfigurationshierarchien zulassen oder ablehnen, indem Sie erweiterte reguläre Ausdrücke definieren. Sie können die regulären Ausdrücke angeben, indem Sie die folgenden Anweisungen für eine Anmeldeklasse konfigurieren:

  • allow-commands und deny-commands— Erlauben oder verweigern Sie den Zugriff auf Betriebs- und Konfigurationsmodusbefehle.

  • allow-configuration und deny-configuration— Erlauben oder verweigern Sie den Zugriff auf bestimmte Konfigurationshierarchien.

    HINWEIS:

    Diese Aussagen führen langsamere Übereinstimmungen durch und bieten mehr Flexibilität, insbesondere beim Wildcard-Matching. Es kann jedoch sehr lange dauern, alle möglichen Aussagen zu bewerten, wenn eine große Anzahl von regulären Ausdrücken mit vollem Pfad oder Platzhalterausdrücken konfiguriert ist, was sich möglicherweise negativ auf die Leistung auswirkt.

  • allow-commands-regexps und deny-commands-regexps— Erlauben oder verweigern Sie den Zugriff auf bestimmte Befehle mithilfe von Zeichenfolgen regulärer Ausdrücke.

  • allow-configuration-regexps und deny-configuration-regexps— Erlauben oder verweigern Sie den Zugriff auf bestimmte Konfigurationshierarchien mithilfe von Zeichenfolgen regulärer Ausdrücke.

HINWEIS:

Wenn Ihre vorhandenen Konfigurationen die allow/deny-commands oder allow/deny-configuration Anweisungen verwenden, führen die Verwendung derselben Konfigurationsoptionen mit den allow/deny-commands-regexps oder allow/deny-configuration-regexps Anweisungen möglicherweise nicht zu den gleichen Ergebnissen. Die Such- und Abgleichmethoden unterscheiden sich in den beiden Formen dieser Aussagen.

Das explizite Zulassen von Befehlen und Konfigurationsanweisungenhierarchien mithilfe der allow/deny-* Anweisungen fügt den Berechtigungen hinzu, die in der permissions Anweisung bereits definiert werden. Ebenso entfernt das explizite Ablehnen von Befehlen und Konfigurationsanweisungenhierarchien mithilfe der Anweisungen berechtigungen allow/deny-* , die bereits in der permissions Anweisung definiert werden.

In der folgenden Konfiguration ermöglicht die configure Berechtigung beispielsweise Benutzern in der Anmeldeklasse den Eintritt in den Konfigurationsmodus. Darüber hinaus ermöglicht der allow-configuration Ausdruck Benutzern, die Konfiguration auf [edit system services] Hierarchieebene zu ändern und zu bestätigen.

Ebenso kann der Benutzer der Anmeldeklasse in der folgenden Konfiguration alle Vorgänge ausführen, die das all Berechtigungs-Flag zulässt, es sei denn, der Benutzer kann die Konfiguration nicht auf [edit system services] Hierarchieebene anzeigen oder ändern:

Grundlegendes zur Syntax der Anweisung Zulassen und Ablehnen

Sie können eine allow/deny-* Anweisung nur einmal in jeder Anmeldeklasse konfigurieren. Wenn Sie eine Anweisung konfigurieren,

  • Sie können so viele reguläre Ausdrücke konfigurieren, wie sie benötigt werden.

  • Bei regulären Ausdrücken wird die Groß- und Kleinschreibung nicht berücksichtigt.

Die allow/deny-commands Aussagen schließen sich gegenseitig mit den allow/deny-commands-regexps Aussagen aus, und die allow/deny-configuration Aussagen schließen sich gegenseitig mit den allow/deny-configuration-regexps Aussagen aus. Sie können beispielsweise nicht beides allow-configuration und allow-configuration-regexps in derselben Anmeldeklasse konfigurieren.

Um Zugriffsberechtigungen für Befehle zu definieren, geben Sie erweiterte reguläre Ausdrücke mithilfe von und allow-commandsdeny-commands Anweisungen an. Schließen Sie jeden vollständigen eigenständigen Ausdruck in Klammern ( ) ein und verwenden Sie das Pipe-Symbol (|), um die Ausdrücke zu trennen. Verwenden Sie keine Leerzeichen zwischen regulären Ausdrücken, die mit dem Pipe-Symbol verbunden sind. Der vollständige Ausdruck ist in doppelte Anführungszeichen eingeschlossen.

Zum Beispiel:

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

Um Zugriffsberechtigungen für Teile der Konfigurationshierarchie zu definieren, geben Sie erweiterte reguläre Ausdrücke in der und deny-configuration den allow-configuration Anweisungen an. Schließen Sie die vollständigen Pfade in Klammern ( ) ein und verwenden Sie das Pipe -Symbol (|), um die Ausdrücke zu trennen. Verwenden Sie keine Leerzeichen zwischen regulären Ausdrücken, die mit dem Pipe-Symbol verbunden sind. Der vollständige Ausdruck ist in doppelte Anführungszeichen eingeschlossen.

Zum Beispiel:

Wenn Sie erweiterte reguläre Ausdrücke mit dem oder allow/deny-configuration-regexps Anweisungen allow/deny-commands-regexps angeben, schließen Sie jeden Ausdruck in Anführungszeichen (" ") ein und trennen Sie die Ausdrücke mithilfe eines Leerzeichens. Schließen Sie mehrere Ausdrücke in eckige Klammern [ ]. Zum Beispiel:

Modifizierer wie set, logund count werden innerhalb der Zeichenfolge mit regulären Ausdrücken, die abgeglichen werden soll, nicht unterstützt. Wenn Sie einen Modifizierer verwenden, wird nichts abgeglichen.

Korrekte Konfiguration:

Falsche Konfiguration:

Grundlegendes zur Rangfolge und Demy-Anweisung "Allow and Deny Statement" (Rangfolge und Abgleich)

Standardmäßig haben die allow-commands ausdrücken und allow-configuration die regulären Ausdrücke Vorrang vor den Ausdrücken deny-commandsdeny-configuration . Wenn Sie also denselben Befehl für die allow-commands Und-Anweisungen deny-commands konfigurieren, hat der Allow-Vorgang Vorrang vor dem Vorgang deny. Ebenso hat der Allow-Vorgang Vorrang vor dem Vorgang ablehnen, wenn Sie dieselbe Anweisung sowohl für die allow-configurationdeny-configuration als auch für die Anweisungen konfigurieren.

Die folgende Konfiguration ermöglicht es beispielsweise einem Benutzer in der test Anmeldeklasse, Software mit dem request system software add Befehl zu installieren, obwohl die deny-commands Anweisung den gleichen Befehl enthält:

Ebenso ermöglicht die folgende Konfiguration einem Benutzer im Anmeldeklassentest, test die [edit system services] Konfigurationshierarchie anzuzeigen und zu ändern, obwohl die deny-configuration Anweisung dieselbe Hierarchie enthält:

Wenn die allow-commands Anweisungen deny-commands zwei verschiedene Varianten eines Befehls haben, wird immer die längste Übereinstimmung ausgeführt. Die folgende Konfiguration ermöglicht es einem Benutzer in der test Anmeldeklasse, den commit synchronize Befehl auszuführen, aber nicht den commit Befehl. Dies liegt daran, dass commit synchronize die längste Übereinstimmung zwischen commit und und commit synchronize, und sie für angegeben ist.allow-commands

Die folgende Konfiguration ermöglicht es einem Benutzer in der test Anmeldeklasse, den commit Befehl auszuführen, aber nicht den commit synchronize Befehl. Dies liegt daran, dass commit synchronize die längste Übereinstimmung zwischen commit und und commit synchronize, und sie für angegeben ist.deny-commands

Im Gegensatz zu den anderen Anweisungen besteht das Standardverhalten für die *-regexps Anweisungen darin, dass die und deny-configuration-regexps die deny-commands-regexps regulären Ausdrücke Vorrang vor ausdrücken allow-commands-regexps habenallow-configuration-regexps. Sie können die regex-additive-logic Anweisung auf Hierarchieebene [edit system] konfigurieren, um zu erzwingen, dass die allow-configuration-regexps regulären Ausdrücke Vorrang vor den deny-configuration-regexps Anweisungen haben. Wenn Sie die Anweisung konfigurieren, können Sie Konfigurationshierarchien auf einer höheren Ebene verweigern und dem Benutzer dann nur den Zugriff auf bestimmte Unterhierarchien gewähren.

Grundlegendes zu Deny- und Allowy Statement-Regeln

Der allow/deny-commands, , allow/deny-configuration, , allow/deny-commands-regexpsund allow/deny-configuration-regexps die Anweisungen haben Vorrang vor den Berechtigungen der Anmeldeklasse. Wenn Sie diese Anweisungen konfigurieren, gelten die folgenden Regeln:

  • Reguläre Ausdrücke allow-commands und deny-commands Anweisungen können auch die commitBefehle , load, , rollback, save, statusund update Befehle umfassen.

  • Die all Berechtigungsbits für die Anmeldeklasse haben Vorrang vor erweiterten regulären Ausdrücken, wenn ein Benutzer den rollback Befehl mit aktivierter rollback Berechtigungsflagge aus gibt.

  • Benutzer können den load override Befehl nicht ausstellen, wenn sie einen erweiterten regulären Ausdruck angeben. Benutzer können nur die mergeBefehle und replacepatch Konfigurationsbefehle ausstellen.

  • Beim Ablehnen von regulären Ausdrücken können Sie das Wildcard-Zeichen * verwenden. Sie müssen ihn jedoch als Teil eines regulären Ausdrucks verwenden. Sie können den einzigen Ausdruck nicht verwenden[ * ].[ .* ] Darüber hinaus können Sie die allow-configuration Anweisung nicht mit einem Ausdruck wie (interfaces (description (|.*)), konfigurieren, da dieser auf allow-configuration .*.

Unterschiede für die *-regexps-Aussagen verstehen

In diesem Abschnitt werden die Unterschiede zwischen den allow/deny-configuration Aussagen und den allow/deny-configuration-regexps Aussagen beschrieben.

Die allow/deny-configuration-regexps Anweisungen teilen den regulären Ausdruck in Token auf und gleichen jedes Stück mit jedem Teil des vollständigen Pfads der angegebenen Konfiguration, während die allow/deny-configuration Anweisungen mit der vollständigen Zeichenfolge übereinstimmen. Für allow/deny-configuration-regexps Anweisungen konfigurieren Sie eine Reihe von Zeichenfolgen, in denen jede Zeichenfolge ein regulärer Ausdruck ist, mit Leerzeichen zwischen den Begriffen der Zeichenfolge. Diese Syntax ermöglicht eine sehr schnelle Übereinstimmung, bietet jedoch weniger Flexibilität. Zum Festlegen von Platzhalterausdrücken müssen Sie Platzhalter für jedes Token der Zeichenfolge mit Leerzeichen, die Sie abgleichen möchten, einrichten, was die Verwendung von Platzhalterausdrücken für diese Anweisungen erschwert.

Zum Beispiel:

  • Regulärer Ausdruck, der ein Token unter Verwendung von allow-configuration-regexps abgleicht

    In diesem Beispiel wird options der einzige Ausdruck mit dem ersten Token der Anweisung abgeglichen.

    Die vorhergehende Konfiguration entspricht den folgenden Anweisungen:

    • Festlegen der Bedingung condition für Richtlinienoptionen dynamic-db

    • Festlegen von Routing-Optionen statische Route static-route Next-Hop next-hop

    • Setzen Sie ereignisbasierte Optionen , Zeitintervalle für ereignisgeneriere event Ereignisse seconds

    Die vorhergehende Konfiguration entspricht nicht den folgenden Anweisungen:

    • System-Host-Name-Host-Optionen

    • Schnittstellenbeschreibungsoptioneninterface-name

  • Regulärer Ausdruck, der drei Token unter Verwendung von allow-configuration-regexps abgleicht

    In diesem Beispiel wird ssh der einzige Ausdruck mit dem dritten Token der Anweisung abgeglichen.

    Im vorhergehenden Beispiel umfassen .*die drei Token , .*und .*ssh.

    Die vorhergehende Konfiguration entspricht den folgenden Anweisungen:

    • Host-Name des Systems hostname-ssh

    • Systemservices ssh

    • Systemservices outbound-ssh

    Die vorhergehende Konfiguration entspricht nicht der folgenden Anweisung:

    • Schnittstellenbeschreibung interface-namessh

Es ist einfacher, die Anweisung zur Einschränkung des deny-configuration Konfigurationszugriffs zu verwenden, als die deny-configuration-regexps Anweisung zu verwenden. Tabelle 2 Veranschaulicht die Verwendung sowohl der Anweisungen als deny-configuration-regexps auch der deny-configuration Anweisungen in verschiedenen Konfigurationen, um dasselbe Ergebnis der Zugriffsbeschränkung auf eine bestimmte Konfiguration zu erzielen.

Tabelle 2: Einschränkung des Konfigurationszugriffs mithilfe von "deny-configuration and Deny-configuration-regexps"-Anweisungen

Konfiguration verweigert

Mit: deny-configuration

Mit: 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 Konfigurationsaussage wird abgelehnt:

  • Systemservices 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:

  • Host-Name des Systems hostname-ssh

  • Systemservices ssh

  • Systemservices outbound-ssh

  • Sicherheit ssh-bekannter 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 Unklarheit, die beim Kombinieren von Ausdrücken in den allow/deny-configuration Anweisungen vorhanden war.

Verwenden von regulären Ausdrücken auf Remote-Autorisierungsservern

Sie können erweiterte reguläre Ausdrücke verwenden, um anzugeben, welche Betriebs- und Konfigurationsmodusbefehle sowie Konfigurationsanweisungen und Hierarchien für bestimmte Benutzer zulässig oder verweigert werden. Sie geben diese regulären Ausdrücke lokal in der allow/deny-commands, und allow/deny-commands-regexpsallow/deny-configurationallow/deny-configuration-regexps Anweisungen auf [edit system login class class-name] Hierarchieebene an. Sie geben diese regulären Ausdrücke remote an, indem Sie in der Konfiguration des Autorisierungsservers anbieterspezifische TACACS+ oder RADIUS-Attribute von Juniper Networks angeben. Wenn Sie Autorisierungsparameter sowohl lokal als auch remote konfigurieren, führt das Gerät die regulären Ausdrücke, die während der TACACS+- oder RADIUS-Autorisierung empfangen werden, mit beliebigen regulären Ausdrücken zusammen, die auf dem lokalen Gerät definiert sind.

HINWEIS:

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

Wenn Sie mehrere reguläre Ausdrücke in einer lokalen Konfiguration mithilfe von allow-commands, , deny-commandsoder allow-configurationdeny-configuration Anweisungen angeben, konfigurieren Sie reguläre Ausdrücke in Klammern und trennen sie mithilfe des Pipe-Symbols. Sie schließen den vollständigen Ausdruck in doppelte Anführungszeichen ein. Sie können beispielsweise mehrere allow-commands Parameter mit der folgenden Syntax angeben:

Der RADIUS-Autorisierungsserver verwendet die folgenden Attribute und die folgende Syntax:

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

Wenn Sie mehrere reguläre Ausdrücke in einer lokalen Konfiguration mit dem allow-commands-regexps, , deny-commands-regexps, allow-configuration-regexpsoder deny-configuration-regexps Anweisungen angeben, konfigurieren Sie reguläre Ausdrücke in doppelten Anführungszeichen und trennen sie mit dem Leerzeichenoperator. Sie schließen den vollständigen Ausdruck in eckige Klammern ein. Sie können z. B. mehrere Allow-Commands-Parameter mit der folgenden Syntax angeben:

Der RADIUS-Autorisierungsserver verwendet die folgenden Attribute und die folgende Syntax:

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

RADIUS- und TACACS+-Server unterstützen außerdem eine vereinfachte Syntax, bei der Sie jeden einzelnen Ausdruck in einer separaten Zeile angeben. Die vereinfachte Syntax des RADIUS-Servers lautet beispielsweise:

Ebenso lautet die vereinfachte TACACS+-Serversyntax:

Tabelle 3 Unterscheidet die lokale Autorisierungskonfiguration und die TACACS+-Serverautorisierungskonfiguration mithilfe von regulären Ausdrücken.

Tabelle 3: Beispielkonfiguration für lokale und Remote-Autorisierung 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 per Fernzugriff, indem Sie die folgenden drei Befehle ausstellen: xml-mode, netconfund need-trailer.

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

Angeben regulärer Ausdrücke

WARNUNG:

Achten Sie beim Angeben regulärer Ausdrücke für Befehle und Konfigurationsanweisungen auf die folgenden Beispiele. Ein regulärer Ausdruck mit ungültiger Syntax liefert möglicherweise nicht die gewünschten Ergebnisse, selbst wenn die Konfiguration ohne Fehler festgelegt wird.

Sie sollten reguläre Ausdrücke für Befehle und Konfigurationsanweisungen auf die gleiche Weise angeben wie die Ausführung des vollständigen Befehls oder der vollständigen Anweisung. Tabelle 4 listet die regulären Ausdrücke für die Konfiguration von Zugriffsrechten für die [edit interfaces] Hierarchien und [edit vlans] Anweisungshierarchien auf.

Tabelle 4: Angeben regulärer Ausdrücke

Anweisung

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 Aussage ist von sich aus unvollständig und erfordert die Möglichkeit, unit die Anweisung auszuführen.

Daher muss der reguläre Ausdruck, der für das Ablehnen der set interfaces Konfiguration erforderlich ist, die gesamte ausführbare Zeichenfolge mit dem .* Operator anstelle der 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 Anweisung. In diesem Beispiel bezeichnet er jeden Schnittstellennamen mit einem beliebigen Einheitswert.

  • Wenn angegeben wird, dass nur die deny-configuration "interfaces .*" Anweisung falsch ist und der Zugriff auf die Schnittstellenkonfiguration für die angegebene Anmeldeklasse nicht verweigert wird.

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

    [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, in den angegebenen regulären Ausdruck einbezogen werden. Wenn nur eine member Zeichenfolge enthalten sein soll, 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 von sich aus unvollständig und erfordert die Möglichkeit, die vlan-id Anweisung auszuführen.

Daher muss der reguläre Ausdruck, der für die Genehmigung der set vlans Konfiguration erforderlich ist, die gesamte ausführbare Zeichenfolge mit dem .* Operator anstelle der 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 Anweisung. In diesem Beispiel bezeichnet er jeden VLAN-Namen mit einer beliebigen VLAN-ID.

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

    [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 regulärer Ausdrücke

Tabelle 5 listet Operatoren mit regulären Ausdrücken auf, die Sie zum Zulassen oder Ablehnen von Betriebs- und Konfigurationsmodi verwenden können.

Reguläre Befehlsausdrücke implementieren die erweiterten (modernen) regulären Ausdrücke, wie in POSIX 1003.2 definiert.

Tabelle 5: Operatoren mit häufigen regulären Ausdrücken

Betreiber

Match

Beispiel

|

Einer von zwei oder mehr Begriffen, die durch die Pipe getrennt sind. Jeder Begriff muss ein vollständiger eigenständiger Ausdruck sein, der in Klammern ( ) eingeschlossen ist, ohne Leerzeichen zwischen der Pipe und den angrenzenden Klammern.

[edit system login class test]
user@host# set permissions configure
user@host# set allow-commands "(ping)|(traceroute)|(show system alarms)|(show system software)"
user@host# set deny-configuration "(access)|(access-profile)|(accounting-options)|(applications)|(apply-groups)|(bridge-domains)|(chassis)|(class-of-service)"

In der vorhergehenden Konfiguration haben die Benutzer, die der Testanmeldungsklasse zugewiesen sind, den Betriebsmodus-Zugriff nur auf die in der allow-commands Anweisung angegebenen Befehle. Sie haben auch Zugriff auf den Konfigurationsmodus, mit Ausnahme der in der deny-configuration Anweisung angegebenen Hierarchieebenen.

^

Zu Beginn eines Ausdrucks, der verwendet wird, um zu bezeichnen, wo der Befehl beginnt, wo es unklar sein kann.

[edit system login class test]
user@host# set permissions interface
user@host# set permissions interface-control
user@host# set allow-commands "(^show) (log|interfaces|policer))|(^monitor)"

Mit der vorherigen Konfiguration haben die Benutzer, die der Testanmeldungsklasse zugewiesen sind, Zugriff auf die Anzeige und Konfiguration der Schnittstellenkonfiguration. Die allow-commands Anweisung gewährt Zugriff auf Befehle, die mit den show Schlüsselwörtern beginnen monitor .

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

$

Zeichen am Ende eines Befehls. Wird verwendet, um einen Befehl anzugeben, der bis zu diesem Punkt genau abgeglichen werden muss.

[edit system login class test]
user@host# set permissions interface
user@host# set allow-commands "(show interfaces$)"

Mit der vorherigen Konfiguration können die Benutzer, die der Testanmeldungsklasse zugewiesen sind, die Schnittstellenkonfiguration im Konfigurationsmodus anzeigen. Die Benutzer können die Schnittstellenkonfiguration auch mit dem show configuration Betriebsmodus-Befehl 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.

[ ]

Bereich von Buchstaben oder Ziffern. Um den Anfang und das Ende eines Bereichs zu trennen, verwenden Sie einen Bindestrich ( - ).

[edit system login class test]
user@host# set permissions clear
user@host# set permissions configure
user@host# set permissions network
user@host# set permissions trace
user@host# set permissions view
user@host# set allow-configuration-regexps [ "interfaces [gx]e-.* unit [0-9]* description .*" ]

In der vorherigen Konfiguration verfügen die Benutzer, die der Testanmeldungsklasse zugewiesen sind, über Benutzerberechtigungen auf Betreiberebene. Diese Benutzer haben auch Zugriff auf Die Konfiguration von Schnittstellen innerhalb des angegebenen Bereichs von Schnittstellenname und Einheitennummer (0 bis 9).

( )

Eine Gruppe von Befehlen, die einen vollständigen, eigenständigen Ausdruck anzeigen, der ausgewertet werden soll. Das Ergebnis wird dann als Teil des Gesamtausdrucks ausgewertet. Wie erläutert, müssen Klammern zusammen mit Leitungsbetreibern verwendet werden.

[edit system login class test]
user@host# set permissions all
user@host# set allow-commands "(clear)|(configure)"
user@host# deny-commands "(mtrace)|(start)|(delete)"

Mit der obigen Konfiguration haben Benutzer, die der Testanmeldungsklasse zugewiesen sind, Berechtigungen auf Superbenutzerebene und Zugriff auf die in der allow-commands Anweisung angegebenen Befehle.

*

Keine oder mehr Begriffe.

[edit system login class test]
user@host# set permissions configure
user@host# set deny-configuration "(system login class m*)"

Mit der obigen Konfiguration wird Benutzern, die der Testanmeldungsklasse zugewiesen sind, deren Anmeldename beginnt m , 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 Testanmeldungsklasse zugewiesen sind, deren Anmeldename beginnt m , der Konfigurationszugriff verweigert.

.

Alle Zeichen mit Ausnahme von Leerzeichen ".

[edit system login class test]
user@host# set permissions configure
user@host# set deny-configuration "(system login class m.)"

Mit der obigen Konfiguration wird Benutzern, die der Testanmeldungsklasse zugewiesen sind, deren Anmeldename beginnt m , der Konfigurationszugriff verweigert.

.*

Alles vom angegebenen Punkt an.

[edit system login class test]
user@host# set permissions configure
user@host# set deny-configuration "(system login class m .*)"

Mit der obigen Konfiguration wird Benutzern, die der Testanmeldungsklasse zugewiesen sind, deren Anmeldename beginnt m , der Konfigurationszugriff verweigert.

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

HINWEIS:
  • Der *, +und . der Betrieb können durch die Verwendung .*von .

  • Die deny-commands .* Anweisungen verweigern deny-configuration .* den Zugriff auf alle Befehle im Betriebsmodus 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 in zwei Konfigurationshierarchien zuzulassen –[edit system ntp server] und [edit protocols rip]– als Beispiel für das Angeben 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 Anweisungshierarchien und [edit protocols rip] -[edit system ntp server]hierarchien validiert.

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

Anweisungshierarchie

Reguläre Ausdrücke

Zulässige Konfiguration

Konfiguration verweigert

[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

  • Bevorzugen

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

  • key

  • Bevorzugen

Bevorzugen

[edit system login class test]
set permissions configure
set allow-configuration-regexps [ "system ntp server .*" "system ntp server .* prefer" ];
set deny-configuration-regexps [ "system ntp server .* key .*" "system ntp server .* version .*" ]
  • Server-IP

  • Server-IP und bevorzugen

  • key

  • version

[edit protocols rip]

     

Nachrichtengröße message-size

[edit system login class test]
set permissions configure
set allow-configuration-regexps "protocols rip message-size .*"
set deny-configuration-regexps [ "protocols rip metric-in .*" "protocols rip route-timeout .*" "protocols rip update-interval .*" ]
  • Nachrichtengröße

  • metric-in

  • Route-Timeout

  • Update-Intervall

metric-in metric-in

[edit system login class test]
set permissions configure
set  allow-configuration-regexps "protocols rip metric-in .*"
set  deny-configuration-regexps [ "protocols rip message-size .*" "protocols rip route-timeout .*" "protocols rip update-interval .*" ]
  • metric-in

  • Nachrichtengröße

  • 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

  • Nachrichtengröße

  • metric-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

  • Nachrichtengröße

  • metric-in

  • Route-Timeout

So definieren Sie Zugriffsberechtigungen mit Anweisungen zur Zulassen-Konfiguration und Konfiguration verweigern

Sie können Zugriffsberechtigungen für Konfigurationsanweisungenhierarchien definieren, indem Sie eine Kombination der folgenden Arten von Anweisungen verwenden:

  • Berechtigungs-Flags

  • allow-configuration und deny-configuration Aussagen

Die Berechtigungs-Flags definieren die größeren Grenzen, auf die eine Person oder Anmeldeklasse zugreifen und kontrollieren kann. Die allow-configuration Anweisungen enthalten deny-configuration einen oder mehrere reguläre Ausdrücke, die bestimmte Konfigurationshierarchien und -anweisungen zulassen oder ablehnen. deny-configuration Die allow-configuration Anweisungen haben Vorrang vor Berechtigungs-Flags und geben dem Administrator eine detailliertere Kontrolle darüber, welche Hierarchien und Anweisungen der Benutzer anzeigen und konfigurieren kann.

In diesem Thema wird erläutert, wie Sie Zugriffsrechte mithilfe allow-configuration und deny-configuration Anweisungen definieren, indem Sie Beispiele für Konfigurationen von Anmeldeklassen sehen, die diese Anweisungen verwenden. Die Beispiele 1 bis 3 erstellen Anmeldeklassen, die Benutzern den Zugriff auf alle Befehle und Anweisungen mit Ausnahme der in der deny-configuration Anweisung definierten ermöglichen.

Beachten Sie, dass Berechtigungsbit und Berechtigungsflagge austauschbar verwendet werden.

Beispiel 1

So erstellen Sie eine Anmeldeklasse, die es dem Benutzer ermöglicht, alle Befehle auszuführen und alles außer Telnet-Parametern zu konfigurieren:

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

Beispiel 2

So erstellen Sie eine Anmeldeklasse, die es dem Benutzer ermöglicht, alle Befehle auszuführen und alle außer Anweisungen innerhalb einer Anmeldeklasse zu konfigurieren, deren Name mit "m" beginnt:

  1. Legen Sie die Anmeldeklassenberechtigungen des Benutzers auf all.

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

Beispiel 3

So erstellen Sie eine Anmeldeklasse, die es dem Benutzer ermöglicht, alle Befehle auszuführen und alles mit Ausnahme der Hierarchieebene oder [edit system services] der [edit system login class] Hierarchieebene zu konfigurieren:

  1. Legen Sie die Anmeldeklassenberechtigungen des Benutzers auf all.

  2. Fügen Sie die folgende deny-configuration Aussage bei:

Die folgenden Beispiele zeigen, wie Sie die anweisungen und deny-configuration die allow-configuration Anweisungen verwenden, um die Berechtigungen für die [edit system services] Hierarchieebene zueinander zu bestimmen.

Beispiel 4

So erstellen Sie eine Anmeldeklasse, die es dem Benutzer ermöglicht, vollständige Konfigurationsberechtigungen nur auf [edit system services] Hierarchieebene zu haben:

  1. Legen Sie die Anmeldeklassenberechtigungen des Benutzers auf configure.

  2. Fügen Sie die folgende allow-configuration Aussage bei:

Beispiel 5

So erstellen Sie eine Anmeldeklasse, die dem Benutzer vollständige Berechtigungen für alle Befehle und alle Konfigurationshierarchien außer der [edit system services] Hierarchieebene ermöglicht:

  1. Legen Sie die Anmeldeklassenberechtigungen des Benutzers auf all.

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

Beispiel: Verwenden Sie additive Logik mit regulären Ausdrücken, um Zugriffsrechte zu spezifizieren

In diesem Beispiel wird gezeigt, wie Sie additive Logik verwenden, wenn Sie reguläre Ausdrücke zum Einrichten von Konfigurationszugriffsrechten verwenden.

Anforderungen

In diesem Beispiel wird ein Gerät verwendet, auf dem Junos OS Version 16.1 oder höher ausgeführt wird.

Überblick

Sie können reguläre Ausdrücke definieren, um zu steuern, wer Änderungen an der Konfiguration vornehmen darf und was sie ändern können. Diese regulären Ausdrücke geben spezifische Konfigurationshierarchien an, auf die Benutzer in einer Anmeldeklasse zugreifen dürfen. Sie können beispielsweise reguläre Ausdrücke definieren, mit denen Benutzer eine Gruppe von Routing-Instanzen ändern können, und reguläre Ausdrücke definieren, die benutzer daran hindern, Änderungen an anderen Routing-Instanzen oder an anderen Konfigurationsebenen vorzunehmen. Sie definieren die regulären Ausdrücke, indem Sie die und deny-configuration-regexps die allow-configuration-regexps Anweisungen für eine Anmeldeklasse konfigurieren.

Standardmäßig hat die deny-configuration-regexps Anweisung Vorrang vor der allow-configuration-regexps Anweisung. Wenn eine Konfigurationshierarchie in einer deny-configuration-regexps Anweisung für eine Anmeldeklasse angezeigt wird, ist sie unabhängig vom Inhalt der Anweisung für die Benutzer in dieser allow-configuration-regexps Klasse nicht sichtbar. Wenn eine Konfigurationshierarchie in einer deny-configuration-regexps Anweisung nicht angezeigt wird, ist sie für die Benutzer in dieser Klasse sichtbar, wenn sie in einer allow-configuration-regexps Anweisung angezeigt wird.

Sie können dieses Standardverhalten ändern, indem Sie die additive Logik für die *-configuration-regexps Anweisungen aktivieren. Wenn Sie die additive Logik aktivieren, hat die allow-configuration-regexps Anweisung Vorrang vor der deny-configuration-regexps Anweisung.

Wenn also die Anweisung den deny-configuration-regexps Zugriff auf alle Konfigurationshierarchien auf einer bestimmten Ebene (Protokolle .*) verweigert, die Anweisung aber den allow-configuration-regexps Zugriff auf eine Unterhierarchie (Protokolle bgp .*) zulässt, verweigert das Gerät standardmäßig den Zugriff auf die Hierarchien für Benutzer in dieser Anmeldeklasse, da die deny-configuration-regexps Anweisung Vorrang hat. Wenn Sie jedoch die additive Logik aktivieren, ermöglicht das Gerät den Zugriff auf die angegebene Unterhierarchie für Benutzer in dieser Anmeldeklasse, da dies allow-configuration-regexps in diesem Fall Vorrang hat.

Konfiguration

Schritt-für-Schritt-Verfahren

So aktivieren Sie eine additive Logik, die Benutzern in einer bestimmten Anmeldeklasse explizit den Zugriff auf eine oder mehrere individuelle Konfigurationshierarchien erlaubt:

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

    Zum Beispiel:

  2. Schließen Sie die Anweisung ein allow-configuration-regexps , und definieren Sie reguläre Ausdrücke für die bestimmten Hierarchien, die zulässig sind.

    Zum Beispiel:

  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. Übernehmen Sie Ihre Änderungen.

    Benutzer, die dieser Anmeldeklasse zugewiesen sind, haben Zugriff auf die Konfigurationshierarchien, die in der allow-configuration-regexps Anweisung enthalten sind, haben jedoch keinen Zugriff auf die anderen Hierarchien, die in der deny-configuration-regexps Anweisung angegeben sind.

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 Auswirkungen auswerten und die regulären Ausdrücke in diesen Anweisungen entsprechend aktualisieren.

Beispiele:

Verwenden von regulären Ausdrücken mit additiver Logik

Zweck

In diesem Abschnitt finden Sie Beispiele für reguläre Ausdrücke, die additive Logik verwenden, um Ideen zum Erstellen von systemgerechten Konfigurationen zu erhalten.

Zulassen spezifischer Routing-Instanzen

Die folgende Beispielanmeldungsklasse enthält einen regulären Ausdruck, der die Konfiguration von Routing-Instanzen ermöglicht, CUST-VRF-1deren Namen mit CUST-VRF-beginnen, z. B. , CUST-VRF-25, CUST-VRF-100usw. Das Beispiel enthält auch einen regulären Ausdruck, der die Konfiguration von Routing-Instanzen verhindert.

Standardmäßig hat die deny-configuration-regexps Anweisung Vorrang, und die vorherige Konfiguration verhindert, dass die Benutzer in der Anmeldeklasse unabhängig vom Namen Routing-Instanzen konfigurieren.

Wenn Sie jedoch die folgende Anweisung konfigurieren, hat die allow-configuration-regexps Anweisung Vorrang. So können die Benutzer Routing-Instanzen konfigurieren, deren Namen mit CUST-VRF-beginnen, aber die Benutzer können keine anderen Routing-Instanzen konfigurieren.

Nur BGP-Peer-Konfiguration zulassen

Die folgende Beispielanmeldungsklasse enthält reguläre Ausdrücke, die die Konfiguration auf [edit protocols] Hierarchieebene verhindern, aber die Konfiguration von BGP-Peers ermöglichen:

Standardmäßig verhindert die vorherige Konfiguration, dass die Benutzer in der Anmeldeklasse Änderungen an beliebigen Hierarchien unter [edit protocols].

Wenn Sie jedoch die folgende Anweisung konfigurieren, können die Benutzer in der Anmeldeklasse Änderungen an BGP-Peers vornehmen, die Benutzer können jedoch keine anderen Protokolle oder andere BGP-Anweisungen außerhalb der zulässigen Hierarchieebene konfigurieren.

Überprüfung

So stellen Sie sicher, dass Sie die Zugriffsrechte korrekt festgelegt haben:

  1. Konfigurieren Sie eine Anmeldeklasse und übernehmen Sie die Änderungen.

  2. Weisen Sie die Anmeldeklasse einer username.

  3. Melden Sie sich mit der username neuen Anmeldeklasse als zugewiesen an.

  4. Versuchen Sie, die zulässigen Hierarchieebenen zu konfigurieren.

    • Sie sollten in der Lage sein, Anweisungen in Hierarchieebenen zu konfigurieren, die zulässig sind.

    • Hierarchieebenen, die verweigert werden, sollten nicht sichtbar sein.

    • Alle zulässigen oder verweigerten Ausdrücke sollten Vorrang vor den mit der permissions Anweisung gewährten Berechtigungen haben.

Beispiel: Konfigurieren von Benutzerberechtigungen mit Zugriffsrechten für Betriebsmodusbefehle

Dieses Beispiel zeigt, wie Sie benutzerdefinierte Anmeldeklassen konfigurieren und Zugriffsrechte für Betriebsmodusbefehle zuweisen. Benutzer in der Anmeldeklasse können nur die Befehle ausführen, auf die sie Zugriff haben. Dadurch wird verhindert, dass unbefugte Benutzer sensible Befehle ausführen, die das Netzwerk beschädigen könnten.

Anforderungen

In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:

  • Ein Gerät von Juniper Networks

  • Ein TACACS+ (oder RADIUS)-Server

Stellen Sie zunächst eine TCP-Verbindung zwischen dem Gerät und dem TACACS+-Server her. Stellen Sie im Fall des RADIUS-Servers eine UDP-Verbindung zwischen dem Gerät und dem RADIUS-Server her.

Übersicht und Topologie

Abbildung 1 veranschaulicht eine einfache Topologie, bei der Router R1 ein Gerät von Juniper Networks ist und über eine TCP-Verbindung mit einem TACACS+-Server verfügt.

Abbildung 1: Topologie Topologie

In diesem Beispiel wird R1 mit drei angepassten Anmeldeklassen konfiguriert: Klasse1, Klasse2 und Klasse3. Jede Klasse definiert Zugriffsrechte für den Benutzer, indem sie die permissions Anweisung konfigurieren und erweiterte reguläre Ausdrücke mithilfe von und allow-commandsdeny-commands Anweisungen definieren.

Der Zweck jeder Login-Klasse ist wie folgt:

  • Class1– Definiert Zugriffsberechtigungen für den Benutzer nur mit der allow-commands Anweisung. Diese Anmeldeklasse bietet Benutzerberechtigungen auf Betreiberebene und Autorisierung für den Neustart des Geräts.

  • Class2– Definiert Zugriffsberechtigungen für den Benutzer nur mit der deny-commands Anweisung. Diese Anmeldeklasse bietet Benutzerberechtigungen auf Betreiberebene und verweigert den Zugriff auf set Befehle.

  • Class3– Definiert Zugriffsrechte für den Benutzer mit beiden allow-commands Anweisungen.deny-commands Diese Anmeldeklasse bietet Benutzerberechtigungen auf Superbenutzerebene und Autorisierung für den Zugriff auf Schnittstellen und das Anzeigen von Geräteinformationen. Außerdem wird der Zugriff auf die Befehle und configure die edit Befehle verweigert.

Router R1 verfügt über drei verschiedene Benutzer, Benutzer1, Benutzer2 und Benutzer3, die den Anmeldeklassen Class1, Class2 und Class3 zugewiesen sind.

Konfiguration

CLI-Schnellkonfiguration

Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, kopieren Sie die Befehle, fügen Sie sie auf Hierarchieebene in die [edit] CLI ein, und geben Sie dann im Konfigurationsmodus ein commit .

R1

Konfigurieren von Authentifizierungsparametern für Router R1

Schritt-für-Schritt-Verfahren

So konfigurieren Sie die Router R1-Authentifizierung:

  1. Konfigurieren Sie die Reihenfolge, in der R1 versucht, den Benutzer zu authentifizieren. In diesem Beispiel wird zuerst die TACACS+-Serverauthentifizierung, gefolgt von der RADIUS-Serverauthentifizierung und dann das lokale Kennwort.

  2. Konfigurieren Sie den TACACS+-Server.

  3. Konfigurieren Sie den RADIUS-Server.

  4. Konfigurieren Sie R1-Buchhaltungsparameter.

Konfigurieren von Zugriffsrechten mit der Allow-Commands-Anweisung (Class1)

Schritt-für-Schritt-Verfahren

So geben Sie reguläre Ausdrücke mithilfe der allow-commands Anweisung an:

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

  2. Konfigurieren Sie den allow-commands regulären Ausdruck, damit 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 Anweisung deny-commands (Class2)

Schritt-für-Schritt-Verfahren

So geben Sie reguläre Ausdrücke mithilfe der deny-commands Anweisung an:

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

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

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

Konfigurieren von Zugriffsrechten mit den Anweisungen "allow-commands" und "Deny-commands" (Class3)

Schritt-für-Schritt-Verfahren

So geben Sie reguläre Ausdrücke mit den allow-commands anweisungen und deny-commands

  1. Konfigurieren Sie die Class3-Anmeldeklasse und weisen Sie Berechtigungen auf Superbenutzerebene 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 allow-commands regulären Ausdruck so, dass Benutzer in den Konfigurationsmodus wechseln können.

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

Ergebnisse

Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie den show system Befehl eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Überprüfung

Melden Sie sich als Benutzername an, der der neuen Anmeldeklasse zugewiesen ist, und bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.

Überprüfen der Class1-Konfiguration

Zweck

Stellen Sie sicher, dass die Berechtigungen und Befehle, die in der Anmeldeklasse Class1 zulässig sind, funktionieren.

Aktion

Führen Sie den Befehl im show system users Betriebsmodus aus.

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

Bedeutung

Die Anmeldeklasse Class1, der Benutzer1 zugewiesen ist, verfügt über Benutzerberechtigungen auf Betreiberebene und ermöglicht benutzern in der Klasse die Ausführung des request system reboot Befehls.

Für die vordefinierte Anmeldeklasse des Betreibers sind die folgenden Berechtigungs-Flags angegeben:

  • clear— Kann Befehle verwenden clear , um Informationen zu löschen (zu löschen), die das Gerät aus dem Netzwerk lernt und in verschiedenen Netzwerkdatenbanken speichert.

  • network— Zugriff auf das Netzwerk mithilfe von ping, ssh, und telnettraceroute Befehlen.

  • reset— Kann Softwareprozesse mithilfe des restart Befehls neu starten.

  • trace— Kann Trace-Dateieinstellungen anzeigen und Trace-Dateieigenschaften konfigurieren.

  • view— Kann verschiedene Befehle verwenden, um die aktuelle systemweite Routing-Tabelle sowie protokollspezifische Werte und Statistiken anzuzeigen. Die geheime Konfiguration kann nicht angezeigt werden.

Für die Class1-Anmeldeklasse kann Benutzer1 zusätzlich zu den oben genannten Benutzerberechtigungen den request system reboot Befehl ausführen. Die erste Ausgabe zeigt die Ansichtsberechtigungen als Operator an, und die zweite Ausgabe zeigt, dass der einzige request system Befehl, den Benutzer1 als Operator ausführen kann, der request system reboot Befehl ist.

Überprüfung der Class2-Konfiguration

Zweck

Stellen Sie sicher, dass die Berechtigungen und Befehle, die für die Class2-Anmeldeklasse zulässig sind, funktionieren.

Aktion

Führen Sie den Befehl im ping Betriebsmodus aus.

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

Führen Sie über die CLI-Eingabeaufforderung einen beliebigen Set-Befehl aus.

Bedeutung

Die Class2-Anmeldeklasse, der Benutzer2 zugewiesen ist, verfügt über Benutzerberechtigungen auf Betreiberebene und verweigert den Zugriff auf alle set Befehle.

Die für die vordefinierte Anmeldeklasse des Betreibers angegebenen Berechtigungs-Flags sind identisch mit den für Class1 angegebenen Berechtigungen.

Überprüfen der Class3-Konfiguration

Zweck

Stellen Sie sicher, dass die Berechtigungen und Befehle, die für die Class3-Anmeldeklasse zulässig sind, funktionieren.

Aktion

Überprüfen Sie im Betriebsmodus die verfügbaren Befehle.

Gehen Sie in den Konfigurationsmodus.

Bedeutung

Die Class3-Anmeldeklasse, der Benutzer3 zugewiesen ist, verfügt über Superuser-Berechtigungen (alle), aber diese Klasse erlaubt benutzern nur die Ausführung des configure Befehls. Die Klasse verweigert den Zugriff auf alle anderen Befehle im Betriebsmodus. Da die in den allow/deny-commands Anweisungen angegebenen regulären Ausdrücke Vorrang vor den Benutzerberechtigungen haben, hat Benutzer3 auf R1 nur Zugriff auf den Konfigurationsmodus und wird der Zugriff auf alle anderen Befehle im Betriebsmodus verweigert.

Beispiel: Konfigurieren von Benutzerberechtigungen mit Zugriffsrechten für Konfigurationsanweisungen und Hierarchien

Dieses Beispiel zeigt, wie Sie benutzerdefinierte Anmeldeklassen konfigurieren und bestimmten Konfigurationshierarchien Zugriffsrechte zuweisen. Benutzer in der Anmeldeklasse können nur die Konfigurationsanweisungen und Hierarchien anzeigen und ändern, auf die sie Zugriff haben. Dadurch wird verhindert, dass unbefugte Benutzer Gerätekonfigurationen ändern, die das Netzwerk beschädigen könnten.

Anforderungen

In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:

  • Ein Gerät von Juniper Networks

  • Ein TACACS+ (oder RADIUS)-Server

Stellen Sie zunächst eine TCP-Verbindung zwischen dem Gerät und dem TACACS+-Server her. Stellen Sie im Fall des RADIUS-Servers eine UDP-Verbindung zwischen dem Gerät und dem RADIUS-Server her.

Übersicht und Topologie

Abbildung 2 veranschaulicht eine einfache Topologie, bei der Router R1 ein Gerät von Juniper Networks ist und über eine TCP-Verbindung mit einem TACACS+-Server verfügt.

Abbildung 2: Topologie Topologie

In diesem Beispiel wird R1 mit zwei angepassten Anmeldeklassen konfiguriert: Klasse1 und Klasse2. Jede Klasse definiert Zugriffsrechte für den Benutzer, indem sie die permissions Anweisung konfigurieren und erweiterte reguläre Ausdrücke mithilfe von allow-configuration, , deny-configurationund allow-configuration-regexpsdeny-configuration-regexps Anweisungen definieren.

Der Zweck jeder Login-Klasse ist wie folgt:

  • Class1– Definiert Zugriffsrechte für den Benutzer mit den allow-configuration und deny-configuration Anweisungen. Diese Anmeldeklasse bietet Zugriff, um nur die [edit interfaces] Hierarchie zu konfigurieren, und verweigert alle anderen Zugriffe auf dem Gerät. Dazu gehören die Benutzerberechtigungen, configure um Konfigurationszugriff bereitzustellen. Darüber hinaus ermöglicht die Anweisung den allow-configuration Zugriff auf die Schnittstellenkonfiguration, und die Anweisung verweigert den deny-configuration Zugriff auf alle anderen Konfigurationshierarchien. Da die Allow-Anweisung Vorrang vor der Anweisung deny hat, können die Benutzer, die der Class1-Anmeldeklasse zugewiesen sind, nur auf die [edit interfaces] Hierarchieebene zugreifen.

  • Class2– Definiert Zugriffsrechte für den Benutzer mit den allow-configuration-regexps und deny-configuration-regexps Anweisungen. Diese Anmeldeklasse bietet Benutzerberechtigungen auf Superbenutzerebene und erlaubt explizit die Konfiguration auf mehreren Hierarchieebenen für Schnittstellen. Außerdem wird der Zugriff auf die Hierarchieebene und [edit protocols] die [edit system] Hierarchieebene verweigert.

Router R1 verfügt über zwei Benutzer, Benutzer1 und Benutzer2, die den Anmeldeklassen Class1 bzw. Class2 zugewiesen sind.

Konfiguration

CLI-Schnellkonfiguration

Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, kopieren Sie die Befehle, fügen Sie sie auf Hierarchieebene in die [edit] CLI ein, und geben Sie dann im Konfigurationsmodus ein commit .

R1

Konfigurieren von Authentifizierungsparametern für Router R1

Schritt-für-Schritt-Verfahren

So konfigurieren Sie die Router R1-Authentifizierung:

  1. Konfigurieren Sie die Reihenfolge, in der R1 versucht, den Benutzer zu authentifizieren. In diesem Beispiel wird zuerst die TACACS+-Serverauthentifizierung, gefolgt von der RADIUS-Serverauthentifizierung und dann das lokale Kennwort.

  2. Konfigurieren Sie den TACACS+-Server.

  3. Konfigurieren Sie den RADIUS-Server.

  4. Konfigurieren Sie die R1-Buchhaltungsparameter.

Konfigurieren von Zugriffsrechten mit den Anweisungen "Allow-Configuration" und "Konfigurationsverweigerung" (Class1)

Schritt-für-Schritt-Verfahren

So geben Sie reguläre Ausdrücke mit den allow-configuration Anweisungen an deny-configuration :

  1. Konfigurieren Sie die Class1-Anmeldeklasse mit configure Berechtigungen.

  2. Konfigurieren Sie den allow-configuration regulären Ausdruck, damit Benutzer in der Klasse einen Teil der [edit interfaces] Hierarchieebene anzeigen und ändern können.

  3. Konfigurieren Sie den deny-configuration regulären Ausdruck, um den Zugriff auf alle Konfigurationshierarchien zu verweigern.

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

Konfigurieren Sie Zugriffsberechtigungen mit den Anweisungen allow-configuration-regexps und Deny-configuration-regexps (Class2)

Schritt-für-Schritt-Verfahren

So geben Sie reguläre Ausdrücke mit den allow-configuration-regexps Anweisungen an deny-configuration-regexps :

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

  2. Konfigurieren Sie den allow-configuration-regexps regulären Ausdruck, damit Benutzer in der Klasse auf mehrere Hierarchien unter der [edit interfaces] Hierarchieebene zugreifen können.

  3. Konfigurieren Sie den deny-configuration-regexps regulären Ausdruck, um zu verhindern, dass Benutzer in der Klasse die Konfiguration auf der Hierarchieebene und [edit protocols] auf [edit system] Hierarchieebene anzeigen oder ändern.

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

Ergebnisse

Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie den show system Befehl eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Überprüfung

Melden Sie sich als Benutzername an, der der neuen Anmeldeklasse zugewiesen ist, und bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.

Überprüfen der Class1-Konfiguration

Zweck

Stellen Sie sicher, dass die Berechtigungen, die in der Anmeldeklasse Class1 zulässig sind, funktionieren.

Aktion

Überprüfen Sie im Betriebsmodus die verfügbaren Befehle.

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

Bedeutung

Benutzer1 verfügt über configure Benutzerberechtigungen, wie in der ersten Ausgabe zu sehen. Darüber hinaus hat Benutzer1 im Konfigurationsmodus Zugriff auf die interfaces Hierarchieebene, aber nur auf diese Hierarchieebene, wie in der zweiten Ausgabe zu sehen ist.

Überprüfen der Class2-Konfiguration

Zweck

Stellen Sie sicher, dass die Class2-Konfiguration wie erwartet funktioniert.

Aktion

Greifen Sie im Konfigurationsmodus auf die interfaces Konfiguration zu.

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

Bedeutung

Benutzer2 verfügt über Berechtigungen zur Konfiguration von Schnittstellen auf R1, aber der Benutzer verfügt nicht über die Berechtigung zum Anzeigen oder Ändern der Hierarchieebene oder [edit protocols] der [edit system] Hierarchieebene.

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