Junos OS von Benutzerzugriffsberechtigungen

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

• Ein Juniper Networks Gerät

• Ein TACACS+-Server (oder RADIUS)

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

Bevor Sie beginnen:

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

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

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

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

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

So konfigurieren Sie die Berechtigungsebenen für den Benutzerzugriff:

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

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

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

2. Konfigurieren Sie Benutzerberechtigungen mit Zugriffsberechtigungen.

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

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

• Konfigurieren von Benutzerberechtigungen mit Zugriffsberechtigungsebenen
• Ergebnisse

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

• Überprüfung der SNMP-Konfiguration
• Überprüfung der Konfiguration ohne SNMP

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

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

• Junos OS 16.1 oder höher

  • Mindestens einem Benutzer muss eine Anmeldeklasse zugewiesen sein.

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

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

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

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

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

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

• Ein Juniper Networks Gerät

• Ein TACACS+-Server (oder RADIUS)

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

Bevor Sie beginnen:

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

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

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

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

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

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

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

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

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

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

Configuration Notes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Zum Beispiel:

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

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

  Falsche Konfiguration:

  Richtige Konfiguration:

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

  Zum Beispiel:

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

  Zum Beispiel:

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

  Zum Beispiel:

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

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

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

Topologie

Abbildung 1: Konfigurieren der TACACS+ Serverauthentifizierung

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

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

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

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

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

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

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

• CLI-Konfiguration
• Konfigurieren von Authentifizierungsparametern für Router R1
• Konfigurieren von Zugriffsberechtigungen mit allow-commands Statement Only (Class1)
• Konfigurieren von Zugriffsberechtigungen mit Deny-Commands Statement Only (Class2)
• Konfigurieren von Zugriffsberechtigungen mit Allow-Commands und Deny-Commands Anweisungen (Class3)
• Ergebnisse

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

• Überprüfung der Class1-Konfiguration
• Überprüfung der Class2-Konfiguration
• Überprüfung der Class 3-Konfiguration

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

• Ein Juniper Networks Gerät

• Ein TACACS+-Server (oder RADIUS)

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

Bevor Sie beginnen:

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

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

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

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

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

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

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

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

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

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

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

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

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

Zum Beispiel:

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

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

  Die oben genannte Konfiguration entspricht den folgenden Anweisungen:

  • Set options Policy-Condition Condition Dynamic-db

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

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

  Die oben genannte Konfiguration passt nicht zu den folgenden Anweisungen:

  • Hostname des Systemsoptions

  • Schnittstellennameoptions

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

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

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

  Die oben genannte Konfiguration entspricht den folgenden Anweisungen:

  • Hostname des Systemsssh

  • Systemservices ssh

  • ausgehende Systemservicesssh

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

  • Schnittstellennamessh

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

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

Configuration Notes

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

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

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

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

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

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

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

  Zum Beispiel:

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

  Zum Beispiel:

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

  Zum Beispiel:

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

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

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

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

  Falsche Konfiguration:

  Richtige Konfiguration:

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

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

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

Topologie

Abbildung 2: Konfigurieren der TACACS+ Serverauthentifizierung

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

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

Die Anmeldeklassen dienen folgendem Zweck:

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

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

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

• CLI-Konfiguration
• Konfigurieren von Authentifizierungsparametern für Router R1
• Konfigurieren von Zugriffsberechtigungen mit Anweisungen zur Konfigurationsberechtigung und Konfiguration des Verweigerns (Class1)
• Konfigurieren von Zugriffsberechtigungen mit Allow-configuration-regexps und Deny-configuration-regexps-Anweisungen (Class2)
• Ergebnisse

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

• Überprüfung der Class1-Konfiguration
• Überprüfung der Class2-Konfiguration