Présentation de l’authentification des utilisateurs
Junos OS prend en charge différentes méthodes d’authentification que vous (l’administrateur réseau) utilisez pour contrôler l’accès des utilisateurs au réseau. Ces méthodes incluent l’authentification par mot de passe local, RADIUS et TACACS+. Vous utilisez l’une de ces méthodes d’authentification pour valider les utilisateurs et les périphériques qui tentent d’accéder au routeur ou au commutateur à l’aide de SSH et Telnet. L’authentification empêche les appareils et les utilisateurs non autorisés d’accéder à votre réseau local.
Méthodes d’authentification des utilisateurs
Junos OS prend en charge trois méthodes d’authentification des utilisateurs : authentification par mot de passe local, RADIUS et TACACS+.
Avec l’authentification par mot de passe local, vous configurez un mot de passe pour chaque utilisateur autorisé à se connecter au routeur ou au commutateur.
RADIUS et TACACS+ sont des méthodes d’authentification permettant de valider les utilisateurs qui tentent d’accéder au routeur ou au commutateur à l’aide de l’une des méthodes de connexion. Il s’agit de systèmes client/serveur distribués : les clients RADIUS et TACACS+ s’exécutent sur le routeur ou le commutateur, et le serveur s’exécute sur un système de réseau distant.
Vous pouvez configurer le routeur ou le commutateur pour qu’il soit un client RADIUS, TACACS+ ou une combinaison des deux. Vous pouvez également configurer les mots de passe d’authentification dans le fichier de configuration de Junos OS. Vous pouvez hiérarchiser les méthodes pour configurer l’ordre dans lequel le logiciel essaie les différentes méthodes d’authentification lors de la vérification de l’accès utilisateur.
Configurer des comptes modèles d’utilisateurs locaux pour l’authentification des utilisateurs
Vous utilisez des comptes de modèle d’utilisateur locaux pour attribuer différentes classes de connexion, et ainsi accorder des autorisations différentes, aux utilisateurs qui sont authentifiés via un serveur d’authentification distant. Chaque modèle peut définir un ensemble différent d’autorisations appropriées pour les utilisateurs qui lui sont affectés. Vous définissez les modèles localement sur le routeur ou le commutateur, et les serveurs d’authentification TACACS+ et RADIUS référencent les modèles. Lorsqu’un utilisateur authentifié est affecté à un compte de modèle, le nom d’utilisateur CLI est le nom de connexion, mais l’utilisateur hérite des privilèges, de la propriété du fichier et de l’ID utilisateur effectif du compte de modèle.
Lorsque vous configurez des modèles utilisateur locaux et qu’un utilisateur se connecte, Junos OS envoie une demande au serveur d’authentification pour authentifier le nom de connexion de l’utilisateur. Si l’utilisateur est authentifié, le serveur renvoie le nom d’utilisateur local à Junos OS ( local-user-name pour TACACS+ et Juniper-Local-User-Name pour RADIUS ). Junos OS détermine ensuite si un nom d’utilisateur local est spécifié pour ce nom de connexion et, dans ce cas, Junos OS affecte l’utilisateur à ce modèle d’utilisateur local. S’il n’existe pas de modèle d’utilisateur local pour l’utilisateur authentifié, le routeur ou le commutateur utilise le remote modèle par défaut, s’il est configuré.
Pour configurer un modèle d’utilisateur local, définissez le nom d’utilisateur du modèle au niveau de la [edit system login] hiérarchie. Attribuez une classe pour spécifier les privilèges que vous souhaitez accorder aux utilisateurs locaux auxquels le modèle s’applique :
[edit system login]
user local-username {
full-name "Local user account";
uid uid-value;
class class-name;
}
Pour affecter un utilisateur au modèle d’utilisateur local, configurez le serveur d’authentification à distance avec le paramètre approprié ( local-user-name pour TACACS+ et pour RADIUS) et Juniper-Local-User-Name spécifiez le nom d’utilisateur défini pour le modèle d’utilisateur local. Pour configurer des privilèges d’accès différents pour les utilisateurs qui partagent le compte de modèle d’utilisateur local, vous pouvez utiliser des attributs spécifiques au fournisseur dans le fichier de configuration du serveur d’authentification afin d’autoriser ou de refuser des commandes et des hiérarchies de configuration spécifiques pour un utilisateur.
Cet exemple configure les sales modèles et engineering user sur l’appareil local. Le fichier de configuration du serveur TACACS+ affecte ensuite les utilisateurs à des modèles spécifiques.
[edit]
system {
login {
user sales {
uid 6003;
class sales-class;
}
user engineering {
uid 6004;
class super-user;
}
}
}
Lorsque les utilisateurs Simon et Rob sont authentifiés, le routeur ou le commutateur applique le modèle d’utilisateur sales local. Lorsque les utilisateurs Harold et Jim sont authentifiés, le routeur ou le commutateur applique le modèle d’utilisateur engineering local.
user = simon {
...
service = junos-exec {
local-user-name = sales
allow-commands = "configure"
deny-commands = "shutdown"
}
}
user = rob {
...
service = junos-exec {
local-user-name = sales
allow-commands = "(request system) | (show rip neighbor)"
deny-commands = "clear"
}
}
user = harold {
...
service = junos-exec {
local-user-name = engineering
allow-commands = "monitor | help | show | ping | traceroute"
deny-commands = "configure"
}
}
user = jim {
...
service = junos-exec {
local-user-name = engineering
allow-commands = "show bgp neighbor"
deny-commands = "telnet | ssh"
}
}
Configurer des comptes modèles d’utilisateurs distants pour l’authentification des utilisateurs
L’équipement réseau peut mapper des utilisateurs authentifiés à distance à un compte d’utilisateur défini localement ou à un compte d’utilisateur modèle, qui détermine l’autorisation. Le remote compte modèle est un modèle d’utilisateur spécial. Par défaut, affecte des utilisateurs authentifiés à distance au compte de modèle, s’il est configuré, Junos OS dans les remote cas suivants :
-
L’utilisateur authentifié n’a pas de compte d’utilisateur configuré sur l’appareil local.
-
Le serveur d’authentification à distance n’affecte pas l’utilisateur à un modèle d’utilisateur local ou le modèle attribué par le serveur n’est pas configuré sur le périphérique local.
Pour configurer le compte de remote modèle, incluez l’instruction user remote au niveau de la hiérarchie et spécifiez la classe de [edit system login] connexion pour les utilisateurs affectés au remote modèle :
[edit system login]
user remote {
full-name "remote users";
uid uid-value;
class class-name;
}
Pour configurer différents privilèges d’accès pour les utilisateurs qui partagent le compte de modèle, vous pouvez utiliser des attributs spécifiques au fournisseur dans le remote fichier de configuration du serveur d’authentification afin d’autoriser ou de refuser des commandes et des hiérarchies de configuration spécifiques pour un utilisateur.
Exemple : Créer des comptes modèles
Cet exemple montre comment créer des comptes modèles.
Conditions préalables
Aucune configuration spéciale au-delà de l’initialisation de l’appareil n’est requise avant de configurer cette fonctionnalité.
Présentation
Vous pouvez créer des comptes modèles partagés par un ensemble d’utilisateurs lorsque vous utilisez l’authentification RADIUS ou TACACS+. Lorsqu’un utilisateur authentifié est affecté à un compte de modèle, le nom d’utilisateur CLI est le nom de connexion, mais l’utilisateur hérite des privilèges, de la propriété du fichier et de l’ID utilisateur effectif du compte de modèle.
Par défaut, Junos OS affecte des utilisateurs authentifiés à distance au compte de modèle dans les remote cas suivants :
-
L’utilisateur authentifié n’a pas de compte d’utilisateur configuré sur l’appareil local.
-
Le serveur d’authentification à distance n’affecte pas l’utilisateur à un modèle d’utilisateur local ou le modèle attribué par le serveur n’est pas configuré sur le périphérique local.
Dans cet exemple, vous créez le compte modèle et définissez le remote nom d’utilisateur et la classe de connexion de l’utilisateur sur remoteoperator. L’appareil attribue le remote modèle aux utilisateurs qui sont authentifiés par RADIUS ou TACACS+, mais qui n’ont pas de compte d’utilisateur local ou qui appartiennent à un autre compte de modèle local.
Vous créez ensuite un compte de modèle local et définissez le nom d’utilisateur comme admin et la classe de connexion comme superutilisateur. Vous utilisez des comptes modèles locaux lorsque vous devez affecter des utilisateurs authentifiés à distance à différentes classes de connexion. Ainsi, chaque modèle peut accorder un ensemble différent d’autorisations appropriées pour les utilisateurs affectés à ce modèle d’utilisateur.
Configuration
Créer un compte modèle de compte distant
Procédure étape par étape
Pour créer le compte modèle, remote procédez comme suit :
-
Définissez le nom d’utilisateur et la classe de connexion de l’utilisateur
remote.[edit system login] user@host# set user remote class operator
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 configuration de cet exemple pour la corriger.
[edit]
user@host# show system login
user remote {
class operator;
}
Après avoir configuré l’appareil, passez commit en mode de configuration.
Créer un compte modèle local
Procédure étape par étape
Pour créer un compte modèle local :
-
Définissez le nom d’utilisateur et la classe de connexion pour le modèle d’utilisateur.
[edit system login] user@host# set user admin class superuser
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 configuration de cet exemple pour la corriger.
[edit]
user@host# show system login
user admin {
class super-user;
}
Après avoir configuré l’appareil, passez commit en mode de configuration.
Pour configurer complètement l’authentification RADIUS ou TACACS+, vous devez configurer au moins un serveur RADIUS ou TACACS+ et spécifier un ordre d’authentification système. Pour plus d’informations, consultez les tâches suivantes :
-
Configurez un serveur RADIUS. Reportez-vous à la section Exemple : Configurer un serveur RADIUS pour l’authentification du système.
-
Configurez un serveur TACACS+. Reportez-vous à la section Exemple : Configurer un serveur TACACS+ pour l’authentification du système.
-
Configurez l’ordre d’authentification du système. Reportez-vous à la section Exemple : Configurer l’ordre d’authentification.
Qu’est-ce qu’un serveur d’authentification à distance ?
Vous utilisez probablement déjà un ou plusieurs serveurs d’authentification à distance dans votre réseau. Il est recommandé d’utiliser ces serveurs, car ils vous permettent de créer un ensemble cohérent de comptes utilisateur de manière centralisée pour tous les périphériques de votre réseau. La gestion des comptes utilisateur est beaucoup plus facile lorsque vous utilisez des serveurs d’authentification distants pour implémenter une solution d’authentification, d’autorisation et de responsabilité (AAA) dans votre réseau.
La plupart des entreprises utilisent une ou plusieurs des trois méthodes d’authentification à distance suivantes : RADIUS et TACACS+. Junos OS prend en charge les trois méthodes et vous pouvez configurer Junos OS pour interroger n’importe quel type de serveur d’authentification distant. L’idée d’un serveur RADIUS, ou TACACS+, est simple : Chacun d’eux agit comme un serveur d’authentification central que les routeurs, les commutateurs, les dispositifs de sécurité et les serveurs peuvent utiliser pour authentifier les utilisateurs lorsqu’ils tentent d’accéder à ces systèmes. Pensez aux avantages qu’offre un annuaire utilisateur central pour l’audit d’authentification et le contrôle d’accès dans un modèle client/serveur. Les méthodes d’authentification RADIUS et TACACS+ offrent des avantages comparables pour votre infrastructure réseau.
L’utilisation d’un serveur central présente de multiples avantages par rapport à la création d’utilisateurs locaux sur chaque appareil, une tâche chronophage et sujette aux erreurs. Un système d’authentification centralisé simplifie également l’utilisation de systèmes de mots de passe à usage unique tels que SecureID, qui offrent une protection contre le reniflement de mots de passe et les attaques par relecture de mots de passe. Dans de telles attaques, quelqu’un peut utiliser un mot de passe capturé pour se faire passer pour un administrateur système.
-
RADIUS—Vous devez utiliser RADIUS lorsque vos priorités sont l’interopérabilité et les performances.
-
Interopérabilité : RADIUS est plus interopérable que TACACS+, principalement en raison de sa nature propriétaire. Bien que TACACS+ prenne en charge davantage de protocoles, RADIUS est universellement pris en charge.
-
Performances : RADIUS est beaucoup plus léger sur vos routeurs et commutateurs que TACACS+. C’est pourquoi les ingénieurs réseau préfèrent généralement RADIUS à TACACS+.
-
-
TACACS+—Vous devez utiliser TACACS+ lorsque vos priorités sont la sécurité et la flexibilité.
-
Sécurité : TACACS+ est plus sécurisé que RADIUS. Non seulement l’intégralité de la session est chiffrée, mais l’autorisation et l’authentification sont effectuées séparément afin d’empêcher quiconque de tenter de s’introduire de force dans votre réseau.
-
Flexibilité : le protocole TCP (Transmission Control Protocol) est un protocole de transport plus flexible que le protocole UDP. TCP permet d’en faire plus sur les réseaux plus avancés. En outre, TACACS+ prend en charge davantage de protocoles d’entreprise, tels que NetBIOS.
-