Présentation de l’authentification utilisateur
Junos OS Evolved 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 appareils 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 LAN.
Méthodes d’authentification des utilisateurs
Junos OS Evolved prend en charge trois méthodes d’authentification des utilisateurs : l’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. Ce sont des systèmes client/serveur distribués : les clients RADIUS et TACACS+ s’exécutent sur le routeur ou le commutateur, et le serveur fonctionne sur un système de réseau distant.
Vous pouvez configurer le routeur ou le commutateur pour qu’il soit un client RADIUS ou TACACS+, ou les deux. Vous pouvez également configurer les mots de passe d’authentification dans le fichier de configuration de Junos OS Evolved. 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 local pour attribuer différentes classes de connexion, et ainsi accorder différentes autorisations, aux utilisateurs 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 affectés à ce modèle. 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 modèle, le nom d’utilisateur de la 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 modèle.
Lorsque vous configurez des modèles d’utilisateur locaux et qu’un utilisateur se connecte, Junos OS Evolved 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 Evolved (local-user-name pour TACACS+ et Juniper-Local-User-Name pour RADIUS). Junos OS Evolved détermine ensuite si un nom d’utilisateur local est spécifié pour ce nom de connexion, et si c’est le cas, Junos OS Evolved affecte l’utilisateur à ce modèle d’utilisateur local. S’il n’existe pas de modèle d’utilisateur local pour l’utilisateur authentifié, l’appareil affecte l’utilisateur au modèle, s’il remote 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 Juniper-Local-User-Name pour RADIUS) et spécifiez le nom d’utilisateur défini pour le modèle d’utilisateur local. Pour configurer différents privilèges d’accès 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 pour autoriser ou refuser des commandes et des hiérarchies de configuration spécifiques pour un utilisateur.
Cet exemple configure les sales modèles et engineering utilisateur 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 sales modèle utilisateur local. Lorsque les utilisateurs de connexion Harold et Jim sont authentifiés, le routeur ou le commutateur applique le engineering modèle d’utilisateur 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 modèle d’utilisateur, qui détermine l’autorisation. Le remote compte modèle est un modèle utilisateur spécial. Par défaut, Junos OS Evolved affecte les utilisateurs authentifiés à distance au compte modèle, s’il remote est configuré, lorsque :
-
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 l’appareil local.
Pour configurer le remote compte modèle, incluez l’instruction user remote au niveau de la [edit system login] hiérarchie et spécifiez la classe de 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 remote compte modèle, vous pouvez utiliser des attributs spécifiques au fournisseur dans le fichier de configuration du serveur d’authentification pour autoriser ou 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.
Exigences
Aucune configuration spéciale au-delà de l’initialisation de l’équipement n’est requise avant de configurer cette fonctionnalité.
Vue d’ensemble
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 modèle, le nom d’utilisateur de la 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 modèle.
Par défaut, Junos OS Evolved affecte les utilisateurs authentifiés à distance au compte 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 l’appareil local.
Dans cet exemple, vous créez le remote compte modèle et définissez le nom d’utilisateur sur remote et la classe de connexion de l’utilisateur comme . operator L’appareil attribue le remote modèle aux utilisateurs 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 modèle local et définissez le nom d’utilisateur en tant qu’administrateur et la classe de connexion en tant que 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 aux utilisateurs affectés à ce modèle utilisateur.
La configuration
Créer un compte modèle distant
Procédure étape par étape
Pour créer le remote compte modèle :
-
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, entrez commit en mode 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 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, entrez commit en mode 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. Voir Authentification RADIUS.
-
Configurez un serveur TACACS+. Voir Authentification TACACS+.
-
Configurez l’ordre d’authentification du système. Voir Ordre d’authentification pour LDAPS, RADIUS, TACACS+ et Local Password.
Vérification
Vérifiez que la configuration fonctionne correctement.
Vérifiez la création des comptes modèles
Objet
Vérifiez que les comptes modèles ont été créés.
Mesures à prendre
En mode opérationnel, entrez la show system login commande.
Que sont les serveurs d’authentification à distance ?
Vous utilisez probablement déjà un serveur (ou des serveurs) d’authentification distant dans votre réseau. L’utilisation de ces serveurs est une bonne pratique, car ils vous permettent de créer un ensemble cohérent de comptes utilisateur de manière centralisée pour tous les appareils de votre réseau. La gestion des comptes d’utilisateurs 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 de base : LDAPS, RADIUS et TACACS+. Junos OS Evolved prend en charge RADIUS et TACACS+, et vous pouvez configurer Junos OS Evolved pour interroger l’un ou l’autre type de serveur d’authentification distant. L’idée derrière un serveur RADIUS ou TACACS+ est simple : chacun 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 répertoire utilisateur central pour l’authentification, l’audit 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 à l’alternative de créer des utilisateurs locaux sur chaque appareil, une tâche chronophage et sujette aux erreurs. Un système d’authentification central simplifie également l’utilisation de systèmes de mots de passe à usage unique tels que SecureID, qui offrent une protection contre le reniflage de mots de passe et les attaques par rejeu de mot 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 la nature propriétaire de TACACS+. 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+. Pour cette raison, 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 la session complète est chiffrée, mais l’autorisation et l’authentification sont effectuées séparément pour empêcher quiconque d’essayer de se frayer un chemin dans votre réseau.
-
Flexibilité : le protocole TCP (Transmission Control Protocol) est un protocole de transport plus flexible qu’UDP. Vous pouvez faire plus avec TCP sur des réseaux plus avancés. En outre, TACACS+ prend en charge davantage de protocoles d’entreprise, tels que NetBIOS.
-