Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Benutzerzugriffsrechte

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

Überblick über zugriffsberechtigungsebenen

Jede Befehlszeilenbefehls- und Konfigurationsanweisung der obersten Ebene hat eine zugeordnete Zugriffsberechtigungsebene. Benutzer können nur diese Befehle ausführen und nur die Anweisungen konfigurieren und anzeigen, für die sie Zugriffsrechte besitzen. Eine oder mehrere Berechtigungs-Flags definieren die Zugriffsrechte für jede Anmeldeklasse.

Für jede Anmeldeklasse können Sie auch die Verwendung von Befehlen und Anweisungshierarchien im Betriebsmodus und Konfigurationsmodus explizit zulassen oder ablehnen, die ansonsten von einer in der permissions Anweisung angegebenen Berechtigungsebene zulässig oder verweigert würden.

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 .

Anmerkung:

Jeder aufgelistete Befehl repräsentiert diesen Befehl und alle Sub- und Sub-Unterbefehle mit diesem Befehl als Präfix. Jede aufgelistete Konfigurationsanweisung steht am oberen Rand der Konfigurationshierarchie, der das Flag Zugriff gewährt.

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.

Tabelle 1: Berechtigungs-Flags für Anmeldeklassen

Berechtigungs-Flag

Beschreibung

access

Kann die Zugriffskonfiguration im Betriebs- oder Konfigurationsmodus anzeigen.

access-control

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

admin

Kann Benutzerkontoinformationen im Betriebs- oder Konfigurationsmodus anzeigen.

admin-control

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

all

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

clear

Kann Informationen löschen (löschen), die das Gerät aus dem Netzwerk lernt und in verschiedenen Netzwerkdatenbanken speichert (mithilfe der clear Befehle).

configure

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

control

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

field

Kann Feldde debug-Befehle anzeigen. Für Debugging-Unterstützung reserviert.

firewall

Kann die Konfiguration des Firewallfilters im Betriebs- oder Konfigurationsmodus anzeigen.

firewall-control

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

floppy

Kann von lesen und auf die Wechselmedien schreiben.

flow-tap

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

flow-tap-control

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

flow-tap-operation

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

Anmerkung:

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

idp-profiler-operation

Kann Profilerdaten anzeigen.

interface

Kann die Schnittstellenkonfiguration im Betriebs- und Konfigurationsmodus anzeigen.

interface-control

Kann Gehäuse, Class of Service (CoS), Gruppen, Weiterleitungsoptionen und Schnittstellenkonfigurationsinformationen anzeigen. Kann die Konfiguration auf den folgenden Hierarchieebenen ändern:

  • [edit chassis]

  • [edit class-of-service]

  • [edit groups]

  • [edit forwarding-options]

  • [edit interfaces]

maintenance

Kann Systemwartung durchführen, einschließlich des Startens einer lokalen Shell auf dem Gerät und des Werdens zum Superbenutzer in der Shell (mit dem su root Befehl) und Anhalten und Neustarts des Geräts (mit den request system Befehlen).

network

Kann mithilfe von , , sshtelnetund traceroute Befehlen auf das pingNetzwerk zugreifen.

pgcp-session-mirroring

Kann die Konfiguration zur Sitzungsspiegelung pgcp anzeigen.

pgcp-session-mirroring-control

Kann die Konfiguration der Sitzungsspiegelung pgcp ändern.

reset

Kann Softwareprozesse mithilfe des Befehls restart neu starten.

rollback

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

routing

Kann allgemeine Informationen zur Routing-, Routingprotokoll- und Routing-Richtlinienkonfiguration im Konfigurations- und Betriebsmodus anzeigen.

routing-control

Kann allgemeines Routing auf Hierarchieebene [edit routing-options] , Routingprotokolle auf Hierarchieebene [edit protocols] und Informationen zu Routingrichtlinien auf [edit policy-options] Hierarchieebene anzeigen und konfigurieren.

secret

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

secret-control

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

security

Kann Sicherheitskonfigurationsinformationen im Betriebs- und Konfigurationsmodus anzeigen.

security-control

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

shell

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

snmp

Kann Konfigurationsinformationen des Simple Network Management Protocol (SNMP) im Betriebsmodus oder Konfigurationsmodus anzeigen.

snmp-control

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

system

Kann Informationen auf Systemebene im Betriebs- oder Konfigurationsmodus anzeigen.

system-control

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

trace

Kann Trace-Dateieinstellungen anzeigen und Tracedateieigenschaften konfigurieren.

trace-control

Kann Die Trace-Dateieinstellungen ändern und die Eigenschaften der Trace-Datei konfigurieren.

view

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

view-configuration

Kann alle Konfigurationen außer Geheimnissen, Systemskripten und Ereignisoptionen anzeigen.

Anmerkung:

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

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.

Beispiel: Konfigurieren von Benutzerberechtigungen mit Zugriffsberechtigungsebenen

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

Anforderungen

Vor der Konfiguration dieses Beispiels ist keine spezielle Konfiguration über die Geräte initialisierung hinaus erforderlich.

Überblick

Jedem CLI-Befehl der obersten Ebene und jeder Konfigurationsanweisung ist eine Zugriffsberechtigungsebene zugeordnet. Wenn Sie eine Anmeldeklasse konfigurieren, können Sie die Verwendung von Befehlen und Konfigurationsanweisungen für den Betriebsmodus und den Konfigurationsmodus 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.

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

Anmerkung:

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

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

Tipp:

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

Konfiguration

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

Konfigurieren von Benutzerberechtigungen mit Zugriffsberechtigungsebenen

Schritt-für-Schritt-Verfahren

So konfigurieren Sie Zugriffsrechte für die Anmeldeklasse:

  1. Konfigurieren Sie die snmp-admin Anmeldeklasse mit den configureFlags " , snmp" und snmp-control "Permission".

    Die konfigurierten Berechtigungs-Flags bieten sowohl snmp- als auch snmp-control-Funktionen (snmp-control), und dies ist die einzige zulässige Zugriffsberechtigung für diese Anmeldeklasse. Allen anderen Zugriffsrechten wird verweigert.

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

Ergebnisse

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

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

Überprüfung

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

Überprüfen der SNMP-Konfiguration

Zweck

Vergewissern Sie sich, dass ein Benutzer in der snmp-admin Anmeldeklasse SNMP konfigurieren kann.

Aktion

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

Bedeutung

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

Überprüfung der Nicht-SNMP-Konfiguration

Zweck

Vergewissern Sie sich, dass ein Benutzer in der snmp-admin Anmeldeklasse nicht-SNMP-Konfigurationsanweisungen ändern kann.

Aktion

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

Bedeutung

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

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

Dieses Thema enthält die folgenden Abschnitte:

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.

Anmerkung:

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

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.

Tabelle 2: Beschränkung des Konfigurationszugriffs mit Deny-Configuration- und Deny-Configuration-regexps-Anweisungen

Abgelehnte Konfiguration

Mit: deny-configuration

Mit: deny-configuration-regexps

Ergebnis

xnm-ssl

[edit system]
login {
    class test {
        permissions configure;
         allow-configuration .*;
        deny-configuration .*xnm-ssl;
    }
}
[edit system]
login {
    class test {
        permissions configure;
         allow-configuration .*;
        deny-configuration-regexps ".* .* .*-ssl"";
    }
}

Die folgende Konfigurationsanweisung 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";
    }
}

Folgende Konfigurationsanweisungen werden abgelehnt:

  • Hostname-ssh des Systems

  • Systemservices SSH

  • Systemservices outbound-ssh

  • Sicherheit ssh-known-host

Obwohl die allow/deny-configuration Anweisungen auch nützlich sind, wenn Sie eine einfache Konfiguration wünschen, bieten die allow/deny-configuration-regexps Anweisungen eine bessere Leistung und überwinden die 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.

Anmerkung:

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

Wenn Sie mehrere reguläre Ausdrücke in einer lokalen Konfiguration mithilfe von allow-commands, deny-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.

Tabelle 3: Beispielkonfiguration für lokale und Remote-Autorisierung mit regulären Ausdrücken

Lokale Konfiguration

Tacacs+-Remotekonfiguration

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"
    }
}
Anmerkung:
  • Sie müssen den Zugriff auf den NETCONF-Modus (lokal oder remote) explizit zulassen, indem Sie die folgenden drei Befehle ausgeben: xml-mode, netconfund need-trailer.

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

Reguläre Ausdrücke angeben

Warnung:

Wenn Sie reguläre Ausdrücke für Befehle und Konfigurationsanweisungen angeben, achten Sie auf die folgenden Beispiele. Ein regulärer Ausdruck mit ungültiger Syntax führt möglicherweise nicht zu den gewünschten Ergebnissen, selbst wenn die Konfiguration ohne Fehler begangen wurde.

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.

Tabelle 4: Reguläre Ausdrücke angeben

Anweisung

Regulärer Ausdruck

Konfigurationshinweise

[edit interfaces]

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

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

Die set interfaces Aussage ist von sich aus unvollständig und erfordert die unit Möglichkeit, die Anweisung auszuführen.

Daher muss der reguläre Ausdruck, der zum Verweigern der set interfaces Konfiguration erforderlich ist, die gesamte ausführbare Zeichenfolge mit dem .* Operator anstelle von Anweisungsvariablen angeben:

[edit system login class class-name]
user@host# set permissions configure
user@host# set deny-configuration "interfaces .* unit .*"
  • Der .* Operator bezeichnet alles ab dem angegebenen Punkt für diesen bestimmten Befehl oder die jeweilige Anweisung. In diesem Beispiel wird jeder Schnittstellenname mit einem Einheitenwert bezeichnet.

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

  • Andere gültige Optionen können im regulären Ausdruck enthalten sein. Zum Beispiel:

    [edit system login class class-name]
    user@host# set permissions configure
    user@host# set deny-configuration "interfaces .* description .*"
    
    [edit system login class class-name]
    user@host# set permissions configure
    user@host# set allow-configuration-regexps [ "interfaces .* description .*" "interfaces .* unit .* description .*" "interfaces .* unit .* family inet address .*" "interfaces.* disable" ]
    
    [edit system login class class-name]
    user@host# set permissions configure
    user@host# set allow-configuration "interfaces .* unit 0 family ethernet-switching vlan mem.* .*"
    

    Hinweis: Der mem.* reguläre Ausdruck in diesem Beispiel wird verwendet, wenn erwartet wird, dass mehrere Zeichenfolgen, die mit dem mem-Schlüsselwort beginnen, in den angegebenen regulären Ausdruck einbezogen werden. Wenn nur eine member Zeichenfolge erwartet wird, 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 delete interfaces Anweisung kann von selbst ausgeführt werden und erfordert keine zusätzlichen Anweisungen.

Daher sollte der reguläre Ausdruck, der für die Ablehnung der delete interfaces Anweisung erforderlich ist, folgende Angaben enthalten:

[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 die jeweilige Anweisung. In diesem Beispiel wird jeder Schnittstellenname bezeichnet.

  • Damit der deny-configuration "interfaces .*" reguläre Ausdruck wirksam wird, sollte die angegebene Anmeldeklasse Konfigurationsberechtigungen für die Schnittstellenhierarchie mithilfe des regulären Ausdrucks allow-configuration "interfaces .*" 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 set vlans Aussage selbst unvollständig und erfordert die vlan-id Option, die Anweisung auszuführen.

Daher muss der reguläre Ausdruck, der für die set vlans Konfiguration erforderlich ist, die gesamte ausführbare Zeichenfolge mit dem .* Operator anstelle von 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 die jeweilige Anweisung. In diesem Beispiel wird jeder VLAN-Name mit jeder VLAN-ID bezeichnet.

  • Andere gültige Optionen in der [edit vlans] Anweisungshierarchie können im regulären Ausdruck enthalten sein. Zum Beispiel:

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

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.

Tabelle 5: Betreiber häufiger regulärer Ausdrücke

Betreiber

Match

Beispiel

|

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

[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 vorherigen Konfiguration haben die der Testanmeldungsklasse zugewiesenen Benutzer nur auf die in der Anweisung angegebenen Befehle Zugriff auf den allow-commands Betriebsmodus. Sie haben auch Zugriff auf den Konfigurationsmodus, mit Ausnahme der in der deny-configuration Anweisung angegebenen Hierarchieebenen.

^

Wird am Anfang eines Ausdrucks verwendet, um zu kennzeichnen, wo der Befehl beginnt, wo es einige Unklarheiten geben könnte.

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

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

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

$

Zeichen am Ende eines Befehls. Wird verwendet, um einen Befehl zu bezeichnen, der genau bis zu diesem Punkt übereinstimmen muss.

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

Bei der vorherigen Konfiguration können die der Testanmeldungsklasse zugewiesenen Benutzer die Schnittstellenkonfiguration im Konfigurationsmodus anzeigen. Die Benutzer können auch die Schnittstellenkonfiguration mit dem Befehl für den show configuration Betriebsmodus anzeigen. Der in allow-commands der Anweisung angegebene reguläre Ausdruck beschränkt jedoch die Ausführung nur des show interfaces Befehls und verweigert den Zugriff auf die Befehlserweiterungen wie show interfaces detail oder show interfaces extensive.

[ ]

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

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

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

( )

Eine Gruppe von Befehlen, die einen vollständigen eigenständigen Ausdruck angeben, der ausgewertet werden soll. Das Ergebnis wird dann als Teil des Gesamtausdrucks ausgewertet. Klammern müssen wie erläutert 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)"

Mit der oben genannten Konfiguration haben benutzer, die der Testanmeldungsklasse zugewiesen sind, Berechtigungen auf Übergeordneter Ebene und haben Zugriff auf die in der allow-commands Anweisung angegebenen Befehle.

*

Null oder mehr Bedingungen.

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

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

+

Eine oder mehrere Begriffe.

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

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

.

Jedes Zeichen mit Ausnahme eines Leerzeichens " ".

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

Mit der obigen Konfiguration wird Benutzern, die der Testanmeldungsklasse zugewiesen wurden, deren Benutzername beginnt, m der Konfigurationszugriff 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 .*)"

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

In ähnlicher Weise verweigert die Anweisung den deny-configuration "protocols .*" gesamten Konfigurationszugriff unter der [edit protocols] Hierarchieebene.

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

  • Die deny-commands .* Anweisungen und deny-configuration .* die Anweisungen verweigern den Zugriff auf alle Befehle im Betriebsmodus bzw. auf Konfigurationshierarchien.

Anmerkung:

Der ! Operator für reguläre Ausdrücke wird nicht unterstützt.

Beispiele für reguläre Ausdrücke

Tabelle 6 listet die regulären Ausdrücke auf, die verwendet werden, um Konfigurationsoptionen unter zwei Konfigurationshierarchien zu ermöglichen–[edit system ntp server] und [edit protocols rip]– als Beispiel für die Angabe regulärer Ausdrücke.

Anmerkung:

Tabelle 6 enthält keine umfassende Liste aller regulären Ausdrücke und Keywords für alle Konfigurationsanweisungen und Hierarchien. Die in der Tabelle aufgeführten regulären Ausdrücke werden nur für die [edit system ntp server] Hierarchien und [edit protocols rip] Die Anweisung validiert.

Tabelle 6: Beispiele regulärer Ausdrücke

Statement-Hierarchie

Reguläre Ausdrücke

Zulässige Konfiguration

Verweigerte 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

Metrik-in-Metrik-in

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

  • Nachrichtengröße

  • Route Timeout

  • Aktualisierungsintervall

Route Timeout Route Timeout

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

  • Nachrichtengröße

  • Metrik-in

  • Aktualisierungsintervall

Aktualisierungsintervall Aktualisierungsintervall

[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

Definition von Zugriffsrechten mit Anweisungen zur Allow-Configuration und Deny-Configuration

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

  • Berechtigungs-Flags

  • allow-configuration und deny-configuration Aussagen

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

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

Beachten Sie, dass Berechtigungsbit und Berechtigungs-Flag synonym verwendet werden.

Beispiel 1

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

  1. Legen Sie die Berechtigungen für die Anmeldeklasse des Benutzers auf allfest.
  2. Fügen Sie die folgende deny-configuration Anweisung bei.

Beispiel 2

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

  1. Legen Sie die Berechtigungen für die Anmeldeklasse des Benutzers auf allfest.

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

Beispiel 3

So erstellen Sie eine Anmeldeklasse, mit der der Benutzer alle Befehle ausführen und alles außer den [edit system login class][edit system services] Hierarchieebenen konfigurieren kann:

  1. Legen Sie die Berechtigungen für die Anmeldeklasse des Benutzers auf allfest.

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

Die folgenden Beispiele zeigen, wie Sie mithilfe der Anweisungen und deny-configuration Anweisungen allow-configuration die einander inversen Berechtigungen für die [edit system services] Hierarchieebene bestimmen.

Beispiel 4

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

  1. Legen Sie die Berechtigungen für die Anmeldeklasse des Benutzers auf configurefest.

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

Beispiel 5

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

  1. Legen Sie die Berechtigungen für die Anmeldeklasse des Benutzers auf allfest.

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

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

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

Anforderungen

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

Überblick

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

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

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

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

Konfiguration

Schritt-für-Schritt-Verfahren

Um die additive Logik zu aktivieren, den Benutzern in einer bestimmten Anmeldeklasse explizit den Zugriff auf eine oder mehrere individuelle Konfigurationshierarchien zu ermöglichen:

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

    Zum Beispiel:

  2. Fügen Sie die allow-configuration-regexps Anweisung ein, und definieren Sie reguläre Ausdrücke, die für die spezifischen Hierarchien zulässig sind.

    Zum Beispiel:

  3. Aktivieren der additiven Logik für die allow-configuration-regexps und deny-configuration-regexps reguläre Ausdrücke.

  4. Weisen Sie einem oder mehreren Benutzern die Anmeldeklasse zu.

  5. Bestätigen Sie Ihre Änderungen.

    Benutzer, die dieser Anmeldeklasse zugewiesen sind, haben Zugriff auf die in der allow-configuration-regexps Anweisung enthaltenen Konfigurationshierarchien, haben aber keinen Zugriff auf die anderen in der deny-configuration-regexps Anweisung angegebenen Hierarchien.

Anmerkung:

Wenn Sie die regex-additive-logic Anweisung konfigurieren, gilt die Verhaltensänderung für alle allow-configuration-regexps und deny-configuration-regexps Anweisungen, die in allen Anmeldeklassen vorhanden sind. Wenn Sie additive Logik aktivieren, sollten Sie vorhandene Anweisungen auf mögliche Auswirkungen auswerten und die regulären Ausdrücke in diesen Anweisungen entsprechend aktualisieren.

Beispiele

Reguläre Ausdrücke mit additiver Logik verwenden

Zweck

In diesem Abschnitt finden Sie Beispiele für reguläre Ausdrücke, die mit additiver Logik Ideen zum Erstellen von systemgerechten Konfigurationen entwickeln.

Bestimmte Routing-Instanzen zulassen

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

Standardmäßig hat die deny-configuration-regexps Anweisung Vorrang, und die vorherige Konfiguration hindert die Benutzer in der Anmeldeklasse daran, routing-Instanzen unabhängig vom Namen zu konfigurieren.

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

Nur BGP-Peer-Konfiguration zulassen

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

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

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

Überprüfung

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

  1. Konfigurieren Sie eine Anmeldeklasse und bestätigen Sie die Änderungen.

  2. Weisen Sie der Anmeldeklasse einen Benutzernamen zu.

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

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

    • Sie sollten in der Lage sein, Anweisungen in zulässigen Hierarchieebenen zu konfigurieren.

    • Verweigerte Hierarchieebenen sollten nicht sichtbar sein.

    • Alle zulässigen oder verweigerten Ausdrücke sollten Vorrang vor allen Berechtigungen haben, die mit der permissions Anweisung gewährt werden.

Beispiel: Konfigurieren von Benutzerberechtigungen mit Zugriffsrechten für Befehle im Betriebsmodus

In diesem Beispiel wird gezeigt, wie Benutzerdefinierte Anmeldeklassen konfiguriert und Zugriffsrechte für Befehle im Betriebsmodus zugewiesen werden. Benutzer in der Anmeldeklasse können nur die Befehle ausführen, auf die sie Zugriff haben. Dadurch wird verhindert, dass unbefugte Benutzer sensible Befehle ausführen, die Das Netzwerk beschädigen könnten.

Anforderungen

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

  • Ein Gerät von Juniper Networks

  • Ein TACACS+-Server (oder RADIUS)

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

Überblick und Topologie

Abbildung 1 zeigt eine einfache Topologie, in der Router R1 ein Gerät von Juniper Networks ist und eine TCP-Verbindung mit einem TACACS+-Server hergestellt wird.

Abbildung 1: Topologie Topologie

In diesem Beispiel wird R1 mit drei benutzerdefinierten Anmeldeklassen konfiguriert: Klasse 1, Klasse2 und Klasse 3. Jede Klasse definiert die Zugriffsrechte für den Benutzer, indem die permissions Anweisung konfiguriert und erweiterte reguläre Ausdrücke mithilfe der allow-commands und deny-commands Anweisungen definiert werden.

Der Zweck jeder Anmeldeklasse lautet wie folgt:

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

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

  • Class3— Definiert die Zugriffsrechte für den Benutzer sowohl mit den allow-commandsdeny-commands Zugriffsrechten als auch mit Anweisungen. Diese Anmeldeklasse bietet Benutzerberechtigungen und Autorisierungen auf Übergeordneter Ebene für den Zugriff auf Schnittstellen und die Anzeige von Geräteinformationen. Es verweigert auch den Zugriff auf die edit und configure Befehle.

Der Router R1 hat drei verschiedene Benutzer, Benutzer1, Benutzer2 und Benutzer3, die den Class1-, Class2- bzw. Class3-Anmeldeklassen zugewiesen sind.

Konfiguration

CLI-Schnellkonfiguration

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

R1

Konfigurieren der Authentifizierungsparameter für Router R1

Schritt-für-Schritt-Verfahren

So konfigurieren Sie die Router-R1-Authentifizierung:

  1. Konfigurieren Sie die Reihenfolge, in der R1 versucht, den Benutzer zu authentifizieren. In diesem Beispiel steht die TACACS+-Serverauthentifizierung an erster Stelle, gefolgt von der RADIUS-Serverauthentifizierung und dann dem lokalen Kennwort.

  2. Konfigurieren Sie den TACACS+-Server.

  3. Konfigurieren Sie den RADIUS-Server.

  4. Konfigurieren Sie R1-Accounting-Parameter.

Konfigurieren Von Zugriffsrechten mit der Anweisung allow-commands (Class1)

Schritt-für-Schritt-Verfahren

So legen Sie reguläre Ausdrücke mithilfe der allow-commands Anweisung fest:

  1. Konfigurieren Sie die Login-Klasse Class1, und weisen Sie Benutzerberechtigungen auf Betreiberebene zu.

  2. Konfigurieren Sie den allow-commands regulären Ausdruck, damit Benutzer in der Klasse das Gerät neu starten können.

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

Konfigurieren Von Zugriffsrechten mit der Anweisung deny-commands (Class2)

Schritt-für-Schritt-Verfahren

So legen Sie reguläre Ausdrücke mithilfe der deny-commands Anweisung fest:

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

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

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

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

Schritt-für-Schritt-Verfahren

So geben Sie reguläre Ausdrücke sowohl mit den allow-commandsdeny-commands folgenden Ausdrücken als auch mit Anweisungen an:

  1. Konfigurieren Sie die Class3-Anmeldeklasse und weisen Sie Berechtigungen auf Superuser-Ebene zu.

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

  3. Konfigurieren Sie den allow-commands regulären Ausdruck, um Benutzern den Konfigurationsmodus zu ermöglichen.

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

Ergebnisse

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

Überprüfung

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

Überprüfen der Class1-Konfiguration

Zweck

Vergewissern Sie sich, dass die Berechtigungen und Befehle, die in der Class1-Anmeldeklasse zulässig sind, 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 Class1-Anmeldeklasse, der Benutzer1 zugewiesen ist, hat Benutzerberechtigungen auf Betreiberebene und ermöglicht Benutzern der Klasse, den request system reboot Befehl auszuführen.

Die vordefinierte Anmeldeklasse für Betreiber verfügt über die folgenden Berechtigungs-Flags:

  • clear— Kann mithilfe von clear Befehlen Informationen löschen (löschen), die das Gerät aus dem Netzwerk lernt und in verschiedenen Netzwerkdatenbanken speichert.

  • network— Kann mit den Befehlen , , sshtelnetund traceroute dem Befehl auf das pingNetzwerk zugreifen.

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

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

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

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

Überprüfen der Class2-Konfiguration

Zweck

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

Aktion

Führen Sie im Betriebsmodus den ping Befehl aus.

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

Führen Sie in der CLI-Eingabeaufforderung einen beliebigen Set-Befehl aus.

Bedeutung

Die Class2-Anmeldeklasse, der User2 zugewiesen ist, hat Benutzerberechtigungen auf Betreiberebene und verweigert den Zugriff auf alle set Befehle.

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

Überprüfung der Class3-Konfiguration

Zweck

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

Aktion

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

Geben Sie den Konfigurationsmodus ein.

Bedeutung

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

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

In diesem Beispiel wird gezeigt, wie benutzerdefinierte Anmeldeklassen konfiguriert und zugriffsberechtigungen bestimmten Konfigurationshierarchien zugewiesen werden. Benutzer in der Anmeldeklasse können nur die Konfigurationsanweisungen und Hierarchien anzeigen und ändern, auf die sie Zugriff haben. Dadurch wird verhindert, dass unbefugte Benutzer Gerätekonfigurationen ändern, die Schaden am Netzwerk verursachen könnten.

Anforderungen

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

  • Ein Gerät von Juniper Networks

  • Ein TACACS+-Server (oder RADIUS)

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

Überblick und Topologie

Abbildung 2 zeigt eine einfache Topologie, in der Router R1 ein Gerät von Juniper Networks ist und eine TCP-Verbindung mit einem TACACS+-Server hergestellt wird.

Abbildung 2: Topologie Topologie

In diesem Beispiel wird R1 mit zwei benutzerdefinierten Anmeldeklassen konfiguriert: Klasse 1 und Klasse 2. Jede Klasse definiert die Zugriffsrechte für den Benutzer, indem die permissions Anweisung konfiguriert und erweiterte reguläre Ausdrücke mithilfe von allow-configuration, deny-configuration, allow-configuration-regexpsund deny-configuration-regexps Anweisungen definiert werden.

Der Zweck jeder Anmeldeklasse lautet wie folgt:

  • Class1— Definiert die Zugriffsrechte für den Benutzer mit den Anweisungen und deny-configuration den allow-configuration Anweisungen. Diese Anmeldeklasse bietet nur Zugriff auf die Konfiguration der [edit interfaces] Hierarchie und verweigert allen anderen Zugriff auf dem Gerät. Dazu umfassen configure die Benutzerberechtigungen die Bereitstellung des Konfigurationszugriffs. Darüber hinaus ermöglicht die Anweisung den allow-configuration Zugriff auf die Schnittstellenkonfiguration, und die Anweisung verweigert den deny-configuration Zugriff auf alle anderen Konfigurationshierarchien. Da die Allow-Anweisung Vorrang vor der Deny-Anweisung hat, können die der Class1-Anmeldeklasse zugewiesenen Benutzer nur auf die [edit interfaces] Hierarchieebene zugreifen.

  • Class2— Definiert die Zugriffsrechte für den Benutzer mit den Anweisungen und deny-configuration-regexps den allow-configuration-regexps Anweisungen. Diese Anmeldeklasse bietet Benutzerberechtigungen auf Superuser-Ebene und ermöglicht explizit die Konfiguration unter mehreren Hierarchieebenen für Schnittstellen. Es verweigert auch den Zugriff auf die [edit system] und [edit protocols] Hierarchieebenen.

Der Router R1 hat zwei Benutzer, User1 und User2, die den Class1- bzw. Class2-Anmeldeklassen zugewiesen werden.

Konfiguration

CLI-Schnellkonfiguration

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

R1

Konfigurieren der Authentifizierungsparameter für Router R1

Schritt-für-Schritt-Verfahren

So konfigurieren Sie die Router-R1-Authentifizierung:

  1. Konfigurieren Sie die Reihenfolge, in der R1 versucht, den Benutzer zu authentifizieren. In diesem Beispiel steht die TACACS+-Serverauthentifizierung an erster Stelle, gefolgt von der RADIUS-Serverauthentifizierung und dann dem lokalen Kennwort.

  2. Konfigurieren Sie den TACACS+-Server.

  3. Konfigurieren Sie den RADIUS-Server.

  4. Konfigurieren Sie die Accounting-Parameter R1.

Konfigurieren Von Zugriffsrechten mit den Anweisungen "Allow-Configuration and Deny-Configuration" (Class1)

Schritt-für-Schritt-Verfahren

So legen Sie reguläre Ausdrücke mithilfe von allow-configuration und deny-configuration Anweisungen fest:

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

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

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

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

Konfigurieren Sie Zugriffsrechte mit den Anweisungen allow-configuration-regexps und deny-configuration-regexps (Class2)

Schritt-für-Schritt-Verfahren

So legen Sie reguläre Ausdrücke mithilfe von allow-configuration-regexps und deny-configuration-regexps Anweisungen fest:

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

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

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

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

Ergebnisse

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

Überprüfung

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

Überprüfen der Class1-Konfiguration

Zweck

Vergewissern Sie sich, dass die berechtigungen, die in der Class1-Anmeldeklasse zulässig sind, funktionieren.

Aktion

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

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

Bedeutung

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

Überprüfen der Class2-Konfiguration

Zweck

Überprüfen Sie, ob die Class2-Konfiguration wie erwartet funktioniert.

Aktion

Greifen Sie im Konfigurationsmodus auf die interfaces Konfiguration zu.

Greifen Sie im Konfigurationsmodus auf die systemprotocols Und-Konfigurationshierarchien zu.

Bedeutung

Benutzer2 verfügt über Berechtigungen zur Konfiguration von Schnittstellen auf R1, der Benutzer hat jedoch keine Berechtigung zum Anzeigen oder Ändern der [edit system][edit protocols] Oderhierarchieebenen.

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