Benutzerzugriffsrechte

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 .

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.

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.

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.

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.

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

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

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.

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.

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

Angeben regulärer Ausdrücke

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.

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

[edit system login class class-name]
user@host# set permissions configure
user@host# set deny-configuration "interfaces .* unit .*"

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

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

Operatoren regulärer Ausdrücke

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

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

[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)"

[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)"

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

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

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

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

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

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

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

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.

[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" ]

[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" ]

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

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

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

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

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