Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Privilèges d’accès utilisateur

Vous (l’administrateur système) accordez aux utilisateurs l’accès ou les autorisations aux commandes, aux niveaux hiérarchiques 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, les instructions de configuration et les hiérarchies 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 s’associent à 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 classe de connexion

Les indicateurs d’autorisation permettent à un utilisateur d’accéder aux commandes en mode opérationnel, ainsi qu’aux niveaux et instructions 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 indicateur d’autorisation, l’utilisateur accède aux commandes, aux niveaux de 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 all d’autorisations.

Note:

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 le 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 « simple » : 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 est interface-control.

Pour les indicateurs d’autorisation qui accordent l’accès aux niveaux hiérarchiques et aux instructions de configuration, 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 hiérarchique [edit interfaces] .

Le 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 hiérarchie de configuration auxquels cet indicateur accorde l’accès.

Tableau 1 : indicateurs d’autorisation de la classe de connexion

Indicateur d’autorisation

Description

access

Peut visualiser la configuration d’accès en mode opérationnel ou en mode configuration.

access-control

Peut afficher et configurer les informations d’accès au niveau de la [edit access] hiérarchie.

admin

Peut afficher les informations du compte utilisateur en mode opérationnel ou en mode configuration.

admin-control

Peut afficher les informations du compte utilisateur et les configurer au niveau de la [edit system] hiérarchie.

all

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 hiérarchiques de configuration.

clear

Peut effacer (supprimer) les informations que l’équipement apprend du réseau et stocke dans diverses bases de données réseau (à l’aide des clear commandes).

configure

Peut entrer en mode configuration (à l’aide de la configure commande) et valider les configurations (à l’aide de la commit commande).

control

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 -control .

field

Peut afficher les commandes de débogage de champ. Réservé au support de débogage.

firewall

Peut visualiser la configuration du filtre de pare-feu en mode opérationnel ou en mode configuration.

firewall-control

Peut afficher et configurer les informations des filtres de pare-feu au niveau de la [edit firewall] hiérarchie.

floppy

Peut lire et écrire sur le support amovible.

flow-tap

Peut visualiser la configuration flow-tap en mode opérationnel ou en mode configuration.

flow-tap-control

Peut afficher et configurer les informations de flux au niveau de la [edit services flow-tap] hiérarchie.

flow-tap-operation

Peut envoyer des requêtes de débit au routeur ou au commutateur. Par exemple, un client DTCP (Dynamic Tasking Control Protocol) doit avoir flow-tap-operation l’autorisation de s’authentifier auprès de Junos OS Evolved en tant qu’utilisateur administratif.

Note:

L’option flow-tap-operation n’est pas incluse dans l’indicateur d’autorisations all-control .

idp-profiler-operation

Peut afficher les données du profileur.

interface

Peut visualiser la configuration de l’interface en mode opérationnel et en mode configuration.

interface-control

Peut afficher les informations sur 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 :

  • [edit chassis]

  • [edit class-of-service]

  • [edit groups]

  • [edit forwarding-options]

  • [edit interfaces]

maintenance

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 su root commande) et arrêter et redémarrer l’appareil (à l’aide des request system commandes).

network

Peut accéder au réseau à l’aide des pingcommandes , ssh, telnetet traceroute .

pgcp-session-mirroring

Peut afficher la configuration de la mise en miroir des pgcp sessions.

pgcp-session-mirroring-control

Peut modifier la configuration de la mise en miroir des pgcp sessions.

reset

Peut redémarrer les processus logiciels à l’aide de la restart commande.

rollback

Peut utiliser la rollback commande pour revenir à une configuration précédemment validée.

routing

Peut afficher les informations générales de configuration du routage, du protocole de routage et de la stratégie de routage en mode configuration et en mode opérationnel.

routing-control

Peut afficher et configurer le routage général au niveau hiérarchique [edit routing-options] , les protocoles de routage au [edit protocols] niveau hiérarchique et les informations sur les stratégies de routage au [edit policy-options] niveau hiérarchique.

secret

Peut afficher les mots de passe et autres clés d’authentification dans la configuration.

secret-control

Peut afficher et modifier les mots de passe et autres clés d’authentification dans la configuration.

security

Peut afficher les informations de configuration de la sécurité en mode opérationnel et en mode configuration.

security-control

Peut afficher et configurer les informations de sécurité au niveau de la [edit security] hiérarchie.

shell

Peut démarrer un shell local sur le routeur ou le commutateur à l’aide de la start shell commande, et peut devenir l’utilisateur root dans le shell à l’aide de la start shell user root commande.

snmp

Peut afficher les informations de configuration du protocole SNMP (Simple Network Management Protocol) en mode opérationnel ou en mode configuration.

snmp-control

Peut afficher et modifier les informations de configuration SNMP au niveau de la [edit snmp] hiérarchie.

storage

Peut afficher les informations de configuration du stockage Fibre Channel au niveau de la [edit fc-fabrics] hiérarchie.

storage-control

Peut modifier les informations de configuration du stockage Fibre Channel au niveau de la [edit fc-fabrics] hiérarchie.

system

Peut afficher des informations au niveau du système en mode opérationnel ou en mode configuration.

system-control

Peut afficher et modifier les informations de configuration au niveau du système au niveau de la [edit system] hiérarchie.

trace

Peut afficher les paramètres du fichier de trace et configurer les propriétés du fichier de trace.

trace-control

Peut modifier les paramètres du fichier de trace et configurer les propriétés du fichier de trace.

unified-edge

Peut visualiser la configuration de périphérie unifiée au niveau de la [edit unified-edge] hiérarchie.

unified-edge

Peut modifier la configuration liée à la périphérie unifiée au niveau de la [edit unified-edge] hiérarchie.

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.

view-configuration

Peut afficher toute la configuration, à l’exclusion des secrets, des scripts système et des options d’événement.

Note:

Seuls les utilisateurs autorisés peuvent afficher la configuration du script de validation, du script op ou du script d’événement maintenance .

Autoriser et refuser des commandes individuelles et des hiérarchies d’instructions pour les classes de connexion

Par défaut, toutes les commandes CLI de niveau supérieur et les niveaux hiérarchiques 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 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 .

Les indicateurs d’autorisation permettent à un utilisateur d’accéder aux commandes des modes opérationnel et 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 [edit system login class] hiérarchie, vous accordez à l'utilisateur l'accès aux commandes correspondantes et aux niveaux et instructions de la hiérarchie de configuration. Pour accorder l’accès à toutes les commandes et instructions de configuration, utilisez l’indicateur all d’autorisations.

Vous pouvez explicitement autoriser ou refuser l’utilisation de commandes et d’instructions en configurant les allow-commandsinstructions , deny-commands, allow-configurationet 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.

Exigences

Aucune configuration spéciale au-delà de l’initialisation de l’appareil n’est requise avant de configurer cet exemple.

Aperçu

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 du mode opérationnel et du 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 all d’autorisations. Les indicateurs d’autorisation fournissent des fonctionnalités en lecture seule (formulaire « plain ») et en lecture et écriture (formulaire qui se termine par -control) pour un type d’autorisation.

Note:

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èges d’accès utilisateur d’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 les autorisations multiples sous la forme d’une liste séparée par des espaces et entre crochets :

Pourboire:

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' permissions instruction :

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 de la classe de connexion :

  1. Configurez la snmp-admin classe de connexion à l’aide des configureindicateurs , snmpet snmp-control d’autorisation.

    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 c’est le seul privilège d’accès autorisé pour cette classe de connexion. Tous les autres privilèges d’accès sont refusés.

  2. Créez les comptes d’utilisateur affectés à la snmp-admin classe de connexion.

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.

Après avoir configuré l’appareil, entrez 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érification de 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.

Signification

L’utilisateur de la classe de connexion est en mesure de configurer les snmp-admin 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.

Signification

L’utilisateur de la snmp-admin classe login n’est pas en mesure de configurer la [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 pour autoriser et refuser les commandes, les instructions de configuration et les hiérarchies en mode opérationnel

Cette rubrique contient les sections suivantes :

Comprendre les instructions allow et deny

Chaque hiérarchie de commandes et d’instructions de configuration CLI 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 de commandes en mode opérationnel et en 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 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 deny-commands: autorisent ou refusent l’accès aux commandes du mode opérationnel et du mode configuration.

  • allow-configuration et deny-configuration: autoriser ou refuser l’accès à des hiérarchies de configuration spécifiques.

    Note:

    Ces instructions effectuent une correspondance plus lente, avec plus de flexibilité, en particulier dans la correspondance générique. Toutefois, l’évaluation de toutes les instructions possibles peut prendre beaucoup de temps si un grand nombre d’expressions régulières de chemin complet ou d’expressions génériques sont configurées, ce qui peut nuire aux performances.

  • allow-commands-regexps et deny-commands-regexps: autorise ou refuse l’accès à des commandes particulières à l’aide de chaînes d’expressions régulières.

  • allow-configuration-regexps et deny-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.

Note:

Si vos configurations existantes utilisent les allow/deny-commands instructions or allow/deny-configuration , l’utilisation des mêmes options de configuration avec les allow/deny-commands-regexps instructions or allow/deny-configuration-regexps peut ne pas produire les 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 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 [edit system services] hiérarchie et de la valider.

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 all , sauf que l’utilisateur ne peut pas afficher ou modifier la configuration au niveau de la [edit system services] hiérarchie :

Présentation de la syntaxe des instructions allow et deny

Vous ne pouvez configurer une allow/deny-* instruction qu’une 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 allow/deny-commands-regexps énoncés, et les allow/deny-configuration énoncés s’excluent mutuellement avec les 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 les 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 le symbole de 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.

Par exemple:

Vous devez utiliser des ancres lorsque vous spécifiez des expressions régulières complexes avec l’instruction allow-commands . Par exemple:

Pour définir des privilèges d’accès à certaines 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.

Par exemple:

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 plusieurs expressions entre crochets [ ]. Par exemple:

Les modificateurs tels que set, loget 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 correspondant.

Configuration correcte :

Configuration incorrecte :

Compréhension de la priorité et de la correspondance des instructions allow et deny

Par défaut, les expressions régulières allow-commands et allow-configuration sont prioritaires sur deny-commands les deny-configuration expressions. 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 test classe login d’installer un logiciel à l’aide de la request system software add commande, même si l’instruction deny-commands inclut la même commande :

De même, la configuration suivante permet à un utilisateur du test test de classe de connexion d’afficher et de modifier la hiérarchie de configuration [edit system services] , même si l’instruction deny-configuration inclut la même hiérarchie :

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 synchronizeet qu’elle est spécifiée pour allow-commands.

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 synchronizeet qu’elle est spécifiée pour deny-commands.

Contrairement aux autres instructions, le comportement par défaut des *-regexps instructions est que les expressions régulières deny-commands-regexps et deny-configuration-regexps sont prioritaires sur allow-commands-regexps allow-configuration-regexps les 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 à ê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 l’utilisateur à accéder uniquement à des sous-hiérarchies spécifiques.

Comprendre les règles d’autorisation et de refus

Les allow/deny-commandsinstructions , allow/deny-configuration, allow/deny-commands-regexpset 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 pour allow-commands et les instructions peuvent également inclure les commitcommandes , load, rollback, savestatus, et update deny-commands .

  • Les all bits d’autorisation de la classe de connexion sont prioritaires sur les expressions régulières étendues lorsqu’un utilisateur exécute la rollback commande avec l’indicateur d’autorisation rollback 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 les mergecommandes , replace, et patch 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’instruction allow-configuration avec une expression telle que (interfaces (description (|.*)), car cela équivaut à allow-configuration .*.

Comprendre les différences entre les instructions *-regexps

Cette section décrit les différences entre les allow/deny-configuration énoncés et les allow/deny-configuration-regexps énoncés.

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 rationnelle 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.

    La configuration précédente correspond aux instructions suivantes :

    • set policy-options condition condition dynamic-db

    • set routing-options route static-route statique saut suivant next-hop

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

    La configuration précédente ne correspond pas aux instructions suivantes :

    • nom_hôte système options hôte

    • Options de description des interfaces interface-name

  • Expression rationnelle correspondant à trois jetons à l’aide de allow-configuration-regexps

    Cet exemple montre que c’est ssh la seule expression correspondante par rapport au troisième jeton de l’instruction.

    Dans l’exemple précédent, les trois jetons sont .*respectivement , .*et .*ssh, .

    La configuration précédente correspond aux instructions suivantes :

    • nom_hôte système_nom_hôte-ssh

    • Services système SSH

    • Services système sortants-SSH

    La configuration précédente ne correspond pas à l’instruction suivante :

    • Description des interfaces interface-name SSH

Il est plus facile d’utiliser l’instruction pour restreindre l’accès à la deny-configuration configuration que d’utiliser l’instruction deny-configuration-regexps . Le Tableau 2 illustre l’utilisation des deny-configuration instructions et deny-configuration-regexps dans différentes configurations afin d’obtenir le même résultat de restriction de l’accès à une configuration particulière.

Tableau 2 : restriction de l’accès à la configuration à l’aide des instructions deny-configuration et deny-configuration-regexps

Configuration refusée

Utilisant: deny-configuration

Utilisant: deny-configuration-regexps

Résultat

xnm-ssl

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

L’instruction de configuration suivante est refusée :

  • Services système XNM-SSL

ssh

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

Les instructions de configuration suivantes sont refusées :

  • nom_hôte système_nom_hôte-ssh

  • Services système SSH

  • Services système sortants-SSH

  • sécurité hôte-connu-ssh

Bien que les allow/deny-configuration instructions soient également utiles lorsque vous souhaitez une configuration simple, les allow/deny-configuration-regexps instructions 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 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-commandsinstructions , allow/deny-configurationallow/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 les paramètres d’autorisation à la fois localement et à distance, le périphérique 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 le périphérique local.

Lorsque vous spécifiez plusieurs expressions régulières dans une configuration locale à l’aide des allow-commandsinstructions , deny-commands, allow-configurationou , configurez deny-configuration les expressions régulières entre parenthèses et séparez-les à 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 :

Le serveur d’autorisation RADIUS utilise les attributs et la syntaxe suivants :

Le serveur d’autorisation TACACS+ utilise les attributs et la syntaxe suivants :

Lorsque vous spécifiez plusieurs expressions régulières dans une configuration locale à l’aide des allow-commands-regexpsinstructions , deny-commands-regexps, allow-configuration-regexpsou , 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 :

Le serveur d’autorisation RADIUS utilise les attributs et la syntaxe suivants :

Le serveur d’autorisation TACACS+ utilise les attributs et la syntaxe suivants :

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 :

De même, la syntaxe simplifiée du serveur TACACS+ est la suivante :

Le Tableau 3 différencie la configuration d’autorisation locale et la configuration d’autorisation de serveur TACACS+ à l’aide d’expressions régulières.

Tableau 3 : exemple de configuration d’autorisation locale et distante à 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"
    }
}
Note:
  • Vous devez autoriser explicitement l’accès au mode NETCONF, localement ou à distance, en émettant les trois commandes suivantes : xml-mode, netconf, et need-trailer.

  • Lorsque vous utilisez l’instruction deny-configuration = ".*" , vous devez autoriser toutes les configurations souhaitées à l’aide de l’instruction allow-configuration . Toutefois, cette configuration peut affecter la limite de mémoire tampon autorisée pour les expressions régulières pour l’instruction allow-configuration . Si cette limite est dépassée, la configuration autorisée peut ne pas fonctionner.

Spécifier des expressions régulières

Avertissement:

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 souhaité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 pour exécuter la commande ou l’instruction complète. Le 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] .

Tableau 4 : spécification d’expressions régulières

Déclaration

Expression régulière

Configuration Notes

[edit interfaces]

La set commande pour les interfaces est exécutée comme suit :

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

L’instruction set interfaces est incomplète en elle-même et nécessite l’option d’exécution unit de l’instruction.

Par conséquent, l’expression régulière requise pour refuser la set interfaces configuration doit spécifier la chaîne exécutable entière avec l’opérateur à la .* place des variables d’instruction :

[edit system login class class-name]
user@host# set permissions configure
user@host# set deny-configuration "interfaces .* unit .*"
  • L’opérateur .* désigne tout à partir du point spécifié pour cette commande ou instruction particulière. Dans cet exemple, il désigne n’importe quel nom d’interface avec n’importe quelle valeur d’unité.

  • La spécification uniquement de l’instruction deny-configuration "interfaces .*" est incorrecte et ne refuse pas l’accès à la configuration des interfaces pour la classe de connexion spécifiée.

  • D’autres options valides peuvent être incluses dans l’expression régulière. Par exemple:

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

    Remarque : Dans cet exemple, l’expression mem.* régulière est utilisée lorsque plusieurs chaînes commençant par le mem mot-clé sont censées être incluses dans l’expression régulière spécifiée. Lorsqu’une member seule chaîne doit être incluse, l’expression member .* régulière est utilisée.

[edit vlans]

La set commande pour les VLAN est exécutée comme suit :

[edit]
user@host# set vlans vlan-name vlan-id vlan-id

Ici, l’instruction set vlans est incomplète en elle-même et nécessite l’option d’exécution vlan-id de l’instruction.

Par conséquent, l’expression régulière requise pour autoriser la set vlans configuration doit spécifier l’intégralité de la chaîne exécutable avec l’opérateur à la .* place des variables d’instruction :

[edit system login class class-name]
user@host# set permissions configure
user@host# set allow-configuration "vlans .* vlan-id .*"
  • L’opérateur .* désigne tout à partir du point spécifié pour cette commande ou instruction particulière. Dans cet exemple, il désigne n’importe quel nom de VLAN avec n’importe quel ID de VLAN.

  • D’autres options valides sous la hiérarchie d’instructions [edit vlans] peuvent être incluses dans l’expression régulière. Par exemple:

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

Opérateurs d’expressions régulières

Le 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 régulières étendues (modernes), telles que définies dans POSIX 1003.2.

Tableau 5 : opérateurs d’expression régulière courants

Opérateur

Allumette

Exemple

|

L’un des deux termes ou plus séparés par une 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, l’accès en mode opérationnel des utilisateurs affectés à la classe de connexion de test est limité aux seules commandes spécifiées dans l’instruction allow-commands . Ils ont également accès au mode de configuration, à l’exclusion des niveaux hiérarchiques spécifiés dans l’instruction deny-configuration .

^

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 allow-commands accorde l’accès aux commandes qui commencent par les show mots-clés et monitor .

Pour le premier filtre, les commandes spécifiées incluent les show logcommandes , show interfaces, et show policer . Le deuxième filtre spécifie toutes les commandes commençant par le monitor mot-clé, telles que les commandes ou monitor interfaces .monitor traffic

$

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 de test peuvent afficher la configuration des interfaces en mode configuration. Les utilisateurs peuvent également visualiser la configuration de l’interface à l’aide de la show configuration commande mode opérationnel. Toutefois, l’expression régulière spécifiée dans l’instruction allow-commands restreint les utilisateurs à exécuter uniquement la show interfaces commande et refuse l’accès aux extensions de commande telles que show interfaces detail ou show interfaces extensive.

[ ]

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 d’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 allow-commands .

*

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 m se voient refuser l’accès à la configuration.

+

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 m se voient refuser l’accès à la configuration.

.

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 m se voient refuser l’accès à la configuration.

.*

Le 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 m se voient refuser l’accès à la configuration.

De même, l’instruction refuse tout accès à la deny-configuration "protocols .*" configuration sous le niveau hiérarchique [edit protocols] .

Note:
  • Les *opérations , +, et . peuvent être réalisées à l’aide de .*.

  • Les deny-commands .* instructions et deny-configuration .* refusent respectivement l’accès à toutes les commandes en mode opérationnel et à toutes les hiérarchies de configuration.

Note:

L’opérateur ! d’expression régulière n’est pas pris en charge.

Exemples d’expressions régulières

Le 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]—, à titre d’exemple pour la spécification d’expressions régulières.

Note:

Le 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 les hiérarchies. Les expressions régulières répertoriées dans le tableau sont validées uniquement pour les hiérarchies d’instructions [edit system ntp server] et [edit protocols rip] .

Tableau 6 : exemples d’expressions régulières

Hiérarchie des instructions

Expressions régulières

Configuration autorisée

Configuration refusée

[edit system ntp server]

     

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" ]
  • adresse IP du serveur

  • adresse IP et clé du serveur

  • Version

  • préférer

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" ]
  • adresse IP du serveur

  • adresse IP et version du serveur

  • clé

  • préférer

préférer

[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 .*" ]
  • adresse IP du serveur

  • IP serveur et préfère

  • clé

  • Version

[edit protocols rip]

     

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 .*" ]
  • taille du message

  • Entrée métrique

  • délai d’attente de routage

  • intervalle_de_mise à jour

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 .*" ]
  • Entrée métrique

  • taille du message

  • délai d’attente de routage

  • intervalle_de_mise à jour

délai d’attente 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 .*" ]
  • délai d’attente de routage

  • taille du message

  • Entrée métrique

  • intervalle_de_mise à jour

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 .*" ]
  • intervalle_de_mise à jour

  • taille du message

  • Entrée métrique

  • délai d’attente de routage

Comment définir des privilèges d’accès à l’aide d’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 et deny-configuration 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 deny-configuration contiennent une ou plusieurs expressions régulières qui autorisent ou refusent des hiérarchies et des instructions de configuration spécifiques. Les allow-configuration instructions et deny-configuration sont prioritaires sur les indicateurs d’autorisation et donnent à l’administrateur un contrôle plus précis sur les hiérarchies et les instructions que l’utilisateur peut afficher et configurer.

Cette rubrique explique comment définir les privilèges d’accès à l’aide allow-configuration des instructions and 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 login qui permet à l’utilisateur d’exécuter toutes les commandes et de tout configurer à l’exception des paramètres telnet :

  1. Définissez les autorisations de la classe de connexion de l’utilisateur sur all.
  2. Incluez l’énoncé suivant deny-configuration .

Exemple 2

Pour créer une classe login qui permet à l’utilisateur d’exécuter toutes les commandes et de tout configurer, à l’exception des instructions dans toute classe de login dont le nom commence par « m » :

  1. Définissez les autorisations de la classe de connexion de l’utilisateur sur all.

  2. Incluez l’énoncé suivant deny-configuration .

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 niveaux hiérarchiques [edit system login class] ou [edit system services] :

  1. Définissez les autorisations de la classe de connexion de l’utilisateur sur all.

  2. Incluez l’énoncé suivant deny-configuration :

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 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 :

  1. Définissez les autorisations de la classe de connexion de l’utilisateur sur configure.

  2. Incluez l’énoncé suivant allow-configuration :

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 :

  1. Définissez les autorisations de la classe de connexion de l’utilisateur sur all.

  2. Incluez l’énoncé suivant deny-configuration .

Exemple : Utiliser une 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 les privilèges d’accès à la configuration.

Exigences

Aucune configuration spéciale au-delà de l’initialisation de l’appareil n’est requise avant de configurer cet exemple.

Aperçu

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 and deny-configuration-regexps pour une classe de connexion.

Par défaut, l’instruction deny-configuration-regexps est prioritaire 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 la logique additive pour les *-configuration-regexps instructions. Lorsque vous activez la logique additive, l’instruction allow-configuration-regexps est prioritaire sur l’instruction deny-configuration-regexps .

Ainsi, si l’instruction deny-configuration-regexps refuse l’accès à toutes les hiérarchies de configuration à un niveau donné (protocoles .*) mais autorise l’accès allow-configuration-regexps à une sous-hiérarchie (protocoles bgp .*), alors par défaut l’appareil refuse l’accès aux hiérarchies pour les utilisateurs de cette classe de connexion car l’instruction 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 :

  1. Incluez l’instruction et refusez explicitement l’accès deny-configuration-regexps aux hiérarchies de configuration.

    Par exemple:

  2. Incluez l’instruction allow-configuration-regexps et définissez des expressions régulières pour les hiérarchies spécifiques à autoriser.

    Par exemple:

  3. Activez la logique additive pour les expressions régulières allow-configuration-regexps et deny-configuration-regexps .

  4. Attribuez la classe de connexion à un ou plusieurs utilisateurs.

  5. Validez vos modifications.

    Les utilisateurs affecté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’instruction deny-configuration-regexps .

Note:

Lorsque vous configurez l’instruction regex-additive-logic , le changement de comportement s’applique à toutes les allow-configuration-regexps instructions et deny-configuration-regexps présentes dans toutes les classes de connexion. Si vous activez la logique additive, vous devez évaluer les instructions existantes pour détecter tout impact 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 adapté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 CUST-VRF-; 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 toute instance de routage.

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 qu’en soit le nom.

Toutefois, si vous configurez l’instruction suivante, l’instruction allow-configuration-regexps est prioritaire. 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.

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 [edit protocols] hiérarchie, mais autorisent la configuration des homologues BGP :

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é.

Vérification

Pour vérifier que vous avez correctement défini les privilèges d’accès :

  1. Configurez une classe de connexion et validez les modifications.

  2. Affectez la classe de connexion à un usernamefichier .

  3. Connectez-vous en tant qu’assigné username avec la nouvelle classe de connexion.

  4. 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 des 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.

Exigences

Cet exemple utilise les composants matériels et logiciels suivants :

  • Un appareil 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 l’appareil et le serveur RADIUS.

Vue d’ensemble et topologie

La 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+.

Figure 1 : topologie Topology

Cet exemple configure R1 avec trois classes de connexion personnalisées : Class1, Class2 et Class3. Chaque classe définit des privilèges 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 and deny-commands .

L’objectif de chaque classe de connexion est le suivant :

  • Class1: définit les privilèges d’accès pour 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 pour 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 aux set commandes.

  • Class3: définit les privilèges d’accès de l’utilisateur à l’aide des allow-commands instructions and deny-commands . Cette classe de connexion fournit des autorisations utilisateur et une autorisation de niveau superutilisateur pour accéder aux interfaces et afficher les informations sur les périphériques. Il refuse également l’accès aux edit commandes and configure .

Le routeur R1 a trois utilisateurs différents, Utilisateur1, Utilisateur2 et Utilisateur3 affectés respectivement aux classes de connexion Class1, Class2 et Class3.

Configuration

Configuration rapide de la CLI

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 à votre configuration réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode configuration.

R1

Configurer les paramètres d’authentification pour le routeur R1

Procédure étape par étape

Pour configurer l’authentification du routeur R1 :

  1. 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.

  2. Configurez le serveur TACACS+.

  3. Configurez le serveur RADIUS.

  4. Configurez les paramètres de comptabilité R1.

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 :

  1. Configurez la classe de connexion Class1 et attribuez des autorisations utilisateur au niveau de l’opérateur.

  2. Configurez l’expression allow-commands régulière pour permettre aux utilisateurs de la classe de redémarrer l’appareil.

  3. Configurez le compte d’utilisateur pour la classe de connexion Class1.

Configurer les privilèges d’accès à l’aide de 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 :

  1. Configurez la classe de connexion Class2 et attribuez des autorisations utilisateur au niveau de l’opérateur.

  2. Configurez l’expression deny-commands régulière pour empêcher les utilisateurs de la classe d’exécuter set des commandes.

  3. Configurez le compte d’utilisateur pour la classe de connexion Class2.

Configurer les privilèges d’accès à l’aide des instructions allow-commands et deny-commands (Class3)

Procédure étape par étape

Pour spécifier des expressions régulières à l’aide des allow-commands instructions et deny-commands :

  1. Configurez la classe de connexion Class3 et attribuez des autorisations au niveau du superutilisateur.

  2. Configurez l’expression deny-commands régulière pour empêcher les utilisateurs de la classe d’exécuter des commandes.

  3. Configurez l’expression allow-commands régulière pour permettre aux utilisateurs d’entrer en mode de configuration.

  4. Configurez le compte d’utilisateur pour la classe de connexion Class3.

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.

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

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.

En mode opérationnel, exécutez la request system reboot commande.

Signification

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 de l’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: permet d’accéder au réseau à l’aide des pingcommandes , ssh, telnet, et traceroute .

  • 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 indique 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.

À partir de l’invite CLI, vérifiez les commandes disponibles.

À partir de l’invite de ligne de commande, exécutez n’importe quelle commande définie.

Signification

La classe de connexion Class2 à laquelle User2 est affecté dispose d’autorisations d’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.

Entrez en mode de configuration.

Signification

La classe de connexion Class3 à laquelle User3 est affecté dispose d’autorisations de superutilisateur (tous), 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 sont prioritaires sur les autorisations utilisateur, User3 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 des 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.

Exigences

Cet exemple utilise les composants matériels et logiciels suivants :

  • Un appareil 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 l’appareil et le serveur RADIUS.

Vue d’ensemble et topologie

La 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+.

Figure 2 : topologie Topology

Cet exemple configure R1 avec deux classes de connexion personnalisées : Class1 et Class2. Chaque classe définit les privilèges d’accès de l’utilisateur en configurant l’instruction permissions et en définissant des expressions régulières étendues à l’aide des allow-configurationinstructions , deny-configuration, allow-configuration-regexpset 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 and deny-configuration . Cette classe de connexion permet de configurer la [edit interfaces] hiérarchie uniquement et refuse tous les autres accès sur l’appareil. Pour ce faire, les autorisations de l’utilisateur incluent configure de fournir un accès à la configuration. De plus, l’instruction allow-configuration autorise l’accès à la configuration des interfaces et refuse l’accès deny-configuration à toutes les autres hiérarchies de configuration. Étant donné que l’instruction allow est prioritaire sur l’instruction ny, 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 and deny-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 [edit system] aux niveaux hiérarchiques et [edit protocols] .

Le routeur R1 a deux utilisateurs, User1 et User2, affectés respectivement aux classes de connexion Class1 et Class2.

Configuration

Configuration rapide de la CLI

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 à votre configuration réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode configuration.

R1

Configurer les paramètres d’authentification pour le routeur R1

Procédure étape par étape

Pour configurer l’authentification du routeur R1 :

  1. 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.

  2. Configurez le serveur TACACS+.

  3. Configurez le serveur RADIUS.

  4. Configurez les paramètres comptables R1.

Configurer les privilèges d’accès à l’aide des instructions allow-configuration et deny-configuration (Class1)

Procédure étape par étape

Pour spécifier des expressions régulières à l’aide des allow-configuration instructions et deny-configuration :

  1. Configurez la classe de connexion Class1 avec configure autorisations.

  2. Configurez l’expression allow-configuration régulière pour permettre aux utilisateurs de la classe d’afficher et de modifier une [edit interfaces] partie du niveau hiérarchique.

  3. Configurez l’expression régulière pour refuser l’accès deny-configuration à toutes les hiérarchies de configuration.

  4. Configurez le compte d’utilisateur pour la classe de connexion Class1.

Configurez les privilèges d’accès à l’aide des instructions 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 :

  1. Configurez la classe de connexion Class2 et attribuez des autorisations de superutilisateur (tous).

  2. Configurez l’expression allow-configuration-regexps régulière pour permettre aux utilisateurs de la classe d’accéder à plusieurs hiérarchies sous le niveau hiérarchique [edit interfaces] .

  3. 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 de la hiérarchie et [edit protocols] de la [edit system] hiérarchie.

  4. Configurez le compte d’utilisateur pour la classe de connexion Class2.

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.

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

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.

En mode configuration, vérifiez les autorisations de configuration disponibles.

Signification

User1 dispose configure des autorisations 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.

En mode configuration, accédez aux system hiérarchies de protocols configuration.

Signification

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] autres.