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 et aux niveaux et déclarations de la hiérarchie de configuration. Les utilisateurs peuvent exécuter uniquement les commandes et afficher et configurer uniquement les instructions pour lesquelles ils disposent de privilèges d’accès. Vous pouvez également utiliser des expressions régulières étendues pour spécifier les commandes du mode opérationnel, les instructions de configuration et les hiérarchies autorisées ou refusées pour les utilisateurs. Cette pratique empêche les utilisateurs non autorisés d’exécuter des commandes sensibles ou de configurer des instructions susceptibles de causer des dommages au réseau.

Présentation des niveaux de privilèges d’accès

Chaque commande CLI de niveau supérieur et chaque déclaration de configuration a un niveau de privilège d’accès associé. Les utilisateurs peuvent exécuter uniquement les commandes et configurer et afficher uniquement les instructions pour lesquelles ils disposent de privilèges d’accès. Un ou plusieurs indicateurs d’autorisation définissent les privilèges d’accès pour chaque classe de connexion.

Pour chaque classe de connexion, vous pouvez également autoriser ou refuser explicitement l’utilisation de commandes de mode opérationnel et de configuration et de hiérarchies d’instruction qui seraient autrement autorisées ou refusées par un niveau de privilège spécifié dans l’instruction permissions .

Indicateurs d’autorisation de classe de connexion

Vous utilisez des indicateurs d’autorisation pour accorder à un utilisateur l’accès aux commandes du mode opérationnel et aux niveaux et déclarations de la hiérarchie de configuration. Vous configurez les indicateurs d’autorisation pour la classe de connexion de l’utilisateur au niveau de la [edit system login class] hiérarchie. Lorsque vous spécifiez un certain indicateur d’autorisation, l’utilisateur accède aux commandes et aux niveaux de la hiérarchie de configuration et aux déclarations correspondant à cet indicateur. Pour accorder l’accès à toutes les commandes et déclarations de configuration, utilisez l’indicateur d’autorisation all .

REMARQUE :

Chaque commande répertoriée représente cette commande et toutes les sous-commandes avec cette commande comme préfixe. Chaque déclaration de configuration répertoriée représente le sommet de la hiérarchie de configuration à laquelle cet indicateur accorde l’accès.

L’instruction permissions spécifie un ou plusieurs des indicateurs d’autorisation répertoriés dans Tableau 1. Les indicateurs d’autorisation ne sont pas cumulables. Pour chaque classe, vous devez lister tous les indicateurs d’autorisation nécessaires, y compris view pour afficher les informations et configure accéder au mode de configuration. Deux formes d’autorisations contrôlent l’accès d’un utilisateur aux différentes parties de la configuration :

  • Formulaire « simple » : offre une fonctionnalité en lecture seule pour ce type d’autorisation. Par exemple interface, .

  • -control form : permet de lire et d’écrire ce type d’autorisation. Par exemple interface-control, .

Pour les indicateurs d’autorisation qui accordent l’accès aux niveaux et aux instructions de la hiérarchie de configuration, les indicateurs de forme simple accordent le privilège de lecture seule à cette configuration. Par exemple, l’indicateur d’autorisation interface accorde un accès en lecture seule au [edit interfaces] niveau hiérarchique. Le -control formulaire de l’indicateur donne un accès en lecture-écriture à cette configuration. Par exemple, l’indicateur interface-control accorde un accès en lecture-écriture au niveau de la [edit interfaces] hiérarchie.

Tableau 1 répertorie les indicateurs d’autorisation des classes de connexion que vous pouvez configurer en incluant l’instruction permissions au niveau de la [edit system login class class-name] hiérarchie.

Les indicateurs d’autorisation accordent un ensemble spécifique de privilèges d’accès. Chaque indicateur d’autorisation est répertorié avec les commandes du mode opérationnel ou du mode de configuration, ainsi que les niveaux et les déclarations de hiérarchie de configuration pour lesquels cet indicateur accorde l’accès.

Tableau 1 : Indicateurs d’autorisation de classe de connexion

Indicateur d’autorisation

Description

access

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

access-control

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

admin

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

admin-control

Peut consulter les informations de 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 du mode de configuration. Peut modifier la configuration à tous les niveaux de la hiérarchie 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 clear des 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 de niveau contrôle, toutes les opérations configurées avec les indicateurs d’autorisation -control .

field

Peut afficher les commandes de débogage sur le terrain. Réservé à la prise en charge du débogage.

firewall

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

firewall-control

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

floppy

Peut lire et écrire sur le support amovible.

flow-tap

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

flow-tap-control

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

flow-tap-operation

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

REMARQUE :

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

idp-profiler-operation

Peut consulter les données du profileur.

interface

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

interface-control

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 :

  • [edit chassis]

  • [edit class-of-service]

  • [edit groups]

  • [edit forwarding-options]

  • [edit interfaces]

maintenance

Peut effectuer la maintenance du système, notamment en commençant un shell local sur l’équipement et en devenant le superutilisateur du shell (à l’aide de la su root commande) et en arrêtant et en redémarrant l’équipement (à l’aide request system des commandes).

network

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

pgcp-session-mirroring

Peut afficher la configuration de pgcp mise en miroir de session.

pgcp-session-mirroring-control

Peut modifier la configuration de pgcp mise en miroir de session.

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 consulter les informations générales de configuration du routage, du protocole de routage et des stratégies de routage en mode de configuration et en mode opérationnel.

routing-control

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

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 consulter les informations de configuration de sécurité en mode opérationnel et en mode de configuration.

security-control

Peut consulter 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.

snmp

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

snmp-control

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

system

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

system-control

Peut consulter 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 suivi et configurer les propriétés du fichier de trace.

trace-control

Peut modifier les paramètres du fichier de suivi et 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, des tables de routage et des valeurs et statistiques spécifiques au protocole. Impossible d’afficher la configuration secrète.

view-configuration

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

REMARQUE :

Seuls les utilisateurs autorisés peuvent consulter le maintenance script de validation, le script op ou la configuration des scripts d’événements.

Autoriser et refuser les commandes individuelles et les hiérarchies d’instruction pour les classes d’identification

Par défaut, toutes les commandes CLI de niveau supérieur et les niveaux de hiérarchie de configuration ont des niveaux de privilèges d’accès associés. Les utilisateurs peuvent exécuter uniquement les commandes et afficher et configurer uniquement les instructions pour lesquelles ils disposent de privilèges d’accès. Pour chaque classe de connexion, vous pouvez autoriser et refuser explicitement l’utilisation de commandes de mode opérationnel et de mode de configuration et de hiérarchies d’instruction qui seraient autrement autorisées ou refusées par un niveau de privilège spécifié dans l’instruction permissions .

Les indicateurs d’autorisation donnent à l’utilisateur l’accès aux commandes du mode opérationnel et du mode de configuration, ainsi qu’aux niveaux et déclarations de la hiérarchie de configuration. En spécifiant un indicateur d’autorisation spécifique sur la classe de connexion de l’utilisateur au niveau hiérarchique, vous donnez à l’utilisateur l’accès [edit system login class] aux commandes et aux niveaux et déclarations de hiérarchie de configuration correspondants. Pour accorder l’accès à toutes les commandes et déclarations de configuration, utilisez l’indicateur d’autorisation all .

Vous pouvez explicitement autoriser ou refuser l’utilisation de commandes et d’instructions en configurant le allow-commands, deny-commandsallow-configurationet deny-configuration les instructions pour une classe de connexion. Dans les instructions, vous utilisez des expressions régulières étendues pour définir les commandes et les instructions à autoriser ou refuser pour les utilisateurs assignés à la classe.

Exemple : Configurer les autorisations utilisateur avec des niveaux de privilèges d’accès

Cet exemple configure les autorisations utilisateur pour une classe de connexion. Vous configurez les autorisations utilisateur pour une classe de connexion afin d’empêcher les utilisateurs d’effectuer des actions réseau non autorisées. Les utilisateurs ne peuvent exécuter que les commandes et afficher et modifier uniquement les instructions pour lesquelles ils disposent de privilèges d’accès. Cette contrainte empêche les utilisateurs non autorisés d’exécuter des commandes sensibles ou de configurer des instructions susceptibles d’endommager le réseau.

Conditions préalables

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

Présentation

Chaque commande CLI de niveau supérieur et chaque déclaration de configuration a un niveau de privilège d’accès associé. Lorsque vous configurez une classe de connexion, vous pouvez explicitement autoriser ou refuser l’utilisation de commandes et d’instructions de configuration de mode opérationnel et de configuration. Les utilisateurs peuvent exécuter uniquement les commandes et afficher et configurer uniquement les instructions pour lesquelles ils disposent de privilèges d’accès.

Vous définissez les droits d’accès pour chaque classe de connexion en spécifiant un ou plusieurs indicateurs d’autorisation dans l’instruction permissions . Les indicateurs d’autorisation accordent à l’utilisateur l’accès aux commandes, aux déclarations et aux hiérarchies. Les indicateurs d’autorisation ne sont pas cumulables. Pour chaque classe de connexion, vous devez lister tous les indicateurs d’autorisation nécessaires, y compris view pour afficher les informations et configure accéder au mode de configuration. En spécifiant un indicateur d’autorisation spécifique sur la classe de connexion de l’utilisateur, vous donnez à l’utilisateur l’accès aux commandes, aux déclarations et aux hiérarchies correspondantes. Pour accorder l’accès à toutes les commandes et déclarations de configuration, utilisez l’indicateur d’autorisation all . Les indicateurs d’autorisation fournissent une fonctionnalité de lecture seule (formulaire simple) et de lecture et d’écriture (forme qui se termine par -contrôle) pour un type d’autorisation.

REMARQUE :

Les all bits d’autorisation de classe de connexion ont priorité sur les expressions régulières étendues lorsqu’un utilisateur émet une rollback commande avec l’indicateur d’autorisation rollback activé.

Pour configurer les niveaux de privilèges d’accès utilisateur pour une classe de connexion, incluez l’instruction permissions au niveau de la [edit system login class class-name] hiérarchie, suivie des indicateurs d’autorisation. Configurez plusieurs autorisations sous la forme d’une liste séparée de l’espace entre crochets :

Conseil :

Pour afficher les autorisations disponibles, utilisez l’aide contextuelle de l’interface cli et saisissez un point d’interrogation (?) après l’énoncé permissions :

Configuration

Cet exemple configure la classe de snmp-admin connexion. Les utilisateurs de cette classe de connexion peuvent uniquement configurer et afficher les paramètres SNMP.

Configurer les autorisations utilisateur avec des niveaux de privilèges d’accès

Procédure étape par étape

Pour configurer les privilèges d’accès pour la classe de connexion :

  1. Configurez la snmp-admin classe de connexion avec les configureindicateurs , snmpet snmp-control d’autorisation.

    Les indicateurs d’autorisation configurés fournissent à la fois une fonctionnalité de lecture (snmp) et de lecture et d’écriture (snmp-control) pour SNMP, et il s’agit du seul privilège d’accès autorisé pour cette classe de connexion. Tous les autres privilèges d’accès sont refusés.

  2. Créez les comptes d’utilisateur assigné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’équipement, saisissez commit le mode de configuration.

Vérification

Connectez-vous à l’aide d’un nom d’utilisateur attribué à la nouvelle classe de connexion et vérifiez que la configuration fonctionne correctement.

Vérifier la configuration SNMP

But

Vérifiez qu’un utilisateur de la snmp-admin classe de connexion peut configurer SNMP.

Action

En mode configuration, configurez les instructions SNMP au niveau de la [edit snmp] hiérarchie.

Sens

L’utilisateur de la snmp-admin classe de connexion peut configurer les paramètres SNMP. L’utilisateur peut configurer ces paramètres, car les indicateurs d’autorisation spécifiés pour cette classe comprennent à la fois des bits d’autorisation snmp (capacités de lecture) et de contrôle snmp (capacités de lecture et d’écriture).

Vérifier une configuration non SNMP

But

Vérifiez qu’un utilisateur de la snmp-admin classe de connexion ne peut pas modifier les instructions de configuration non SNMP.

Action

En mode configuration, essayez de configurer n’importe quelle instruction non SNMP, telle qu’une instruction dans la interfaces hiérarchie.

Sens

L’utilisateur de la snmp-admin classe login n’est pas en mesure de configurer la [edit interfaces] hiérarchie parce que les indicateurs d’autorisation spécifiés pour cette classe ne l’autorisent pas. Dans ce cas, la CLI émet un message d’erreur.

Expressions régulières pour autoriser et refuser les commandes du mode opérationnel, les déclarations de configuration et les hiérarchies

Cette rubrique contient les sections suivantes :

Comprendre les déclarations d’autorisation et de refus

Chaque hiérarchie de commandes cli et d’énoncés de configuration de niveau supérieur a un niveau de privilège d’accès associé. Chaque classe de connexion peut explicitement autoriser ou refuser l’utilisation de commandes de mode opérationnel et de mode de configuration, ainsi que de hiérarchies et d’instructions de configuration qui seraient autrement autorisées ou refusées par un niveau de privilège. Les utilisateurs peuvent exécuter uniquement les commandes et afficher et configurer uniquement les instructions pour lesquelles ils disposent de privilèges d’accès.

Les privilèges d’accès pour chaque classe de connexion sont définis par un ou plusieurs indicateurs d’autorisation spécifiés dans l’instruction permissions au niveau de la [edit system login class class-name] hiérarchie. En outre, vous pouvez autoriser ou refuser l’utilisation de commandes et de hiérarchies de configuration spécifiques en définissant des expressions régulières étendues. Vous pouvez spécifier les expressions régulières en configurant les instructions suivantes pour une classe de connexion :

  • allow-commands et deny-commands: autorisez ou refusez l’accès aux commandes du mode opérationnel et du mode de configuration.

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

    REMARQUE :

    Ces instructions effectuent des correspondances plus lentes, avec plus de flexibilité, en particulier dans la correspondance de caractères génériques. Cependant, il peut être très long d’évaluer toutes les déclarations possibles si un grand nombre d’expressions régulières ou génériques de chemin complet sont configurés, ce qui peut affecter négativement les performances.

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

REMARQUE :

Si vos configurations existantes utilisent le allow/deny-commands ou allow/deny-configuration des instructions, l’utilisation des mêmes options de configuration avec les allow/deny-commands-regexps ou allow/deny-configuration-regexps des instructions risque de ne pas produire les mêmes résultats. Les méthodes de recherche et de correspondance diffèrent dans les deux formes de ces déclarations.

L’autorisation explicite des commandes et des hiérarchies d’instructions de configuration à l’aide allow/deny-* des instructions ajoute aux autorisations que l’instruction permissions définit déjà. De même, le refus explicite des commandes et des hiérarchies d’instructions de configuration à l’aide allow/deny-* des instructions supprime les autorisations que l’instruction permissions définit déjà.

Par exemple, dans la configuration suivante, l’autorisation configure permet aux utilisateurs de la classe de connexion d’entrer en mode de configuration. En outre, l’expression allow-configuration permet aux utilisateurs de modifier la configuration au niveau de la hiérarchie et de la [edit system services] valider.

De même, dans la configuration suivante, l’utilisateur de la classe de connexion peut effectuer toutes les opérations que l’indicateur all d’autorisation permet, sauf que l’utilisateur ne peut pas afficher ou modifier la configuration au niveau de la [edit system services] hiérarchie :

Comprendre la syntaxe de l’instruction Autoriser et refuser

Vous ne pouvez configurer une instruction qu’une allow/deny-* seule fois dans chaque classe de connexion. Lorsque vous configurez une déclaration :

  • Vous pouvez configurer autant d’expressions régulières que nécessaire.

  • Les expressions régulières ne sont pas sensibles à la casse

Les allow/deny-commands déclarations sont mutuellement exclusives avec les allow/deny-commands-regexps déclarations, et les allow/deny-configuration déclarations sont mutuellement exclusives avec les allow/deny-configuration-regexps déclarations. Par exemple, vous ne pouvez pas configurer les deux allow-configuration et allow-configuration-regexps dans la même classe de connexion.

Pour définir des droits d’accès aux commandes, spécifiez des expressions régulières étendues à l’aide des allow-commands instructions et deny-commands . Enfermez chaque expression autonome complète entre parenthèses ( ) et utilisez le symbole de tuyau (| ) pour séparer les expressions. N’utilisez pas d’espaces entre les expressions régulières connectées au symbole du tuyau. L’expression complète est jointe entre deux guillemets.

Par exemple :

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

Pour définir des droits d’accès à certaines parties de la hiérarchie de configuration, spécifiez des expressions régulières étendues dans les allow-configuration instructions et deny-configuration . Enfermez l’ensemble des chemins entre parenthèses ( ) et utilisez le symbole du tuyau (|) pour séparer les expressions. N’utilisez pas d’espaces entre les expressions régulières connectées au symbole du tuyau. L’expression complète est jointe entre deux guillemets.

Par exemple :

Lorsque vous spécifiez des expressions régulières étendues à l’aide de allow/deny-commands-regexpsallow/deny-configuration-regexps ou d’instructions, enfermez chaque expression entre guillemets (« »), puis séparez les expressions à l’aide d’un espace. Enfermer plusieurs expressions entre crochets [ ]. Par exemple :

Les modificateurs tels que set, loget count ne sont pas pris en charge dans la chaîne d’expression régulière à correspondre. Si vous utilisez un modificateur, rien n’est assorti.

Configuration correcte :

Configuration incorrecte :

Compréhension de la priorité et de la correspondance de l’instruction Autoriser et refuser

Par défaut, les expressions et allow-configuration les allow-commands expressions régulières ont priorité sur deny-commands et deny-configuration les expresssions. Ainsi, si vous configurez la même commande pour les allow-commands instructions et deny-commands , alors l’opération d’autorisation prend la priorité sur l’opération de refus. De même, si vous configurez la même instruction pour les allow-configuration instructions et deny-configuration , alors l’opération d’autorisation a priorité sur l’opération de refus.

Par exemple, la configuration suivante permet à un utilisateur de la test classe de connexion d’installer un logiciel à l’aide de la request system software add commande, même si l’instruction deny-commands comprend la même commande :

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

Si les allow-commands instructions et deny-commands ont deux variantes différentes d’une commande, la correspondance la plus longue est toujours exécutée. La configuration suivante permet à un utilisateur de la test classe login d’exécuter la commit synchronize commande, mais pas la commit commande. C’est parce que commit synchronize c’est la correspondance la plus longue entre commit et commit synchronize, et elle est spécifiée pour allow-commands.

La configuration suivante permet à un utilisateur de la test classe login d’exécuter la commit commande, mais pas la commit synchronize commande. C’est parce que commit synchronize c’est la correspondance la plus longue entre commit et commit synchronize, et elle est spécifiée pour deny-commands.

Contrairement aux autres déclarations, le comportement par défaut des déclarations est que les *-regexps expressions et deny-configuration-regexps les deny-commands-regexps expressions régulières ont priorité sur allow-commands-regexps et les allow-configuration-regexps expressions. Vous pouvez configurer l’instruction regex-additive-logic au niveau de la [edit system] hiérarchie pour forcer les allow-configuration-regexps expressions régulières à prendre la priorité sur les deny-configuration-regexps déclarations. La configuration de l’instruction vous permet de refuser les hiérarchies de configuration à un niveau supérieur, puis d’autoriser l’utilisateur à accéder uniquement à des sous-hiérarchies spécifiques.

Comprendre les règles d’instruction d’autorisation et de refus

Les allow/deny-commands, allow/deny-configuration, , allow/deny-commands-regexpset allow/deny-configuration-regexps les instructions ont priorité sur les autorisations de classe de connexion. Lorsque vous configurez ces instructions, les règles suivantes s’appliquent :

  • Les expressions allow-commands et deny-commands les instructions régulières peuvent également inclure le commit, load, rollback, save, statuset les update commandes.

  • Les all bits d’autorisation de classe de connexion ont priorité sur les expressions régulières étendues lorsqu’un utilisateur émet la rollback commande avec l’indicateur d’autorisation rollback activé.

  • Les utilisateurs ne peuvent pas émettre la load override commande lorsqu’ils spécifient une expression régulière étendue. Les utilisateurs ne peuvent émettre que les mergecommandes , replaceet patch de configuration.

  • Vous pouvez utiliser le caractère générique * pour dénoter des expressions régulières. Cependant, vous devez l’utiliser dans le cadre d’une expression régulière. Vous ne pouvez pas utiliser [ * ] ou [ .* ] comme seule expression. En outre, vous ne pouvez pas configurer l’instruction allow-configuration avec une expression telle que (interfaces (description (|.*)), car cela évalue à allow-configuration .*.

Comprendre les différences pour les déclarations *-regexps

Cette section présente les différences entre les allow/deny-configuration déclarations et les allow/deny-configuration-regexps déclarations.

Les allow/deny-configuration-regexps déclarations divisent l’expression régulière en jetons et font correspondre chaque élément à chaque partie du chemin complet de la configuration spécifiée, tandis que les allow/deny-configuration déclarations correspondent à la chaîne complète. Pour allow/deny-configuration-regexps les instructions, vous configurez un ensemble de chaînes dans laquelle chaque chaîne est une expression régulière, avec des espaces entre les termes de la chaîne. Cette syntaxe offre une correspondance très rapide, mais offre moins de flexibilité. Pour spécifier des expressions génériques, vous devez configurer des caractères génériques pour chaque jeton de la chaîne délimitée par l’espace que vous souhaitez faire correspondre, ce qui rend plus difficile l’utilisation d’expressions génériques pour ces déclarations.

Par exemple :

  • Correspondance d’expression régulière avec un jeton à l’aide de regexps de configuration autorisée

    Cet exemple montre que options c’est la seule expression correspondant au premier jeton de l’instruction.

    La configuration précédente correspond aux déclarations suivantes :

    • définir la condition condition de stratégie-options dynamic-db

    • définir les options de routage route static-route statique saut suivant next-hop

    • définir les options d’événements générer un intervalle de temps d’événement eventseconds

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

    • options d’hôte du nom d’hôte système

    • options de description des interfacesinterface-name

  • Correspondance d’expression régulière avec trois jetons à l’aide de regexps de configuration autorisée

    Cet exemple montre qu’il ssh s’agit de la seule expression correspondant au troisième jeton de l’instruction.

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

    La configuration précédente correspond aux déclarations suivantes :

    • nom d’hôte système hostname-ssh

    • services système ssh

    • services système outbound-ssh

    La configuration précédente ne correspond pas à l’énoncé suivant :

    • description des interfaces interface-namessh

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

Tableau 2 : Restriction de l’accès à la configuration à l’aide des déclarations de refus-configuration et de refus-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 d’hôte système hostname-ssh

  • services système ssh

  • services système outbound-ssh

  • sécurité ssh-known-host

Bien que les allow/deny-configuration instructions soient également utiles lorsque vous souhaitez une configuration simple, elles allow/deny-configuration-regexps offrent de meilleures performances et surmontent l’ambiguïté qui existait lors de la combinaison d’expressions dans les allow/deny-configuration instructions.

Utilisation d’expressions régulières sur les serveurs d’autorisation à distance

Vous pouvez utiliser des expressions régulières étendues pour spécifier les commandes du mode opérationnel et du mode de configuration, ainsi que les instructions de configuration et les hiérarchies autorisées ou refusées pour certains utilisateurs. Vous spécifiez ces expressions régulières localement dans le allow/deny-commands, allow/deny-commands-regexpsallow/deny-configurationet allow/deny-configuration-regexps les instructions au niveau de la [edit system login class class-name] hiérarchie. Vous spécifiez ces expressions régulières à distance en spécifiant les attributs TACACS+ ou RADIUS spécifiques aux fournisseurs Juniper Networks dans la configuration de votre serveur d’autorisation. Lorsque vous configurez les paramètres d’autorisation à la fois localement et à distance, l’équipement fusionne les expressions régulières reçues lors de l’autorisation TACACS+ ou RADIUS avec toutes les expressions régulières définies sur l’équipement local.

REMARQUE :

À partir de la version 18.1 de Junos OS, les instructions et deny-commands-regexps sont prises en charge pour l’autorisation allow-commands-regexps TACACS+.

Lorsque vous spécifiez plusieurs expressions régulières dans une configuration locale à l’aide de allow-commands, deny-commandsallow-configurationou deny-configuration d’instructions, vous configurez les expressions régulières entre parenthèses et séparez-les à l’aide du symbole de tuyau. Vous joignez l’expression complète entre guillemets. Par exemple, vous pouvez spécifier plusieurs allow-commands paramètres avec la syntaxe suivante :

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 de allow-commands-regexps, deny-commands-regexpsallow-configuration-regexpsou deny-configuration-regexps d’instructions, vous configurez des expressions régulières dans des guillemets doubles et séparez-les à l’aide de l’opérateur d’espace. Vous joignez l’expression complète entre crochets. Par exemple, vous pouvez spécifier plusieurs paramètres allow-commands avec la syntaxe suivante :

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 dans laquelle vous spécifiez chaque expression individuelle sur une ligne distincte. Par exemple, la syntaxe simplifiée du serveur RADIUS est :

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

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

Tableau 3 : Exemple de configuration des autorisations locales et distantes à 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"
    }
}
REMARQUE :
  • Vous devez autoriser explicitement l’accès au mode NETCONF, que ce soit localement ou à distance, en envoyant les trois commandes suivantes : xml-mode, netconfet 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 tampon d’expressions régulières autorisée pour l’instruction allow-configuration . Si cette limite est dépassée, la configuration autorisée risque de ne pas fonctionner.

Spécifier des expressions régulières

AVERTISSEMENT :

Lorsque vous spécifiez des expressions régulières pour les commandes et les instructions de configuration, portez une attention particulière aux exemples suivants. Une expression régulière avec une syntaxe non valide peut ne pas produire les résultats souhaités, même si la configuration est validée sans aucune erreur.

Vous devez spécifier des expressions régulières pour les commandes et les instructions de configuration de la même manière que l’exécution de la commande ou de l’instruction complète. Tableau 4 répertorie les expressions régulières pour configurer les privilèges d’accès pour les [edit interfaces] hiérarchies et [edit vlans] d’instruction.

Tableau 4 : Spécifier des 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 par elle-même et nécessite la unit possibilité d’exécuter l’instruction.

En conséquence, l’expression régulière requise pour refuser la configuration doit spécifier l’ensemble set interfaces de la chaîne exécutable avec l’opérateur .* en lieu et 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 cette instruction particulière. Dans cet exemple, il désigne n’importe quel nom d’interface avec n’importe quelle valeur d’unité.

  • Spécifier uniquement 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.* .*"
    

    NB : L’expression mem.* régulière de cet exemple est utilisée lorsque plusieurs chaînes commençant par le mem mot-clé doivent être incluses dans l’expression régulière spécifiée. Lorsque l’on s’attend à ce qu’une member seule chaîne soit incluse, l’expression member .* régulière est utilisée.

[edit vlans]

La set commande pour les VLAN s’exécute 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 la vlan-id possibilité d’exécuter l’instruction.

En conséquence, l’expression régulière requise pour permettre la configuration doit spécifier l’ensemble set vlans de la chaîne exécutable avec l’opérateur .* en lieu et 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 cette instruction particulière. Dans cet exemple, il désigne n’importe quel nom de VLAN avec n’importe quel ID VLAN.

  • D’autres options valides dans la [edit vlans] hiérarchie d’instruction 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

Tableau 5 répertorie les opérateurs d’expression régulière courants que vous pouvez utiliser pour autoriser ou refuser les modes opérationnels et de configuration.

Les expressions régulières de commande implémentent les expressions régulières étendues (modernes), telles que définies dans POSIX 1003.2.

Tableau 5 : Opérateurs d’expression régulière courante

Opérateur

Correspondance

Exemple

|

Un ou plusieurs termes séparés par le tuyau. Chaque terme doit être une expression autonome complète enfermée entre parenthèses (), sans espace entre le tuyau et les parenthèses adjacentes.

[edit system login class test]
user@host# set permissions configure
user@host# set allow-commands "(ping)|(traceroute)|(show system alarms)|(show system software)"
user@host# set deny-configuration "(access)|(access-profile)|(accounting-options)|(applications)|(apply-groups)|(bridge-domains)|(chassis)|(class-of-service)"

Avec la configuration précédente, les utilisateurs assignés à la classe de connexion de test disposent d’un accès en mode opérationnel limité aux seules commandes spécifiées dans l’instruction 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ée pour désigner l’endroit où commence la commande, où il peut y avoir une certaine ambiguïté.

[edit system login class test]
user@host# set permissions interface
user@host# set permissions interface-control
user@host# set allow-commands "(^show) (log|interfaces|policer))|(^monitor)"

Avec la configuration précédente, les utilisateurs assignés à la classe de connexion de test ont accès à l’affichage et à la configuration de l’interface. L’instruction allow-commands donne accès aux commandes qui commencent par les show mots-clés et monitor .

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

$

Caractère à la fin d’une commande. Utilisé pour désigner une commande qui doit correspondre exactement jusqu’à ce point.

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

Avec la configuration précédente, les utilisateurs assignés à la classe de connexion de test peuvent afficher la configuration des interfaces en mode configuration. Les utilisateurs peuvent également consulter la configuration de l’interface avec la commande du show configuration mode opérationnel. Toutefois, l’expression régulière spécifiée dans l’instruction allow-commands restreint les utilisateurs à exécuter uniquement la commande et refuse l’accès show interfaces 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 assignés à la classe de connexion de test disposent d’autorisations utilisateur de niveau opérateur. Ces utilisateurs ont également accès à la configuration des interfaces dans la plage spécifiée de nom d’interface et de numéro d’unité (0 à 9).

( )

Un groupe de commandes indiquant une expression complète et autonome à évaluer. Le résultat est ensuite évalué dans le cadre de l’expression globale. Les parenthèses doivent être utilisées conjointement avec les opérateurs de tuyaux, comme expliqué.

[edit system login class test]
user@host# set permissions all
user@host# set allow-commands "(clear)|(configure)"
user@host# deny-commands "(mtrace)|(start)|(delete)"

Avec la configuration ci-dessus, les utilisateurs assignés à la classe de connexion test disposent d’autorisations de niveau superutilisateur et ont accès aux commandes spécifiées dans l’instruction allow-commands .

*

Zéro mandat ou plus.

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

Avec la configuration ci-dessus, les utilisateurs assignés m à la classe de connexion test dont le nom d’utilisateur commence par le nom d’utilisateur 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 assignés m à la classe de connexion test dont le nom d’utilisateur commence par le nom d’utilisateur se voient refuser l’accès à la configuration.

.

Tout caractère à l’exception d’un espace " « .

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

Avec la configuration ci-dessus, les utilisateurs assignés m à la classe de connexion test dont le nom d’utilisateur commence par le nom d’utilisateur se voient refuser l’accès à la configuration.

.*

Tout à partir du point spécifié.

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

Avec la configuration ci-dessus, les utilisateurs assignés m à la classe de connexion test dont le nom d’utilisateur commence par le nom d’utilisateur se voient refuser l’accès à la configuration.

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

REMARQUE :
  • Le *, +et les . opérations peuvent être réalisés à l’aide de .*.

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

REMARQUE :

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

Exemples d’expression régulière

Tableau 6 répertorie les expressions régulières utilisées pour autoriser les options de configuration dans deux hiérarchies de configuration,[edit system ntp server] et [edit protocols rip]par exemple pour spécifier des expressions régulières.

REMARQUE :

Tableau 6 ne fournit pas de liste complète de toutes les expressions et mots-clés réguliers pour toutes les déclarations de configuration et toutes les hiérarchies. Les expressions régulières répertoriées dans le tableau sont validées uniquement pour les [edit system ntp server] hiérarchies et [edit protocols rip] d’instruction.

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

Hiérarchie des déclarations

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

  • ip et clé du serveur

  • version

  • Préfère

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

  • IP et version du serveur

  • key

  • Préfère

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

  • ip du serveur et préférer

  • key

  • 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

  • métrique-in

  • timeout de routage

  • intervalle de mise à jour

métrique-in metric-in

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

  • taille du message

  • timeout de routage

  • intervalle de mise à jour

timeout de routage route-timeout

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

  • taille du message

  • métrique-in

  • 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

  • métrique-in

  • timeout de routage

Comment définir des privilèges d’accès avec des déclarations d’autorisation de configuration et de refus de configuration

Vous pouvez définir des privilèges d’accès pour les hiérarchies d’instructions de configuration à l’aide d’une combinaison des types d’instructions suivants :

  • indicateurs d’autorisation

  • allow-configuration et deny-configuration déclarations

Les indicateurs d’autorisation définissent les limites plus larges de ce qu’une personne ou une classe de connexion peut accéder et contrôler. Les allow-configuration instructions et deny-configuration contiennent une ou plusieurs expressions régulières qui autorisent ou refusent des hiérarchies de configuration et des déclarations spécifiques. Les allow-configuration déclarations et deny-configuration ont priorité sur les indicateurs d’autorisation et donnent à l’administrateur un contrôle plus fin sur les hiérarchies et les déclarations que l’utilisateur peut afficher et configurer.

Cette rubrique explique comment définir des privilèges d’accès à l’aide allow-configuration d’instructions et deny-configuration des instructions en montrant des exemples de configurations de classe de connexion qui utilisent ces instructions. Les exemples 1 à 3 créent des classes d’identification qui permettent aux utilisateurs d’accéder à toutes les commandes et déclarations, à l’exception de celles définies dans l’instruction deny-configuration .

Notez que le bit d’autorisation et l’indicateur d’autorisation sont utilisés indifféremment.

Exemple 1

Pour créer une classe de connexion qui permet à l’utilisateur d’exécuter toutes les commandes et de tout configurer, à l’exception des paramètres telnet :

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

Exemple 2

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

  1. Définissez les autorisations de 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, sauf les [edit system login class] niveaux hiérarchiques :[edit system services]

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

  2. Incluez la déclaration suivante 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 [edit system services] niveau hiérarchique.

Exemple 4

Pour créer une classe de connexion qui permet à l’utilisateur de disposer de privilèges de configuration complets uniquement au [edit system services] niveau hiérarchique :

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

  2. Incluez la déclaration suivante allow-configuration :

Exemple 5

Pour créer une classe de connexion qui donne à l’utilisateur des autorisations complètes pour toutes les commandes et toutes les hiérarchies de configuration, à l’exception du [edit system services] niveau hiérarchique :

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

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

Exemple : Utiliser la logique additive avec des expressions régulières pour spécifier des privilèges d’accès

Cet exemple montre comment utiliser une logique additive lorsque vous utilisez des expressions régulières pour configurer les privilèges d’accès.

Conditions préalables

Cet exemple utilise un équipement exécutant Junos OS version 16.1 ou ultérieure.

Présentation

Vous pouvez définir des expressions régulières pour contrôler qui peut apporter des modifications à la configuration et ce qu’elles peuvent changer. Ces expressions régulières indiquent des hiérarchies de configuration spécifiques auxquelles les utilisateurs d’une classe de connexion sont autorisés à accéder. Par exemple, vous pouvez définir des expressions régulières qui permettent aux utilisateurs de modifier un groupe d’instances de routage et définir des expressions régulières qui empêchent les utilisateurs d’apporter des modifications à d’autres instances de routage ou à d’autres niveaux de configuration. Vous définissez les expressions régulières en configurant les allow-configuration-regexps instructions et deny-configuration-regexps pour une classe de connexion.

Par défaut, l’instruction deny-configuration-regexps prévaut sur l’instruction allow-configuration-regexps . Si une hiérarchie de configuration apparaît dans une deny-configuration-regexps instruction pour une classe de connexion, elle n’est pas visible par les utilisateurs de cette classe, quel que soit le contenu de l’instruction allow-configuration-regexps . Si une hiérarchie de configuration n’apparaît pas dans une deny-configuration-regexps instruction, elle est visible par les utilisateurs de cette classe si elle apparaît dans une allow-configuration-regexps instruction.

Vous pouvez modifier ce comportement par défaut en activant une logique additive pour les *-configuration-regexps déclarations. Lorsque vous activez la logique d’additif, l’instruction allow-configuration-regexps a priorité sur l’instruction deny-configuration-regexps .

Ainsi, si l’instruction refuse l’accès deny-configuration-regexps à toutes les hiérarchies de configuration à un niveau donné (protocoles .*) mais que l’instruction autorise l’accès allow-configuration-regexps à une sous-hiérarchie (protocoles bgp .*), l’équipement refuse par défaut l’accès aux hiérarchies pour les utilisateurs de cette classe de connexion, car l’instruction deny-configuration-regexps prime. Toutefois, si vous activez la logique d’additif, l’équipement autorise l’accès à la sous-hiérarchie spécifiée pour les utilisateurs de cette classe de connexion, car la allow-configuration-regexps priorité est dans ce cas.

Configuration

Procédure étape par étape

Pour activer la logique additive pour permettre explicitement aux utilisateurs d’une classe d’identification donnée d’accéder à une ou plusieurs hiérarchies de configuration individuelles :

  1. Incluez l’instruction deny-configuration-regexps et refusez explicitement l’accès 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.

    Par exemple :

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

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

  5. Validez vos modifications.

    Les utilisateurs assignés à cette classe de connexion ont accès aux hiérarchies de configuration incluses dans l’instruction allow-configuration-regexps , mais n’ont pas accès aux autres hiérarchies spécifiées dans l’instruction deny-configuration-regexps .

REMARQUE :

Lorsque vous configurez l’instruction regex-additive-logic , le changement de comportement s’applique à toutes et aux allow-configuration-regexpsdeny-configuration-regexps déclarations présentes dans toutes les classes de connexion. Si vous activez la logique additive, vous devez évaluer les déclarations existantes pour tout impact et mettre à jour les expressions régulières de ces déclarations le cas échéant.

Exemples

Utiliser des expressions régulières avec la logique additive

But

Cette section fournit des exemples d’expressions régulières qui utilisent la logique additive pour vous donner des idées pour créer des configurations adaptées à votre système.

Autoriser des instances de routage spécifiques

L’exemple suivant de classe login inclut une expression régulière qui permet de configurer des instances de routage dont les noms commencent CUST-VRF-par ; par exemple, CUST-VRF-1, CUST-VRF-25, CUST-VRF-100, et ainsi de suite. L’exemple inclut également une expression régulière qui empêche la configuration de toutes les instances de routage.

Par défaut, l’instruction deny-configuration-regexps prime, et la configuration précédente empêche les utilisateurs de la classe de connexion de configurer des instances de routage, quel que soit le nom.

Toutefois, si vous configurez l’instruction suivante, l’instruction allow-configuration-regexps prime. Ainsi, les utilisateurs peuvent configurer des instances de routage dont le nom commence par CUST-VRF-, mais les utilisateurs ne peuvent pas configurer d’autres instances de routage.

Autoriser la configuration peer BGP uniquement

L’exemple de classe de connexion suivant inclut des expressions régulières qui empêchent la configuration au niveau de la [edit protocols] hiérarchie, mais autorisent la configuration des pairs BGP :

Par défaut, la configuration précédente empêche les utilisateurs de la classe de connexion d’apporter des modifications aux hiérarchies sous [edit protocols].

Toutefois, si vous configurez l’instruction suivante, les utilisateurs de la classe de connexion peuvent apporter des modifications aux pairs BGP, mais ils ne peuvent pas configurer d’autres protocoles ou déclarations BGP en dehors du niveau hiérarchique autorisé.

Vérification

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

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

  2. Attribuez la classe de connexion à un .username

  3. Connectez-vous comme username assigné avec la nouvelle classe de connexion.

  4. Essayez de configurer les niveaux hiérarchiques autorisés.

    • Vous devriez pouvoir configurer des instructions dans les niveaux hiérarchiques autorisés.

    • Les niveaux hiérarchiques refusés ne doivent pas être visibles.

    • Toutes les expressions autorisées ou refusées doivent primer sur les autorisations accordées avec l’instruction permissions .

Exemple : Configurer les autorisations utilisateur avec des privilèges d’accès pour les commandes du mode opérationnel

Cet exemple montre comment configurer des classes de connexion personnalisées et attribuer des privilèges d’accès aux commandes du mode opérationnel. Les utilisateurs de la classe login ne peuvent exécuter que les commandes auxquelles ils ont accès. Cela empêche les utilisateurs non autorisés d’exécuter des commandes sensibles qui pourraient endommager le réseau.

Conditions préalables

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

  • Un seul équipement Juniper Networks

  • Un serveur TACACS+ (ou RADIUS)

Avant de commencer, établissez une connexion TCP entre l’équipement et le serveur TACACS+. Dans le cas du serveur RADIUS, établissez une connexion UDP entre l’équipement et le serveur RADIUS.

Présentation et topologie

Figure 1 illustre une topologie simple, où le routeur R1 est un équipement Juniper Networks et dispose d’une connexion TCP établie avec un serveur TACACS+.

Figure 1 : topologie topologie

Cet exemple configure R1 avec trois classes de connexion personnalisées : Classe1, Classe2 et Classe3. Chaque classe définit les droits d’accès pour l’utilisateur en configurant l’instruction permissions et en définissant des expressions régulières étendues à l’aide des allow-commands instructions et.deny-commands

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

  • Class1: définit les privilèges d’accès pour l’utilisateur avec l’instruction allow-commands uniquement. Cette classe de connexion fournit des autorisations et des autorisations utilisateur au niveau de l’opérateur pour redémarrer l’équipement.

  • Class2: définit les privilèges d’accès pour l’utilisateur avec l’instruction deny-commands uniquement. Cette classe de connexion fournit des autorisations utilisateur de niveau opérateur et refuse l’accès aux set commandes.

  • Class3: définit les privilèges d’accès pour l’utilisateur à l’aide des allow-commands déclarations et deny-commands . Cette classe de connexion fournit des autorisations et des autorisations d’accès aux interfaces et d’affichage des informations sur l’équipement au niveau superutilisateur. Il refuse également l’accès aux edit commandes et configure .

Le routeur R1 a trois utilisateurs différents, User1, User2 et User3 assignés aux classes de connexion Class1, Class2 et Class3, respectivement .

Configuration

Configuration rapide cli

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à votre configuration réseau, copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie, puis entrez commit en mode configuration.

R1

Configurer les paramètres d’authentification du routeur R1

Procédure étape par étape

Pour configurer l’authentification R1 du routeur :

  1. Configurez l’ordre dans lequel le R1 tente d’authentifier l’utilisateur. Dans cet exemple, l’authentification du serveur TACACS+ est d’abord suivie de l’authentification du serveur RADIUS, puis du mot de passe local.

  2. Configurez le serveur TACACS+.

  3. Configurez le serveur RADIUS.

  4. Configurez les paramètres de comptabilisation R1.

Configurez les privilèges d’accès avec l’instruction allow-commands (Classe1)

Procédure étape par étape

Pour spécifier des expressions régulières à l’aide de l’instruction allow-commands :

  1. Configurez la classe de connexion Classe1 et attribuez des autorisations utilisateur de niveau opérateur.

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

  3. Configurez le compte utilisateur pour la classe de connexion Classe1.

Configurez les privilèges d’accès avec l’instruction deny-commands (Class2)

Procédure étape par étape

Pour spécifier des expressions régulières à l’aide de l’instruction deny-commands :

  1. Configurez la classe de connexion classe2 et attribuez des autorisations utilisateur de niveau 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 utilisateur pour la classe de connexion Classe2.

Configurez les privilèges d’accès avec les déclarations allow-commands et deny-commands (Classe3)

Procédure étape par étape

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

  1. Configurez la classe de connexion classe3 et attribuez des autorisations de niveau 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 utilisateur pour la classe de connexion Classe3.

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 assigné à 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 de classe 1 fonctionnent.

Action

En mode opérationnel, exécutez la show system users commande.

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

Sens

La classe de connexion Classe1 à laquelle l’utilisateur1 est assigné dispose d’autorisations utilisateur de niveau opérateur et permet aux utilisateurs de la classe d’exécuter la request system reboot commande.

Les indicateurs d’autorisation suivants sont spécifiés dans la classe de connexion opérateur prédéfinie :

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

  • network: peut accéder au réseau à l’aide du ping, ssh, telnetet traceroute des commandes.

  • reset: peut redémarrer les processus logiciels à l’aide de la restart commande.

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

  • view: peut utiliser diverses commandes pour afficher les valeurs et statistiques actuelles à l’échelle du système, des tables de routage et des valeurs et statistiques spécifiques au protocole. Impossible d’afficher la configuration secrète.

Pour la classe de connexion Classe1, en plus des autorisations utilisateur mentionnées ci-dessus, l’utilisateur1 peut exécuter la request system reboot commande. La première sortie affiche les autorisations d’affichage en tant qu’opérateur, et la seconde montre que la seule request system commande que l’utilisateur1 peut exécuter en tant qu’opérateur est la request system reboot commande.

Vérification de la configuration de classe 2

But

Vérifiez que les autorisations et les commandes autorisées pour la classe de connexion de classe 2 fonctionnent.

Action

En mode opérationnel, exécutez la ping commande.

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

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

Sens

La classe de connexion classe2 à laquelle l’utilisateur2 est assigné dispose d’autorisations utilisateur de niveau opérateur et refuse l’accès à toutes les set commandes.

Les indicateurs d’autorisation spécifiés pour la classe de connexion opérateur prédéfinie sont les mêmes que ceux spécifiés pour la classe 1.

Vérification de la configuration de classe 3

But

Vérifiez que les autorisations et les commandes autorisées pour la classe de connexion classe3 fonctionnent.

Action

En mode opérationnel, vérifiez les commandes disponibles.

Passez en mode configuration.

Sens

La classe de connexion Classe3 à laquelle l’utilisateur3 est assigné dispose d’autorisations superutilisateur (toutes), mais cette classe permet uniquement aux utilisateurs d’exécuter la configure commande. La classe refuse l’accès à toutes les autres commandes du mode opérationnel. Étant donné que les expressions régulières spécifiées dans les allow/deny-commands instructions ont priorité sur les autorisations utilisateur, l’utilisateur3 sur R1 n’a accès qu’au mode de configuration et se voit refuser l’accès à toutes les autres commandes du mode opérationnel.

Exemple : Configurer les autorisations utilisateur avec des privilèges d’accès pour les déclarations de configuration et les hiérarchies

Cet exemple montre comment configurer des classes de connexion personnalisées et attribuer des privilèges d’accès à des hiérarchies de configuration spécifiques. Les utilisateurs de la classe login peuvent afficher et modifier uniquement les déclarations de configuration et les hiérarchies auxquelles ils ont accès. Cela empêche les utilisateurs non autorisés de modifier les configurations des équipements qui pourraient endommager le réseau.

Conditions préalables

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

  • Un seul équipement Juniper Networks

  • Un serveur TACACS+ (ou RADIUS)

Avant de commencer, établissez une connexion TCP entre l’équipement et le serveur TACACS+. Dans le cas du serveur RADIUS, établissez une connexion UDP entre l’équipement et le serveur RADIUS.

Présentation et topologie

Figure 2 illustre une topologie simple, où le routeur R1 est un équipement Juniper Networks et dispose d’une connexion TCP établie avec un serveur TACACS+.

Figure 2 : topologie topologie

Cet exemple configure R1 avec deux classes de connexion personnalisées : Classe 1 et Classe2. Chaque classe définit les droits d’accès pour l’utilisateur en configurant l’instruction permissions et en définissant des expressions régulières étendues à l’aide des allow-configuration, deny-configuration, allow-configuration-regexpset deny-configuration-regexps des instructions.

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

  • Class1: définit les droits d’accès pour l’utilisateur avec les allow-configuration instructions et deny-configuration . Cette classe de connexion permet de configurer la [edit interfaces] hiérarchie uniquement et refuse tout autre accès sur l’équipement. Pour ce faire, les autorisations utilisateur incluent configure de fournir un accès à la configuration. En outre, l’instruction permet d’accéder allow-configuration à la configuration des interfaces, et l’instruction deny-configuration refuse l’accès à toutes les autres hiérarchies de configuration. L’instruction allow ayant la priorité sur l’instruction de refus, les utilisateurs assignés à la classe de connexion classe1 peuvent accéder uniquement au [edit interfaces] niveau hiérarchique.

  • Class2: définit les droits d’accès pour l’utilisateur avec les allow-configuration-regexps instructions et deny-configuration-regexps . Cette classe de connexion fournit des autorisations utilisateur de niveau superutilisateur et permet explicitement la configuration sous plusieurs niveaux hiérarchiques pour les interfaces. Il refuse également l’accès aux [edit system] niveaux et [edit protocols] hiérarchiques.

Le routeur R1 a deux utilisateurs, User1 et User2, assignés aux classes de connexion Classe1 et Classe2, respectivement.

Configuration

Configuration rapide cli

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à votre configuration réseau, copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie, puis entrez commit en mode configuration.

R1

Configurer les paramètres d’authentification du routeur R1

Procédure étape par étape

Pour configurer l’authentification R1 du routeur :

  1. Configurez l’ordre dans lequel le R1 tente d’authentifier l’utilisateur. Dans cet exemple, l’authentification du serveur TACACS+ est d’abord suivie de l’authentification du serveur RADIUS, puis du mot de passe local.

  2. Configurez le serveur TACACS+.

  3. Configurez le serveur RADIUS.

  4. Configurez les paramètres de comptabilisation R1.

Configurez les privilèges d’accès avec les déclarations d’autorisation de configuration et de refus de configuration (Classe1)

Procédure étape par étape

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

  1. Configurez la classe de connexion classe1 avec configure des autorisations.

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

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

  4. Configurez le compte utilisateur pour la classe de connexion Classe1.

Configurez les privilèges d’accès avec les déclarations allow-configuration-regexps et deny-configuration-regexps (Class2)

Procédure étape par étape

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

  1. Configurez la classe de connexion de classe2 et attribuez des autorisations 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 au 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 et [edit protocols] de la [edit system] hiérarchie.

  4. Configurez le compte utilisateur pour la classe de connexion Classe2.

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 assigné à la nouvelle classe de connexion et vérifiez que la configuration fonctionne correctement.

Vérifier la configuration de classe 1

But

Vérifiez que les autorisations autorisées dans la classe de connexion de classe 1 fonctionnent.

Action

En mode opérationnel, vérifiez les commandes disponibles.

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

Sens

L’utilisateur1 dispose configure d’autorisations utilisateur, comme indiqué dans la première sortie. En outre, en mode configuration, l’utilisateur1 a accès au niveau hiérarchique interfaces , mais uniquement à ce niveau hiérarchique, comme le montre la deuxième sortie.

Vérifier la configuration de classe 2

But

Vérifiez que la configuration de Classe2 fonctionne comme prévu.

Action

En mode configuration, accédez à la interfaces configuration.

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

Sens

L’utilisateur2 a l’autorisation de configurer des interfaces sur R1, mais il n’a pas l’autorisation d’afficher ou de modifier les [edit system] niveaux hiérarchiques [edit protocols] .

Tableau de l'historique des versions
Version
Description
18.1
À partir de la version 18.1 de Junos OS, les instructions et deny-commands-regexps sont prises en charge pour l’autorisation allow-commands-regexps TACACS+.