Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Junos OS von Benutzerzugriffsberechtigungen

Junos OS gewähren Sie Zugriff auf oder Berechtigungen für die Befehle und Konfigurationshierarchieebenen und Anweisungen. Auf diese Weise können Benutzer nur die Befehle ausführen und nur die Anweisungen konfigurieren und anzeigen, für die sie Zugriffsberechtigungen haben. Sie können erweiterte reguläre Ausdrücke verwenden, um anzugeben, welche Betriebsmodusbefehle, Konfigurations anweisungen und Hierarchien Benutzern abgelehnt oder zulässig sind. Auf diese Weise wird verhindert, dass nicht autorisierte Benutzer vertrauliche Befehle und Anweisungen ausführen oder konfigurieren, die im Netzwerk zu Schäden führen könnten. Lesen Sie dieses Thema für weitere Informationen.

Kenntnisse Junos OS Zugriffsberechtigungsebenen

Jeder Befehl auf der CLI der obersten Ebene und jeder Konfigurationserklärung ist eine Zugriffsrechteebene zugeordnet. Benutzer können nur die Befehle ausführen und nur die Anweisungen konfigurieren und anzeigen, für die sie Zugriffsberechtigungen haben. Die Zugriffsberechtigungen für jede Anmeldeklasse werden durch einen oder mehrere Berechtigungs-Flags definiert.

Für jede Anmeldeklasse können Sie die Verwendung von Befehlen im Betriebs- und Konfigurationsmodus explizit verweigern oder zulassen, die anderenfalls nach einer in der Anweisung angegebenen Berechtigungsebene zulässig oder nicht permissions zulässig wären.

Die folgenden Abschnitte bieten zusätzliche Informationen zu Berechtigungen:

Junos OS Class-Berechtigungs-Flags

Berechtigungs-Flags werden verwendet, um einem Benutzer Zugriff auf Betriebsmodusbefehle, Konfigurationshierarchieebenen und Anweisungen zu gewähren. Indem Sie auf der Anmeldeklasse des Benutzers einen speziellen Berechtigungs-Flag auf der Hierarchieebene angeben, gewähren Sie dem Benutzer Zugriff auf die entsprechenden Befehle und [edit system login class] Konfigurationshierarchieebenen und Anweisungen. Verwenden Sie den Berechtigungs-Flag, um Zugriff auf alle Befehle und all Konfigurationserklärungen zu gewähren.

Anmerkung:

Jeder aufgeführte Befehl repräsentiert diesen Befehl und alle Untermands mit diesem Befehl als Präfix. Jede aufgeführte Konfigurationsauszug stellt den obersten Teil der Konfigurationshierarchie dar, für die dieser Flag Zugriff gewährt.

Die permissions Anweisung gibt mindestens einen der in . Tabelle 1 Berechtigungs-Flags sind nicht kumuliert. Daher müssen für jede Klasse alle erforderlichen Berechtigungs-Flags aufgeführt werden, einschließlich zur Anzeige von Informationen und für den viewconfigure Konfigurationsmodus. Zwei Formen der Berechtigungssteuerung für einzelne Teile der Konfiguration sind:

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

  • Formular, das endet: -control Bietet Lese- und Schreibfunktionen für diesen Berechtigungstyp. Ein Beispiel ist interface-control ...

Die Flags gewähren schreibgeschützte Berechtigungen für diese Konfiguration, wenn Sie Zugriff auf Konfigurationshierarchieebenen und -anweisungen gewähren. Der Berechtigungs-Flag gewährt interface z. B. schreibgeschützten Zugriff auf die [edit interfaces] Hierarchieebene. Die -control Form des Flags gewährt Lesezugriff auf diese Konfiguration. Im vorherigen Beispiel erhalten interface-control Sie Lesezugriff auf die [edit interfaces] Hierarchieebene.

Tabelle 1 Listen die Junos OS von Anmeldeklassenberechtigungs-Flags auf, die Sie konfigurieren können, indem Sie die permissions Anweisung auf der [edit system login class class-name] Hierarchieebene einschlingen.

Die Berechtigungs-Flags gewähren einen bestimmten Satz von Zugriffsberechtigungen. Jeder Berechtigungs-Flag wird mit den Befehlen im Betriebsmodus sowie den Konfigurationshierarchieebenen und Anweisungen aufgeführt, für die dieser Flag Zugriff gewährt.

Tabelle 1: Berechtigungs-Flags für Anmeldeklassen

Berechtigungs-Flag

Beschreibung

Zugriff

Kann die Zugriffskonfiguration im Konfigurationsmodus und mit dem Befehl für den show configuration Betriebsmodus anzeigen.

Zugangskontrolle

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

Admin

Kann Benutzerkontoinformationen im Konfigurationsmodus und mit dem Befehl zum show configuration Betriebsmodus anzeigen.

Admin Control

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

All-Control

Kann Benutzerkonten anzeigen und auf der [edit system login] Hierarchieebene konfigurieren.

all

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

Klar

Kann mithilfe der Befehle aus dem Netzwerk gelernte Informationen löschen (löschen), die in verschiedenen Netzwerkdatenbanken gespeichert clear sind.

Konfigurieren

Kann mithilfe des Befehls in den Konfigurationsmodus configure eingaben.

Steuerung

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

Feld

Kann Field debug-Befehle anzeigen. Für Debugging-Support reserviert.

Firewall

Kann die Konfiguration der Firewall-Filter im Konfigurationsmodus anzeigen.

Firewall-Steuerung

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

Diskette

Kann von den Wechselmedien gelesen und auf diese geschrieben werden.

Flow-Tap

Kann die Flow-Tap-Konfiguration im Konfigurationsmodus anzeigen.

Flow-Tap-Control

Kann die Konfiguration mit "Flow-Tap" im Konfigurationsmodus anzeigen und Konfigurationsinformationen zu Fluss-Tap auf der [edit services flow-tap] Hierarchieebene konfigurieren.

Flow-Tap-Betrieb

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

Anmerkung:

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

IDP-Profiler-Betrieb

Kann Profiler-Daten anzeigen.

Schnittstelle

Kann die Schnittstellenkonfiguration im Konfigurationsmodus und mit dem show configuration Betriebsmodusbefehl anzeigen.

Schnittstellenkontrolle

Anzeige von Chassis-, Class-of-Service (CoS), Gruppen, Weiterleitungsoptionen und Konfigurationsinformationen für Schnittstellen. Kann Konfigurationen in den folgenden Hierarchieebenen bearbeiten:

  • [edit chassis]

  • [edit class-of-service]

  • [edit groups]

  • [edit forwarding-options]

  • [edit interfaces]

Wartung

Kann Systemwartung durchführen, einschließlich Starten einer lokalen Shell auf dem Router oder Switch und Werden der Superuser in der Shell mithilfe des Befehls, und kann den Router oder Switch mithilfe der Befehle anhalten und neu su rootrequest system starten.

Netzwerk

Kann mithilfe von , und Befehlen pingssh auf das Netzwerk telnettraceroute zugreifen.

pgcp-Sitzungsspiegelung

Kann die Konfiguration pgcp zur Sitzungsspiegelung anzeigen.

pgcp-session-mirroring-control

Kann die Konfiguration pgcp der Sitzungsspiegelung ändern.

Zurücksetzen

Kann Softwareprozesse mithilfe des Befehls neu starten und konfigurieren, ob Softwareprozesse auf der Hierarchieebene aktiviert oder restart[edit system processes] deaktiviert sind.

Rollback

Kann den Befehl rollback verwenden, um eine zuvor zugesagte Konfiguration zu einer anderen als der kürzlich zugesagten Konfiguration zurück kehren.

Routing

Kann allgemeine Informationen zur Konfiguration von Routing-, Routing-Protokoll- und Routing-Richtlinien im Konfigurations- und Betriebsmodus anzeigen.

Routing-Steuerung

Kann allgemeine Informationen zur Konfiguration von Routing-, Routing-Protokoll- und Routing-Richtlinien anzeigen und allgemeines Routing auf Hierarchieebene, Routingprotokolle auf Hierarchieebene und Routingrichtlinien auf Hierarchieebene [edit routing-options][edit protocols][edit policy-options] konfigurieren.

Geheimnis

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 im Konfigurationsmodus ändern.

Sicherheit

Kann Die Sicherheitskonfiguration im Konfigurationsmodus und mit dem Befehl zum show configuration Betriebsmodus anzeigen.

Sicherheitskontrolle

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

Muschel

Kann mithilfe des Befehls eine lokale Shell auf dem Router oder Switch start shell starten.

Snmp

Kann SNMP-Konfigurationsinformationen (Simple Network Management Protocol) im Konfigurations- und Betriebsmodus anzeigen.

SNMP-Steuerung

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

System

Anzeige von Informationen auf Systemebene im Konfigurations- und Betriebsmodus

Systemsteuerung

Kann Konfigurationsinformationen auf Systemebene anzeigen und auf der [edit system] Hierarchieebene konfigurieren.

Spur

Kann Trace-Dateieinstellungen anzeigen und Trace-Dateieigenschaften konfigurieren.

Trace-Control

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

ansehen

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

View-Konfiguration

Kann die ganze Konfiguration außer Secrets, Systemskripts und Ereignisoptionen anzeigen.

Anmerkung:

Nur Benutzer mit einer maintenance Berechtigung können Commit-, Opskript- oder Ereignisskriptkonfiguration anzeigen.

Zulassen oder Verweigern einzelner Befehle für Junos OS-Anmeldeklassen

Standardmäßig verfügen alle Befehlen der obersten CLI über entsprechende Zugriffsberechtigungsebenen. Benutzer können nur die Befehle ausführen und nur die Anweisungen anzeigen, für die sie Zugriffsberechtigungen haben. Für jede Anmeldeklasse können Sie die Verwendung von Befehlen im Betriebs- und Konfigurationsmodus explizit verweigern oder zulassen, die anderenfalls nach einer in der Anweisung angegebenen Berechtigungsebene zulässig oder nicht permissions zulässig wären.

Berechtigungs-Flags werden verwendet, um einem Benutzer Zugriff auf Betriebsmodusbefehle, Konfigurationshierarchieebenen und Anweisungen zu gewähren. Indem Sie auf der Anmeldeklasse des Benutzers einen speziellen Berechtigungs-Flag auf der Hierarchieebene angeben, gewähren Sie dem Benutzer Zugriff auf die entsprechenden Befehle und [edit system login class] Konfigurationshierarchieebenen und Anweisungen. Verwenden Sie den Berechtigungs-Flag, um Zugriff auf alle Befehle und all Konfigurationserklärungen zu gewähren. Die Flags gewähren schreibgeschützte Berechtigungen für diese Konfiguration, wenn Sie Zugriff auf Konfigurationshierarchieebenen und -anweisungen gewähren. Der Berechtigungs-Flag gewährt interface z. B. schreibgeschützten Zugriff auf die [edit interfaces] Hierarchieebene. Die -control Form des Flags gewährt Lesezugriff auf diese Konfiguration. Im vorherigen Beispiel erhalten interface-control Sie Lesezugriff auf die [edit interfaces] Hierarchieebene.

  • Die Berechtigungsbits der Anmeldeklasse haben Vorrang vor erweiterten reguläre Ausdrücken, wenn ein all Benutzerbefehl mit rollbackrollback aktivierter Berechtigungs-Flag aus dem Benutzerbereich aus ausgaben.

  • Ausdrücke, die zum Zulassen und Verweigern von Befehlen für Benutzer auf RADIUS und TACACS+-Servern verwendet werden, wurden vereinfacht. Anstelle eines einzigen, langen Ausdrucks mit mehreren Befehlen ( ) können Sie jeden allow-commands=cmd1 cmd2 ... cmdn Befehl als separaten Ausdruck angeben. Diese neue Syntax ist allow-configuration für, und alle deny-configurationallow-commandsdeny-commands Benutzerberechtigungsbits gültig.

  • Benutzer können den Befehl load override nicht lösen, wenn ein erweiterter regulärer Ausdruck angegeben wird. Es können nur die Konfigurationsbefehle mergereplace und patch -befehle für die Benutzer ausgeführt werden.

  • Wenn Sie dieselben Befehle zulassen und verweigern, haben die Berechtigungen Vorrang vor den allow-commands von der deny-commands . Beispielsweise kann der Benutzer der Anmeldeklasse mithilfe des Befehls Software allow-commands "request system software add"deny-commands "request system software add"request system software add installieren.

  • Reguläre Ausdrücke für allow-commands und können auch die , , und die Befehle deny-commandscommitloadrollbacksavestatusupdate enthalten.

  • Wenn Sie einen regelmäßigen Ausdruck für und mit zwei unterschiedlichen Varianten eines Befehls angeben, wird immer die längste Übereinstimmung allow-commandsdeny-commands ausgeführt.

    Wenn Sie beispielsweise einen regelmäßigen Ausdruck mit dem Befehl und einen regelmäßigen Ausdruck für den Befehl angeben, können benutzer, die einer solchen Anmeldeklasse zugewiesen sind, den Befehl ausführen, nicht aber den allow-commandscommit-synchronizedeny-commandscommitcommit synchronizecommit Befehl. Der Grund dafür commit-synchronize ist, dass die längste Übereinstimmung besteht und festgelegt commitcommit-synchronizeallow-commands ist.

    Wenn Sie einen regelmäßigen Ausdruck mit dem Befehl und einen regelmäßigen Ausdruck für den Befehl angeben, können die einer solchen Anmeldeklasse zugewiesenen Benutzer den Befehl ausführen, nicht aber den allow-commandscommitdeny-commandscommit-synchronizecommitcommit-synchronize Befehl. Der Grund dafür commit-synchronize ist, dass die längste Übereinstimmung besteht und festgelegt commitcommit-synchronizedeny-commands ist.

Beispiel: Konfigurieren von Benutzerberechtigungen mit Zugriffsberechtigungsebenen

In diesem Beispiel wird gezeigt, wie Die Berechtigungen für ein Benutzerkonto angezeigt und die Benutzerberechtigungen mit Zugriffsberechtigungen für eine Anmeldeklasse konfiguriert werden. Auf diese Weise können Benutzer nur die Befehle ausführen und nur die Anweisungen konfigurieren und anzeigen, für die sie Zugriffsberechtigungen haben. Auf diese Weise wird verhindert, dass nicht autorisierte Benutzer vertrauliche Befehle und Anweisungen ausführen oder konfigurieren, die im Netzwerk zu Schäden führen könnten.

Anforderungen

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

  • Ein Juniper Networks Gerät

  • Ein TACACS+-Server (oder RADIUS)

  • Junos OS das auf einem Gerät ausgeführte Juniper Networks aufbauen

Bevor Sie beginnen:

  • Herstellen einer Verbindung zwischen dem Gerät und dem TACACS+-Server.

    Informationen zur Konfiguration eines TACACS+-Servers finden Sie unter Konfigurieren der TACACS+-Authentifizierung.

  • Konfigurieren Sie mindestens einen Benutzer, dem eine Anmeldeklasse auf dem Juniper Networks zugewiesen ist. Es kann mehr als eine Anmeldeklasse mit unterschiedlichen Berechtigungskonfigurationen und mehr als einem Benutzer auf dem Gerät geben.

Überblick

Jeder Befehl auf der obersten Befehlszeilenschnittstelle (CLI) (CLI) und jede Konfigurationserklärung in Junos OS verfügt über eine entsprechende Zugriffsrechteebene. Für jede Anmeldeklasse können Sie die Verwendung von Befehlen im Betriebs- und Konfigurationsmodus explizit verweigern oder zulassen, die ansonsten nach einer Berechtigungsebene zulässig oder nicht zulässig wären. Benutzer können nur die Befehle ausführen und nur die Anweisungen konfigurieren und anzeigen, für die sie Zugriffsberechtigungen haben. Um Zugriffsberechtigungsebenen zu konfigurieren, fügen Sie die permissions Anweisung auf der [edit system login class class-name] Hierarchieebene ein.

Die Zugriffsberechtigungen für jede Anmeldeklasse werden durch einen oder mehrere in der Anweisung angegebene Berechtigungs-Flags permissions definiert. Berechtigungs-Flags werden verwendet, um einem Benutzer Zugriff auf Betriebsmodusbefehle, Anweisungen und Konfigurationshierarchien zu gewähren. Berechtigungs flags sind nicht kumuliert. Daher müssen Sie für jede Anmeldeklasse alle erforderlichen Berechtigungs-Flags auflisten, einschließlich zur Anzeige von Informationen und zur Eingabe viewconfigure des Konfigurationsmodus. Indem Sie in der Anmeldeklasse des Benutzers einen speziellen Berechtigungs-Flag angeben, gewähren Sie dem Benutzer Zugriff auf die entsprechenden Befehle, Anweisungen und Konfigurationshierarchien. Verwenden Sie den Berechtigungs-Flag, um Zugriff auf alle Befehle und all Konfigurationserklärungen zu gewähren. Die Berechtigungs-Flags bieten eine schreibgeschützte ("nur" Form) und Lese- und Schreibfunktion (die bei der Steuerung endet) für einen Berechtigungstyp.

Anmerkung:

Die Berechtigungsbits der Anmeldeklasse haben Vorrang vor erweiterten reguläre Ausdrücken, wenn ein Benutzer einen Rollback-Befehl mit dem all aktivierten Rollback-Berechtigungs flag aus gibt.

So konfigurieren Sie die Berechtigungsebenen für den Benutzerzugriff:

  1. Zeigen Sie die Berechtigungen für ein Benutzerkonto an.

    Sie können die Berechtigungen für ein Benutzerkonto anzeigen, bevor Sie die Zugriffsrechte für diese Berechtigungen konfigurieren.

    Geben Sie auf der Hierarchieebene die ?[edit] Benutzerberechtigungen ein:

  2. Konfigurieren Sie Benutzerberechtigungen mit Zugriffsberechtigungen.

    Alle Benutzer, die sich an einem Gerät anmelden können, müssen in einer Anmeldeklasse sein. Für jede Anmeldeklasse können Sie die Zugriffsberechtigungen konfigurieren, die die verbundenen Benutzer besitzen, wenn sie sich auf dem Gerät anmelden.

    Um die Zugriffsberechtigungsebenen für Benutzerberechtigungen zu konfigurieren, fügen Sie die Anweisung auf der Hierarchieebene mit der Benutzerberechtigung, der Option und den erforderlichen permissions[edit system login class class-name]permissions Berechtigungs-Flags bei.

Konfiguration

Konfigurieren von Benutzerberechtigungen mit Zugriffsberechtigungsebenen

Schritt-für-Schritt-Verfahren

So konfigurieren Sie Zugriffsberechtigungen:

  1. Zeigen Sie auf dem Gerät die Liste der Berechtigungen an, die für das Benutzerkonto verfügbar sind. In diesem Beispiel ist der Benutzername des Benutzerkontos Host.

    Die Ausgabe listet die Berechtigungen für den Benutzer-Host auf. Benutzerdefinierte Anmeldeklassen können durch die Konfiguration verschiedener Zugriffsberechtigungen für diese Benutzerberechtigungen erstellt werden.

  2. Konfigurieren Sie eine Zugriffsberechtigungsklasse, um dem Benutzerhost nur das Konfigurieren und Anzeigen von SNMP-Parametern zu ermöglichen. In diesem Beispiel wird diese Anmeldeklasse als Netzwerkverwaltung bezeichnet. Um die Anmeldeklasse für die Netzwerkverwaltung anzupassen, fügen Sie die SNMP-Berechtigungs-Flags zur configure Benutzerberechtigung bei.

    Hier bieten die konfigurierten Berechtigungs-Flags für SNMP Lese- (snmp) und Lese-und-Schreiben (snmp-steuerung). Dies ist die einzige zulässige Zugriffsberechtigung für die Anmeldeklasse für die Netzwerkverwaltung. Mit anderen Worten, es werden alle anderen Zugriffsrechte, die nicht auf die Konfiguration und Anzeige von SNMP-Parametern gehören, abgelehnt.

Ergebnisse

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

Überprüfung

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

Überprüfung der SNMP-Konfiguration

Zweck

Stellen Sie sicher, dass die SNMP-Konfiguration ausgeführt wird.

Aktion

Führen Sie im Konfigurationsmodus grundlegende SNMP-Befehle auf der [edit snmp] Hierarchieebene aus.

Bedeutung

Der der Anmeldeklasse für die Netzwerkverwaltung zugewiesene Benutzer-Host kann SNMP-Parameter konfigurieren, da die für diese Klasse angegebenen Berechtigungs-Flags sowohl Snmp- (Read-Funktionen) als auch Snmp-Control-Berechtigungsbits (Lese- und Schreibfunktionen) umfassen.

Überprüfung der Konfiguration ohne SNMP

Zweck

Stellen Sie sicher, dass der Anmeldeklasse für die Netzwerkverwaltung eine Nicht-SNMP-Konfiguration abgelehnt wird.

Aktion

Führen Sie im Konfigurationsmodus alle Konfigurationen aus, die nicht SNMP sind, z. B. die Schnittstellenkonfiguration.

Reguläre Ausdrücke zum Zulassen und Verweigern Junos OS Betriebsmodusbefehle, Konfigurations anweisungen und Hierarchien

Dieses Thema enthält die folgenden Abschnitte:

Verstehen regulärer Ausdrücke

Sie können erweiterte reguläre Ausdrücke verwenden, um anzugeben, welche Betriebsmodusbefehle, Konfigurations anweisungen und Hierarchien abgelehnt oder zulässig sind. Sie geben diese regulären Ausdrücke lokal in der Hierarchieebene und in Anweisungen auf der Hierarchieebene oder remote an, indem Sie Juniper Networks anbieterspezifische TACACS+ oder RADIUS-Attribute in der Konfiguration des allow/deny-commandsallow/deny-configuration,allow/deny-commands-regexpsallow/deny-configuration-regexp[edit system login class class-name] Autorisierungsservers angeben.

Anmerkung:

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

Der Unterschied zwischen einer lokalen und Remote-Autorisierungskonfiguration ist das Muster, in dem die reguläre Ausdrücken-Anweisungen ausgeführt werden. Es ist zwar möglich, mehrere reguläre Ausdrücke mit Zeichenfolgen in der lokalen Autorisierungskonfiguration anzugeben. In einer Remotekonfiguration müssen die regulären Ausdrücken anweisungen jedoch aufgeteilt und in einzelnen Zeichenfolgen festgelegt werden. Wenn die Autorisierungsparameter sowohl remote als auch lokal konfiguriert sind, werden die regelmäßigen Ausdrücke, die während TACACS+ oder RADIUS-Autorisierung empfangen werden, mit allen auf dem lokalen Gerät verfügbaren regulären Ausdrücken zusammengeführt.

Beim Angeben mehrerer regulärer Ausdrücke in einer lokalen Konfiguration mit dem , oder Anweisungen werden reguläre Ausdrücke innerhalb von Klammern konfiguriert und mit dem Pipe-Symbol allow-configurationdeny-configuration voneinander allow-commandsdeny-commands getrennt. Der vollständige Ausdruck ist in doppelten Zitaten eingeschlossen. Sie können z. B. mehrere allow-commands Parameter mit folgender Syntax angeben:

Derselbe Ausdruck, der remote auf dem Autorisierungsserver konfiguriert ist, verwendet die folgende Syntax:

Beim Angeben mehrerer regulärer Ausdrücke in einer lokalen Konfiguration mithilfe von , oder Anweisungen werden reguläre Ausdrücke in doppelten Anführungszeichen konfiguriert und mithilfe des allow-configuration-regexpsdeny-configuration-regexps Platzbetreibers voneinander allow-commands-regexpsdeny-commands-regexps getrennt. Der vollständige Ausdruck ist in quadratischen Klammern eingeschlossen. Sie können z. B. mehrere Parameter für Allow-Befehle mit folgender Syntax angeben:

Derselbe Ausdruck, der remote auf dem Autorisierungsserver konfiguriert ist, verwendet die folgende Syntax:

Tabelle 2 differenziert die lokale und Remote-Autorisierungskonfiguration mit regelmäßigen Ausdrücken.

Tabelle 2: Beispiel für lokale und Remoteautorisierungskonfiguration mit regelmäßigen Ausdrücken

Lokale Konfiguration

Remote-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.*"
        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"
    }
}
Anmerkung:
  • Sie müssen explizit den Zugriff auf den NETCONF-Modus lokal oder remote zulassen, indem Sie die folgenden drei Befehle ausführen: xml-modeund netconfneed-trailer .

  • Wenn die Aussage verwendet wird, sollten alle anderen gewünschten deny-configuration = “.*” Konfigurationen mithilfe der Aussage zugelassen allow-configuration werden. Dies kann die zulässigen regelmäßigen Ausdrücke, die als Puffer für die Anweisung verwendet allow-configuration wird, beeinträchtigen. Wenn diese Grenze überschritten wird, funktioniert die zulässige Konfiguration möglicherweise nicht. Diese Puffergröße für regelmäßigen Ausdruck wurde in der Junos OS 14.1x53-D40, 15.1 und 16.1 erhöht.

Angeben regulärer Ausdrücke

Warnung:

Wenn Sie einen regelmäßigen Ausdruck für Befehle und Konfigurations anweisungen angeben, achten Sie genau auf die folgenden Beispiele. Der regelmäßige Ausdruck mit ungültiger Syntax liefert möglicherweise nicht die gewünschten Ergebnisse, selbst wenn die Konfiguration ohne Fehler festgelegt wird.

Reguläre Ausdrücke für Befehle und Konfigurations anweisungen sollten genauso angegeben werden wie die Ausführung des vollständigen Befehls oder der Anweisung. Tabelle 3 Liste der regulären Ausdrücke zum Konfigurieren von Zugriffsberechtigungen für die [edit interfaces][edit vlans] Anweisungshierarchien und den delete interfaces Befehl.

Tabelle 3: 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 noch nicht vollständig und erfordert die Option zur Ausführung der unit Aussage.

Daher muss bei dem regelmäßigen Ausdruck, der für das Verweigern der Konfiguration erforderlich ist, der gesamte ausführbare String mit dem Operator und an der Stelle von set interfaces.* Statement-Variablen angegeben werden:

[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 steht es für einen beliebigen Schnittstellennamen mit einem beliebigen Einheitswert.

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

  • Andere gültige Optionen können im regelmäßigen Ausdruck enthalten sein, z. B.:

    [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.* .*"
    

    Note:Der reguläre Ausdruck in diesem Beispiel wird verwendet, wenn mehrere Zeichenfolgen, die mit dem Mem-Stichwort beginnen, im angegebenen regelmäßigen mem.* Ausdruck erwartet werden. Wenn nur eine member Zeichenfolge enthalten sein soll, wird der member .* reguläre Ausdruck verwendet.

delete interfaces

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

[edit]
user@host# delete interfaces interface-name

Die Aussage kann selbst ausgeführt werden und erfordert nicht die Durchführung delete interfaces zusätzlicher Anweisungen.

Daher sollte im regelmäßigen Ausdruck, der für die Verweigern einer Aussage erforderlich delete interfaces ist, Folgendes angegeben werden:

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

  • Damit der reguläre Ausdruck wirksam wird, muss die angegebene Anmeldeklasse die Konfigurationsberechtigungen für die deny-configuration "interfaces .*" Schnittstellenhierarchie mithilfe des regulären allow-configuration "interfaces .*" Ausdrucks zulassen.

[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 Aussage unvollständig und erfordert set vlans die Option zur Ausführung der vlan-id Aussage.

Daher muss der reguläre Ausdruck für die Konfiguration den gesamten ausführbaren String mit dem Operator und set vlans den 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 es einen VLAN-Namen mit einer beliebigen VLAN-ID.

  • Andere gültige Optionen in der [edit vlans] Anweisungshierarchie können im regelmäßigen Ausdruck enthalten sein, z. B.:

    [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 4 Liste von Operatoren mit gebräuchlichen regulärem Ausdruck, die zum Zulassen oder Verweigern von Betriebs- und Konfigurationsmodi verwendet werden können.

Command Regular-Ausdrücke implementieren die erweiterten (modernen) regulären Ausdrücke, wie in POSIX 1003.2 definiert.

Tabelle 4: Operatoren für gemeinsamen regulären Ausdruck

Betreiber

Match

Beispiel

|

Einer von zwei oder mehr durch die Pipe voneinander getrennten Begriffe. Jeder Begriff muss ein vollständiger eigenständiger Ausdruck sein, der in Klammern ( ) eingeschlossen ist, ohne Bereiche zwischen der Pipe und den benachbarten 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)"

Bei der oben genannten Konfiguration sind der Zugriff auf den Betriebsmodus für die Benutzer der Testanmeldungsklasse auf die in der Anweisung angegebenen Befehle beschränkt, und der Zugriff auf den Konfigurationsmodus außer auf die in der Anweisung angegebenen allow-commandsdeny-configuration Hierarchieebenen.

^

Am Beginn eines Ausdrucks wird verwendet, um zu bezeichnen, wo der Befehl beginnt, wo es möglicherweise ein bestimmtes Ziel 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 oben genannten Konfiguration haben die der Testanmeldungsklasse zugewiesenen Benutzer Zugriff auf die Konfiguration und Anzeige der Schnittstellenkonfiguration im Betriebs- und Konfigurationsmodus. Die allow-commands Anweisung gibt den Zugriff auf Befehle an, die mit und mit Stichwörtern showmonitor beginnen.

Beim ersten Filter enthalten die angegebenen Befehle show log die , und die show interfacesshow policer Befehle. Der zweite Filter gibt alle Befehle an, die mit dem Stichwort monitor beginnen, z. B. monitor interfaces oder monitor traffic Befehle.

$

Zeichen am Ende eines Befehls. Verwendet einen Befehl, der genau bis zu diesem Punkt abgestimmt sein muss.

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

Mit der oben genannten Konfiguration können die der Testanmeldungsklasse zugewiesenen Benutzer die Schnittstellenkonfiguration im Konfigurationsmodus und mit dem Befehl im Betriebsmodus mit der Benutzerberechtigung der show configuration Schnittstelle anzeigen. Der in der Anweisung angegebene reguläre Ausdruck beschränkt die Benutzer jedoch auf die Ausführung nur des Befehls und verweigert den Zugriff auf die allow-commands Befehlserweiterungen show interfaces wie show interfaces detailshow interfaces extensive bzw. .

[ ]

Bereich von Buchstaben oder Digits. Verwenden Sie eine Bindestriche (- - ), um den Anfang und das Ende eines Bereichs zu   trennen.

[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 oben genannten Konfiguration verfügen die der Testanmeldungsklasse zugewiesenen Benutzer über Benutzerberechtigungen auf Betreiberebene und haben Zugriff auf die Konfiguration von Schnittstellen innerhalb des angegebenen Bereichs von Schnittstellennamen und Einheitennummer (0 bis 9).

( )

Eine Gruppe von Befehlen, die einen vollständigen, eigenständigen Ausdruck, der bewertet werden soll, angibt. Das Ergebnis wird dann als Teil des Gesamtausdrucks bewertet. Klammern müssen, wie erklärt, zusammen mit Pipe-Betreibern 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)"

Bei der oben genannten Konfiguration verfügen Benutzer, die der Testanmeldungsklasse zugewiesen wurden, über Berechtigungen auf Superuser-Ebene und haben Zugriff auf die in der Anweisung allow-commands 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*)"

Bei der oben genannten Konfiguration erhalten Benutzer, die der Testanmeldungsklasse zugewiesen wurden, deren Anmelde-Benutzername beginnt, m den Konfigurationszugriff zu verweigert.

+

Mindestens ein Begriff.

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

Bei der oben genannten Konfiguration erhalten Benutzer, die der Testanmeldungsklasse zugewiesen wurden, deren Anmelde-Benutzername beginnt, m den Konfigurationszugriff zu verweigert.

.

Alle Zeichen außer für einen Raum " " .

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

Bei der oben genannten Konfiguration erhalten Benutzer, die der Testanmeldungsklasse zugewiesen wurden, deren Anmelde-Benutzername beginnt, m den Konfigurationszugriff zu 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 .*)"

Bei der oben genannten Konfiguration erhalten Benutzer, die der Testanmeldungsklasse zugewiesen wurden, deren Anmelde-Benutzername beginnt, m den Konfigurationszugriff zu verweigert.

In ähnlicher Weise verweigert deny-configuration "protocols .*" die Aussage allen Konfigurationszugriff auf der [edit protocols] Hierarchieebene.

Anmerkung:
  • Die , und der Betrieb können mithilfe von erreicht *+..* werden.

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

Anmerkung:

Junos OS unterstützt den Operator für regelmäßigen ! Ausdruck nicht.

Beispiele für regelmäßigen Ausdruck

Tabelle 5 Listen Sie die regulären Ausdrücke, die zum Zulassen von Konfigurationsoptionen in zwei Konfigurationshierarchien ( und – wie zum Beispiel zum Angeben regulärer Ausdrücke) [edit system ntp server][edit protocols rip] verwendet werden.

Anmerkung:

Tabelle 5 stellt keine umfassende Liste aller regulären Ausdrücke und Keywords für alle Konfigurations anweisungen und Hierarchien zur Verfügung. Die in der Tabelle aufgelisteten reguläre Ausdrücke werden in Version 16.1 Junos OS unterstützt und nur für die [edit system ntp server][edit protocols rip] Anweisungshierarchien validiert.

Tabelle 5: Beispiele regulärer Ausdrücke

Anweisungshierarchie

Reguläre Ausdrücke

Zulässige Konfiguration

Abgelehnte Konfiguration

[edit system ntp server]

     

Schlüsselnummer

[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

Versionsnummer

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

  • key

  • Version

[edit protocols rip]

     

Nachrichtengröße

[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

  • Metrik in

  • Route-Timeout

  • Aktualisierungsintervall

Metrikin

[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

  • Nachrichtengröße

  • Route-Timeout

  • Aktualisierungsintervall

Route-Timeout-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

  • Metrik in

  • Aktualisierungsintervall

Aktualisierungsintervall des Update-Intervalls

[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 .*" ]
  • Aktualisierungsintervall

  • Nachrichtengröße

  • Metrik in

  • Route-Timeout

Beispiele zum Definieren von Zugriffsberechtigungen mit Anweisungen zur Berechtigungskonfiguration und "Verweigern"-Konfiguration

Sie können Zugriffsberechtigungen mit einer Kombination der folgenden Anweisungstypen definieren:

  • Berechtigungs-Flags

  • allow-configuration und deny-configuration Anweisungen

Die Berechtigungs-Flags definieren die größeren Grenzen, auf die eine Person oder Anmeldeklasse zugreifen und kontrollieren kann. Die Anweisungen und Anweisungen haben Vorrang vor allow-configuration Berechtigungs-Flags und geben dem Administrator eine feinere Kontrolle über genau das, worauf deny-configuration der Benutzer zugreifen kann.

In diesem Thema wird das Definieren von Zugriffsberechtigungen mithilfe von Anweisungen und einer Reihe von Beispielen zur Konfiguration von Anmeldeklassen allow-configurationdeny-configuration anhand dieser Anweisungen erklärt. Die Beispiele 1 bis 3 verwenden sowohl Berechtigungs-Flags als auch Anweisungen zum Erstellen von Anmeldeklassen, die Benutzern einen Zugriff auf alle außer deny-configuration etwas ermöglichen. Jede oder Anweisung wird mit einem oder mehrere reguläre Ausdrücke konfiguriert, die zulässig oder allow-configurationdeny-configuration abgelehnt werden sollen.

Dabei werden der Berechtigungsbit und der Berechtigungs-Flag synonym verwendet.

Beispiel 1

Um eine Anmeldeklasse zu erstellen, die dem Benutzer die Konfiguration alles außer Telnet-Parametern ermöglicht:

  1. Legen Sie den Berechtigungsbit für die Anmeldeklasse des Benutzers auf all .
  2. Geben Sie dazu die folgende deny-configuration Erklärung an.

Beispiel 2

Um eine Anmeldeklasse zu erstellen, die dem Benutzer die Konfiguration erlaubt, außer für alle Anmeldeklassen, deren Name mit "m" beginnt:

  1. Legen Sie den Berechtigungsbit für die Anmeldeklasse des Benutzers auf all .

  2. Geben Sie dazu die folgende deny-configuration Erklärung an.

Beispiel 3

In diesem nächsten Beispiel wird die Erstellung einer Anmeldeklasse mit dem Berechtigungs-Bit gezeigt, das verhindert, dass der Benutzer eine Konfiguration bearbeiten oder Befehle (z. B. ) auf allcommit den [edit system login class] Hierarchieebenen bearbeiten [edit system services] kann:

Um eine Anmeldeklasse zu erstellen, die dem Benutzer die Konfiguration alles außer auf den [edit system login class] Hierarchie- oder [edit system services] Hierarchieebenen ermöglicht:

  1. Legen Sie den Berechtigungsbit für die Anmeldeklasse des Benutzers auf all .

  2. Geben Sie dazu die folgende deny-configuration Erklärung an.

Die nächsten zwei Beispiele zeigen, wie die Anweisungen und die Verwendung verwendet werden, um Berechtigungen zu bestimmen, die für die allow-configurationdeny-configuration Hierarchieebene übereinander [edit system services] abweichen.

Beispiel 4

Um eine Anmeldeklasse zu erstellen, die dem Benutzer vollständige Konfigurationsrechte auf Hierarchieebene und nur [edit system services] auf [edit system services] der Hierarchieebene gestattet:

  1. Legen Sie den Berechtigungsbit für die Anmeldeklasse des Benutzers auf configure .

  2. Geben Sie dazu die folgende allow-configuration Erklärung an.

Beispiel 5

Um eine Anmeldeklasse zu erstellen, die dem Benutzer vollständige Berechtigungen für alle Konfigurationsmodushierarchien außer der [edit system services] Hierarchieebene gestattet:

  1. Legen Sie den Berechtigungsbit für die Anmeldeklasse des Benutzers auf all .

  2. Geben Sie dazu die folgende deny-configuration Erklärung an.

Beispiel: Verwenden von Logic mit regelmäßigen Ausdrücken zum Angeben von Zugriffsberechtigungen

In diesem Beispiel wird gezeigt, wie Sie Logic verwenden, wenn reguläre Ausdrücke zum Einrichten von Konfigurationszugriffsberechtigungen verwendet werden.

Konfiguration

Schritt-für-Schritt-Verfahren

so aktivieren Sie die Logik für reguläre Ausdrücke:

  1. Um eine oder mehrere einzelne Konfigurationsmodushierarchien explizit zu ermöglichen, fügen Sie die Anweisung auf der Hierarchieebene ein, die mit den regelmäßigen zulässigen allow-configuration-regexps[edit system login class class-name] Ausdrücken konfiguriert ist.

  2. Weisen Sie einer oder mehrere Benutzer die Anmeldeklasse zu.

  3. Aktivieren von logik für reguläre Ausdrücke.

  4. Commit für Änderungen.

    Benutzern, die dieser Anmeldeklasse zugewiesen wurden, haben Zugriff auf die in der Anweisung enthaltenen Konfigurationshierarchien, aber allow-configuration-regexps keine anderen.

Anforderungen

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

  • Ein Juniper Networks-Gerät der J-Serie, M Series-, MX-Serie T-Serie-Serie

  • Junos OS 16.1 oder höher

    • Mindestens einem Benutzer muss eine Anmeldeklasse zugewiesen sein.

    • Es kann mehr als eine Anmeldeklasse mit unterschiedlichen Berechtigungskonfigurationen und mehr als einem Benutzer auf dem Gerät geben.

Überblick

Um zu steuern, wer Konfigurationsänderungen am System vornehmen kann und welche spezifischen Änderungen möglich sind, können Sie reguläre Ausdrücke erstellen, die bestimmte Teile der Konfigurationshierarchie angeben, auf die Benutzer in einer angegebenen Benutzerklasse zugreifen können. Sie können beispielsweise reguläre Ausdrücke erstellen, die eine Gruppe von Routinginstanzen angeben, die Benutzer ändern dürfen, und verhindern, dass Benutzer Änderungen an anderen Routinginstanzen oder einer anderen Konfigurationsebene vornehmen.

Sie konfigurieren reguläre Ausdrücke mithilfe von allow-configuration-regexps und deny-configuration-regexps Anweisungen. Standardmäßig haben Anweisungen Vorrang vor Anweisungen für Benutzer in der benannten Benutzerklasse, auf die deny-configuration-regexpsallow-configuration-regexps sie angewendet werden.

Wenn eine Konfigurationshierarchie in einer Anweisung für eine bestimmte Benutzerklasse angezeigt wird, ist sie für Benutzer nicht sichtbar, unabhängig von dem deny-configuration-regexps Inhalt der allow-configuration-regexps Anweisung. Wenn eine Konfigurationshierarchie nicht in einer Anweisung angezeigt wird, wird sie sichtbar, wenn sie in einer Anweisung angezeigt wird oder wenn keine Anweisung für die deny-configuration-regexpsallow-configuration-regexpsallow-configuration-regexps Benutzerklasse konfiguriert ist.

Sie können optional dieses Standardverhalten ändern, sodass "logic" (d. h. alle standardmäßig verweigern/einige wie angegeben zulassen) in regelmäßigen Ausdrücken verwendet wird. Wenn logik aktiviert ist, ändert sich das Verhalten der vorhandenen regulären Ausdrücke so, dass alle Konfigurationshierarchien abgelehnt werden, sofern sie nicht in einer Anweisung für die named allow-configuration-regexps Benutzerklasse enthalten sind.

Beispiele

Verwenden regulärer Ausdrücke mit Logic von Logic

Zweck

In diesem Abschnitt werden reguläre Ausdrücke mithilfe von Logiken erläutert, die Ihnen Anregungen zur Erstellung von Konfigurationen für Ihr System geben.

Spezifische Routinginstanzen ermöglichen

Die folgende Beispiel-Anmeldeklasse enthält einen regelmäßigen Ausdruck, der die Konfiguration von Routinginstanzen ermöglicht, deren Namen mit u. a. CUST-VRF-CUST-VRF-1CUST-VRF-25CUST-VRF-100 beginnen:

Wenn die folgende Anweisung in der Konfiguration enthalten ist, verhindert dies, dass der Benutzer alle anderen Routinginstanzen konfiguriert und den Zugriff auf eine Konfigurationshierarchie verhindert, die nicht routingen:

Nur Peer BGP konfiguration zulassen

Die folgende Beispiel-Anmeldeklasse enthält einen regelmäßigen Ausdruck, der die Konfiguration von BGP-Peers ermöglicht:

Wenn die folgende Anweisung in der Konfiguration enthalten ist, verhindert dies, dass der Benutzer andere Änderungen wie das Löschen oder Deaktivieren von Anweisungen BGP kann:

Überprüfung

Um sicherzustellen, dass Sie die Zugriffsberechtigungen richtig festgelegt haben:

  1. Konfigurieren Sie eine Anmeldeklasse, und commit die Änderungen.

  2. Weisen Sie die Anmeldeklasse einem Benutzernamen zu.

  3. Melden Sie sich als Benutzername an, der der neuen Anmeldeklasse zugewiesen wurde.

  4. Versuchen Sie, die zulässigen Konfigurationen durchzuführen.

    • Sie sollten in der Lage sein, Konfigurationsänderungen in Hierarchieebenen und regelmäßigen zulässigen Ausdrücken durchzuführen.

    • Alle anderen Hierarchien sind nicht sichtbar.

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

Beispiel: Konfigurieren von Benutzerberechtigungen mit Zugriffsberechtigungen für Betriebsmodusbefehle

In diesem Beispiel wird gezeigt, wie Sie benutzerdefinierte Anmeldeklassen konfigurieren und Zugriffsberechtigungen für Betriebsmodusbefehle zuweisen. Auf diese Weise können Benutzer der angepassten Anmeldeklasse nur die Betriebsbefehle ausführen, für die Zugriffsberechtigungen angegeben wurden. Das verhindert, dass nicht autorisierte Benutzer vertrauliche Befehle ausführen, die im Netzwerk potenziell Schaden verursachen könnten.

Anforderungen

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

  • Ein Juniper Networks Gerät

  • Ein TACACS+-Server (oder RADIUS)

  • Junos OS das auf einem Gerät ausgeführte Juniper Networks aufbauen

Bevor Sie beginnen:

  • Herstellen einer TCP-Verbindung zwischen dem Gerät und dem TACACS+-Server. Stellen Sie im Fall eines RADIUS-Servers eine UDP-Verbindung zwischen dem Gerät und dem Server RADIUS.

    Informationen zur Konfiguration eines TACACS+-Servers finden Sie unter Konfigurieren der TACACS+-Authentifizierung.

  • Konfigurieren Sie mindestens einen Benutzer, dem eine Anmeldeklasse auf dem Juniper Networks zugewiesen ist. Es kann mehr als eine Anmeldeklasse mit unterschiedlichen Berechtigungskonfigurationen und mehr als einem Benutzer auf dem Gerät geben.

Überblick und Topologie

Jeder Befehl auf der obersten Befehlszeilenschnittstelle (CLI) (CLI) und jede Konfigurationserklärung in Junos OS verfügt über eine entsprechende Zugriffsrechteebene. Für jede Anmeldeklasse können Sie die Verwendung von Befehlen im Betriebs- und Konfigurationsmodus explizit verweigern oder zulassen, die ansonsten nach einer Berechtigungsebene zulässig oder nicht zulässig wären. Benutzer können nur die Befehle ausführen und nur die Anweisungen konfigurieren und anzeigen, für die sie Zugriffsberechtigungen haben. Um Zugriffsberechtigungsebenen zu konfigurieren, fügen Sie die permissions Anweisung auf der [edit system login class class-name] Hierarchieebene ein.

Die Zugriffsberechtigungen für jede Anmeldeklasse werden durch einen oder mehrere in der Anweisung angegebene Berechtigungs-Flags permissions definiert. Darüber hinaus können Sie erweiterte reguläre Ausdrücke mit den folgenden Anweisungen angeben:

  • allow-commands und – Erlauben oder verweigern Sie nur deny-commands Befehlen im Betriebsmodus.

  • allow-configuration und deny-configuration – Zugriff auf eine bestimmte Konfigurationshierarchie wird nur ermöglicht oder verweigern.

  • allow-configuration-regexps und – Zugriff auf eine bestimmte Konfigurationshierarchie mit deny-configuration-regexps Zeichenfolgen regulärer Ausdrücke zulassen oder verweigern.

  • allow-commands-regexps und –(TACACS+-Autorisierung) Zugriff auf einen bestimmten Befehl mithilfe von Zeichenfolgen deny-commands-regexps regulärer Ausdrücke zulassen oder verweigern.

Die oben genannten Anweisungen definieren die Zugriffsrechte eines Benutzers auf einzelne Betriebsmodusbefehle, Konfigurations anweisungen und Hierarchien. Diese Anweisungen haben Vorrang vor den Berechtigungen für Anmeldeklassen für einen Benutzer.

Configuration Notes

Berücksichtigen Sie bei der Konfiguration von , und Anweisungen mit Zugriffsberechtigungen allow-commandsdeny-commandsallow-configurationdeny-configuration Folgendes:

  • Sie können die Aussage "Zulassen/Verweigern" nur einmal in jede Anmeldeklasse beinhalten.

  • Wenn unter beiden Anweisungen genau derselbe Befehl bzw. beide Anweisungen konfiguriert ist, hat die Vorgangseinstellung Vorrang allow-commandsdeny-commands vor der allow-configurationdeny-configuration Deny-Anweisung.

    Mit der folgenden Konfiguration kann beispielsweise ein Benutzer, dem der Klassentest der Anmeldeklasse zugewiesen ist, mit dem Befehl Software installieren. Die Anweisung enthält jedoch request system software adddeny-commands auch:

    Mit der folgenden Konfiguration kann beispielsweise ein Benutzer, dem ein Anmeldeklassentest zugewiesen ist, auf die Konfigurationshierarchie zugreifen. Die Anweisung enthält jedoch [edit system services]deny-configuration auch:

  • Wenn Sie einen regelmäßigen Ausdruck für und Anweisungen mit zwei unterschiedlichen Varianten eines Befehls angeben, wird stets die längste Übereinstimmung allow-commandsdeny-commands ausgeführt.

    In der folgenden Konfiguration kann beispielsweise ein Benutzer, dem die Testanmeldungsklasse zugewiesen wurde, den Befehl ausführen, nicht commit synchronize den commit Befehl. Dies liegt commit-synchronize daran, dass die längste Übereinstimmung zwischen commit und ist commit-synchronizeallow-commands festgelegt.

  • Reguläre Ausdrücke für allow-commands und deny-commands Anweisungen können auch commit die , , , und befehle loadrollbacksavestatusupdate enthalten.

  • Das explizite Zulassen von Konfigurationsmodushierarchien oder reguläre Ausdrücken mithilfe der Anweisung fügt den regulären allow-configuration Berechtigungssatz mithilfe der Anweisung permissions hinzu. Auch die explizite Ab verweigern von Konfigurationsmodushierarchien oder reguläre Ausdrücken mithilfe der Anweisung entfernt die Berechtigungen für die angegebene Konfigurationsmodushierarchie und die in der Anweisung angegebenen deny-configurationpermissions Standardberechtigungen.

    Für die folgende Konfiguration kann der Benutzer der Anmeldeklasse beispielsweise die Konfiguration auf Hierarchieebene bearbeiten und Konfigurationsmodusbefehle aus dem Bereich aus dem System eingeben (z. B.), zusätzlich zum Eingaben in den Konfigurationsmodus mithilfe des Befehls. Dabei handelt es sich um die vom Berechtigungs-Flag angegebene [edit system services]commitconfigure Berechtigung:

    In der folgenden Konfiguration ist es dem Benutzer der Anmeldeklasse auch möglich, alle von allen Berechtigungs-Flags zugelassenen Vorgänge auszuführen, es sei denn, es werden Befehle für den Konfigurationsmodus gestartet (z. B.) oder die Konfiguration auf der Hierarchieebene kann geändert commit[edit system services] werden:

  • Die Aussagen schließen sich ausschließlich mit den Aussagen aus, und die Aussagen allow/deny-configurationallow/deny-configuration-regexps enthalten ausschließlich die allow-deny-commandsallow/deny-commands-regexps Aussagen. Beispielsweise können Sie nicht beide als allow-configuration auch nicht in der gleichen allow-configuration-regexps Anmeldeklasse konfigurieren.

  • Wenn Sie über vorhandene Konfigurationen verfügen, die die gleichen Konfigurationsoptionen mit den oder Anweisungen verwenden, erzielen Sie möglicherweise nicht die gleichen Ergebnisse, da die Such- und Übereinstimmungsmethoden in den beiden Formen dieser Anweisungen allow/deny-configurationallow/deny-commands voneinander allow/deny-configuration-regexpsallow/deny-commands-regexps abweichen.

  • Um Zugriffsberechtigungen für Teile der Konfigurationshierarchie zu definieren, geben Sie die vollständigen Pfade in den erweiterten regelmäßigen Ausdrücken mit den und allow-configuration Anweisungen deny-configuration an. Verwenden Sie Klammern um einen erweiterten regulären Ausdruck, der zwei oder mehr Ausdrücke mit dem Pipe-Symbol (|) verbindet.

    Zum Beispiel:

  • Wenn der reguläre Ausdruck Leerzeichen, Operatoren oder Wildcard-Zeichen enthält, können Sie den Ausdruck in Anführungszeichen umschließen. Reguläre Ausdrücke sind nicht fallempfindlich. zum Beispiel allow-commands "show interfaces" .

  • Modifizierer wie "set","log"und "count" werden innerhalb der zu bearbeitenden Zeichenfolge des regulären Ausdrucks nicht unterstützt. Wenn ein Änderungser verwendet wird, dann ist nichts übereinstimmend.

    Falsche Konfiguration:

    Richtige Konfiguration:

  • Bei der Angabe komplexer regulärer Ausdrücke mit der Anweisung sind Anker allow-commands erforderlich.

    Zum Beispiel:

  • Beim Angeben erweiterter regulärer Ausdrücke mithilfe von und Anweisungen muss jeder durch ein Pipe allow/deny-commands (|)-Symbol getrennte Ausdruck ein vollständiger eigenständiger Ausdruck sein und in Klammern ( ) eingeschlossen allow/deny-configuration sein. Verwenden Sie keine Leerzeichen zwischen regulären Ausdrücken, die mit Klammern voneinander getrennt sind und mit dem Pipe-Symbol (|) verbunden sind.

    Zum Beispiel:

  • Bei der Angabe erweiterter regulärer Ausdrücke mithilfe der Oder Anweisung muss jeder in Anführungen (") und durch einen Raum getrennte Ausdruck in eine winkel Klammern [ ] eingeschlossen allow/deny-configuration-regexpsallow/deny-commands-regexps sein.

    Zum Beispiel:

  • Sie können das * Wildcard-Zeichen verwenden, wenn Sie reguläre Ausdrücke ausdrücken. Sie muss jedoch als Teil eines regelmäßigen Ausdrucks verwendet werden. Sie können [ * ] oder [ .* ] nicht allein verwenden.

  • Sie können die allow-configuration Anweisung nicht mit den Schnittstellen (Beschreibung (|. *)) regelmäßiger Ausdruck, da dieser zum regelmäßigen allow-configuration = .* Ausdruck ausgewertet wird.

  • Sie können so viele reguläre Ausdrücke konfigurieren, wie erforderlich, um zu berechtigt oder abgelehnt zu werden. Reguläre ausdrücke, die abgelehnt werden, nehmen Rangfolge vor zu zulässigen Konfigurationen ein.

Topologie

Abbildung 1: Konfigurieren der TACACS+ ServerauthentifizierungKonfigurieren der TACACS+ Serverauthentifizierung

Abbildung 1 zeigt eine einfache Topologie, bei der Router R1 ein Juniper Networks und über eine TCP-Verbindung mit einem TACACS+-Server verfügt.

In diesem Beispiel wird R1 mit drei angepassten Anmeldeklassen konfiguriert – Class1, Class2 und Class3 –, um Zugriffsberechtigungen für erweiterte reguläre Ausdrücke anzugeben, die die Anweisungen unterschiedlich allow-commandsdeny-commands verwenden.

Im Folgenden sind für jede Anmeldeklasse folgende Zwecke zu verwenden:

  • Class1— Definiert Zugriffsberechtigungen für Benutzer, die nur allow-commands die Anweisung verwenden. Diese Anmeldeklasse bietet Benutzerberechtigungen auf Betreiberebene und sollte autorisierungen nur für den Neustart des Geräts bereitstellen.

  • Class2— Definiert Zugriffsberechtigungen für Benutzer, die nur deny-commands die Anweisung verwenden. Diese Anmeldeklasse bietet Benutzerberechtigungen auf Betreiberebene und sollte den Zugriff auf Befehle set verweigern.

  • Class3— Definiert Zugriffsberechtigungen für den Benutzer sowohl mit den allow-commandsdeny-commands Anweisungen als auch Diese Anmeldeklasse bietet Benutzerberechtigungen auf Superuser-Ebene und sollte die Autorisierung für den Zugriff auf Schnittstellen und die Anzeige von Geräteinformationen bereitstellen. Es sollte auch den Zugriff auf und die edit Befehle configure verweigern.

Router R1 verfügt über drei verschiedene Benutzer, Benutzer1, Benutzer2 und Benutzer3, die jeweils Class1-, Class2- und Class 3-Anmeldeklassen zugewiesen sind.

Konfiguration

CLI-Konfiguration

Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit Ihrer Netzwerkkonfiguration erforderlich sind, kopieren Sie die Befehle, kopieren Sie die Befehle in die CLI der Hierarchieebene, und geben Sie sie dann im Konfigurationsmodus [edit]commit ein.

R1

Konfigurieren von Authentifizierungsparametern für Router R1

Schritt-für-Schritt-Verfahren

Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation auf der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI Benutzerhandbuch.

So konfigurieren Sie die Router R1-Authentifizierung:

  1. Konfigurieren Sie die Reihenfolge, in der die Authentifizierung für R1 stattfinden soll. In diesem Beispiel folgt zunächst die TACACS+-Serverauthentifizierung, RADIUS und dann das lokale Kennwort.

  2. Richten Sie die R1-Verbindung mit dem TACACS+-Server ein.

  3. Konfiguration RADIUS-Authentifizierungsparameter

  4. Konfigurieren Sie die Konfigurationsparameter für das R1-Accounting.

Konfigurieren von Zugriffsberechtigungen mit allow-commands Statement Only (Class1)

Schritt-für-Schritt-Verfahren

Um reguläre Ausdrücke nur mit der allow-commands Anweisung anzugeben:

  1. Konfigurieren Sie die benutzerdefinierte Anmeldeklasse Class1 und weisen Sie Benutzerberechtigungen auf Betreiberebene zu. Informationen zu den vordefinierten Systemanmeldungsklassen finden Sie in der Übersicht Junos OS Anmeldeklassen.

  2. Geben Sie den Befehl zum Aktivieren des Neustarts von R1 in der Anweisung allow-commands an.

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

Konfigurieren von Zugriffsberechtigungen mit Deny-Commands Statement Only (Class2)

Schritt-für-Schritt-Verfahren

Um reguläre Ausdrücke nur mit der deny-commands Anweisung anzugeben:

  1. Konfigurieren Sie die benutzerdefinierte Class2-Anmeldeklasse und weisen Sie Benutzerberechtigungen auf Betreiberebene zu. Informationen zu den vordefinierten Systemanmeldungsklassen finden Sie in der Übersicht Junos OS Anmeldeklassen.

  2. Deaktivieren Sie die Ausführung beliebiger Set-Befehle in der deny-commands Anweisung.

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

Konfigurieren von Zugriffsberechtigungen mit Allow-Commands und Deny-Commands Anweisungen (Class3)

Schritt-für-Schritt-Verfahren

Zum Angeben regulärer Ausdrücke mit sowohl der allow-commands Anweisungen als auch deny-commands der Anweisungen:

  1. Konfigurieren Sie die benutzerdefinierte Class-3-Anmeldeklasse und weisen Sie Benutzerberechtigungen auf Endbenutzerebene zu. Informationen zu den vordefinierten Systemanmeldungsklassen finden Sie in der Übersicht Junos OS Anmeldeklassen.

  2. Geben Sie die Befehle an, mit denen Sie in der Anweisung nur Befehle allow-commands konfigurieren können.

  3. Deaktivieren Sie die Ausführung aller Befehle in deny-commands der Anweisung.

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

Ergebnisse

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

Überprüfung

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

Überprüfung der Class1-Konfiguration

Zweck

Stellen Sie sicher, dass die in der Class1-Anmeldeklasse zugelassenen Berechtigungen und Befehle funktionieren.

Aktion

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

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

Bedeutung

Die Anmeldeklasse Class1, der Benutzer1 zugewiesen wird, verfügt über die Benutzerberechtigungen auf Betreiberebene und ist zum Ausführen des request system reboot Befehls berechtigt.

Die vordefinierte Operator-Anmeldeklasse verfügt über die folgenden Berechtigungs-Flags:

  • clear— Kann mithilfe der Befehle aus dem Netzwerk gelernte Informationen löschen (löschen), die in verschiedenen Netzwerkdatenbanken gespeichert clear sind.

  • network— Kann mit den, und Befehlen pingssh auf das Netzwerk telnettraceroute zugreifen.

  • reset— Können Softwareprozesse mithilfe des Befehls neu starten und konfigurieren, ob Softwareprozesse auf der restart Hierarchieebene aktiviert oder [edit system processes] deaktiviert sind.

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

  • view— Ermöglicht die Verwendung verschiedener Befehle zur Anzeige der aktuellen systemweiten, Routing-Tabelle und protokollspezifischer Werte und Statistiken. Die geheime Konfiguration kann nicht angezeigt werden.

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

Überprüfung der Class2-Konfiguration

Zweck

Stellen Sie sicher, dass die berechtigungen und Befehle der Class 2-Anmeldeklasse funktionieren.

Aktion

Führen Sie im Betriebsmodus den Befehl ping aus.

Überprüfen Sie CLI Eingabeaufforderung die verfügbaren Berechtigungen.

Führen Sie CLI jeden festgelegten Befehl aus.

Bedeutung

Die Anmeldeklasse Class2, der Benutzer2 zugewiesen wird, besitzt die Benutzerberechtigungen auf Betreiberebene und wird dem Zugriff auf alle Befehle set verweigert. Dies wird in den Befehlsausgänge angezeigt.

Die für die Anmeldeklasse des vordefinierten Betreibers angegebenen Berechtigungs-Flags sind die gleichen wie in Klasse 1.

Überprüfung der Class 3-Konfiguration

Zweck

Stellen Sie sicher, dass die für die Class 3-Anmeldeklasse zugelassenen Berechtigungen und Befehle funktionieren.

Aktion

Überprüfen Sie CLI Eingabeaufforderung die verfügbaren Berechtigungen.

Geben Sie im Betriebsmodus den Konfigurationsmodus ein.

Bedeutung

Die Anmeldeklasse Class3, der Benutzer3 zugewiesen wird, verfügt über die Superuser-Benutzerberechtigungen (alle), darf aber nur den Befehl ausführen, und es wird der Zugriff auf alle anderen Betriebsmodusbefehle configure verweigert. Da die in den Anweisungen angegebenen reguläre Ausdrücke Vorrang vor den Benutzerberechtigungen haben, hat User3 auf R1 nur Zugriff auf den Konfigurationsmodus und wird dem Zugriff auf alle anderen Betriebsmodusbefehle allow/deny-commands verweigert.

Beispiel: Konfigurieren von Benutzerberechtigungen mit Zugriffsberechtigungen für Konfigurations anweisungen und Hierarchien

In diesem Beispiel wird gezeigt, wie Sie benutzerdefinierte Anmeldeklassen konfigurieren und Teiln der Konfigurationshierarchie Zugriffsberechtigungen zuweisen. Auf diese Weise können Benutzer der angepassten Anmeldeklasse nur Konfigurations anweisungen und Hierarchien ausführen, für die Zugriffsberechtigungen angegeben wurden. Auf diese Weise können nicht autorisierte Benutzer auf Gerätekonfigurationen zugreifen, die im Netzwerk zu Schäden führen könnten.

Anforderungen

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

  • Ein Juniper Networks Gerät

  • Ein TACACS+-Server (oder RADIUS)

  • Junos OS das auf einem Gerät ausgeführte Juniper Networks aufbauen

Bevor Sie beginnen:

  • Herstellen einer TCP-Verbindung zwischen dem Gerät und dem TACACS+-Server. Stellen Sie im Fall eines RADIUS-Servers eine UDP-Verbindung zwischen dem Gerät und dem Server RADIUS.

    Informationen zur Konfiguration eines TACACS+-Servers finden Sie unter Konfigurieren der TACACS+-Authentifizierung.

  • Konfigurieren Sie mindestens einen Benutzer, dem eine Anmeldeklasse auf dem Juniper Networks zugewiesen ist. Es kann mehr als eine Anmeldeklasse mit unterschiedlichen Berechtigungskonfigurationen und mehr als einem Benutzer auf dem Gerät geben.

Überblick und Topologie

Jeder Befehl auf der obersten Befehlszeilenschnittstelle (CLI) (CLI) und jede Konfigurationserklärung in Junos OS verfügt über eine entsprechende Zugriffsrechteebene. Für jede Anmeldeklasse können Sie die Verwendung von Befehlen im Betriebs- und Konfigurationsmodus explizit verweigern oder zulassen, die ansonsten nach einer Berechtigungsebene zulässig oder nicht zulässig wären. Benutzer können nur die Befehle ausführen und nur die Anweisungen konfigurieren und anzeigen, für die sie Zugriffsberechtigungen haben. Um Zugriffsberechtigungsebenen zu konfigurieren, fügen Sie die permissions Anweisung auf der [edit system login class class-name] Hierarchieebene ein.

Die Zugriffsberechtigungen für jede Anmeldeklasse werden durch einen oder mehrere in der Anweisung angegebene Berechtigungs-Flags permissions definiert. Darüber hinaus können Sie erweiterte reguläre Ausdrücke mit den folgenden Anweisungen angeben:

  • allow-commands und deny-commands – Zugriff auf Betriebsmodusbefehle zulassen oder verweigern.

  • allow-configuration und – Zugriff auf Teile der Konfigurationshierarchie zulassen deny-configuration oder verweigern.

    Diese Anweisungen bieten eine langsamere Anpassung mit größerer Flexibilität, insbesondere beim Wildcard-Abgleich. Es kann jedoch sehr lange dauern, alle möglichen Anweisungen zu beurteilen, wenn eine große Anzahl regulärer Ausdrücke mit vollem Pfad oder Platzhalter-Ausdrücke konfiguriert ist, was sich möglicherweise auf die Leistung auswirken kann.

  • allow-configuration-regexps und – Zugriff auf eine bestimmte Konfigurationshierarchie mit deny-configuration-regexps Zeichenfolgen regulärer Ausdrücke zulassen oder verweigern. Diese Anweisungen sind denen und Anweisungen ähnlich. In den Anweisungen können Sie aber Zeichenfolgensätze konfigurieren, in denen die Zeichenfolgen Leerzeichen enthalten, wenn Sie die erste allow-configurationdeny-configurationallow/deny-configuration-regexps Anweisungssätze verwenden.

Die oben genannten Anweisungen definieren die Zugriffsrechte eines Benutzers auf einzelne Betriebsmodusbefehle, Konfigurations anweisungen und Hierarchien. Diese Anweisungen haben Vorrang vor einem Bitsatz für Anmeldeklassenberechtigungen für einen Benutzer.

Difference between allow/deny-configuration and allow/deny-configuration-regexps statements

Die allow-configuration Angaben deny-configuration und Anweisungen wurden vor der Junos OS Version 7.4 eingeführt. Die allow-configuration-regexps Angaben und Angaben wurden in Junos OS Version deny-configuration-regexps 11.2 eingeführt. In Junos OS Version 11.4 wurden die Anweisungen und Anweisungen nicht mehr angezeigt. Da diese Anweisungen jedoch bei der Ausführung einfacher Konfigurationen nützlich waren, waren diese Anweisungen in Junos OS Release 11.4R6 nicht mehr enthalten. Und ab der 11.4R6-Version werden sowohl die Anweisungen als auch die Anweisungen allow-configurationdeny-configurationallow/deny-configurationallow/deny-configuration-regexps unterstützt.

Die Anweisungen teilen den regelmäßigen Ausdruck in Token auf und stimmen jedes Stück mit jedem Teil des vollständigen Pfads der angegebenen Konfiguration ab, während die Anweisungen mit dem vollständigen String allow/deny-configuration-regexpsallow/deny-configuration übereinstimmen. Für Anweisungen konfigurieren Sie eine Gruppe von Zeichenfolgen, in denen jeder String ein regulärer Ausdruck ist, mit Leerzeichen zwischen den Bedingungen allow/deny-configuration-regexps der Zeichenfolge. Dies ermöglicht eine schnelle Anpassung, jedoch mit weniger Flexibilität. Zum Angeben von Wildcard-Ausdrücken müssen Sie Wildcards für jedes Token der zeichenbasierten, nicht voneinander abgegrenzten Zeichenfolge einrichten. Die Verwendung von Platzhalter-Ausdrücken für diese Anweisungen wird dadurch schwieriger.

Zum Beispiel:

  • Regulärer Ausdruck, der ein Token über allow-configuration-regexps abgleicht

    In diesem Beispiel wird options gezeigt, dass es sich um den einzigen Übereinstimmungsausdruck mit dem ersten Token der Aussage handelt.

    Die oben genannte Konfiguration entspricht den folgenden Anweisungen:

    • Set options Policy-Condition Condition Dynamic-db

    • Set Routing – options statische Route Static Route Next-Hop Next-Hop Next-Hop

    • set event- options generate-event time-interval seconds (set event-generate-event time-interval seconds)

    Die oben genannte Konfiguration passt nicht zu den folgenden Anweisungen:

    • Hostname des Systemsoptions

    • Schnittstellennameoptions

  • Regulärer Ausdruck, der drei Token über allow-configuration-regexps abgleicht

    In diesem Beispiel wird ssh der einzige übereinstimmungsbasierte Ausdruck mit dem dritten Token der Aussage angezeigt.

    Im obigen Beispiel enthalten die drei Token .*.*.*ssh bzw.

    Die oben genannte Konfiguration entspricht den folgenden Anweisungen:

    • Hostname des Systemsssh

    • Systemservices ssh

    • ausgehende Systemservicesssh

    Die oben genannte Konfiguration ist nicht mit der folgenden Aussage übereinstimmend:

    • Schnittstellennamessh

Sie können den Konfigurationszugriff mithilfe der Anweisung, die sie mithilfe der Anweisung vergleicht, leicht einschränken. Erläutert die Verwendung der Anweisungen und Anweisungen in verschiedenen Konfigurationen, um dasselbe Ergebnis der Beschränkung des Zugriffs auf eine bestimmte Konfiguration deny-configurationdeny-configuration-regexps zu Tabelle 6deny-configurationdeny-configuration-regexps erzielen.

Tabelle 6: Begrenzung des Konfigurationszugriffs Mit Anweisungen zu "Deny Configurtion and Deny-configuration-regexps"

Konfiguration abgelehnt

Mit: Konfiguration verweigern

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"";
    }
}

Folgende Konfiguration 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 Konfigurationserklärungen werden abgelehnt:

  • System hostname hostname-ssh

  • System-Services SSH

  • Systemservices ausgehender SSH

  • Security SSH-known-Host

Obwohl die Anweisungen auch dann nützlich sind, wenn eine einfache Konfiguration gewünscht ist, bieten die Anweisungen eine bessere Leistung und überwinden die Probleme, die bei der Kombination der in den Anweisungen festgelegten Ausdrücke allow/deny-configurationallow/deny-configuration-regexps vorhanden allow/deny-configuration waren.

Anmerkung:

Diese Anweisungen und Anweisungen schließen sich gegenseitig aus und können allow/deny-configuration nicht gemeinsam für eine allow/deny-configuration-regexps Anmeldeklasse konfiguriert werden. Zu einem bestimmten Zeitpunkt kann eine Anmeldeklasse entweder die Anweisung allow/deny-configuration oder die Aussage allow/deny-configuration-regexps enthalten. Wenn Sie über vorhandene Konfigurationen verfügen, die die Anweisungen verwenden, können dieselben Konfigurationsoptionen mit den Anweisungen unter Umständen nicht die gleichen Ergebnisse erzielen, da die Such- und Übereinstimmungsmethoden in den beiden Formen dieser Anweisungen allow/deny-configurationallow/deny-configuration-regexps voneinander abweichen.

Configuration Notes

Berücksichtigen Sie bei der Konfiguration von , und Anweisungen mit Zugriffsberechtigungen allow-configurationdeny-configurationallow-configuration-regexpsdeny-configuration-regexps Folgendes:

  • Sie können in jeder Anmeldeklasse eine deny-configuration und eine Anweisung allow-configuration enthalten.

  • Diese Anweisungen und Anweisungen schließen sich gegenseitig aus und können allow/deny-configuration nicht gemeinsam für eine allow/deny-configuration-regexps Anmeldeklasse konfiguriert werden. Zu einem bestimmten Zeitpunkt kann eine Anmeldeklasse entweder die Anweisung allow/deny-configuration oder die Aussage allow/deny-configuration-regexps enthalten. Wenn Sie über vorhandene Konfigurationen verfügen, die die Anweisungen verwenden, können dieselben Konfigurationsoptionen mit den Anweisungen unter Umständen nicht die gleichen Ergebnisse erzielen, da die Such- und Übereinstimmungsmethoden in den beiden Formen dieser Anweisungen allow/deny-configurationallow/deny-configuration-regexps voneinander abweichen.

  • Das explizite Zulassen von Konfigurationsmodushierarchien oder reguläre Ausdrücken mithilfe der Anweisung fügt den regulären allow-configuration Berechtigungssatz mithilfe der Anweisung permissions hinzu. Auch die explizite Ab verweigern von Konfigurationsmodushierarchien oder reguläre Ausdrücken mithilfe der Anweisung entfernt die Berechtigungen für die angegebene Konfigurationsmodushierarchie und die in der Anweisung angegebenen deny-configurationpermissions Standardberechtigungen.

    Für die folgende Konfiguration kann der Benutzer der Anmeldeklasse beispielsweise die Konfiguration auf Hierarchieebene bearbeiten und Konfigurationsmodusbefehle aus dem Bereich aus dem System eingeben (z. B.), zusätzlich zum Eingaben in den Konfigurationsmodus mithilfe des Befehls. Dabei handelt es sich um die vom Berechtigungs-Flag angegebene [edit system services]commitconfigure Berechtigung:

    In der folgenden Konfiguration ist es dem Benutzer der Anmeldeklasse auch möglich, alle von allen Berechtigungs-Flags zugelassenen Vorgänge auszuführen, es sei denn, es werden Befehle für den Konfigurationsmodus gestartet (z. B.) oder die Konfiguration auf der Hierarchieebene kann geändert commit[edit system services] werden:

  • Um Zugriffsberechtigungen für Teile der Konfigurationshierarchie zu definieren, geben Sie die vollständigen Pfade in den erweiterten regelmäßigen Ausdrücken mit den und allow-configuration Anweisungen deny-configuration an. Verwenden Sie Klammern um einen erweiterten regulären Ausdruck, der zwei oder mehr Ausdrücke mit dem Pipe-Symbol (|) verbindet.

    Zum Beispiel:

  • Beim Angeben erweiterter regulärer Ausdrücke mithilfe von und Anweisungen muss jeder durch ein Pipe allow/deny-commands (|)-Symbol getrennte Ausdruck ein vollständiger eigenständiger Ausdruck sein und in Klammern ( ) eingeschlossen allow/deny-configuration sein. Verwenden Sie keine Leerzeichen zwischen regulären Ausdrücken, die mit Klammern voneinander getrennt sind und mit dem Pipe-Symbol (|) verbunden sind.

    Zum Beispiel:

  • Bei der Angabe erweiterter regulärer Ausdrücke mithilfe der Anweisung muss jeder Ausdruck in Anführungen (") und durch einen Bereich voneinander getrennt in einer gekapselten Klammer allow-deny-configuration-regexps stehen [ ].

    Zum Beispiel:

  • Wenn unter beiden Anweisungen derselbe Befehl konfiguriert ist, hat der Vorgang "Zulassen" Vorrang allow-configurationdeny-configuration vor der Deny-Anweisung.

    Mit der folgenden Konfiguration kann beispielsweise ein Benutzer, dem ein Anmeldeklassentest zugewiesen ist, auf die Konfigurationshierarchie zugreifen. Die Anweisung enthält jedoch [edit system services]deny-configuration auch:

    Wenn beispielsweise ein bestimmter Befehl oder eine bestimmte Konfiguration zulässig ist, z. B. über Berechtigungsalle, können wir den Befehl verwenden, um den Zugriff auf eine bestimmte deny-configuration Hierarchie zu verweigern.

  • Modifizierer wie "set","log"und "count" werden innerhalb der zu bearbeitenden Zeichenfolge des regulären Ausdrucks nicht unterstützt. Wenn ein Änderungser verwendet wird, dann ist nichts übereinstimmend.

    Falsche Konfiguration:

    Richtige Konfiguration:

  • Sie können das * Wildcard-Zeichen verwenden, wenn Sie reguläre Ausdrücke ausdrücken. Sie muss jedoch als Teil eines regelmäßigen Ausdrucks verwendet werden. Sie können [ * ] oder [ .* ] nicht allein verwenden.

  • Sie können die allow-configuration Anweisung nicht mit den Schnittstellen (Beschreibung (|. *)) regelmäßiger Ausdruck, da dieser zum regelmäßigen allow-configuration = .* Ausdruck ausgewertet wird.

  • Sie können so viele reguläre Ausdrücke konfigurieren, wie erforderlich, um zu berechtigt oder abgelehnt zu werden. Reguläre ausdrücke, die abgelehnt werden, nehmen Rangfolge vor zu zulässigen Konfigurationen ein.

Topologie

Abbildung 2: Konfigurieren der TACACS+ ServerauthentifizierungKonfigurieren der TACACS+ Serverauthentifizierung

Abbildung 2 zeigt eine einfache Topologie, bei der Router R1 ein Juniper Networks und über eine TCP-Verbindung mit einem TACACS+-Server verfügt.

In diesem Beispiel wird R1 mit zwei angepassten Anmeldeklassen konfiguriert – Class1 und Class2 –, um Zugriffsberechtigungen mit erweiterten regelmäßigen Ausdrücken mit den , und Anweisungen anders allow-configurationdeny-configurationallow-configuration-regexpsdeny-configuration-regexps anzugeben.

Die Anmeldeklassen dienen folgendem Zweck:

  • Class1— Definieren der Zugriffsberechtigungen für den Benutzer mit den allow-configurationdeny-configuration Anweisungen. Diese Anmeldeklasse sollte Zugriff nur auf die Schnittstellenhierarchie bereitstellen und allen anderen Zugriff auf das Gerät verweigern. Hierzu sollten die Benutzerberechtigungen auch so konfiguriert werden, dass Konfigurationszugriff gewährt wird. Darüber hinaus sollte diese Aussage die Konfiguration der Schnittstellen ermöglichen und allen anderen Konfigurationen den allow-configurationdeny-configuration Zugriff verweigern. Da die Allow-Anweisung Vorrang vor der Deny Statement hat, können die Benutzer, die der Klasse 1-Anmeldeklasse zugewiesen werden, nur auf die [edit interfaces] Hierarchieebene zugreifen.

  • Class2— Definieren der Zugriffsberechtigungen für den Benutzer mit den allow-configuration-regexpsdeny-configuration-regexps Anweisungen. Diese Anmeldeklasse bietet Benutzerberechtigungen auf Superuser-Ebene und zusätzlich die explizite Konfiguration unter mehreren Hierarchieebenen für Schnittstellen. Auch der Konfigurationszugriff auf die [edit system] Hierarchieebenen wird [edit protocols] verweigert.

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

Konfiguration

CLI-Konfiguration

Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit Ihrer Netzwerkkonfiguration erforderlich sind, kopieren Sie die Befehle, kopieren Sie die Befehle in die CLI der Hierarchieebene, und geben Sie sie dann im Konfigurationsmodus [edit]commit ein.

R1

Konfigurieren von Authentifizierungsparametern für Router R1

Schritt-für-Schritt-Verfahren

Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zur Navigation auf der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI Benutzerhandbuch.

So konfigurieren Sie die Router R1-Authentifizierung:

  1. Konfigurieren Sie die Reihenfolge, in der die Authentifizierung für R1 stattfinden soll. In diesem Beispiel folgt zunächst die TACACS+-Serverauthentifizierung, RADIUS-Serverauthentifizierung und dann das lokale Kennwort.

  2. Richten Sie die R1-Verbindung mit dem TACACS+-Server ein.

  3. Konfiguration RADIUS-Authentifizierungsparameter

  4. Konfigurieren Sie die Konfigurationsparameter für das R1-Accounting.

Konfigurieren von Zugriffsberechtigungen mit Anweisungen zur Konfigurationsberechtigung und Konfiguration des Verweigerns (Class1)

Schritt-für-Schritt-Verfahren

Zum Angeben regulärer Ausdrücke mit den allow-configurationdeny-configuration Anweisungen:

  1. Konfigurieren Sie die benutzerdefinierte Anmeldeklasse Class1 und weisen Sie Benutzerberechtigungen der Konfiguration zu.

  2. Geben Sie den regelmäßigen Ausdruck in der allow-configuration Anweisung an, um die Konfiguration auf der [edit interfaces] Hierarchieebene zu ermöglichen. Um Befehle set auf [edit interfaces] Hierarchieebene zu ermöglichen, wird der reguläre Ausdruck interfaces .* unit .* verwendet.

  3. Geben Sie den regulären Ausdruck in der deny-configuration Anweisung an, um alle Konfigurationszugriffe zu deaktivieren. Der reguläre Ausdruck, der verwendet wird, um allen Konfigurationszugriff zu verweigern, ist .* .

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

Konfigurieren von Zugriffsberechtigungen mit Allow-configuration-regexps und Deny-configuration-regexps-Anweisungen (Class2)

Schritt-für-Schritt-Verfahren

Zum Angeben regulärer Ausdrücke mit den allow-configuration-regexpsdeny-configuration-regexps Anweisungen:

  1. Konfigurieren Sie die benutzerdefinierte Class2-Anmeldeklasse und weisen Sie Superuser (alle) Benutzerberechtigungen zu. Informationen zu den vordefinierten Systemanmeldungsklassen finden Sie in der Übersicht Junos OS Anmeldeklassen.

  2. Geben Sie den regelmäßigen Ausdruck an, um zugriff auf mehrere Hierarchien in der [edit interfaces] Hierarchieebene zu ermöglichen.

  3. Geben Sie den regelmäßigen Ausdruck an, um konfigurationen auf den und [edit system][edit protocols] Hierarchieebenen zu verweigern.

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

Ergebnisse

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

Überprüfung

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

Überprüfung der Class1-Konfiguration

Zweck

Stellen Sie sicher, dass die in der Class1-Anmeldeklasse zulässigen Berechtigungen funktionieren.

Aktion

Überprüfen Sie CLI Eingabeaufforderung die verfügbaren Berechtigungen.

Prüfen Sie im Konfigurationsmodus die verfügbaren Konfigurationsberechtigungen.

Bedeutung

Benutzer1 konfiguriert die in der ersten Ausgabe angezeigten Benutzerberechtigungen, und der einzige zulässige Konfigurationszugriff für Benutzer1 ist die Schnittstellenhierarchieebene. Alle anderen Konfigurationen werden abgelehnt, wie in der zweiten Ausgabe zu sehen.

Überprüfung der Class2-Konfiguration

Zweck

Stellen Sie sicher, dass die Class2-Konfiguration funktioniert.

Aktion

Greifen Sie über den Konfigurationsmodus auf die Schnittstellenkonfiguration zu.

Greifen Sie über den Konfigurationsmodus auf die System- und Protokollkonfigurationshierarchien zu.

Bedeutung

Benutzer2 hat Berechtigungen für die Konfiguration von R1-Schnittstellen, aber den Hierarchieebenen wird der Zugriff verweigert, wie in der [edit system][edit protocols] Ausgabe zu sehen.