Privilèges d’accès utilisateur
Vous (l’administrateur système) accordez aux utilisateurs l’accès ou les autorisations aux commandes, aux niveaux de la hiérarchie de configuration et aux instructions. Les utilisateurs ne peuvent exécuter que ces 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 de mode opérationnel, les instructions de configuration et les hiérarchies qui sont autorisées ou refusées aux utilisateurs. Cette pratique empêche les utilisateurs non autorisés d’exécuter des commandes sensibles ou de configurer des instructions susceptibles d’endommager le réseau.
Vue d’ensemble des niveaux de privilèges d’accès
Chaque commande CLI de niveau supérieur et chaque instruction de configuration est associée à un niveau de privilège d’accès. Les utilisateurs ne peuvent exécuter que ces 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 et de hiérarchies d’instructions en mode opérationnel et en mode de configuration qui seraient autrement autorisées ou refusées par un niveau de privilège spécifié dans l’instruction permissions
.
- Indicateurs d’autorisation de la classe de connexion
- Autoriser et refuser les commandes individuelles et les hiérarchies d’instructions pour les classes de connexion
Indicateurs d’autorisation de la classe de connexion
Vous utilisez des indicateurs d’autorisation pour accorder à un utilisateur l’accès aux commandes du mode opérationnel, ainsi qu’aux niveaux et instructions de la hiérarchie de configuration. Vous configurez des 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 a accès aux commandes, aux niveaux de la hiérarchie de configuration et aux instructions qui correspondent à cet indicateur. Pour accorder l’accès à toutes les commandes et instructions de configuration, utilisez l’indicateur d’autorisations all
.
Chaque commande répertoriée représente cette commande et toutes les sous-commandes avec cette commande comme préfixe. Chaque instruction 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 cumulatifs. Pour chaque classe, vous devez lister tous les indicateurs d’autorisation nécessaires, y compris view
pour afficher des informations et configure
entrer en mode de configuration. Deux formes d’autorisations contrôlent l’accès d’un utilisateur aux différentes parties de la configuration :
-
Formulaire « Plain » : fournit une fonctionnalité en lecture seule pour ce type d’autorisation. Un exemple est
interface
. -
-control
form : fournit des fonctionnalités de lecture et d’écriture pour ce type d’autorisation. Un exemple estinterface-control
.
Pour les indicateurs d’autorisation qui accordent l’accès aux niveaux hiérarchiques de configuration et aux instructions, les indicateurs de forme simple accordent un privilège en lecture seule à cette configuration. Par exemple, l’indicateur d’autorisation interface
accorde un accès en lecture seule au niveau hiérarchique [edit interfaces]
. La -control
forme de l’indicateur accorde 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 de classe 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 instructions de la hiérarchie de configuration auxquels cet indicateur accorde l’accès.
Indicateur d’autorisation |
Description |
---|---|
Peut visualiser la configuration d’accès en mode opérationnel ou en mode configuration. |
|
Peut afficher et configurer les informations d’accès au niveau de la |
|
Peut afficher les informations du compte utilisateur en mode opérationnel ou en mode configuration. |
|
Peut afficher les informations du compte utilisateur et les configurer au niveau de la |
|
Peut accéder à toutes les commandes du mode opérationnel et à toutes les commandes du mode de configuration. Peut modifier la configuration dans 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 de configuration (à l’aide de la commande) et valider les configurations (à l’aide de la |
|
Peut effectuer toutes les opérations au niveau du contrôle, c’est-à-dire toutes les opérations configurées avec les indicateurs d’autorisation |
|
Peut afficher les commandes de débogage de champ. Réservé à la prise en charge du débogage. |
|
Peut visualiser la configuration du filtre de pare-feu en mode opérationnel ou en mode configuration. |
|
Peut afficher et configurer les informations de filtre de pare-feu au niveau de la |
|
Peut lire et écrire sur le support amovible. |
|
Peut visualiser la configuration flow-tap en mode opérationnel ou en mode configuration. |
|
Peut afficher et configurer les informations de flux au niveau de la |
|
Peut envoyer des requêtes de débit au routeur ou au commutateur. Par exemple, un client DTCP (Dynamic Tasking Control Protocol) doit être REMARQUE :
L’option |
|
Permet d’afficher les données du profileur. |
|
Peut visualiser la configuration de l’interface en mode opérationnel et en mode 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, y compris démarrer un shell local sur l’appareil et devenir le superutilisateur dans l’interpréteur de commandes (à l’aide de la |
|
Peut accéder au réseau à l’aide des |
|
Peut afficher la configuration de la mise en miroir de session |
|
Peut modifier la configuration de la mise en miroir de session |
|
Peut redémarrer les processus logiciels à l’aide de la |
|
Peut utiliser la |
|
Peut afficher les informations générales de configuration du routage, du protocole de routage et de la stratégie 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 afficher les informations de configuration de sécurité en mode opérationnel et en mode configuration. |
|
Permet d’afficher et de configurer les informations de sécurité au niveau hiérarchique |
|
Peut démarrer un shell local sur le routeur ou le commutateur à l’aide de la |
|
Peut afficher les informations de configuration SNMP (Simple Network Management Protocol) en mode opérationnel ou en mode configuration. |
|
Permet d’afficher et de modifier les informations de configuration SNMP au niveau de la |
|
|
Permet d’afficher les informations de configuration du stockage Fibre Channel au niveau de la |
|
Peut modifier les informations de configuration du stockage Fibre Channel au niveau de la |
Peut afficher les informations au niveau du système en mode opérationnel ou en mode configuration. |
|
Peut afficher et modifier les informations de configuration au niveau du système au niveau de la |
|
Peut afficher les paramètres du fichier de trace et configurer les propriétés du fichier de trace. |
|
Peut modifier les paramètres du fichier de trace et configurer les propriétés du fichier de trace. |
|
|
Permet d’afficher la configuration du dispositif Edge unifié au niveau de la |
|
Peut modifier la configuration liée au dispositif Edge unifié au niveau de la |
Peut utiliser diverses commandes pour afficher les valeurs et statistiques actuelles à l’échelle du système, de la table de routage et du 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 afficher la configuration du script de validation, du script op ou du script d’événement |
Autoriser et refuser les commandes individuelles et les hiérarchies d’instructions pour les classes de connexion
Par défaut, toutes les commandes CLI de niveau supérieur et tous les niveaux de hiérarchie de configuration sont associés à des niveaux de privilèges d’accès. Les utilisateurs ne peuvent exécuter que ces 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 explicitement autoriser ou refuser l’utilisation des commandes et des hiérarchies d’instructions en mode opérationnel et en mode de configuration qui seraient autrement autorisées ou refusées par un niveau de privilège spécifié dans l’instruction permissions
.
Les indicateurs d’autorisation permettent à un utilisateur d’accéder aux commandes du mode opérationnel et du mode de configuration, ainsi qu’aux niveaux et instructions 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 de la hiérarchie, vous accordez à l’utilisateur l’accès aux commandes et aux niveaux et instructions de [edit system login class]
la hiérarchie de configuration correspondants. Pour accorder l’accès à toutes les commandes et instructions de configuration, utilisez l’indicateur d’autorisations all
.
Vous pouvez explicitement autoriser ou refuser l’utilisation de commandes et d’instructions en configurant les allow-commands
instructions , , deny-commands
allow-configuration
et deny-configuration
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 affecté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 ces 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’appareil n’est requise avant de configurer cet exemple.
Présentation
Chaque commande CLI de niveau supérieur et chaque instruction de configuration est associée à un niveau de privilège d’accès. Lorsque vous configurez une classe de connexion, vous pouvez explicitement autoriser ou refuser l’utilisation des commandes et des instructions de configuration en mode de fonctionnement et en mode de configuration. Les utilisateurs ne peuvent exécuter que ces commandes et afficher et configurer uniquement les instructions pour lesquelles ils disposent de privilèges d’accès.
Vous définissez les privilèges 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 permettent à un utilisateur d’accéder aux commandes, aux instructions et aux hiérarchies. Les indicateurs d’autorisation ne sont pas cumulatifs. Pour chaque classe de connexion, vous devez lister tous les indicateurs d’autorisation nécessaires, y compris view
pour afficher des informations et configure
entrer en mode de configuration. En spécifiant un indicateur d’autorisation spécifique sur la classe de connexion de l’utilisateur, vous accordez à l’utilisateur l’accès aux commandes, instructions et hiérarchies correspondantes. Pour accorder l’accès à toutes les commandes et instructions de configuration, utilisez l’indicateur d’autorisations all
. Les indicateurs d’autorisation fournissent une capacité de lecture seule (formulaire « plain ») et de lecture et d’écriture (formulaire qui se termine par -control) pour un type d’autorisation.
Les all
bits d’autorisation de la classe de connexion sont prioritaires 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ège 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 par des espaces et 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 de ligne de commande et tapez un point d’interrogation ( ?) après l’instruction permissions
:
[edit system login] user@host# set class class-name permissions ?
Configuration
Cet exemple configure la snmp-admin
classe login. 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 à l’aide des indicateurs ,snmp
, etsnmp-control
d’autorisationconfigure
.[edit system login] user@host# set class snmp-admin permissions [configure snmp snmp-control]
Les indicateurs d’autorisation configurés fournissent à la fois une capacité 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 affecté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’appareil, passez commit
en 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 est en mesure de configurer les paramètres SNMP. L’utilisateur peut configurer ces paramètres, car les indicateurs d’autorisation spécifiés pour cette classe incluent à la fois les bits d’autorisation snmp (capacités de lecture) et snmp-control (capacités de lecture et d’écriture).
Vérifier la 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 une 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 classe de connexion n’est pas en mesure de configurer la snmp-admin
[edit interfaces]
hiérarchie, car 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 permettant d’autoriser et de refuser les commandes, les instructions de configuration et les hiérarchies en mode opérationnel
Cette rubrique contient les sections suivantes :
- Comprendre les instructions d’autorisation et de refus
- Présentation de la syntaxe des instructions Allow and Deny
- Présentation de la priorité et de la correspondance des instructions d’autorisation et de refus
- Comprendre les règles d’autorisation et de refus
- Comprendre les différences pour les instructions *-regexps
- Utilisation d’expressions régulières sur des serveurs d’autorisation distants
- Spécifier des expressions régulières
- Opérateurs d’expressions régulières
- Exemples d’expressions régulières
Comprendre les instructions d’autorisation et de refus
Chaque hiérarchie de commandes CLI et d’instructions de configuration de niveau supérieur est associée à un niveau de privilège d’accès. Chaque classe de connexion peut explicitement autoriser ou refuser l’utilisation des commandes de mode opérationnel et de mode de configuration, ainsi que des hiérarchies et des instructions de configuration qui seraient autrement autorisées ou refusées par un niveau de privilège. Les utilisateurs ne peuvent exécuter que ces 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 spécifiques et de hiérarchies de configuration 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
et —Autorisez ou refusez l’accès aux commandes du mode opérationnel etdeny-commands
du mode de configuration. -
allow-configuration
etdeny-configuration
: autorisez ou refusez l’accès à des hiérarchies de configuration spécifiques.REMARQUE :Ces instructions effectuent une correspondance plus lente, avec plus de flexibilité, en particulier dans la correspondance générique. Cependant, l’évaluation de toutes les instructions possibles peut prendre beaucoup de temps si un grand nombre d’expressions régulières ou d’expressions génériques à chemin complet sont configurées, 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 les instructions or, l’utilisation des mêmes options de configuration avec les instructions or allow/deny-configuration
allow/deny-configuration-regexps
peut ne pas produire les allow/deny-commands
allow/deny-commands-regexps
mêmes résultats. Les méthodes de recherche et d’appariement diffèrent par les deux formes de ces énoncés.
L’autorisation explicite des commandes et des hiérarchies d’instructions de configuration à l’aide des instructions ajoute aux autorisations que l’instruction allow/deny-*
permissions
définit déjà. De même, le refus explicite des commandes et des hiérarchies d’instructions de configuration à l’aide des instructions supprime les autorisations que l’instruction allow/deny-*
permissions
définit déjà.
Par exemple, dans la configuration suivante, l’autorisation permet aux utilisateurs de la classe de connexion d’entrer configure
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 [edit system services]
la 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 autorisées par l’indicateur d’autorisations, sauf que l’utilisateur all
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"
Présentation de la syntaxe des instructions Allow and Deny
Vous ne pouvez configurer une instruction qu’une allow/deny-*
seule fois dans chaque classe de connexion. Lorsque vous configurez une instruction :
-
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
énoncés s’excluent mutuellement avec les énoncés, et les énoncés s’excluent mutuellement avec les allow/deny-commands-regexps
allow/deny-configuration
allow/deny-configuration-regexps
énoncés. 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 privilèges d’accès aux commandes, spécifiez des expressions régulières étendues à l’aide des allow-commands
instructions and deny-commands
. Placez chaque expression autonome complète entre parenthèses ( ) et utilisez la barre verticale ( | ) pour séparer les expressions. N’utilisez pas d’espaces entre les expressions régulières qui sont liées au symbole de la barre verticale. L’expression complète est placée entre 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 lorsque vous spécifiez 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 privilèges d’accès à des parties de la hiérarchie de configuration, spécifiez des expressions régulières étendues dans les allow-configuration
instructions and deny-configuration
. Placez les chemins d’accès complets entre parenthèses ( ) et utilisez la barre verticale ( | ) pour séparer les expressions. N’utilisez pas d’espaces entre les expressions régulières qui sont liées au symbole de la barre verticale. L’expression complète est placée entre 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 des allow/deny-commands-regexps
instructions ou allow/deny-configuration-regexps
, placez chaque expression entre guillemets ( » « ) et séparez-les par un espace. Placez les expressions multiples 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 à mettre en correspondance. Si vous utilisez un modificateur, rien n’est égalé.
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"
Présentation de la priorité et de la correspondance des instructions d’autorisation et de refus
Par défaut, les expressions régulières et allow-configuration
sont prioritaires sur deny-commands
les allow-commands
deny-configuration
expresssions. Par conséquent, si vous configurez la même commande pour les allow-commands
instructions and deny-commands
, l’opération allow est prioritaire sur l’opération de refus. De même, si vous configurez la même instruction pour les allow-configuration
instructions and deny-configuration
, l’opération allow est prioritaire sur l’opération de refus.
Par exemple, la configuration suivante permet à un utilisateur de la classe login d’installer un logiciel à l’aide de la commande, même si l’instruction deny-commands
inclut la test
request system software add
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 dans le test
test de la classe de connexion d’afficher et de modifier la hiérarchie de configuration, même si l’instruction deny-configuration
inclut la [edit system services]
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 and 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 classe login d’exécuter la commande, mais pas la test
commit synchronize
commit
commande. C’est parce que commit synchronize
est la correspondance la plus longue entre commit
et , et commit synchronize
qu’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 classe login d’exécuter la commande, mais pas la test
commit
commit synchronize
commande. C’est parce que commit synchronize
est la correspondance la plus longue entre commit
et , et commit synchronize
qu’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 instructions, le comportement par défaut des *-regexps
instructions est que les expressions régulières et deny-configuration-regexps
sont prioritaires sur allow-commands-regexps
les deny-commands-regexps
expressions andallow-configuration-regexps
. 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 à être prioritaires sur les deny-configuration-regexps
instructions. La configuration de l’instruction vous permet de refuser les hiérarchies de configuration à un niveau supérieur, puis d’autoriser uniquement l’utilisateur à accéder à des sous-hiérarchies spécifiques.
Comprendre les règles d’autorisation et de refus
Les allow/deny-commands
instructions , , allow/deny-configuration
allow/deny-commands-regexps
et allow/deny-configuration-regexps
sont prioritaires sur les autorisations de la classe de connexion. Lorsque vous configurez ces instructions, les règles suivantes s’appliquent :
-
Les expressions régulières for
allow-commands
et peuvent également inclure lescommit
commandes , ,rollback
, ,status
load
save
et .deny-commands
update
-
Les
all
bits d’autorisation de la classe de connexion sont prioritaires sur les expressions régulières étendues lorsqu’un utilisateur exécute larollback
commande avec l’indicateur d’autorisationrollback
activé. -
Les utilisateurs ne peuvent pas exécuter la commande lors de la
load override
spécification d’une expression régulière étendue. Les utilisateurs ne peuvent émettre que lesmerge
commandes ,replace
etpatch
configuration. -
Vous pouvez utiliser le caractère générique * pour désigner 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. De plus, vous ne pouvez pas configurer l’instructionallow-configuration
avec une expression telle que(interfaces (description (|.*))
, car cela équivaut àallow-configuration .*
.
Comprendre les différences pour les instructions *-regexps
Cette section décrit les différences entre les déclarations et les allow/deny-configuration
allow/deny-configuration-regexps
déclarations.
Les allow/deny-configuration-regexps
instructions 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
instructions correspondent à la chaîne complète. Pour allow/deny-configuration-regexps
les instructions, vous configurez un ensemble de chaînes dans lequel chaque chaîne est une expression régulière, avec des espaces entre les termes de la chaîne. Cette syntaxe permet 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 des espaces que vous souhaitez faire correspondre, ce qui rend plus difficile l’utilisation d’expressions génériques pour ces instructions.
Par exemple :
-
Expression régulière correspondant à un jeton à l’aide de allow-configuration-regexps
Cet exemple montre que c’est
options
la seule expression correspondante par rapport au premier jeton de l’instruction.[edit system] login { class test { permissions configure; allow-configuration-regexps .*options; } }
La configuration précédente correspond aux instructions suivantes :
-
set policy-options condition condition dynamic-db
-
set routing-options static route static-route next-hop next-hop
-
set event-options generate-event event time-interval seconds
La configuration précédente ne correspond pas aux instructions suivantes :
-
nom d’hôte système options d’hôte
-
Options de description des interfaces interface-name
-
-
Expression régulière correspondant à trois jetons à l’aide de allow-configuration-regexps
Cet exemple montre que
ssh
est la seule expression correspondante par rapport 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 sont
.*
respectivement , et.*ssh
, respectivement.*
.La configuration précédente correspond aux instructions suivantes :
-
nom d’hôte système_nom_hôte-ssh
-
Services système SSH
-
services système outbound-ssh
La configuration précédente ne correspond pas à l’instruction suivante :
-
Description des interfaces interface-nameSSH
-
Il est plus facile d’utiliser l’instruction pour restreindre l’accès à la configuration que d’utiliser l’instruction. illustre l’utilisation deny-configuration
deny-configuration-regexps
des instructions et deny-configuration-regexps
dans différentes configurations pour obtenir le même résultat en restreignant l’accès deny-configuration
à une configuration particulière. Tableau 2
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 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
allow/deny-configuration
instructions.
Utilisation d’expressions régulières sur des serveurs d’autorisation distants
Vous pouvez utiliser des expressions régulières étendues pour spécifier les commandes en mode de fonctionnement et en 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 les allow/deny-commands
instructions , , allow/deny-configuration
allow/deny-commands-regexps
et allow/deny-configuration-regexps
au niveau de la [edit system login class class-name]
hiérarchie. Vous pouvez spécifier ces expressions régulières à distance en spécifiant les attributs TACACS+ ou RADIUS spécifiques au fournisseur de Juniper Networks dans la configuration de votre serveur d’autorisation. Lorsque vous configurez des paramètres d’autorisation à la fois localement et à distance, l’appareil 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 Junos OS version 18.1, 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 des allow-commands
instructions , , deny-commands
allow-configuration
ou , configurez deny-configuration
les expressions régulières entre parenthèses et les séparez à l’aide du symbole de la barre verticale. Vous placez 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 des allow-commands-regexps
instructions , , deny-commands-regexps
allow-configuration-regexps
ou , configurez deny-configuration-regexps
les expressions régulières entre guillemets doubles et les séparez à l’aide de l’opérateur espace. Vous placez 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 qui permet de spécifier chaque expression individuelle sur une ligne distincte. Par exemple, la syntaxe simplifiée du serveur RADIUS est la suivante :
Juniper-Allow-Commands += "cmd1", Juniper-Allow-Commands += "cmd2", Juniper-Allow-Commands += "cmdn",
De même, la syntaxe simplifiée du serveur TACACS+ est la suivante :
allow-commands-regexps1 = "cmd1" allow-commands-regexps2 = "cmd2" allow-commands-regexpsn = "cmdn"
Tableau 3 différencie la configuration d’autorisation locale de la configuration d’autorisation du 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, localement ou à distance, en émettant les trois commandes suivantes :
xml-mode
,netconf
, etneed-trailer
. -
Lorsque vous utilisez l’instruction, vous devez autoriser toutes les configurations souhaitées à l’aide de l’instruction
deny-configuration = ".*"
allow-configuration
. Toutefois, cette configuration peut affecter la limite de mémoire tampon d’expressions régulières autorisée pour l’instructionallow-configuration
. Si cette limite est dépassée, la configuration autorisée peut ne pas fonctionner.
Spécifier des expressions régulières
Lorsque vous spécifiez des expressions régulières pour des commandes et des instructions de configuration, portez une attention particulière aux exemples suivants. Une expression régulière dont la syntaxe n’est pas valide peut ne pas produire les résultats escomptés, même si la configuration est validée sans 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 permettant de configurer les privilèges d’accès pour les hiérarchies d’instructions [edit interfaces]
et [edit vlans]
.
Déclaration |
Expression régulière |
Configuration Notes |
---|---|---|
[edit interfaces] La [edit] user@host# set interfaces interface-name unit interface-unit-number |
L’instruction Par conséquent, l’expression régulière requise pour refuser la configuration doit spécifier l’intégralité de la chaîne exécutable avec l’opérateur à la [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 est incomplète en elle-même et nécessite l’option d’exécution de l’instruction Par conséquent, l’expression régulière requise pour autoriser la configuration doit spécifier la chaîne exécutable entière avec l’opérateur à la [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’expressions régulières 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 rationnelles étendues (modernes), telles que définies dans POSIX 1003.2.
Opérateur |
Correspondance |
Exemple |
---|---|---|
| |
L’un des deux ou plusieurs termes séparés par la barre verticale. Chaque terme doit être une expression autonome complète entre parenthèses ( ), sans espace entre la barre verticale 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 affectés à la classe de connexion de test ont un accès au mode opérationnel limité aux seules commandes spécifiées dans l’instruction |
^ |
Au début d’une expression, utilisé pour indiquer le début de 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 affectés à la classe de connexion de test ont accès à l’affichage et à la configuration de la configuration de l’interface. L’instruction Pour le premier filtre, les commandes spécifiées incluent les |
$ |
Caractère à la fin d’une commande. Utilisé pour désigner une commande qui doit être mise en correspondance 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 affectés à la classe de connexion test peuvent visualiser la configuration des interfaces en mode configuration. Les utilisateurs peuvent également visualiser la configuration de l’interface à l’aide de la |
[ ] |
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 affectés à la classe de connexion de test disposent d’autorisations utilisateur au niveau de l’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). |
( ) |
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 en conjonction 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 affectés à la classe de connexion de test disposent d’autorisations de niveau superutilisateur et ont accès aux commandes spécifiées dans l’instruction |
* |
Zéro 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 affectés à la classe de connexion de test dont le nom d’utilisateur de connexion commence par |
+ |
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 affectés à la classe de connexion de test dont le nom d’utilisateur de connexion commence par |
. |
N’importe quel 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 affectés à la classe de connexion de test dont le nom d’utilisateur de connexion commence par |
.* |
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 affectés à la classe de connexion de test dont le nom d’utilisateur de connexion commence par De même, l’instruction REMARQUE :
|
L’opérateur !
d’expression régulière n’est pas pris en charge.
Exemples d’expressions régulières
Tableau 6répertorie les expressions régulières utilisées pour autoriser les options de configuration sous deux hiérarchies de configuration — et [edit protocols rip]
—[edit system ntp server]
, à titre d’exemple pour spécifier des expressions régulières.
Tableau 6 Ne fournit pas une liste exhaustive de toutes les expressions régulières et de tous les mots-clés pour toutes les instructions de configuration et toutes les hiérarchies. Les expressions régulières répertoriées dans le tableau ne sont validées que pour les hiérarchies d’instructions [edit system ntp server]
et [edit protocols rip]
.
Hiérarchie des instructions |
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 .*" ] |
|
|
Entrée métrique 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 .*" ] |
|
|
délai d’expiration de route 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 à l’aide des instructions allow-configuration et deny-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
des déclarations
Les indicateurs d’autorisation définissent les limites plus larges de ce à quoi une personne ou une classe de connexion peut accéder et contrôler. Les allow-configuration
instructions et contiennent une ou plusieurs expressions régulières qui autorisent ou refusent des hiérarchies et deny-configuration
des instructions de configuration spécifiques. Les allow-configuration
instructions et sont prioritaires sur les indicateurs d’autorisation et donnent à l’administrateur un contrôle plus fin sur les hiérarchies et les instructions que l’utilisateur peut afficher et deny-configuration
configurer.
Cette rubrique explique comment définir les privilèges d’accès à l’aide allow-configuration
des instructions et deny-configuration
en montrant des exemples de configurations de classe de connexion qui utilisent ces instructions. Les exemples 1 à 3 créent des classes de connexion qui permettent aux utilisateurs d’accéder à toutes les commandes et instructions, à 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 de manière interchangeable.
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 de toute classe de connexion dont le nom commence par « m » :
-
Définissez les autorisations de la 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 à l’exception des [edit system login class]
niveaux hiérarchiques ou [edit system services]
:
-
Définissez les autorisations de la 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 l’énoncé suivant
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 instructions et deny-configuration
pour déterminer les autorisations inverses les allow-configuration
unes des autres pour le niveau hiérarchique[edit system services]
.
Exemple 4
Pour créer une classe de connexion qui permet à l’utilisateur de disposer de privilèges de configuration complets uniquement au niveau de la [edit system services]
hiérarchie :
-
Définissez les autorisations de la classe de connexion de l’utilisateur sur
configure
.[edit system login] user@host# set class configure-only-system-services permissions configure
-
Incluez l’énoncé suivant
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 accorde à l’utilisateur des autorisations complètes pour toutes les commandes et toutes les hiérarchies de configuration, à l’exception [edit system services]
du niveau hiérarchique :
-
Définissez les autorisations de la 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 la logique additive lors de l’utilisation d’expressions régulières pour configurer des privilèges d’accès à la configuration.
Conditions préalables
Cet exemple utilise un périphérique 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’ils 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
d’une classe de connexion.
Par défaut, l’instruction est prioritaire sur l’instruction deny-configuration-regexps
allow-configuration-regexps
. Si une hiérarchie de configuration apparaît dans une instruction pour une deny-configuration-regexps
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 instruction, elle est visible par les utilisateurs de cette classe si elle apparaît dans une deny-configuration-regexps
allow-configuration-regexps
instruction.
Vous pouvez modifier ce comportement par défaut en activant la logique additive pour les *-configuration-regexps
instructions. Lorsque vous activez la logique additive, l’instruction est prioritaire sur l’instruction allow-configuration-regexps
deny-configuration-regexps
.
Ainsi, si l’instruction refuse l’accès à toutes les hiérarchies de configuration à un niveau donné (protocoles .*) mais que l’instruction autorise l’accès à une sous-hiérarchie (protocoles bgp .*), alors par défaut l’appareil refuse l’accès aux hiérarchies aux utilisateurs de cette classe de connexion car l’instruction deny-configuration-regexps
allow-configuration-regexps
deny-configuration-regexps
est prioritaire. Toutefois, si vous activez la logique additive, l’appareil autorise l’accès à la sous-hiérarchie spécifiée pour les utilisateurs de cette classe de connexion, car le allow-configuration-regexps
est prioritaire dans ce cas.
Configuration
Procédure étape par étape
Pour activer la logique additive afin d’autoriser explicitement les utilisateurs d’une classe de connexion donnée à accéder à une ou plusieurs hiérarchies de configuration individuelles :
-
Incluez l’instruction et refusez explicitement l’accès
deny-configuration-regexps
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 à autoriser.[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 expressions régulières et
deny-configuration-regexps
lesallow-configuration-regexps
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 affectés à cette classe de connexion ont accès aux hiérarchies de configuration incluses dans l’instruction, mais n’ont pas accès aux autres hiérarchies spécifiées dans l’instruction
allow-configuration-regexps
deny-configuration-regexps
.
Lorsque vous configurez l’instructionregex-additive-logic
, le changement de comportement s’applique à toutes les instructions et deny-configuration-regexps
présentes dans toutes les allow-configuration-regexps
classes de connexion. Si vous activez la logique additive, vous devez évaluer l’impact des instructions existantes et mettre à jour les expressions régulières de ces instructions 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 appropriées à votre système.
Autoriser des instances de routage spécifiques
L’exemple de classe login suivant inclut une expression régulière qui permet de configurer des instances de routage dont le nom commence par ; par CUST-VRF-
exemple, , , , CUST-VRF-1
CUST-VRF-25
CUST-VRF-100
etc. L’exemple inclut également une expression régulière qui empêche la configuration de toute instance 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
est prioritaire et la configuration précédente empêche les utilisateurs de la classe de connexion de configurer des instances de routage, quel que soit leur nom.
Toutefois, si vous configurez l’instruction suivante, elle allow-configuration-regexps
est prioritaire. Ainsi, les utilisateurs peuvent configurer des instances de routage dont le nom commence par CUST-VRF-
, mais ils ne peuvent pas configurer d’autres instances de routage.
[edit system] user@host# set regex-additive-logic
Autoriser la configuration BGP Peer uniquement
L’exemple de classe de connexion suivant inclut des expressions régulières qui empêchent la configuration au niveau de la hiérarchie, mais autorisent la [edit protocols]
configuration des homologues 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 homologues BGP, mais ils ne peuvent pas configurer d’autres protocoles ou d’autres instructions 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 privilèges d’accès :
-
Configurez une classe de connexion et validez les modifications.
-
Affectez la classe de connexion à un usernamefichier .
-
Connectez-vous en tant qu’assigné username avec la nouvelle classe de connexion.
-
Essayez de configurer les niveaux hiérarchiques autorisés.
-
Vous devriez être en mesure de configurer les instructions dans les niveaux hiérarchiques qui ont été autorisés.
-
Les niveaux hiérarchiques refusés ne doivent pas être visibles.
-
Toutes les expressions autorisées ou refusées doivent avoir la priorité sur toutes les autorisations accordées avec l’instruction
permissions
.
-
Exemple : Configurer les autorisations utilisateur avec des privilèges d’accès pour les commandes en mode opérationnel
Cet exemple montre comment configurer des classes de connexion personnalisées et attribuer des privilèges d’accès aux commandes en 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 équipement Juniper Networks
-
Un serveur TACACS+ (ou RADIUS)
Avant de commencer, établissez une connexion TCP entre l’appareil et le serveur TACACS+. Dans le cas du serveur RADIUS, établissez une connexion UDP entre le périphérique et le serveur RADIUS.
Vue d’ensemble 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 : Classe 1, Classe 2 et Classe 3. Chaque classe définit des privilèges d’accès pour l’utilisateur en configurant l’instruction et en définissant des expressions régulières étendues à l’aide permissions
des allow-commands
instructions and deny-commands
.
L’objectif de chaque classe de connexion est le suivant :
-
Class1: définit les privilèges d’accès de l’utilisateur à l’aide de l’instruction
allow-commands
uniquement. Cette classe de connexion fournit des autorisations utilisateur au niveau de l’opérateur et l’autorisation de redémarrer l’appareil. -
Class2: définit les privilèges d’accès de l’utilisateur à l’aide de l’instruction
deny-commands
uniquement. Cette classe de connexion fournit des autorisations utilisateur au niveau de l’opérateur et refuse l’accès auxset
commandes. -
Class3: définit les privilèges d’accès de l’utilisateur à l’aide des
allow-commands
instructions etdeny-commands
. Cette classe de connexion fournit des autorisations et des autorisations utilisateur au niveau du superutilisateur pour accéder aux interfaces et afficher les informations sur les périphériques. Il refuse également l’accèsedit
aux commandes etconfigure
.
Le routeur R1 a trois utilisateurs différents, User1, User2 et User3 affectés aux classes de connexion Class1, Class2 et Class3, respectivement.
Configuration
- Configuration rapide de l’interface de ligne de commande
- Configurer les paramètres d’authentification pour le routeur R1
- Configurer les privilèges d’accès à l’aide de l’instruction allow-commands (Class1)
- Configurer les privilèges d’accès à l’aide de l’instruction deny-commands (classe 2)
- Configurer les privilèges d’accès à l’aide des instructions allow-commands et deny-commands (classe 3)
- Résultats
Configuration rapide de l’interface de ligne de commande
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la hiérarchie, puis passez commit
en mode de [edit]
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 pour le routeur R1
Procédure étape par étape
Pour configurer l’authentification du routeur R1 :
-
Configurez l’ordre dans lequel R1 tente d’authentifier l’utilisateur. Dans cet exemple, l’authentification du serveur TACACS+ est la première, 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 comptables 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
Configurer les privilèges d’accès à l’aide de l’instruction allow-commands (Class1)
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 Class1 et attribuez des autorisations utilisateur au niveau de l’opérateur.
[edit system login] user@R1# set class Class1 permissions [clear network reset trace view]
-
Configurez l’expression régulière pour permettre aux utilisateurs de la classe de redémarrer l’appareil
allow-commands
.[edit system login] user@R1# set class Class1 allow-commands "request system reboot"
-
Configurez le compte d’utilisateur pour la classe de connexion Class1.
[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"
Configurer les privilèges d’accès à l’aide de l’instruction deny-commands (classe 2)
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 Class2 et attribuez des autorisations utilisateur au niveau de l’opérateur.
[edit system login] user@R1# set class Class1 permissions [clear network reset trace view]
-
Configurez l’expression régulière pour empêcher les utilisateurs de la classe d’exécuter
deny-commands
set
des commandes.[edit system login] user@R1# set class Class1 deny-commands "set"
-
Configurez le compte d’utilisateur pour la classe de connexion Class2.
[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"
Configurer les privilèges d’accès à l’aide des instructions allow-commands et deny-commands (classe 3)
Procédure étape par étape
Pour spécifier des expressions régulières à l’aide des allow-commands
instructions et deny-commands
:
-
Configurez la classe de connexion Class3 et attribuez des autorisations au niveau du superutilisateur.
[edit system login] user@R1# set class Class3 permissions all
-
Configurez l’expression régulière pour empêcher les utilisateurs de la classe d’exécuter
deny-commands
des commandes.[edit system login] user@R1# set class Class3 deny-commands ".*"
-
Configurez l’expression régulière pour permettre aux utilisateurs d’entrer
allow-commands
en mode de configuration.[edit system login] user@R1# set class Class3 allow-commands configure
-
Configurez le compte d’utilisateur pour la classe de connexion Class3.
[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 attribué à 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 Class1 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 Class1 à laquelle User1 est affecté dispose d’autorisations utilisateur au niveau de l’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: permet d’utiliser
clear
des commandes pour effacer (supprimer) les informations que l’appareil apprend du réseau et stocke dans diverses bases de données réseau.network: permet d’accéder au réseau à l’aide des
ping
commandes ,ssh
,telnet
ettraceroute
.reset: permet de redémarrer les processus logiciels à l’aide de la
restart
commande.trace: permet d’afficher les paramètres du fichier de trace et de configurer les propriétés du fichier de trace.
view—Peut utiliser diverses commandes pour afficher les valeurs et statistiques actuelles à l’échelle du système, de la table de routage et du protocole. Impossible d’afficher la configuration secrète.
Pour la classe de connexion Class1, en plus des autorisations utilisateur mentionnées ci-dessus, User1 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 sortie montre que la seule request system
commande que User1 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 Class2 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 de la 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 de la CLI, exécutez n’importe quelle commande définie.
User2@R1> set ^ unknown command.
Sens
La classe de connexion Class2 à laquelle User2 est affecté dispose d’autorisations utilisateur au niveau de l’opérateur et refuse l’accès à toutes les set
commandes.
Les indicateurs d’autorisation spécifiés pour la classe de connexion de l’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 Class3 fonctionnent.
Action
En mode opérationnel, vérifiez les commandes disponibles.
User3@R1> ? Possible completions: configure Manipulate software configuration information
Entrez en mode de configuration.
User3@R1> configure Entering configuration mode [edit] User3@R1#
Sens
La classe de connexion Class3 à laquelle User3 est affecté dispose d’autorisations de superutilisateur (all), 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 instructions sont prioritaires sur les autorisations de l’utilisateur, User3 sur R1 n’a accès qu’au mode de configuration et se voit refuser l’accès à toutes les allow/deny-commands
autres commandes du mode opérationnel.
Exemple : Configurer les autorisations utilisateur avec des privilèges d’accès pour les instructions 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 de connexion peuvent afficher et modifier uniquement les instructions de configuration et les hiérarchies auxquelles ils ont accès. Cela empêche les utilisateurs non autorisés de modifier les configurations des appareils qui pourraient endommager le réseau.
Conditions préalables
Cet exemple utilise les composants matériels et logiciels suivants :
-
Un équipement Juniper Networks
-
Un serveur TACACS+ (ou RADIUS)
Avant de commencer, établissez une connexion TCP entre l’appareil et le serveur TACACS+. Dans le cas du serveur RADIUS, établissez une connexion UDP entre le périphérique et le serveur RADIUS.
Vue d’ensemble 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 Classe 2. Chaque classe définit des privilèges d’accès pour l’utilisateur en configurant l’instruction et en définissant des expressions régulières étendues à l’aide permissions
des allow-configuration
instructions , , deny-configuration
allow-configuration-regexps
et deny-configuration-regexps
.
L’objectif de chaque classe de connexion est le suivant :
-
Class1: définit les privilèges d’accès de l’utilisateur à l’aide des
allow-configuration
instructions anddeny-configuration
. Cette classe de connexion permet de configurer la hiérarchie uniquement et[edit interfaces]
refuse tous les autres accès sur l’appareil. Pour ce faire, les autorisations de l’utilisateur incluentconfigure
de fournir un accès à la configuration. En outre, l’instruction autorise l’accès à la configuration des interfaces, et l’instruction refuse l’accèsallow-configuration
deny-configuration
à toutes les autres hiérarchies de configuration. Étant donné que l’instruction allow est prioritaire sur l’instruction refus, les utilisateurs affectés à la classe de connexion Class1 ne peuvent accéder qu’au niveau hiérarchique[edit interfaces]
. -
Class2: définit les privilèges d’accès de l’utilisateur à l’aide des
allow-configuration-regexps
instructions anddeny-configuration-regexps
. Cette classe de connexion fournit des autorisations utilisateur au niveau du superutilisateur et autorise explicitement la configuration sous plusieurs niveaux hiérarchiques pour les interfaces. Il refuse également l’accès aux niveaux hiérarchiques[edit system]
et[edit protocols]
.
Le routeur R1 a deux utilisateurs, User1 et User2, affectés aux classes de connexion Class1 et Class2, respectivement.
Configuration
- Configuration rapide de l’interface de ligne de commande
- Configurer les paramètres d’authentification pour le routeur R1
- Configurer les privilèges d’accès à l’aide des instructions allow-configuration et deny-configuration (classe 1)Configure Access Privileges with the allow-configuration and deny-configuration Statements (Class1)
- Configurer les privilèges d’accès à l’aide des instructions allow-configuration-regexps et deny-configuration-regexps (classe 2)
- Résultats
Configuration rapide de l’interface de ligne de commande
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la hiérarchie, puis passez commit
en mode de [edit]
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 pour le routeur R1
Procédure étape par étape
Pour configurer l’authentification du routeur R1 :
-
Configurez l’ordre dans lequel R1 tente d’authentifier l’utilisateur. Dans cet exemple, l’authentification du serveur TACACS+ est la première, 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 comptables 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
Configurer les privilèges d’accès à l’aide des instructions allow-configuration et deny-configuration (classe 1)Configure Access Privileges with the allow-configuration and deny-configuration Statements (Class1)
Procédure étape par étape
Pour spécifier des expressions régulières à l’aide des allow-configuration
instructions and deny-configuration
:
-
Configurez la classe de connexion Class1 avec
configure
des autorisations.[edit system login] user@R1# set class Class1 permissions configure
-
Configurez l’expression régulière pour permettre aux utilisateurs de la classe d’afficher
allow-configuration
et de modifier une[edit interfaces]
partie du niveau hiérarchique.[edit system login] user@R1# set class Class1 allow-configuration "interfaces .* unit .*"
-
Configurez l’expression régulière pour refuser l’accès
deny-configuration
à toutes les hiérarchies de configuration.[edit system login] user@R1# set class Class1 deny-configuration .*
-
Configurez le compte d’utilisateur pour la classe de connexion Class1.
[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"
Configurer les privilèges d’accès à l’aide des instructions allow-configuration-regexps et deny-configuration-regexps (classe 2)
Procédure étape par étape
Pour spécifier des expressions régulières à l’aide des allow-configuration-regexps
instructions and deny-configuration-regexps
:
-
Configurez la classe de connexion Class2 et attribuez des autorisations de superutilisateur (tous).
[edit system login] user@R1# set class Class2 permissions all
-
Configurez l’expression régulière pour permettre aux utilisateurs de la classe d’accéder
allow-configuration-regexps
à plusieurs hiérarchies sous le 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 régulière pour empêcher les utilisateurs de la classe d’afficher
deny-configuration-regexps
ou de modifier la configuration aux niveaux 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 d’utilisateur pour la classe de connexion Class2.
[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 attribué à 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 Class1 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
User1 dispose d’autorisations configure
d’utilisateur, comme indiqué dans la première sortie. De plus, en mode configuration, User1 a accès au niveau hiérarchique interfaces
, mais uniquement à ce niveau, comme indiqué dans la deuxième sortie.
Vérification de la configuration de classe 2
But
Vérifiez que la configuration de classe 2 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 de protocols
configuration.
User2@R1# edit system ^ Syntax error, expecting <statement> or <identifier>. User2@R1# edit protocols ^ Syntax error, expecting <statement> or <identifier>.
Sens
L’utilisateur 2 est autorisé à configurer les interfaces sur R1, mais il n’est pas autorisé à afficher ou à modifier les [edit system]
niveaux hiérarchiques ou [edit protocols]
.
Tableau de l'historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l' Feature Explorer pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.
deny-commands-regexps
sont prises en charge pour l’autorisation allow-commands-regexps
TACACS+.