Zugriffsrechte des Benutzers

Berechtigungsflags für Anmeldeklassen

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

Die permissions Anweisung gibt eines oder mehrere der Berechtigungsflags an, die in aufgeführt sind Tabelle 1. Berechtigungsflags sind nicht kumulativ. Für jede Klasse müssen Sie alle erforderlichen Berechtigungsflags auflisten, einschließlich view der Anzeige von Informationen und configure des Zugriffs in den Konfigurationsmodus. Zwei Arten von Berechtigungen steuern den Zugriff eines Benutzers auf die einzelnen Teile der Konfiguration:

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

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

Bei Berechtigungsflags, die Zugriff auf Konfigurationshierarchieebenen und -anweisungen gewähren, gewähren die einfachen Formularflags Leseberechtigung für diese Konfiguration. Das Berechtigungskennzeichen gewährt z.B interface . schreibgeschützten Zugriff auf die Hierarchieebene [edit interfaces] . Die -control Form des Flags gewährt Lese-/Schreibzugriff auf diese Konfiguration. Das Kennzeichen interface-control gewährt z.B. Lese-/Schreibzugriff auf die Hierarchieebene [edit interfaces] .

Tabelle 1 Listet die Berechtigungsflags der Anmeldeklasse auf, die Sie konfigurieren können, indem Sie die permissions Anweisung auf Hierarchieebene [edit system login class class-name] einschließen.

Die Berechtigungsflags gewähren einen bestimmten Satz von Zugriffsberechtigungen. Jedes Berechtigungsflag wird mit den Befehlen für den Betriebsmodus oder Konfigurationsmodus sowie den Konfigurationshierarchieebenen und -anweisungen aufgeführt, für die dieses Flag Zugriff gewährt.

Zulassen und Verweigern einzelner Befehle und Anweisungshierarchien für Anmeldeklassen

Standardmäßig verfügen alle CLI-Befehle und Konfigurationshierarchieebenen der obersten Ebene über zugeordnete Zugriffsberechtigungsebenen. Benutzer können nur die Befehle ausführen und nur die Anweisungen anzeigen und konfigurieren, für die sie über Zugriffsrechte verfügen. Für jede Anmeldeklasse können Sie die Verwendung von Befehlen und Anweisungshierarchien für den Betriebsmodus und Konfigurationsmodus, die andernfalls durch eine in der permissions Anweisung angegebene Berechtigungsstufe zugelassen oder verweigert würden, explizit zulassen oder verweigern.

Berechtigungsflags gewähren einem Benutzer Zugriff auf Betriebsmodus- und Konfigurationsmodusbefehle sowie auf Konfigurationshierarchieebenen und -anweisungen. Durch die Angabe eines bestimmten Berechtigungsflags für die Anmeldeklasse des Benutzers auf Hierarchieebene [edit system login class] gewähren Sie dem Benutzer Zugriff auf die entsprechenden Befehle und Konfigurationshierarchieebenen und -anweisungen. Um Zugriff auf alle Befehle und Konfigurationsanweisungen zu gewähren, verwenden Sie das all Berechtigungsflag.

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

Grundlegendes zu den allow- und deny-Anweisungen

Jeder CLI-Befehls- und Konfigurationsanweisungshierarchie der obersten Ebene ist eine Zugriffsberechtigungsebene zugeordnet. Jede Anmeldeklasse kann die Verwendung von Befehlen für den Betriebsmodus und Konfigurationsmodus sowie von Konfigurationshierarchien und -anweisungen, die andernfalls durch eine Berechtigungsstufe zugelassen oder verweigert würden, explizit zulassen oder verweigern. Benutzer können nur die Befehle ausführen und nur die Anweisungen anzeigen und konfigurieren, für die sie über Zugriffsrechte verfügen.

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

• allow-commands and deny-commands—Erlauben oder verweigern Sie den Zugriff auf Befehle für den Betriebsmodus und den Konfigurationsmodus.

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

  HINWEIS:

  Diese Anweisungen führen einen langsameren Abgleich mit mehr Flexibilität durch, insbesondere beim Platzhalterabgleich. Es kann jedoch sehr lange dauern, alle möglichen Anweisungen auszuwerten, wenn eine große Anzahl von regulären Ausdrücken für den gesamten Pfad oder Platzhalterausdrücke konfiguriert sind, was sich möglicherweise negativ auf die Leistung auswirkt.

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

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

Durch das explizite Zulassen von Befehlen und Konfigurationsanweisungshierarchien mithilfe der allow/deny-* Anweisungen werden die bereits in der permissions Anweisung definierten Berechtigungen erweitert. Ebenso werden durch das explizite Verweigern von Befehlen und Konfigurationsanweisungshierarchien mithilfe der allow/deny-* Anweisungen Berechtigungen entfernt, die in der permissions Anweisung bereits definiert sind.

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

In ähnlicher Weise kann der Benutzer der Anmeldeklasse in der folgenden Konfiguration alle Vorgänge ausführen, die das all Berechtigungsflag zulässt, mit der Ausnahme, dass der Benutzer die Konfiguration auf Hierarchieebene [edit system services] nicht anzeigen oder ändern kann:

Grundlegendes zur Syntax von Allow- und Deny-Anweisungen

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

• Sie können beliebig viele reguläre Ausdrücke konfigurieren.

• Bei regulären Ausdrücken wird nicht zwischen Groß- und Kleinschreibung unterschieden

Die allow/deny-commands Aussagen schließen sich gegenseitig mit den allow/deny-commands-regexps Anweisungen aus, und die allow/deny-configuration Aussagen schließen sich gegenseitig mit den allow/deny-configuration-regexps Anweisungen aus. Sie können z. B. nicht sowohl als auch allow-configurationallow-configuration-regexps in derselben Anmeldeklasse konfigurieren.

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

Beispiele:

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

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

Beispiele:

Wenn Sie erweiterte reguläre Ausdrücke mit der allow/deny-commands-regexps oder-Anweisung allow/deny-configuration-regexps angeben, schließen Sie jeden Ausdruck in Anführungszeichen (" ") ein, und trennen Sie die Ausdrücke durch ein Leerzeichen. Schließen Sie mehrere Ausdrücke in eckige Klammern [ ] ein. Beispiele:

Modifizierer wie set, logund count werden in der Zeichenfolge für reguläre Ausdrücke, die abgeglichen werden soll, nicht unterstützt. Wenn Sie einen Modifikator verwenden, wird nichts abgeglichen.

Korrekte Konfiguration:

Falsche Konfiguration:

Grundlegendes zur Rangfolge und zum Abgleich von allow- und deny-Anweisungen

Standardmäßig haben die allow-commands regulären Ausdrücke und allow-configuration Vorrang vor deny-commands und deny-configuration Ausdrücken. Wenn Sie also denselben Befehl für die allow-commandsdeny-commands and-Anweisung konfigurieren, hat der allow-Vorgang Vorrang vor dem deny-Vorgang. Wenn Sie dieselbe Anweisung für die allow-configurationdeny-configuration and-Anweisung konfigurieren, hat der allow-Vorgang Vorrang vor dem deny-Vorgang.

Die folgende Konfiguration ermöglicht es z. B. einem Benutzer in der test login-Klasse, Software mit dem request system software add Befehl zu installieren, obwohl die deny-commands Anweisung denselben Befehl enthält:

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

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

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

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

Grundlegendes zu den Regeln für die Anweisung "Zulassen" und "Verweigern"

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

• Reguläre Ausdrücke für allow-commands and-Anweisungen deny-commands können auch die commitBefehle , load, rollback, save, statusund update enthalten.

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

• Benutzer können den Befehl nicht ausgeben, load override wenn sie einen erweiterten regulären Ausdruck angeben. Benutzer können nur die mergeKonfigurationsbefehle , replaceund patch ausführen.

• Sie können das Platzhalterzeichen * verwenden, wenn Sie reguläre Ausdrücke kennzeichnen. Sie müssen es jedoch als Teil eines regulären Ausdrucks verwenden. Sie können oder [ .* ] nicht als einzigen Ausdruck verwenden[ * ]. Darüber hinaus können Sie die allow-configuration Anweisung nicht mit einem Ausdruck wie , (interfaces (description (|.*))konfigurieren, da dies zu allow-configuration .*.

Grundlegendes zu den Unterschieden für die *-regexps-Anweisungen

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

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

Beispiele:

• Reguläre Ausdrücke, die mit einem Token übereinstimmen, indem sie allow-configuration-regexps verwenden

  Dieses Beispiel zeigt, dass dies options der einzige übereinstimmende Ausdruck für das erste Token der Anweisung ist.

  Die obige Konfiguration stimmt mit den folgenden Anweisungen überein:

  • Bedingung condition für Richtlinienoptionen festlegen dynamic-db

  • setrouting-options static route static-route next-hop next-hop

  • setevent-options generate-event event time-interval seconds

  Die obige Konfiguration stimmt nicht mit den folgenden Anweisungen überein:

  • host-optionen für den System-Hostnamen

  • Schnittstellenbeschreibungsoptioneninterface-name

• Regulärer Ausdruck, der mit drei Token übereinstimmt, indem allow-configuration-regexps verwendet wird

  Dieses Beispiel zeigt, dass dies ssh der einzige übereinstimmende Ausdruck für das dritte Token der Anweisung ist.

  Im vorherigen Beispiel enthalten .*die drei Token , .*bzw. . . . und .*ssh.

  Die obige Konfiguration stimmt mit den folgenden Anweisungen überein:

  • System-HostnameHostname-SSH

  • Systemdienste SSH

  • Systemdiensteausgehend-ssh

  Die obige Konfiguration stimmt nicht mit der folgenden Anweisung überein:

  • Schnittstellen interface-name Beschreibung SSH

Es ist einfacher, die deny-configuration Anweisung zum Einschränken des Konfigurationszugriffs zu verwenden, als die deny-configuration-regexps Anweisung zu verwenden. Tabelle 2 veranschaulicht die Verwendung der and-Anweisung deny-configurationdeny-configuration-regexps in verschiedenen Konfigurationen, um das gleiche Ergebnis der Beschränkung des Zugriffs auf eine bestimmte Konfiguration zu erzielen.

[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 Mehrdeutigkeit, die beim Kombinieren von Ausdrücken in den allow/deny-configuration Anweisungen bestand.

Verwenden regulärer Ausdrücke auf Remoteautorisierungsservern

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

Wenn Sie mehrere reguläre Ausdrücke in einer lokalen Konfiguration mit der allow-commandsdeny-commandsallow-configuration, , oder deny-configuration -Anweisung angeben, konfigurieren Sie reguläre Ausdrücke in Klammern und trennen sie durch das Pipe-Symbol. Sie schließen den vollständigen Ausdruck in doppelte Anführungszeichen ein. Sie können z. B. mehrere allow-commands Parameter mit der folgenden Syntax angeben:

Der RADIUS-Autorisierungsserver verwendet die folgenden Attribute und Syntax:

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

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

Der RADIUS-Autorisierungsserver verwendet die folgenden Attribute und Syntax:

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

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

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

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

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

Reguläre Ausdrücke angeben

Sie sollten reguläre Ausdrücke für Befehle und Konfigurationsanweisungen auf die gleiche Weise angeben wie beim Ausführen des vollständigen Befehls oder der vollständigen Anweisung. Tabelle 4 Listet die regulären Ausdrücke zum Konfigurieren von Zugriffsrechten für die AND-Anweisungshierarchien [edit interfaces][edit vlans]auf.

[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 für reguläre Ausdrücke

Tabelle 5 Listet allgemeine Operatoren für reguläre Ausdrücke auf, die Sie zum Zulassen oder Verweigern von Betriebs- und Konfigurationsmodi verwenden können.

Reguläre Ausdrücke für Befehle implementieren die erweiterten (modernen) regulären Ausdrücke, wie sie in POSIX 1003.2 definiert sind.

[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 unter zwei Konfigurationshierarchien zuzulassen –[edit system ntp server] und [edit protocols rip]– als Beispiel für die Angabe 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 .*" ]