Privilèges d’accès utilisateur
Vous (l’administrateur système) accordez aux utilisateurs l’accès ou les autorisations aux commandes et aux niveaux et déclarations de la hiérarchie de configuration. Les utilisateurs peuvent exécuter uniquement les commandes et afficher et configurer uniquement les instructions pour lesquelles ils disposent de privilèges d’accès. Vous pouvez également utiliser des expressions régulières étendues pour spécifier les commandes du mode opérationnel, les instructions de configuration et les hiérarchies autorisées ou refusées pour les utilisateurs. Cette pratique empêche les utilisateurs non autorisés d’exécuter des commandes sensibles ou de configurer des instructions susceptibles de causer des dommages au réseau.
Présentation des niveaux de privilèges d’accès
Chaque commande CLI de niveau supérieur et chaque déclaration de configuration a un niveau de privilège d’accès associé. Les utilisateurs peuvent exécuter uniquement les commandes et configurer et afficher uniquement les instructions pour lesquelles ils disposent de privilèges d’accès. Un ou plusieurs indicateurs d’autorisation définissent les privilèges d’accès pour chaque classe de connexion.
Pour chaque classe de connexion, vous pouvez également autoriser ou refuser explicitement l’utilisation de commandes de mode opérationnel et de configuration et de hiérarchies d’instruction qui seraient autrement autorisées ou refusées par un niveau de privilège spécifié dans l’instruction permissions
.
- Indicateurs d’autorisation de classe de connexion
- Autoriser et refuser les commandes individuelles et les hiérarchies d’instruction pour les classes d’identification
Indicateurs d’autorisation de classe de connexion
Vous utilisez des indicateurs d’autorisation pour accorder à un utilisateur l’accès aux commandes du mode opérationnel et aux niveaux et déclarations de la hiérarchie de configuration. Vous configurez les indicateurs d’autorisation pour la classe de connexion de l’utilisateur au niveau de la [edit system login class]
hiérarchie. Lorsque vous spécifiez un certain indicateur d’autorisation, l’utilisateur accède aux commandes et aux niveaux de la hiérarchie de configuration et aux déclarations correspondant à cet indicateur. Pour accorder l’accès à toutes les commandes et déclarations de configuration, utilisez l’indicateur d’autorisation all
.
Chaque commande répertoriée représente cette commande et toutes les sous-commandes avec cette commande comme préfixe. Chaque déclaration de configuration répertoriée représente le sommet de la hiérarchie de configuration à laquelle cet indicateur accorde l’accès.
L’instruction permissions
spécifie un ou plusieurs des indicateurs d’autorisation répertoriés dans Tableau 1. Les indicateurs d’autorisation ne sont pas cumulables. Pour chaque classe, vous devez lister tous les indicateurs d’autorisation nécessaires, y compris view
pour afficher les informations et configure
accéder au mode de configuration. Deux formes d’autorisations contrôlent l’accès d’un utilisateur aux différentes parties de la configuration :
-
Formulaire « simple » : offre une fonctionnalité en lecture seule pour ce type d’autorisation. Par exemple
interface
, . -
-control
form : permet de lire et d’écrire ce type d’autorisation. Par exempleinterface-control
, .
Pour les indicateurs d’autorisation qui accordent l’accès aux niveaux et aux instructions de la hiérarchie de configuration, les indicateurs de forme simple accordent le privilège de lecture seule à cette configuration. Par exemple, l’indicateur d’autorisation interface
accorde un accès en lecture seule au [edit interfaces]
niveau hiérarchique. Le -control
formulaire de l’indicateur donne un accès en lecture-écriture à cette configuration. Par exemple, l’indicateur interface-control
accorde un accès en lecture-écriture au niveau de la [edit interfaces]
hiérarchie.
Tableau 1 répertorie les indicateurs d’autorisation des classes de connexion que vous pouvez configurer en incluant l’instruction permissions
au niveau de la [edit system login class class-name]
hiérarchie.
Les indicateurs d’autorisation accordent un ensemble spécifique de privilèges d’accès. Chaque indicateur d’autorisation est répertorié avec les commandes du mode opérationnel ou du mode de configuration, ainsi que les niveaux et les déclarations de hiérarchie de configuration pour lesquels cet indicateur accorde l’accès.
Indicateur d’autorisation |
Description |
---|---|
Peut afficher la configuration d’accès en mode opérationnel ou en mode de configuration. |
|
Peut consulter et configurer les informations d’accès au niveau de la |
|
Peut afficher les informations de compte utilisateur en mode opérationnel ou en mode de configuration. |
|
Peut consulter les informations de compte utilisateur et les configurer au niveau de la |
|
Peut accéder à toutes les commandes du mode opérationnel et du mode de configuration. Peut modifier la configuration à tous les niveaux de la hiérarchie de configuration. |
|
Peut effacer (supprimer) les informations que l’équipement apprend du réseau et stocke dans diverses bases de données réseau (à l’aide |
|
Peut entrer en mode configuration (à l’aide de la |
|
Peut effectuer toutes les opérations de niveau contrôle, toutes les opérations configurées avec les indicateurs d’autorisation |
|
Peut afficher les commandes de débogage sur le terrain. Réservé à la prise en charge du débogage. |
|
Peut afficher la configuration du filtre de pare-feu en mode opérationnel ou en mode de configuration. |
|
Peut afficher et configurer les informations de filtrage de pare-feu au niveau de la |
|
Peut lire et écrire sur le support amovible. |
|
Peut afficher la configuration flow-tap en mode opérationnel ou en mode de configuration. |
|
Peut consulter et configurer les informations de flux au niveau de la |
|
Peut faire des requêtes de flux au routeur ou au commutateur. Par exemple, un client DTCP (Dynamic Tasking Control Protocol) doit avoir REMARQUE :
L’option |
|
Peut consulter les données du profileur. |
|
Peut afficher la configuration de l’interface en mode opérationnel et en mode de configuration. |
|
Peut afficher le châssis, la classe de service (CoS), les groupes, les options de transfert et les informations de configuration des interfaces. Peut modifier la configuration aux niveaux hiérarchiques suivants :
|
|
Peut effectuer la maintenance du système, notamment en commençant un shell local sur l’équipement et en devenant le superutilisateur du shell (à l’aide de la |
|
Peut accéder au réseau à l’aide du |
|
Peut afficher la configuration de |
|
Peut modifier la configuration de |
|
Peut redémarrer les processus logiciels à l’aide de la |
|
Peut utiliser la |
|
Peut consulter les informations générales de configuration du routage, du protocole de routage et des stratégies de routage en mode de configuration et en mode opérationnel. |
|
Peut afficher et configurer le routage général au niveau de la |
|
Peut afficher les mots de passe et autres clés d’authentification dans la configuration. |
|
Peut afficher et modifier les mots de passe et autres clés d’authentification dans la configuration. |
|
Peut consulter les informations de configuration de sécurité en mode opérationnel et en mode de configuration. |
|
Peut consulter et configurer les informations de sécurité au niveau de la |
|
Peut démarrer un shell local sur le routeur ou le commutateur à l’aide de la |
|
Peut consulter les informations de configuration SNMP (Simple Network Management Protocol) en mode opérationnel ou en mode de configuration. |
|
Peut afficher et modifier les informations de configuration SNMP au niveau de la |
|
Peut afficher les informations au niveau du système en mode opérationnel ou en mode de configuration. |
|
Peut consulter et modifier les informations de configuration au niveau du système au niveau de la |
|
Peut afficher les paramètres du fichier de suivi et configurer les propriétés du fichier de trace. |
|
Peut modifier les paramètres du fichier de suivi et configurer les propriétés du fichier de trace. |
|
Peut utiliser diverses commandes pour afficher les valeurs et statistiques actuelles à l’échelle du système, des tables de routage et des valeurs et statistiques spécifiques au protocole. Impossible d’afficher la configuration secrète. |
|
Peut afficher toute la configuration, à l’exception des secrets, des scripts système et des options d’événements. REMARQUE :
Seuls les utilisateurs autorisés peuvent consulter le |
Autoriser et refuser les commandes individuelles et les hiérarchies d’instruction pour les classes d’identification
Par défaut, toutes les commandes CLI de niveau supérieur et les niveaux de hiérarchie de configuration ont des niveaux de privilèges d’accès associés. Les utilisateurs peuvent exécuter uniquement les commandes et afficher et configurer uniquement les instructions pour lesquelles ils disposent de privilèges d’accès. Pour chaque classe de connexion, vous pouvez autoriser et refuser explicitement l’utilisation de commandes de mode opérationnel et de mode de configuration et de hiérarchies d’instruction qui seraient autrement autorisées ou refusées par un niveau de privilège spécifié dans l’instruction permissions
.
Les indicateurs d’autorisation donnent à l’utilisateur l’accès aux commandes du mode opérationnel et du mode de configuration, ainsi qu’aux niveaux et déclarations de la hiérarchie de configuration. En spécifiant un indicateur d’autorisation spécifique sur la classe de connexion de l’utilisateur au niveau hiérarchique, vous donnez à l’utilisateur l’accès [edit system login class]
aux commandes et aux niveaux et déclarations de hiérarchie de configuration correspondants. Pour accorder l’accès à toutes les commandes et déclarations de configuration, utilisez l’indicateur d’autorisation all
.
Vous pouvez explicitement autoriser ou refuser l’utilisation de commandes et d’instructions en configurant le allow-commands
, deny-commands
allow-configuration
et deny-configuration
les instructions pour une classe de connexion. Dans les instructions, vous utilisez des expressions régulières étendues pour définir les commandes et les instructions à autoriser ou refuser pour les utilisateurs assignés à la classe.
Exemple : Configurer les autorisations utilisateur avec des niveaux de privilèges d’accès
Cet exemple configure les autorisations utilisateur pour une classe de connexion. Vous configurez les autorisations utilisateur pour une classe de connexion afin d’empêcher les utilisateurs d’effectuer des actions réseau non autorisées. Les utilisateurs ne peuvent exécuter que les commandes et afficher et modifier uniquement les instructions pour lesquelles ils disposent de privilèges d’accès. Cette contrainte empêche les utilisateurs non autorisés d’exécuter des commandes sensibles ou de configurer des instructions susceptibles d’endommager le réseau.
Conditions préalables
Aucune configuration spéciale au-delà de l’initialisation de l’équipement n’est nécessaire avant de configurer cet exemple.
Présentation
Chaque commande CLI de niveau supérieur et chaque déclaration de configuration a un niveau de privilège d’accès associé. Lorsque vous configurez une classe de connexion, vous pouvez explicitement autoriser ou refuser l’utilisation de commandes et d’instructions de configuration de mode opérationnel et de configuration. Les utilisateurs peuvent exécuter uniquement les commandes et afficher et configurer uniquement les instructions pour lesquelles ils disposent de privilèges d’accès.
Vous définissez les droits d’accès pour chaque classe de connexion en spécifiant un ou plusieurs indicateurs d’autorisation dans l’instruction permissions
. Les indicateurs d’autorisation accordent à l’utilisateur l’accès aux commandes, aux déclarations et aux hiérarchies. Les indicateurs d’autorisation ne sont pas cumulables. Pour chaque classe de connexion, vous devez lister tous les indicateurs d’autorisation nécessaires, y compris view
pour afficher les informations et configure
accéder au mode de configuration. En spécifiant un indicateur d’autorisation spécifique sur la classe de connexion de l’utilisateur, vous donnez à l’utilisateur l’accès aux commandes, aux déclarations et aux hiérarchies correspondantes. Pour accorder l’accès à toutes les commandes et déclarations de configuration, utilisez l’indicateur d’autorisation all
. Les indicateurs d’autorisation fournissent une fonctionnalité de lecture seule (formulaire simple) et de lecture et d’écriture (forme qui se termine par -contrôle) pour un type d’autorisation.
Les all
bits d’autorisation de classe de connexion ont priorité sur les expressions régulières étendues lorsqu’un utilisateur émet une rollback
commande avec l’indicateur d’autorisation rollback
activé.
Pour configurer les niveaux de privilèges d’accès utilisateur pour une classe de connexion, incluez l’instruction permissions
au niveau de la [edit system login class class-name]
hiérarchie, suivie des indicateurs d’autorisation. Configurez plusieurs autorisations sous la forme d’une liste séparée de l’espace entre crochets :
[edit system login] user@host# set class class-name permissions permission-flag user@host# set class class-name permissions [flag1 flag2 flag3]
Pour afficher les autorisations disponibles, utilisez l’aide contextuelle de l’interface cli et saisissez un point d’interrogation (?) après l’énoncé permissions
:
[edit system login] user@host# set class class-name permissions ?
Configuration
Cet exemple configure la classe de snmp-admin
connexion. Les utilisateurs de cette classe de connexion peuvent uniquement configurer et afficher les paramètres SNMP.
Configurer les autorisations utilisateur avec des niveaux de privilèges d’accès
Procédure étape par étape
Pour configurer les privilèges d’accès pour la classe de connexion :
-
Configurez la
snmp-admin
classe de connexion avec lesconfigure
indicateurs ,snmp
etsnmp-control
d’autorisation.[edit system login] user@host# set class snmp-admin permissions [configure snmp snmp-control]
Les indicateurs d’autorisation configurés fournissent à la fois une fonctionnalité de lecture (snmp) et de lecture et d’écriture (snmp-control) pour SNMP, et il s’agit du seul privilège d’accès autorisé pour cette classe de connexion. Tous les autres privilèges d’accès sont refusés.
-
Créez les comptes d’utilisateur assignés à la
snmp-admin
classe de connexion.[edit system login] user@host# set user snmpuser class snmp-admin authentication plain-text-password New password: Retype new password:
Résultats
En mode configuration, confirmez votre configuration en entrant la show system login
commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
user@host# show system login class snmp-admin { permissions [ configure snmp snmp-control ]; } user snmpuser { class snmp-admin; authentication { encrypted-password "$ABC123"; ## SECRET-DATA } }
Après avoir configuré l’équipement, saisissez commit
le mode de configuration.
Vérification
Connectez-vous à l’aide d’un nom d’utilisateur attribué à la nouvelle classe de connexion et vérifiez que la configuration fonctionne correctement.
Vérifier la configuration SNMP
But
Vérifiez qu’un utilisateur de la snmp-admin
classe de connexion peut configurer SNMP.
Action
En mode configuration, configurez les instructions SNMP au niveau de la [edit snmp]
hiérarchie.
[edit snmp] user@host# set name device1 user@host# set description switch1 user@host# set location Lab1 user@host# set contact example.com user@host# commit
Sens
L’utilisateur de la snmp-admin
classe de connexion peut configurer les paramètres SNMP. L’utilisateur peut configurer ces paramètres, car les indicateurs d’autorisation spécifiés pour cette classe comprennent à la fois des bits d’autorisation snmp (capacités de lecture) et de contrôle snmp (capacités de lecture et d’écriture).
Vérifier une configuration non SNMP
But
Vérifiez qu’un utilisateur de la snmp-admin
classe de connexion ne peut pas modifier les instructions de configuration non SNMP.
Action
En mode configuration, essayez de configurer n’importe quelle instruction non SNMP, telle qu’une instruction dans la interfaces
hiérarchie.
[edit] user@host# edit interfaces Syntax error, expecting <statement> or <identifier>.
Sens
L’utilisateur de la snmp-admin
classe login n’est pas en mesure de configurer la [edit interfaces]
hiérarchie parce que les indicateurs d’autorisation spécifiés pour cette classe ne l’autorisent pas. Dans ce cas, la CLI émet un message d’erreur.
Expressions régulières pour autoriser et refuser les commandes du mode opérationnel, les déclarations de configuration et les hiérarchies
Cette rubrique contient les sections suivantes :
- Comprendre les déclarations d’autorisation et de refus
- Comprendre la syntaxe de l’instruction Autoriser et refuser
- Compréhension de la priorité et de la correspondance de l’instruction Autoriser et refuser
- Comprendre les règles d’instruction d’autorisation et de refus
- Comprendre les différences pour les déclarations *-regexps
- Utilisation d’expressions régulières sur les serveurs d’autorisation à distance
- Spécifier des expressions régulières
- Opérateurs d’expressions régulières
- Exemples d’expression régulière
Comprendre les déclarations d’autorisation et de refus
Chaque hiérarchie de commandes cli et d’énoncés de configuration de niveau supérieur a un niveau de privilège d’accès associé. Chaque classe de connexion peut explicitement autoriser ou refuser l’utilisation de commandes de mode opérationnel et de mode de configuration, ainsi que de hiérarchies et d’instructions de configuration qui seraient autrement autorisées ou refusées par un niveau de privilège. Les utilisateurs peuvent exécuter uniquement les commandes et afficher et configurer uniquement les instructions pour lesquelles ils disposent de privilèges d’accès.
Les privilèges d’accès pour chaque classe de connexion sont définis par un ou plusieurs indicateurs d’autorisation spécifiés dans l’instruction permissions
au niveau de la [edit system login class class-name]
hiérarchie. En outre, vous pouvez autoriser ou refuser l’utilisation de commandes et de hiérarchies de configuration spécifiques en définissant des expressions régulières étendues. Vous pouvez spécifier les expressions régulières en configurant les instructions suivantes pour une classe de connexion :
-
allow-commands
etdeny-commands
: autorisez ou refusez l’accès aux commandes du mode opérationnel et du mode de configuration. -
allow-configuration
etdeny-configuration
— Autoriser ou refuser l’accès à des hiérarchies de configuration spécifiques.REMARQUE :Ces instructions effectuent des correspondances plus lentes, avec plus de flexibilité, en particulier dans la correspondance de caractères génériques. Cependant, il peut être très long d’évaluer toutes les déclarations possibles si un grand nombre d’expressions régulières ou génériques de chemin complet sont configurés, ce qui peut affecter négativement les performances.
-
allow-commands-regexps
etdeny-commands-regexps
: autorisez ou refusez l’accès à des commandes particulières à l’aide de chaînes d’expressions régulières. -
allow-configuration-regexps
etdeny-configuration-regexps
: autorisez ou refusez l’accès à des hiérarchies de configuration spécifiques à l’aide de chaînes d’expressions régulières.
Si vos configurations existantes utilisent le allow/deny-commands
ou allow/deny-configuration
des instructions, l’utilisation des mêmes options de configuration avec les allow/deny-commands-regexps
ou allow/deny-configuration-regexps
des instructions risque de ne pas produire les mêmes résultats. Les méthodes de recherche et de correspondance diffèrent dans les deux formes de ces déclarations.
L’autorisation explicite des commandes et des hiérarchies d’instructions de configuration à l’aide allow/deny-*
des instructions ajoute aux autorisations que l’instruction permissions
définit déjà. De même, le refus explicite des commandes et des hiérarchies d’instructions de configuration à l’aide allow/deny-*
des instructions supprime les autorisations que l’instruction permissions
définit déjà.
Par exemple, dans la configuration suivante, l’autorisation configure
permet aux utilisateurs de la classe de connexion d’entrer en mode de configuration. En outre, l’expression allow-configuration
permet aux utilisateurs de modifier la configuration au niveau de la hiérarchie et de la [edit system services]
valider.
[edit system login class test] user@host# set permissions configure allow-configuration "system services"
De même, dans la configuration suivante, l’utilisateur de la classe de connexion peut effectuer toutes les opérations que l’indicateur all
d’autorisation permet, sauf que l’utilisateur ne peut pas afficher ou modifier la configuration au niveau de la [edit system services]
hiérarchie :
[edit system login class test] user@host# set permissions all deny-configuration "system services"
Comprendre la syntaxe de l’instruction Autoriser et refuser
Vous ne pouvez configurer une instruction qu’une allow/deny-*
seule fois dans chaque classe de connexion. Lorsque vous configurez une déclaration :
-
Vous pouvez configurer autant d’expressions régulières que nécessaire.
-
Les expressions régulières ne sont pas sensibles à la casse
Les allow/deny-commands
déclarations sont mutuellement exclusives avec les allow/deny-commands-regexps
déclarations, et les allow/deny-configuration
déclarations sont mutuellement exclusives avec les allow/deny-configuration-regexps
déclarations. Par exemple, vous ne pouvez pas configurer les deux allow-configuration
et allow-configuration-regexps
dans la même classe de connexion.
Pour définir des droits d’accès aux commandes, spécifiez des expressions régulières étendues à l’aide des allow-commands
instructions et deny-commands
. Enfermez chaque expression autonome complète entre parenthèses ( ) et utilisez le symbole de tuyau (| ) pour séparer les expressions. N’utilisez pas d’espaces entre les expressions régulières connectées au symbole du tuyau. L’expression complète est jointe entre deux guillemets.
allow-commands "(cmd1)|(cmd2)|(cmdn)" allow-configuration "(config1)|(config2)|(confign)"
Par exemple :
[edit system login class test] user@host# set allow-commands "(ping .*)|(traceroute .*)|(show .*)|(configure .*)|(edit)|(exit)|(commit)|(rollback .*)"
Vous devez utiliser des ancres pour spécifier des expressions régulières complexes avec l’instruction allow-commands
. Par exemple :
[edit system login] user@host# set class test allow-commands "(^monitor)|(^ping)|(^show)|(^exit)"
Pour définir des droits d’accès à certaines parties de la hiérarchie de configuration, spécifiez des expressions régulières étendues dans les allow-configuration
instructions et deny-configuration
. Enfermez l’ensemble des chemins entre parenthèses ( ) et utilisez le symbole du tuyau (|) pour séparer les expressions. N’utilisez pas d’espaces entre les expressions régulières connectées au symbole du tuyau. L’expression complète est jointe entre deux guillemets.
allow-configuration "(config1)|(config2)|(confign)"
Par exemple :
[edit system login class test] user@host# set deny-configuration "(system login class)|(system services)"
Lorsque vous spécifiez des expressions régulières étendues à l’aide de allow/deny-commands-regexps
allow/deny-configuration-regexps
ou d’instructions, enfermez chaque expression entre guillemets (« »), puis séparez les expressions à l’aide d’un espace. Enfermer plusieurs expressions entre crochets [ ]. Par exemple :
[edit system login class test] user@host# set allow-configuration-regexps ["interfaces .* description .*" "interfaces .* unit .* description .*" “interfaces .* unit .* family inet address .*" "interfaces.* disable"]
Les modificateurs tels que set
, log
et count
ne sont pas pris en charge dans la chaîne d’expression régulière à correspondre. Si vous utilisez un modificateur, rien n’est assorti.
Configuration correcte :
[edit system login class test] user@host# set deny-commands protocols
Configuration incorrecte :
[edit system login class test] user@host# set deny-commands "set protocols"
Compréhension de la priorité et de la correspondance de l’instruction Autoriser et refuser
Par défaut, les expressions et allow-configuration
les allow-commands
expressions régulières ont priorité sur deny-commands
et deny-configuration
les expresssions. Ainsi, si vous configurez la même commande pour les allow-commands
instructions et deny-commands
, alors l’opération d’autorisation prend la priorité sur l’opération de refus. De même, si vous configurez la même instruction pour les allow-configuration
instructions et deny-configuration
, alors l’opération d’autorisation a priorité sur l’opération de refus.
Par exemple, la configuration suivante permet à un utilisateur de la test
classe de connexion d’installer un logiciel à l’aide de la request system software add
commande, même si l’instruction deny-commands
comprend la même commande :
[edit system login class test] user@host# set allow-commands "request system software add" user@host# set deny-commands "request system software add"
De même, la configuration suivante permet à un utilisateur participant au test de classe test
de connexion d’afficher et de modifier la [edit system services]
hiérarchie de configuration, même si l’instruction deny-configuration
comprend la même hiérarchie :
[edit system login class test] user@host# set allow-configuration "system services" user@host# set deny-configuration "system services"
Si les allow-commands
instructions et deny-commands
ont deux variantes différentes d’une commande, la correspondance la plus longue est toujours exécutée. La configuration suivante permet à un utilisateur de la test
classe login d’exécuter la commit synchronize
commande, mais pas la commit
commande. C’est parce que commit synchronize
c’est la correspondance la plus longue entre commit
et commit synchronize
, et elle est spécifiée pour allow-commands
.
[edit system login class test] user@host# set allow-commands "commit synchronize" user@host# set deny-commands commit
La configuration suivante permet à un utilisateur de la test
classe login d’exécuter la commit
commande, mais pas la commit synchronize
commande. C’est parce que commit synchronize
c’est la correspondance la plus longue entre commit
et commit synchronize
, et elle est spécifiée pour deny-commands
.
[edit system login class test] user@host# set allow-commands commit user@host# set deny-commands "commit synchronize"
Contrairement aux autres déclarations, le comportement par défaut des déclarations est que les *-regexps
expressions et deny-configuration-regexps
les deny-commands-regexps
expressions régulières ont priorité sur allow-commands-regexps
et les allow-configuration-regexps
expressions. Vous pouvez configurer l’instruction regex-additive-logic
au niveau de la [edit system]
hiérarchie pour forcer les allow-configuration-regexps
expressions régulières à prendre la priorité sur les deny-configuration-regexps
déclarations. La configuration de l’instruction vous permet de refuser les hiérarchies de configuration à un niveau supérieur, puis d’autoriser l’utilisateur à accéder uniquement à des sous-hiérarchies spécifiques.
Comprendre les règles d’instruction d’autorisation et de refus
Les allow/deny-commands
, allow/deny-configuration
, , allow/deny-commands-regexps
et allow/deny-configuration-regexps
les instructions ont priorité sur les autorisations de classe de connexion. Lorsque vous configurez ces instructions, les règles suivantes s’appliquent :
-
Les expressions
allow-commands
etdeny-commands
les instructions régulières peuvent également inclure lecommit
,load
,rollback
,save
,status
et lesupdate
commandes. -
Les
all
bits d’autorisation de classe de connexion ont priorité sur les expressions régulières étendues lorsqu’un utilisateur émet larollback
commande avec l’indicateur d’autorisationrollback
activé. -
Les utilisateurs ne peuvent pas émettre la
load override
commande lorsqu’ils spécifient une expression régulière étendue. Les utilisateurs ne peuvent émettre que lesmerge
commandes ,replace
etpatch
de configuration. -
Vous pouvez utiliser le caractère générique * pour dénoter des expressions régulières. Cependant, vous devez l’utiliser dans le cadre d’une expression régulière. Vous ne pouvez pas utiliser
[ * ]
ou[ .* ]
comme seule expression. En outre, vous ne pouvez pas configurer l’instructionallow-configuration
avec une expression telle que(interfaces (description (|.*))
, car cela évalue àallow-configuration .*
.
Comprendre les différences pour les déclarations *-regexps
Cette section présente les différences entre les allow/deny-configuration
déclarations et les allow/deny-configuration-regexps
déclarations.
Les allow/deny-configuration-regexps
déclarations divisent l’expression régulière en jetons et font correspondre chaque élément à chaque partie du chemin complet de la configuration spécifiée, tandis que les allow/deny-configuration
déclarations correspondent à la chaîne complète. Pour allow/deny-configuration-regexps
les instructions, vous configurez un ensemble de chaînes dans laquelle chaque chaîne est une expression régulière, avec des espaces entre les termes de la chaîne. Cette syntaxe offre une correspondance très rapide, mais offre moins de flexibilité. Pour spécifier des expressions génériques, vous devez configurer des caractères génériques pour chaque jeton de la chaîne délimitée par l’espace que vous souhaitez faire correspondre, ce qui rend plus difficile l’utilisation d’expressions génériques pour ces déclarations.
Par exemple :
-
Correspondance d’expression régulière avec un jeton à l’aide de regexps de configuration autorisée
Cet exemple montre que
options
c’est la seule expression correspondant au premier jeton de l’instruction.[edit system] login { class test { permissions configure; allow-configuration-regexps .*options; } }
La configuration précédente correspond aux déclarations suivantes :
-
définir la condition condition de stratégie-options dynamic-db
-
définir les options de routage route static-route statique saut suivant next-hop
-
définir les options d’événements générer un intervalle de temps d’événement eventseconds
La configuration précédente ne correspond pas aux déclarations suivantes :
-
options d’hôte du nom d’hôte système
-
options de description des interfacesinterface-name
-
-
Correspondance d’expression régulière avec trois jetons à l’aide de regexps de configuration autorisée
Cet exemple montre qu’il
ssh
s’agit de la seule expression correspondant au troisième jeton de l’instruction.[edit system] login { class test { permissions configure; allow-configuration-regexps ".* .* .*ssh"; } }
Dans l’exemple précédent, les trois jetons comprennent
.*
,.*
et.*ssh
, respectivement.La configuration précédente correspond aux déclarations suivantes :
-
nom d’hôte système hostname-ssh
-
services système ssh
-
services système outbound-ssh
La configuration précédente ne correspond pas à l’énoncé suivant :
-
description des interfaces interface-namessh
-
Il est plus facile d’utiliser l’instruction pour restreindre l’accès deny-configuration
à la configuration que pour utiliser l’instruction deny-configuration-regexps
. Tableau 2 Illustre l’utilisation des deny-configuration
deny-configuration-regexps
et des déclarations dans différentes configurations pour obtenir le même résultat de restreindre l’accès à une configuration particulière.
Configuration refusée |
Utilisant: |
Utilisant: |
Résultat |
|
[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""; } } |
L’instruction de configuration suivante est refusée :
|
|
[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"; } } |
Les instructions de configuration suivantes sont refusées :
|
Bien que les allow/deny-configuration
instructions soient également utiles lorsque vous souhaitez une configuration simple, elles allow/deny-configuration-regexps
offrent de meilleures performances et surmontent l’ambiguïté qui existait lors de la combinaison d’expressions dans les allow/deny-configuration
instructions.
Utilisation d’expressions régulières sur les serveurs d’autorisation à distance
Vous pouvez utiliser des expressions régulières étendues pour spécifier les commandes du mode opérationnel et du mode de configuration, ainsi que les instructions de configuration et les hiérarchies autorisées ou refusées pour certains utilisateurs. Vous spécifiez ces expressions régulières localement dans le allow/deny-commands
, allow/deny-commands-regexps
allow/deny-configuration
et allow/deny-configuration-regexps
les instructions au niveau de la [edit system login class class-name]
hiérarchie. Vous spécifiez ces expressions régulières à distance en spécifiant les attributs TACACS+ ou RADIUS spécifiques aux fournisseurs Juniper Networks dans la configuration de votre serveur d’autorisation. Lorsque vous configurez les paramètres d’autorisation à la fois localement et à distance, l’équipement fusionne les expressions régulières reçues lors de l’autorisation TACACS+ ou RADIUS avec toutes les expressions régulières définies sur l’équipement local.
À partir de la version 18.1 de Junos OS, les instructions et deny-commands-regexps
sont prises en charge pour l’autorisation allow-commands-regexps
TACACS+.
Lorsque vous spécifiez plusieurs expressions régulières dans une configuration locale à l’aide de allow-commands
, deny-commands
allow-configuration
ou deny-configuration
d’instructions, vous configurez les expressions régulières entre parenthèses et séparez-les à l’aide du symbole de tuyau. Vous joignez l’expression complète entre guillemets. Par exemple, vous pouvez spécifier plusieurs allow-commands
paramètres avec la syntaxe suivante :
allow-commands "(cmd1)|(cmd2)|(cmdn)"
Le serveur d’autorisation RADIUS utilise les attributs et la syntaxe suivants :
Juniper-Allow-Commands += "(cmd1)|(cmd2)|(cmd3)", Juniper-Deny-Commands += "(cmd1)|(cmd2)", Juniper-Allow-Configuration += "(config1)|(config2)", Juniper-Deny-Configuration += "(config1)|(config2)",
Le serveur d’autorisation TACACS+ utilise les attributs et la syntaxe suivants :
allow-commands = "(cmd1)|(cmd2)|(cmdn)" deny-commands = "(cmd1)|(cmd2)|(cmdn)" allow-configuration = "(config1)|(config2)|(confign)" deny-configuration = "(config1)|(config2)|(confign)"
Lorsque vous spécifiez plusieurs expressions régulières dans une configuration locale à l’aide de allow-commands-regexps
, deny-commands-regexps
allow-configuration-regexps
ou deny-configuration-regexps
d’instructions, vous configurez des expressions régulières dans des guillemets doubles et séparez-les à l’aide de l’opérateur d’espace. Vous joignez l’expression complète entre crochets. Par exemple, vous pouvez spécifier plusieurs paramètres allow-commands avec la syntaxe suivante :
allow-commands-regexps [ "cmd1" "cmd2" "cmdn" ]
Le serveur d’autorisation RADIUS utilise les attributs et la syntaxe suivants :
Juniper-Allow-Configuration-Regexps += "(config1)|(config2)|(confign)", Juniper-Deny-Configuration-Regexps += "(config1)|(config2)|(confign)",
Le serveur d’autorisation TACACS+ utilise les attributs et la syntaxe suivants :
allow-commands-regexps = "(cmd1)|(cmd2)|(cmdn)" deny-commands-regexps = "(cmd1)|(cmd2)|(cmdn)" allow-configuration-regexps = "(config1)|(config2)|(confign)" deny-configuration-regexps = "(config1)|(config2)|(confign)"
Les serveurs RADIUS et TACACS+ prennent également en charge une syntaxe simplifiée dans laquelle vous spécifiez chaque expression individuelle sur une ligne distincte. Par exemple, la syntaxe simplifiée du serveur RADIUS est :
Juniper-Allow-Commands += "cmd1", Juniper-Allow-Commands += "cmd2", Juniper-Allow-Commands += "cmdn",
De même, la syntaxe simplifiée du serveur TACACS+ est :
allow-commands-regexps1 = "cmd1" allow-commands-regexps2 = "cmd2" allow-commands-regexpsn = "cmdn"
Tableau 3 différencie la configuration d’autorisation locale et la configuration d’autorisation serveur TACACS+ à l’aide d’expressions régulières.
Configuration locale |
Configuration TACACS+ à distance |
---|---|
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" } } |
-
Vous devez autoriser explicitement l’accès au mode NETCONF, que ce soit localement ou à distance, en envoyant les trois commandes suivantes :
xml-mode
,netconf
etneed-trailer
. -
Lorsque vous utilisez l’instruction
deny-configuration = ".*"
, vous devez autoriser toutes les configurations souhaitées à l’aide de l’instructionallow-configuration
. Toutefois, cette configuration peut affecter la limite de tampon d’expressions régulières autorisée pour l’instructionallow-configuration
. Si cette limite est dépassée, la configuration autorisée risque de ne pas fonctionner.
Spécifier des expressions régulières
Lorsque vous spécifiez des expressions régulières pour les commandes et les instructions de configuration, portez une attention particulière aux exemples suivants. Une expression régulière avec une syntaxe non valide peut ne pas produire les résultats souhaités, même si la configuration est validée sans aucune erreur.
Vous devez spécifier des expressions régulières pour les commandes et les instructions de configuration de la même manière que l’exécution de la commande ou de l’instruction complète. Tableau 4 répertorie les expressions régulières pour configurer les privilèges d’accès pour les [edit interfaces]
hiérarchies et [edit vlans]
d’instruction.
Déclaration |
Expression régulière |
Configuration Notes |
---|---|---|
[edit interfaces] La [edit] user@host# set interfaces interface-name unit interface-unit-number |
L’instruction En conséquence, l’expression régulière requise pour refuser la configuration doit spécifier l’ensemble [edit system login class class-name] user@host# set permissions configure user@host# set deny-configuration "interfaces .* unit .*" |
|
[edit vlans] La [edit] user@host# set vlans vlan-name vlan-id vlan-id |
Ici, l’instruction En conséquence, l’expression régulière requise pour permettre la configuration doit spécifier l’ensemble [edit system login class class-name] user@host# set permissions configure user@host# set allow-configuration "vlans .* vlan-id .*" |
|
Opérateurs d’expressions régulières
Tableau 5 répertorie les opérateurs d’expression régulière courants que vous pouvez utiliser pour autoriser ou refuser les modes opérationnels et de configuration.
Les expressions régulières de commande implémentent les expressions régulières étendues (modernes), telles que définies dans POSIX 1003.2.
Opérateur |
Correspondance |
Exemple |
---|---|---|
| |
Un ou plusieurs termes séparés par le tuyau. Chaque terme doit être une expression autonome complète enfermée entre parenthèses (), sans espace entre le tuyau et les parenthèses adjacentes. |
[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)" Avec la configuration précédente, les utilisateurs assignés à la classe de connexion de test disposent d’un accès en mode opérationnel limité aux seules commandes spécifiées dans l’instruction |
^ |
Au début d’une expression, utilisée pour désigner l’endroit où commence la commande, où il peut y avoir une certaine ambiguïté. |
[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)" Avec la configuration précédente, les utilisateurs assignés à la classe de connexion de test ont accès à l’affichage et à la configuration de l’interface. L’instruction Pour le premier filtre, les commandes spécifiées comprennent le |
$ |
Caractère à la fin d’une commande. Utilisé pour désigner une commande qui doit correspondre exactement jusqu’à ce point. |
[edit system login class test] user@host# set permissions interface user@host# set allow-commands "(show interfaces$)" Avec la configuration précédente, les utilisateurs assignés à la classe de connexion de test peuvent afficher la configuration des interfaces en mode configuration. Les utilisateurs peuvent également consulter la configuration de l’interface avec la commande du |
[ ] |
Plage de lettres ou de chiffres. Pour séparer le début et la fin d’une plage, utilisez un trait d’union (- |
[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 .*" ] Avec la configuration précédente, les utilisateurs assignés à la classe de connexion de test disposent d’autorisations utilisateur de niveau opérateur. Ces utilisateurs ont également accès à la configuration des interfaces dans la plage spécifiée de nom d’interface et de numéro d’unité (0 à 9). |
( ) |
Un groupe de commandes indiquant une expression complète et autonome à évaluer. Le résultat est ensuite évalué dans le cadre de l’expression globale. Les parenthèses doivent être utilisées conjointement avec les opérateurs de tuyaux, comme expliqué. |
[edit system login class test] user@host# set permissions all user@host# set allow-commands "(clear)|(configure)" user@host# deny-commands "(mtrace)|(start)|(delete)" Avec la configuration ci-dessus, les utilisateurs assignés à la classe de connexion test disposent d’autorisations de niveau superutilisateur et ont accès aux commandes spécifiées dans l’instruction |
* |
Zéro mandat ou plus. |
[edit system login class test] user@host# set permissions configure user@host# set deny-configuration "(system login class m*)" Avec la configuration ci-dessus, les utilisateurs assignés |
+ |
Un ou plusieurs termes. |
[edit system login class test] user@host# set permissions configure user@host# set deny-configuration "(system login class m+)" Avec la configuration ci-dessus, les utilisateurs assignés |
. |
Tout caractère à l’exception d’un espace " « . |
[edit system login class test] user@host# set permissions configure user@host# set deny-configuration "(system login class m.)" Avec la configuration ci-dessus, les utilisateurs assignés |
.* |
Tout à partir du point spécifié. |
[edit system login class test] user@host# set permissions configure user@host# set deny-configuration "(system login class m .*)" Avec la configuration ci-dessus, les utilisateurs assignés De même, l’instruction REMARQUE :
|
L’opérateur !
d’expression régulière n’est pas pris en charge.
Exemples d’expression régulière
Tableau 6 répertorie les expressions régulières utilisées pour autoriser les options de configuration dans deux hiérarchies de configuration,[edit system ntp server]
et [edit protocols rip]
par exemple pour spécifier des expressions régulières.
Tableau 6 ne fournit pas de liste complète de toutes les expressions et mots-clés réguliers pour toutes les déclarations de configuration et toutes les hiérarchies. Les expressions régulières répertoriées dans le tableau sont validées uniquement pour les [edit system ntp server]
hiérarchies et [edit protocols rip]
d’instruction.
Hiérarchie des déclarations |
Expressions régulières |
Configuration autorisée |
Configuration refusée |
---|---|---|---|
|
|||
Clé key-number |
[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" ] |
|
|
Version version-number |
[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" ] |
|
|
Préfère |
[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 .*" ] |
|
|
|
|||
taille du message message-size |
[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 .*" ] |
|
|
métrique-in metric-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 .*" ] |
|
|
timeout de routage 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 .*" ] |
|
|
intervalle de mise à jour update-interval |
[edit system login class test] set permissions configure set allow-configuration-regexps "protocols rip update-interval .*" set deny-configuration-regexps [ "protocols rip metric-in .*" "protocols rip route-timeout .*" "protocols rip message-size .*" ] |
|
|
Comment définir des privilèges d’accès avec des déclarations d’autorisation de configuration et de refus de configuration
Vous pouvez définir des privilèges d’accès pour les hiérarchies d’instructions de configuration à l’aide d’une combinaison des types d’instructions suivants :
indicateurs d’autorisation
allow-configuration
etdeny-configuration
déclarations
Les indicateurs d’autorisation définissent les limites plus larges de ce qu’une personne ou une classe de connexion peut accéder et contrôler. Les allow-configuration
instructions et deny-configuration
contiennent une ou plusieurs expressions régulières qui autorisent ou refusent des hiérarchies de configuration et des déclarations spécifiques. Les allow-configuration
déclarations et deny-configuration
ont priorité sur les indicateurs d’autorisation et donnent à l’administrateur un contrôle plus fin sur les hiérarchies et les déclarations que l’utilisateur peut afficher et configurer.
Cette rubrique explique comment définir des privilèges d’accès à l’aide allow-configuration
d’instructions et deny-configuration
des instructions en montrant des exemples de configurations de classe de connexion qui utilisent ces instructions. Les exemples 1 à 3 créent des classes d’identification qui permettent aux utilisateurs d’accéder à toutes les commandes et déclarations, à l’exception de celles définies dans l’instruction deny-configuration
.
Notez que le bit d’autorisation et l’indicateur d’autorisation sont utilisés indifféremment.
Exemple 1
Pour créer une classe de connexion qui permet à l’utilisateur d’exécuter toutes les commandes et de tout configurer, à l’exception des paramètres telnet :
Exemple 2
Pour créer une classe de connexion qui permet à l’utilisateur d’exécuter toutes les commandes et de tout configurer, à l’exception des instructions dans n’importe quelle classe de connexion dont le nom commence par « m » :
-
Définissez les autorisations de classe de connexion de l’utilisateur sur
all
.[edit system login] user@host# set class all-except-login-class-m permissions all
-
Incluez l’énoncé suivant
deny-configuration
.[edit system login class all-except-login-class-m] user@host# set deny-configuration "system login class m.*"
Exemple 3
Pour créer une classe de connexion qui permet à l’utilisateur d’exécuter toutes les commandes et de tout configurer, sauf les [edit system login class]
niveaux hiérarchiques :[edit system services]
-
Définissez les autorisations de classe de connexion de l’utilisateur sur
all
.[edit system login] user@host# set class all-except-login-class-or-system-services permissions all
-
Incluez la déclaration suivante
deny-configuration
:[edit system login class all-except-login-class-or-system-services] user@host# set deny-configuration "(system login class) | (system services)"
Les exemples suivants montrent comment utiliser les allow-configuration
instructions et deny-configuration
pour déterminer les autorisations inverses les unes des autres pour le [edit system services]
niveau hiérarchique.
Exemple 4
Pour créer une classe de connexion qui permet à l’utilisateur de disposer de privilèges de configuration complets uniquement au [edit system services]
niveau hiérarchique :
-
Définissez les autorisations de classe de connexion de l’utilisateur sur
configure
.[edit system login] user@host# set class configure-only-system-services permissions configure
-
Incluez la déclaration suivante
allow-configuration
:[edit system login class configure-only-system-services] user@host# set allow-configuration "system services"
Exemple 5
Pour créer une classe de connexion qui donne à l’utilisateur des autorisations complètes pour toutes les commandes et toutes les hiérarchies de configuration, à l’exception du [edit system services]
niveau hiérarchique :
-
Définissez les autorisations de classe de connexion de l’utilisateur sur
all
.[edit system login] user@host# set class all-except-system-services permissions all
-
Incluez l’énoncé suivant
deny-configuration
.[edit system login class all-except-system-services] user@host# set deny-configuration "system services"
Exemple : Utiliser la logique additive avec des expressions régulières pour spécifier des privilèges d’accès
Cet exemple montre comment utiliser une logique additive lorsque vous utilisez des expressions régulières pour configurer les privilèges d’accès.
Conditions préalables
Cet exemple utilise un équipement exécutant Junos OS version 16.1 ou ultérieure.
Présentation
Vous pouvez définir des expressions régulières pour contrôler qui peut apporter des modifications à la configuration et ce qu’elles peuvent changer. Ces expressions régulières indiquent des hiérarchies de configuration spécifiques auxquelles les utilisateurs d’une classe de connexion sont autorisés à accéder. Par exemple, vous pouvez définir des expressions régulières qui permettent aux utilisateurs de modifier un groupe d’instances de routage et définir des expressions régulières qui empêchent les utilisateurs d’apporter des modifications à d’autres instances de routage ou à d’autres niveaux de configuration. Vous définissez les expressions régulières en configurant les allow-configuration-regexps
instructions et deny-configuration-regexps
pour une classe de connexion.
Par défaut, l’instruction deny-configuration-regexps
prévaut sur l’instruction allow-configuration-regexps
. Si une hiérarchie de configuration apparaît dans une deny-configuration-regexps
instruction pour une classe de connexion, elle n’est pas visible par les utilisateurs de cette classe, quel que soit le contenu de l’instruction allow-configuration-regexps
. Si une hiérarchie de configuration n’apparaît pas dans une deny-configuration-regexps
instruction, elle est visible par les utilisateurs de cette classe si elle apparaît dans une allow-configuration-regexps
instruction.
Vous pouvez modifier ce comportement par défaut en activant une logique additive pour les *-configuration-regexps
déclarations. Lorsque vous activez la logique d’additif, l’instruction allow-configuration-regexps
a priorité sur l’instruction deny-configuration-regexps
.
Ainsi, si l’instruction refuse l’accès deny-configuration-regexps
à toutes les hiérarchies de configuration à un niveau donné (protocoles .*) mais que l’instruction autorise l’accès allow-configuration-regexps
à une sous-hiérarchie (protocoles bgp .*), l’équipement refuse par défaut l’accès aux hiérarchies pour les utilisateurs de cette classe de connexion, car l’instruction deny-configuration-regexps
prime. Toutefois, si vous activez la logique d’additif, l’équipement autorise l’accès à la sous-hiérarchie spécifiée pour les utilisateurs de cette classe de connexion, car la allow-configuration-regexps
priorité est dans ce cas.
Configuration
Procédure étape par étape
Pour activer la logique additive pour permettre explicitement aux utilisateurs d’une classe d’identification donnée d’accéder à une ou plusieurs hiérarchies de configuration individuelles :
-
Incluez l’instruction
deny-configuration-regexps
et refusez explicitement l’accès aux hiérarchies de configuration.[edit system login class class-name] user@host# set deny-configuration-regexps ["regular expression 1" "regular expression 2" "regular expression 3"]
Par exemple :
[edit system login class class-name] user@host# set deny-configuration-regexps "protocols .*"
-
Incluez l’instruction
allow-configuration-regexps
et définissez des expressions régulières pour les hiérarchies spécifiques.[edit system login class class-name] user@host# set allow-configuration-regexps ["regular expression 1" "regular expression 2" "regular expression 3"]
Par exemple :
[edit system login class class-name] user@host# set allow-configuration-regexps ["protocols bgp .*" "protocols ospf .*"]
-
Activez la logique additive pour les
allow-configuration-regexps
expressions etdeny-configuration-regexps
les expressions régulières.[edit system] user@host# set regex-additive-logic
-
Attribuez la classe de connexion à un ou plusieurs utilisateurs.
[edit system login] user@host# set user username class class-name
-
Validez vos modifications.
Les utilisateurs assignés à cette classe de connexion ont accès aux hiérarchies de configuration incluses dans l’instruction
allow-configuration-regexps
, mais n’ont pas accès aux autres hiérarchies spécifiées dans l’instructiondeny-configuration-regexps
.
Lorsque vous configurez l’instruction regex-additive-logic
, le changement de comportement s’applique à toutes et aux allow-configuration-regexps
deny-configuration-regexps
déclarations présentes dans toutes les classes de connexion. Si vous activez la logique additive, vous devez évaluer les déclarations existantes pour tout impact et mettre à jour les expressions régulières de ces déclarations le cas échéant.
Exemples
Utiliser des expressions régulières avec la logique additive
But
Cette section fournit des exemples d’expressions régulières qui utilisent la logique additive pour vous donner des idées pour créer des configurations adaptées à votre système.
Autoriser des instances de routage spécifiques
L’exemple suivant de classe login inclut une expression régulière qui permet de configurer des instances de routage dont les noms commencent CUST-VRF-
par ; par exemple, CUST-VRF-1
, CUST-VRF-25
, CUST-VRF-100
, et ainsi de suite. L’exemple inclut également une expression régulière qui empêche la configuration de toutes les instances de routage.
[edit system login class class-name] user@host# set permissions [configure routing-control view view-configuration] user@host# set deny-configuration-regexps "routing-instances .*" user@host# set allow-configuration-regexps "routing-instances CUST-VRF-.* .*"
Par défaut, l’instruction deny-configuration-regexps
prime, et la configuration précédente empêche les utilisateurs de la classe de connexion de configurer des instances de routage, quel que soit le nom.
Toutefois, si vous configurez l’instruction suivante, l’instruction allow-configuration-regexps
prime. Ainsi, les utilisateurs peuvent configurer des instances de routage dont le nom commence par CUST-VRF-
, mais les utilisateurs ne peuvent pas configurer d’autres instances de routage.
[edit system] user@host# set regex-additive-logic
Autoriser la configuration peer BGP uniquement
L’exemple de classe de connexion suivant inclut des expressions régulières qui empêchent la configuration au niveau de la [edit protocols]
hiérarchie, mais autorisent la configuration des pairs BGP :
[edit system login class class-name] user@host# set permissions [configure routing-control view view-configuration] user@host# set deny-configuration-regexps "protocols .*" user@host# set allow-configuration-regexps "protocols bgp group *"
Par défaut, la configuration précédente empêche les utilisateurs de la classe de connexion d’apporter des modifications aux hiérarchies sous [edit protocols]
.
Toutefois, si vous configurez l’instruction suivante, les utilisateurs de la classe de connexion peuvent apporter des modifications aux pairs BGP, mais ils ne peuvent pas configurer d’autres protocoles ou déclarations BGP en dehors du niveau hiérarchique autorisé.
[edit system] user@host# set regex-additive-logic
Vérification
Pour vérifier que vous avez correctement défini les droits d’accès :
-
Configurez une classe de connexion et validez les modifications.
-
Attribuez la classe de connexion à un .username
-
Connectez-vous comme username assigné avec la nouvelle classe de connexion.
-
Essayez de configurer les niveaux hiérarchiques autorisés.
-
Vous devriez pouvoir configurer des instructions dans les niveaux hiérarchiques autorisés.
-
Les niveaux hiérarchiques refusés ne doivent pas être visibles.
-
Toutes les expressions autorisées ou refusées doivent primer sur les autorisations accordées avec l’instruction
permissions
.
-
Exemple : Configurer les autorisations utilisateur avec des privilèges d’accès pour les commandes du mode opérationnel
Cet exemple montre comment configurer des classes de connexion personnalisées et attribuer des privilèges d’accès aux commandes du mode opérationnel. Les utilisateurs de la classe login ne peuvent exécuter que les commandes auxquelles ils ont accès. Cela empêche les utilisateurs non autorisés d’exécuter des commandes sensibles qui pourraient endommager le réseau.
Conditions préalables
Cet exemple utilise les composants matériels et logiciels suivants :
-
Un seul équipement Juniper Networks
-
Un serveur TACACS+ (ou RADIUS)
Avant de commencer, établissez une connexion TCP entre l’équipement et le serveur TACACS+. Dans le cas du serveur RADIUS, établissez une connexion UDP entre l’équipement et le serveur RADIUS.
Présentation et topologie
Figure 1 illustre une topologie simple, où le routeur R1 est un équipement Juniper Networks et dispose d’une connexion TCP établie avec un serveur TACACS+.

Cet exemple configure R1 avec trois classes de connexion personnalisées : Classe1, Classe2 et Classe3. Chaque classe définit les droits d’accès pour l’utilisateur en configurant l’instruction permissions
et en définissant des expressions régulières étendues à l’aide des allow-commands
instructions et.deny-commands
L’objectif de chaque classe de connexion est le suivant :
-
Class1: définit les privilèges d’accès pour l’utilisateur avec l’instruction
allow-commands
uniquement. Cette classe de connexion fournit des autorisations et des autorisations utilisateur au niveau de l’opérateur pour redémarrer l’équipement. -
Class2: définit les privilèges d’accès pour l’utilisateur avec l’instruction
deny-commands
uniquement. Cette classe de connexion fournit des autorisations utilisateur de niveau opérateur et refuse l’accès auxset
commandes. -
Class3: définit les privilèges d’accès pour l’utilisateur à l’aide des
allow-commands
déclarations etdeny-commands
. Cette classe de connexion fournit des autorisations et des autorisations d’accès aux interfaces et d’affichage des informations sur l’équipement au niveau superutilisateur. Il refuse également l’accès auxedit
commandes etconfigure
.
Le routeur R1 a trois utilisateurs différents, User1, User2 et User3 assignés aux classes de connexion Class1, Class2 et Class3, respectivement .
Configuration
- Configuration rapide cli
- Configurer les paramètres d’authentification du routeur R1
- Configurez les privilèges d’accès avec l’instruction allow-commands (Classe1)
- Configurez les privilèges d’accès avec l’instruction deny-commands (Class2)
- Configurez les privilèges d’accès avec les déclarations allow-commands et deny-commands (Classe3)
- Résultats
Configuration rapide cli
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à votre configuration réseau, copiez et collez les commandes dans la CLI au niveau de la [edit]
hiérarchie, puis entrez commit
en mode configuration.
R1
set system authentication-order tacplus set system authentication-order radius set system authentication-order password set system radius-server 10.209.1.66 secret "$ABC123" set system tacplus-server 10.209.1.66 secret "$ABC123" set system radius-options enhanced-accounting set system tacplus-options enhanced-accounting set system accounting events login set system accounting events change-log set system accounting events interactive-commands set system accounting traceoptions file auditlog set system accounting traceoptions flag all set system accounting destination tacplus server 10.209.1.66 secret "$ABC123" set system login class Class1 permissions clear set system login class Class1 permissions network set system login class Class1 permissions reset set system login class Class1 permissions trace set system login class Class1 permissions view set system login class Class1 allow-commands "request system reboot" set system login class Class2 permissions clear set system login class Class2 permissions network set system login class Class2 permissions reset set system login class Class2 permissions trace set system login class Class2 permissions view set system login class Class2 deny-commands set set system login class Class3 permissions all set system login class Class3 allow-commands configure set system login class Class3 deny-commands .* set system login user User1 uid 2001 set system login user User1 class Class1 set system login user User1 authentication encrypted-password "$ABC123" set system login user User2 uid 2002 set system login user User2 class Class2 set system login user User2 authentication encrypted-password "$ABC123" set system login user User3 uid 2003 set system login user User3 class Class3 set system login user User3 authentication encrypted-password "$ABC123" set system syslog file messages any any
Configurer les paramètres d’authentification du routeur R1
Procédure étape par étape
Pour configurer l’authentification R1 du routeur :
-
Configurez l’ordre dans lequel le R1 tente d’authentifier l’utilisateur. Dans cet exemple, l’authentification du serveur TACACS+ est d’abord suivie de l’authentification du serveur RADIUS, puis du mot de passe local.
[edit system] user@R1# set authentication-order tacplus user@R1# set authentication-order radius user@R1# set authentication-order password
-
Configurez le serveur TACACS+.
[edit system] user@R1# set tacplus-server 10.209.1.66 secret "$ABC123" user@R1# set tacplus-options enhanced-accounting user@R1# set accounting destination tacplus server 10.209.1.66 secret "$ABC123"
-
Configurez le serveur RADIUS.
[edit system] user@R1# set radius-server 10.209.1.66 secret "$ABC123" user@R1# set radius-options enhanced-accounting
-
Configurez les paramètres de comptabilisation R1.
[edit system] user@R1# set accounting events login user@R1# set accounting events change-log user@R1# set accounting events interactive-commands user@R1# set accounting traceoptions file auditlog user@R1# set accounting traceoptions flag all
Configurez les privilèges d’accès avec l’instruction allow-commands (Classe1)
Procédure étape par étape
Pour spécifier des expressions régulières à l’aide de l’instruction allow-commands
:
-
Configurez la classe de connexion Classe1 et attribuez des autorisations utilisateur de niveau opérateur.
[edit system login] user@R1# set class Class1 permissions [clear network reset trace view]
-
Configurez l’expression
allow-commands
régulière pour permettre aux utilisateurs de la classe de redémarrer l’équipement.[edit system login] user@R1# set class Class1 allow-commands "request system reboot"
-
Configurez le compte utilisateur pour la classe de connexion Classe1.
[edit system login] user@R1# set user User1 uid 2001 user@R1# set user User1 class Class1 user@R1# set user User1 authentication encrypted-password "$ABC123"
Configurez les privilèges d’accès avec l’instruction deny-commands (Class2)
Procédure étape par étape
Pour spécifier des expressions régulières à l’aide de l’instruction deny-commands
:
-
Configurez la classe de connexion classe2 et attribuez des autorisations utilisateur de niveau opérateur.
[edit system login] user@R1# set class Class1 permissions [clear network reset trace view]
-
Configurez l’expression
deny-commands
régulière pour empêcher les utilisateurs de la classe d’exécuterset
des commandes.[edit system login] user@R1# set class Class1 deny-commands "set"
-
Configurez le compte utilisateur pour la classe de connexion Classe2.
[edit system login] user@R1# set user User2 uid 2002 user@R1# set user User2 class Class2 user@R1# set user User2 authentication encrypted-password "$ABC123"
Configurez les privilèges d’accès avec les déclarations allow-commands et deny-commands (Classe3)
Procédure étape par étape
Pour spécifier des expressions régulières à l’aide d’instructions et de et allow-commands
deny-commands
:
-
Configurez la classe de connexion classe3 et attribuez des autorisations de niveau superutilisateur.
[edit system login] user@R1# set class Class3 permissions all
-
Configurez l’expression
deny-commands
régulière pour empêcher les utilisateurs de la classe d’exécuter des commandes.[edit system login] user@R1# set class Class3 deny-commands ".*"
-
Configurez l’expression
allow-commands
régulière pour permettre aux utilisateurs d’entrer en mode de configuration.[edit system login] user@R1# set class Class3 allow-commands configure
-
Configurez le compte utilisateur pour la classe de connexion Classe3.
[edit system login] user@R1# set user User3 uid 2003 user@R1# set user User3 class Class3 user@R1# set user User3 authentication encrypted-password "$ABC123"
Résultats
En mode configuration, confirmez votre configuration en entrant la show system
commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
user@R1# show system authentication-order [ tacplus radius password ]; radius-server { 10.209.1.66 secret "$ABC123"; } tacplus-server { 10.209.1.66 secret "$ABC123"; } radius-options { enhanced-accounting; } tacplus-options { enhanced-accounting; } accounting { events [ login change-log interactive-commands ]; traceoptions { file auditlog; flag all; } destination { tacplus { server { 10.209.1.66 secret "$ABC123"; } } } } login { class Class1 { permissions [ clear network reset trace view ]; allow-commands "request system reboot"; } class Class2 { permissions [ clear network reset trace view ]; deny-commands set; } class Class3 { permissions all; allow-commands configure; deny-commands .*; } user User1 { uid 2001; class Class1; authentication { encrypted-password "$ABC123"; } } user User2 { uid 2002; class Class2; authentication { encrypted-password "$ABC123"; } } user User3 { uid 2003; class Class3; authentication { encrypted-password “$ABC123”; } } } syslog { file messages { any any; } }
Vérification
Connectez-vous en tant que nom d’utilisateur assigné à la nouvelle classe de connexion et vérifiez que la configuration fonctionne correctement.
- Vérification de la configuration de classe 1
- Vérification de la configuration de classe 2
- Vérification de la configuration de classe 3
Vérification de la configuration de classe 1
But
Vérifiez que les autorisations et les commandes autorisées dans la classe de connexion de classe 1 fonctionnent.
Action
En mode opérationnel, exécutez la show system users
commande.
User1@R1> show system users 12:39PM up 6 days, 23 mins, 6 users, load averages: 0.00, 0.01, 0.00 USER TTY FROM LOGIN@ IDLE WHAT User1 p0 abc.example.net 12:34AM 12:04 cli User2 p1 abc.example.net 12:36AM 12:02 -cli (cli) User3 p2 abc.example.net 10:41AM 11 -cli (cli)
En mode opérationnel, exécutez la request system reboot
commande.
User1@R1> request system ? Possible completions: reboot Reboot the system
Sens
La classe de connexion Classe1 à laquelle l’utilisateur1 est assigné dispose d’autorisations utilisateur de niveau opérateur et permet aux utilisateurs de la classe d’exécuter la request system reboot
commande.
Les indicateurs d’autorisation suivants sont spécifiés dans la classe de connexion opérateur prédéfinie :
clear— Peut utiliser
clear
des commandes pour effacer (supprimer) les informations que l’équipement apprend du réseau et stocke dans diverses bases de données réseau.network: peut accéder au réseau à l’aide du
ping
,ssh
,telnet
ettraceroute
des commandes.reset: peut redémarrer les processus logiciels à l’aide de la
restart
commande.trace— Peut afficher les paramètres du fichier de suivi et configurer les propriétés du fichier de suivi.
view: peut utiliser diverses commandes pour afficher les valeurs et statistiques actuelles à l’échelle du système, des tables de routage et des valeurs et statistiques spécifiques au protocole. Impossible d’afficher la configuration secrète.
Pour la classe de connexion Classe1, en plus des autorisations utilisateur mentionnées ci-dessus, l’utilisateur1 peut exécuter la request system reboot
commande. La première sortie affiche les autorisations d’affichage en tant qu’opérateur, et la seconde montre que la seule request system
commande que l’utilisateur1 peut exécuter en tant qu’opérateur est la request system reboot
commande.
Vérification de la configuration de classe 2
But
Vérifiez que les autorisations et les commandes autorisées pour la classe de connexion de classe 2 fonctionnent.
Action
En mode opérationnel, exécutez la ping
commande.
User2@R1> ping 10.209.1.66 ping 10.209.1.66 PING 10.209.1.66 (10.209.1.66): 56 data bytes 64 bytes from 10.209.1.66: icmp_seq=0 ttl=52 time=212.521 ms 64 bytes from 10.209.1.66: icmp_seq=1 ttl=52 time=212.844 ms 64 bytes from 10.209.1.66: icmp_seq=2 ttl=52 time=211.304 ms 64 bytes from 10.209.1.66: icmp_seq=3 ttl=52 time=210.963 ms ^C --- 10.209.1.66 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 210.963/211.908/212.844/0.792 ms
À partir de l’invite CLI, vérifiez les commandes disponibles.
User2@R1> ? Possible completions: clear Clear information in the system file Perform file operations help Provide help information load Load information from file monitor Show real-time debugging information mtrace Trace multicast path from source to receiver op Invoke an operation script ping Ping remote target quit Exit the management session request Make system-level requests restart Restart software process save Save information to file show Show system information ssh Start secure shell on another host start Start shell telnet Telnet to another host test Perform diagnostic debugging traceroute Trace route to remote host
À partir de l’invite CLI, exécutez n’importe quelle commande d’ensemble.
User2@R1> set ^ unknown command.
Sens
La classe de connexion classe2 à laquelle l’utilisateur2 est assigné dispose d’autorisations utilisateur de niveau opérateur et refuse l’accès à toutes les set
commandes.
Les indicateurs d’autorisation spécifiés pour la classe de connexion opérateur prédéfinie sont les mêmes que ceux spécifiés pour la classe 1.
Vérification de la configuration de classe 3
But
Vérifiez que les autorisations et les commandes autorisées pour la classe de connexion classe3 fonctionnent.
Action
En mode opérationnel, vérifiez les commandes disponibles.
User3@R1> ? Possible completions: configure Manipulate software configuration information
Passez en mode configuration.
User3@R1> configure Entering configuration mode [edit] User3@R1#
Sens
La classe de connexion Classe3 à laquelle l’utilisateur3 est assigné dispose d’autorisations superutilisateur (toutes), mais cette classe permet uniquement aux utilisateurs d’exécuter la configure
commande. La classe refuse l’accès à toutes les autres commandes du mode opérationnel. Étant donné que les expressions régulières spécifiées dans les allow/deny-commands
instructions ont priorité sur les autorisations utilisateur, l’utilisateur3 sur R1 n’a accès qu’au mode de configuration et se voit refuser l’accès à toutes les autres commandes du mode opérationnel.
Exemple : Configurer les autorisations utilisateur avec des privilèges d’accès pour les déclarations de configuration et les hiérarchies
Cet exemple montre comment configurer des classes de connexion personnalisées et attribuer des privilèges d’accès à des hiérarchies de configuration spécifiques. Les utilisateurs de la classe login peuvent afficher et modifier uniquement les déclarations de configuration et les hiérarchies auxquelles ils ont accès. Cela empêche les utilisateurs non autorisés de modifier les configurations des équipements qui pourraient endommager le réseau.
Conditions préalables
Cet exemple utilise les composants matériels et logiciels suivants :
-
Un seul équipement Juniper Networks
-
Un serveur TACACS+ (ou RADIUS)
Avant de commencer, établissez une connexion TCP entre l’équipement et le serveur TACACS+. Dans le cas du serveur RADIUS, établissez une connexion UDP entre l’équipement et le serveur RADIUS.
Présentation et topologie
Figure 2 illustre une topologie simple, où le routeur R1 est un équipement Juniper Networks et dispose d’une connexion TCP établie avec un serveur TACACS+.

Cet exemple configure R1 avec deux classes de connexion personnalisées : Classe 1 et Classe2. Chaque classe définit les droits d’accès pour l’utilisateur en configurant l’instruction permissions
et en définissant des expressions régulières étendues à l’aide des allow-configuration
, deny-configuration
, allow-configuration-regexps
et deny-configuration-regexps
des instructions.
L’objectif de chaque classe de connexion est le suivant :
-
Class1: définit les droits d’accès pour l’utilisateur avec les
allow-configuration
instructions etdeny-configuration
. Cette classe de connexion permet de configurer la[edit interfaces]
hiérarchie uniquement et refuse tout autre accès sur l’équipement. Pour ce faire, les autorisations utilisateur incluentconfigure
de fournir un accès à la configuration. En outre, l’instruction permet d’accéderallow-configuration
à la configuration des interfaces, et l’instructiondeny-configuration
refuse l’accès à toutes les autres hiérarchies de configuration. L’instruction allow ayant la priorité sur l’instruction de refus, les utilisateurs assignés à la classe de connexion classe1 peuvent accéder uniquement au[edit interfaces]
niveau hiérarchique. -
Class2: définit les droits d’accès pour l’utilisateur avec les
allow-configuration-regexps
instructions etdeny-configuration-regexps
. Cette classe de connexion fournit des autorisations utilisateur de niveau superutilisateur et permet explicitement la configuration sous plusieurs niveaux hiérarchiques pour les interfaces. Il refuse également l’accès aux[edit system]
niveaux et[edit protocols]
hiérarchiques.
Le routeur R1 a deux utilisateurs, User1 et User2, assignés aux classes de connexion Classe1 et Classe2, respectivement.
Configuration
- Configuration rapide cli
- Configurer les paramètres d’authentification du routeur R1
- Configurez les privilèges d’accès avec les déclarations d’autorisation de configuration et de refus de configuration (Classe1)
- Configurez les privilèges d’accès avec les déclarations allow-configuration-regexps et deny-configuration-regexps (Class2)
- Résultats
Configuration rapide cli
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à votre configuration réseau, copiez et collez les commandes dans la CLI au niveau de la [edit]
hiérarchie, puis entrez commit
en mode configuration.
R1
set system authentication-order tacplus set system authentication-order radius set system authentication-order password set system radius-server 10.209.1.66 secret "$ABC123" set system tacplus-server 10.209.1.66 secret "$ABC123" set system radius-options enhanced-accounting set system tacplus-options enhanced-accounting set system accounting events login set system accounting events change-log set system accounting events interactive-commands set system accounting traceoptions file auditlog set system accounting traceoptions flag all set system accounting destination tacplus server 10.209.1.66 secret "$ABC123" set system login class Class1 permissions configure set system login class Class1 allow-configuration "interfaces .* unit .*" set system login class Class1 deny-configuration .* set system login class Class2 permissions all set system login class Class2 allow-configuration-regexps [ "interfaces .* description .*" "interfaces .* unit .* description .*" "interfaces .* unit .* family inet address .*" "interfaces.* disable" ] set system login class Class2 deny-configuration-regexps [ "system" "protocols" ] set system login user User1 uid 2004 set system login user User1 class Class1 set system login user User1 authentication encrypted-password "$ABC123" set system login user User2 uid 2006 set system login user User2 class Class2 set system login user User2 authentication encrypted-password "$ABC123" set system syslog file messages any any
Configurer les paramètres d’authentification du routeur R1
Procédure étape par étape
Pour configurer l’authentification R1 du routeur :
-
Configurez l’ordre dans lequel le R1 tente d’authentifier l’utilisateur. Dans cet exemple, l’authentification du serveur TACACS+ est d’abord suivie de l’authentification du serveur RADIUS, puis du mot de passe local.
[edit system] user@R1# set authentication-order tacplus user@R1# set authentication-order radius user@R1# set authentication-order password
-
Configurez le serveur TACACS+.
[edit system] user@R1# set tacplus-server 10.209.1.66 secret "$ABC123" user@R1# set tacplus-options enhanced-accounting user@R1# set accounting destination tacplus server 10.209.1.66 secret "$ABC123"
-
Configurez le serveur RADIUS.
[edit system] user@R1# set radius-server 10.209.1.66 secret "$ABC123" user@R1# set radius-options enhanced-accounting
-
Configurez les paramètres de comptabilisation R1.
[edit system] user@R1# set accounting events login user@R1# set accounting events change-log user@R1# set accounting events interactive-commands user@R1# set accounting traceoptions file auditlog user@R1# set accounting traceoptions flag all
Configurez les privilèges d’accès avec les déclarations d’autorisation de configuration et de refus de configuration (Classe1)
Procédure étape par étape
Pour spécifier des expressions régulières à l’aide des allow-configuration
instructions et :deny-configuration
-
Configurez la classe de connexion classe1 avec
configure
des autorisations.[edit system login] user@R1# set class Class1 permissions configure
-
Configurez l’expression
allow-configuration
régulière pour permettre aux utilisateurs de la classe d’afficher et de modifier une partie du[edit interfaces]
niveau hiérarchique.[edit system login] user@R1# set class Class1 allow-configuration "interfaces .* unit .*"
-
Configurez l’expression
deny-configuration
régulière pour refuser l’accès à toutes les hiérarchies de configuration.[edit system login] user@R1# set class Class1 deny-configuration .*
-
Configurez le compte utilisateur pour la classe de connexion Classe1.
[edit system login] user@R1# set user User1 uid 2004 user@R1# set user User1 class Class1 user@R1# set user User1 authentication encrypted-password "$ABC123"
Configurez les privilèges d’accès avec les déclarations allow-configuration-regexps et deny-configuration-regexps (Class2)
Procédure étape par étape
Pour spécifier des expressions régulières à l’aide des allow-configuration-regexps
instructions et :deny-configuration-regexps
-
Configurez la classe de connexion de classe2 et attribuez des autorisations superutilisateur (tous).
[edit system login] user@R1# set class Class2 permissions all
-
Configurez l’expression
allow-configuration-regexps
régulière pour permettre aux utilisateurs de la classe d’accéder à plusieurs hiérarchies au niveau hiérarchique[edit interfaces]
.[edit system login] user@R1# set class Class2 allow-configuration-regexps [ "interfaces .* description .*" "interfaces .* unit .* description .*" "interfaces .* unit .* family inet address .*" "interfaces.* disable" ]
-
Configurez l’expression
deny-configuration-regexps
régulière pour empêcher les utilisateurs de la classe d’afficher ou de modifier la configuration au niveau et[edit protocols]
de la[edit system]
hiérarchie.[edit system login] user@R1# set class Class2 deny-configuration-regexps [ "system" "protocols" ]
-
Configurez le compte utilisateur pour la classe de connexion Classe2.
[edit system login] user@R1# set user User2 uid 2006 user@R1# set user User2 class Class2 user@R1# set user User2 authentication encrypted-password "$ABC123"
Résultats
En mode configuration, confirmez votre configuration en entrant la show system
commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
user@R1# show system authentication-order [ tacplus radius password ]; radius-server { 10.209.1.66 secret "$ABC123"; } tacplus-server { 10.209.1.66 secret "$ABC123"; } radius-options { enhanced-accounting; } tacplus-options { enhanced-accounting; } accounting { events [ login change-log interactive-commands ]; traceoptions { file auditlog; flag all; } destination { tacplus { server { 10.209.1.66 secret "$ABC123"; } } } } login { class Class1 { permissions configure; allow-configuration "interfaces .* unit .*"; deny-configuration .*; } class Class2 { permissions all; allow-configuration-regexps [ "interfaces .* description .*" "interfaces .* unit .* description .*" "interfaces .* unit .* family inet address .*" "interfaces.* disable" ]; deny-configuration-regexps [ "system" "protocols" ]; } user User1 { uid 2001; class Class1; authentication { encrypted-password "$ABC123"; } } user User2 { uid 2002; class Class2; authentication { encrypted-password "$ABC123"; } } } syslog { file messages { any any; } }
Vérification
Connectez-vous en tant que nom d’utilisateur assigné à la nouvelle classe de connexion et vérifiez que la configuration fonctionne correctement.
Vérifier la configuration de classe 1
But
Vérifiez que les autorisations autorisées dans la classe de connexion de classe 1 fonctionnent.
Action
En mode opérationnel, vérifiez les commandes disponibles.
User1@R1> ? Possible completions: clear Clear information in the system configure Manipulate software configuration information file Perform file operations help Provide help information load Load information from file op Invoke an operation script quit Exit the management session request Make system-level requests save Save information to file set Set CLI properties, date/time, craft interface message start Start shell test Perform diagnostic debugging
En mode configuration, vérifiez les autorisations de configuration disponibles.
User1@R1# edit ? Possible completions: > interfaces Interface configuration
Sens
L’utilisateur1 dispose configure
d’autorisations utilisateur, comme indiqué dans la première sortie. En outre, en mode configuration, l’utilisateur1 a accès au niveau hiérarchique interfaces
, mais uniquement à ce niveau hiérarchique, comme le montre la deuxième sortie.
Vérifier la configuration de classe 2
But
Vérifiez que la configuration de Classe2 fonctionne comme prévu.
Action
En mode configuration, accédez à la interfaces
configuration.
[edit interfaces] User2@R1# set ? Possible completions: <interface-name> Interface name + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups ge-0/0/3 Interface name > interface-range Interface ranges configuration > interface-set Logical interface set configuration > traceoptions Interface trace options
En mode configuration, accédez aux system
hiérarchies et protocols
de configuration.
User2@R1# edit system ^ Syntax error, expecting <statement> or <identifier>. User2@R1# edit protocols ^ Syntax error, expecting <statement> or <identifier>.
Sens
L’utilisateur2 a l’autorisation de configurer des interfaces sur R1, mais il n’a pas l’autorisation d’afficher ou de modifier les [edit system]
niveaux hiérarchiques [edit protocols]
.
deny-commands-regexps
sont prises en charge pour l’autorisation allow-commands-regexps
TACACS+.