Benutzerzugriffsrechte

Berechtigungs-Flags für Anmeldeklassen

Sie verwenden Berechtigungs-Flags, um einem Benutzer Zugriff auf Befehle im Betriebsmodus und Konfigurationshierarchieebenen und -anweisungen zu gewähren. Sie konfigurieren Berechtigungs-Flags für die Anmeldeklasse des Benutzers auf Hierarchieebene [edit system login class] . 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 Berechtigungs-Flags an, die in Tabelle 1aufgeführt sind. Berechtigungs-Flags sind nicht kumulativ. Für jede Klasse müssen Sie alle erforderlichen Berechtigungs-Flags auflisten, einschließlich view der Anzeige von Informationen und configure des Konfigurationsmodus. Zwei Arten von Berechtigungen kontrollieren den Zugriff eines Benutzers auf die einzelnen Teile der Konfiguration:

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

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

Für Berechtigungs-Flags, die Zugriff auf Konfigurationshierarchieebenen und -anweisungen gewähren, gewähren die Einfachformular-Flags dieser Konfiguration schreibgeschützte Berechtigungen. Das Berechtigungs-Flag interface gewährt beispielsweise schreibgeschützten Zugriff auf die [edit interfaces] Hierarchieebene. Die -control Form des Flags gewährt Schreibzugriff auf diese Konfiguration. Das interface-control Flag gewährt beispielsweise Schreib- und Lesezugriff auf die [edit interfaces] Hierarchieebene.

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

Die Berechtigungs-Flags gewähren einen bestimmten Satz von Zugriffsrechten. Jedes Berechtigungs-Flag 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.

Individuelle Befehle und Anweisungshierarchien für Anmeldeklassen zulassen und ablehnen

Standardmäßig verfügen alle CLI-Befehle der obersten Ebene und Konfigurationshierarchie über die zugriffsberechtigungsebenen. Benutzer können nur diese Befehle ausführen und nur die Anweisungen anzeigen und konfigurieren, für die sie Zugriffsrechte besitzen. Für jede Anmeldeklasse können Sie ausdrücklich die Verwendung von Befehlen und Anweisungshierarchien des Betriebsmodus und des Konfigurationsmodus zulassen und ablehnen, die ansonsten von einer in der permissions Anweisung angegebenen Berechtigungsebene zulässig oder verweigert würden.

Berechtigungs-Flags gewähren einem Benutzer Zugriff auf Betriebsmodus- und Konfigurationsmodusbefehle sowie auf Konfigurationshierarchieebenen und -anweisungen. Indem Sie auf Hierarchieebene ein bestimmtes Berechtigungs-Flag auf der Anmeldeklasse des [edit system login class] Benutzers 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 ausdrücklich zulassen oder verweigern, indem Sie die allow-commands, deny-commandsund allow-configurationdeny-configuration Anweisungen für eine Anmeldeklasse konfigurieren. In den Anweisungen verwenden Sie erweiterte reguläre Ausdrücke, um zu definieren, welche Befehle und Anweisungen den der Klasse zugewiesenen Benutzern zu erlauben oder abzulehnen sind.

Verstehen der Aussagen "Zulassen" und "Ablehnen"

Jeder Cli-Befehls- und Konfigurationsanweisungshierarchie der obersten Ebene ist eine Zugriffsberechtigungsebene zugeordnet. Jede Anmeldeklasse kann die Verwendung von Befehlen im Betriebs- und Konfigurationsmodus sowie von Konfigurationshierarchien und Anweisungen, die sonst von einer Berechtigungsebene zulässig oder verweigert würden, ausdrücklich zulassen oder ablehnen. Benutzer können nur diese Befehle ausführen und nur die Anweisungen anzeigen und konfigurieren, für die sie Zugriffsrechte besitzen.

Die Zugriffsrechte für jede Anmeldeklasse werden durch eine oder mehrere Berechtigungs-Flags definiert, die in der permissions Anweisung auf der [edit system login class class-name] Hierarchieebene 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 Anmeldeklasse konfigurieren:

• allow-commands und deny-commands— Zugriff auf Betriebsmodus- und Konfigurationsmodusbefehle zulassen oder verweigern.

• allow-configuration und deny-configuration— Zugriff auf bestimmte Konfigurationshierarchien zulassen oder verweigern.

  Anmerkung:

  Diese Anweisungen führen eine langsamere Abgleichung mit mehr Flexibilität durch, insbesondere beim Wildcard-Matching. Es kann jedoch sehr lange dauern, alle möglichen Anweisungen auszuwerten, wenn eine große Anzahl regulärer Ausdrücke oder Platzhalterausdrücke konfiguriert sind, was sich möglicherweise negativ auf die Leistung auswirkt.

• allow-commands-regexps und deny-commands-regexps– Erlauben oder verweigern den Zugriff auf bestimmte Befehle über Zeichenfolgen regulärer Ausdrücke.

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

Explizites Zulassen von Befehlen und Konfigurationsanweisungshierarchien mithilfe der allow/deny-* Anweisungen fügt die Berechtigungen hinzu, die die permissions Anweisung bereits definiert. Ebenso entfernt das explizite Verweigern von Befehlen und Konfigurationsanweisungshierarchien mithilfe der allow/deny-* Anweisungen Berechtigungen, die die permissions Anweisung bereits definiert.

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

In ähnlicher Weise kann der Benutzer der Anmeldeklasse in der folgenden Konfiguration alle Vorgänge ausführen, die vom all Berechtigungs-Flag erlaubt werden, außer dass der Benutzer die Konfiguration auf Hierarchieebene [edit system services] nicht anzeigen oder ändern kann:

Verständnis der Syntax von Allow and Deny Statement

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

• Sie können so viele reguläre Ausdrücke wie erforderlich konfigurieren.

• Reguläre Ausdrücke werden nicht groß- und kleinschreibungssensibel

Die allow/deny-commands Aussagen schließen sich mit den allow/deny-commands-regexps Aussagen gegenseitig aus, und die allow/deny-configuration Aussagen schließen sich gegenseitig mit den allow/deny-configuration-regexps Aussagen 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 mithilfe von allow-commands und deny-commands Anweisungen an. Schließen Sie jeden vollständigen eigenständigen Ausdruck in Klammern () an, 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 doppelten Anführungszeichen umschlossen.

Zum Beispiel:

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

Um Zugriffsrechte für Teile der Konfigurationshierarchie zu definieren, geben Sie erweiterte reguläre Ausdrücke in den allow-configuration und deny-configuration Anweisungen an. Umschließen Sie die vollständigen Pfade in Klammern ( ), 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 doppelten Anführungszeichen umschlossen.

Zum Beispiel:

Wenn Sie erweiterte reguläre Ausdrücke mithilfe der allow/deny-commands-regexps oder allow/deny-configuration-regexps Anweisungen angeben, umschließen Sie jeden Ausdruck in Anführungszeichen (""), und trennen Sie die Ausdrücke mit einem Leerzeichen. Schließen Sie mehrere Ausdrücke in eckigen Klammern [ ] an. Zum Beispiel:

Modifikatoren wie set, logund count werden innerhalb der zeichenfolge für regulären Ausdruck nicht unterstützt, die angepasst werden soll. Wenn Sie einen Modifikator verwenden, ist nichts übereinstimmen.

Korrekte Konfiguration:

Falsche Konfiguration:

Understanding the Allow and Deny Statement Precedence and Matching

Standardmäßig haben die allow-commands und allow-configuration regulären Ausdrücke Vorrang vor deny-commands und deny-configuration Expresssionen. Wenn Sie also den gleichen Befehl sowohl für die Anweisungen als auch für die allow-commandsdeny-commands Anweisungen konfigurieren, hat die Vorgangsweise zulassen Vorrang vor dem Vorgang ablehnen. Wenn Sie dieselbe Anweisung sowohl für die Anweisungen als auch für die allow-configurationdeny-configuration Anweisungen konfigurieren, hat die Zulässigkeitsoperation Vorrang vor dem Vorgang ablehnen.

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

In ähnlicher 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 allow-commands Befehle und deny-commands Anweisungen zwei verschiedene Varianten eines Befehls haben, wird immer die längste Übereinstimmung ausgeführt. Mit der folgenden Konfiguration kann ein Benutzer in der test Anmeldeklasse den commit synchronize Befehl ausführen, nicht jedoch den commit Befehl. Dies liegt daran, dass commit synchronize die längste Übereinstimmung zwischen commit und ist commit synchronizeund für allow-commandsangegeben ist.

Mit der folgenden Konfiguration kann ein Benutzer in der test Anmeldeklasse den commit Befehl ausführen, nicht jedoch den commit synchronize Befehl. Dies liegt daran, dass commit synchronize die längste Übereinstimmung zwischen commit und ist commit synchronizeund 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 und deny-configuration-regexps reguläre Ausdrücke Vorrang vor allow-commands-regexps und allow-configuration-regexps Ausdrücken haben. Sie können die regex-additive-logic Anweisung auf Der [edit system] Hierarchieebene so konfigurieren, dass reguläre allow-configuration-regexps Ausdrücke Vorrang vor den deny-configuration-regexps Anweisungen haben. Die Konfiguration der Anweisung ermöglicht es Ihnen, Konfigurationshierarchien auf einer höheren Ebene zu verweigern und dem Benutzer dann nur den Zugriff auf bestimmte Unterhierarchien zu gewähren.

Verständnis der Regeln für die "Allow and Deny Statement"-Regeln

Die allow/deny-commands, allow/deny-configurationallow/deny-commands-regexpsund allow/deny-configuration-regexps Anweisungen haben Vorrang vor den Berechtigungen für die Anmeldeklasse. Wenn Sie diese Anweisungen konfigurieren, gelten die folgenden Regeln:

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

• Die all Berechtigungsbits der Login-Klasse haben Vorrang vor erweiterten regulären Ausdrücken, wenn ein Benutzer den rollback Befehl mit aktiviertem Berechtigungs-Flag rollback ausleitet.

• Benutzer können den load override Befehl nicht ausführen, wenn ein erweiterter regulärer Ausdruck angegeben wird. Benutzer können nur die mergeBefehle , replaceund patch die Konfigurationsbefehle ausstellen.

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

Understanding Differences for the *-regexps Statements

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

Die allow/deny-configuration-regexps Anweisungen teilen den regulären Ausdruck in Token auf und stimmen jedes Teil mit jedem Teil des vollständigen Pfads der angegebenen Konfiguration ab, während die allow/deny-configuration Anweisungen mit der vollen Zeichenfolge übereinstimmen. Für allow/deny-configuration-regexps Anweisungen konfigurieren Sie eine Gruppe von Zeichenfolgen, in denen jede Zeichenfolge ein regulärer Ausdruck ist, mit Leerzeichen zwischen den Bedingungen der Zeichenfolge. Diese Syntax bietet eine sehr schnelle Abgleichung, bietet jedoch weniger Flexibilität. Für die Angabe von Platzhalterausdrücken müssen Sie Platzhalter für jedes Token der leerzeichenbegrenzten Zeichenfolge einrichten, die Sie anpassen möchten. Dadurch wird es schwieriger, Platzhalterausdrücke für diese Anweisungen zu verwenden.

Zum Beispiel:

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

  Dieses Beispiel zeigt, dass options es sich um den einzigen übereinstimmenden Ausdruck gegen das erste Token der Anweisung handelt.

  Die vorherige Konfiguration entspricht den folgenden Anweisungen:

  • Festlegen der Bedingung dynamic-db für Richtlinienoptionen

  • Festlegen von Routing-Optionen statische Route Statisch-Route Next-Hop Next-Hop

  • festlegen, dass EreignisoptionenEreignisereigniszeitintervalleSekunden generieren

  Die vorherige Konfiguration entspricht nicht den folgenden Anweisungen:

  • Host-Optionen für Systemhostname

  • Schnittstellenbeschreibungsoptionenfür Schnittstellennamen

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

  Dieses Beispiel zeigt, dass ssh es sich um den einzigen übereinstimmenden Ausdruck gegen das dritte Token der Anweisung handelt.

  Im vorhergehenden Beispiel enthalten die drei Token jeweils .*, .*und .*ssh.

  Die vorherige Konfiguration entspricht den folgenden Anweisungen:

  • Hostname-ssh des Systems

  • Systemservices SSH

  • Systemservices outbound-ssh

  Die vorherige Konfiguration entspricht nicht der folgenden Anweisung:

  • Schnittstellen Schnittstellenname Beschreibung SSH

Es ist einfacher, die Anweisung zu verwenden, um den deny-configuration Konfigurationszugriff einzuschränken, als die deny-configuration-regexps Anweisung zu verwenden. Tabelle 2 veranschaulicht die Verwendung der Anweisungen und deny-configuration-regexps der deny-configuration Anweisungen in verschiedenen Konfigurationen, um das gleiche Ergebnis zu erzielen, indem der Zugriff auf eine bestimmte Konfiguration beschränkt wird.

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

Reguläre Ausdrücke auf Remote-Autorisierungsservern verwenden

Sie können erweiterte reguläre Ausdrücke verwenden, um festzulegen, welche Betriebsmodus- und Konfigurationsmodusbefehle und Konfigurationsanweisungen und Hierarchien bestimmten Benutzern erlaubt oder verweigert werden. Sie geben diese regulären Ausdrücke lokal in der allow/deny-commands, allow/deny-configurationallow/deny-commands-regexps und allow/deny-configuration-regexps Anweisungen auf der [edit system login class class-name] Hierarchieebene an. Sie geben diese regulären Ausdrücke aus der Ferne an, indem Sie in der Konfiguration Ihres 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 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 mithilfe von allow-commands, deny-commands, allow-configurationoder deny-configuration Anweisungen angeben, konfigurieren Sie reguläre Ausdrücke in Klammern und trennen sie mit dem Pipe-Symbol. Sie umschließen den vollständigen Ausdruck in doppelten Anführungszeichen. Sie können z. B. mehrere allow-commands Parameter mit der folgenden Syntax angeben:

Der RADIUS-Autorisierungsserver verwendet die folgenden Attribute und Syntax:

Der Autorisierungsserver TACACS+ verwendet die folgenden Attribute und Syntax:

Wenn Sie mehrere reguläre Ausdrücke in einer lokalen Konfiguration mithilfe von 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 Space-Operator. Sie umschließen den vollständigen Ausdruck in eckigen Klammern. Sie können z. B. mehrere Allow-Commands-Parameter mit der folgenden Syntax angeben:

Der RADIUS-Autorisierungsserver verwendet die folgenden Attribute und Syntax:

Der Autorisierungsserver TACACS+ 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 ist beispielsweise:

Ebenso vereinfacht die TACACS+-Serversyntax:

Tabelle 3 unterscheidet die lokale Autorisierungskonfiguration und die TACACS+-Serverautorisierungskonfiguration mit 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"
    }
}

Reguläre Ausdrücke angeben

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 Hierarchien und [edit interfaces][edit vlans] Anweisungen sowie für den delete interfaces Befehl 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# delete interfaces interface-name

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

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

Betreiber regulärer Ausdrücke

Tabelle 5 listet gängige Operatoren regulärer Ausdrücke auf, die Sie zum Zulassen oder Verweigern von Betriebs- und Konfigurationsmodi verwenden können.

Reguläre Command Regular-Ausdrü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 unter zwei Konfigurationshierarchien zu ermöglichen–[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 .*" ]