layout: doc description: Use Active Directory to create additional users that can administer XenServer. Configure the user permissions with role-based access control.—
La définition des utilisateurs, des groupes, des rôles et des autorisations vous permet de contrôler qui a accès à vos hôtes et à vos pools XenServer et quelles actions ils peuvent effectuer.
Lorsque vous installez XenServer pour la première fois, un compte utilisateur est automatiquement ajouté à XenServer. Ce compte est le super utilisateur local (LSU), ou root, que XenServer authentifie localement.
Le LSU, ou root, est un compte d’utilisateur spécial destiné à l’administration du système et possède toutes les autorisations. Dans XenServer, le LSU est le compte par défaut lors de l’installation. XenServer authentifie le compte LSU. Le LSU ne nécessite aucun service d’authentification externe. Si un service d’authentification externe échoue, le LSU peut toujours se connecter et gérer le système. Le LSU peut toujours accéder au serveur physique XenServer via SSH.
Vous pouvez créer davantage d’utilisateurs en ajoutant les comptes Active Directory via l’onglet Utilisateurs de XenCenter ou l’interface de ligne de commande xe. Si votre environnement n’utilise pas Active Directory, vous êtes limité au compte LSU.
Remarque :
Lorsque vous créez des utilisateurs, XenServer n’attribue pas automatiquement les rôles RBAC aux comptes utilisateurs nouvellement créés. Par conséquent, ces comptes n’ont aucun accès au pool XenServer tant que vous ne leur avez pas attribué un rôle.
Ces autorisations sont accordées par le biais de rôles, comme indiqué dans la section Authentification des utilisateurs auprès d’Active Directory (AD) .
Si vous souhaitez disposer de plusieurs comptes utilisateur sur un hôte ou un pool, vous devez utiliser les comptes utilisateur Active Directory pour l’authentification. Les comptes AD permettent aux utilisateurs de XenServer de se connecter à un pool à l’aide de leurs informations d’identification de domaine Windows.
Remarque :
Vous pouvez activer la liaison de canal LDAP et la signature LDAP sur vos contrôleurs de domaine AD. Pour plus d’informations, consultez Avis de sécurité Microsoft.
Vous pouvez configurer différents niveaux d’accès pour des utilisateurs spécifiques en activant l’authentification Active Directory, en ajoutant des comptes utilisateurs et en attribuant des rôles à ces comptes.
Les utilisateurs Active Directory peuvent utiliser l’interface de ligne de commande xe (en transmettant les arguments -u et -pw appropriés) et également se connecter à l’hôte à l’aide de XenCenter. L’authentification est effectuée par pool de ressources.
Les sujets contrôlent l’accès aux comptes d’utilisateurs. Un sujet dans XenServer est mappé à une entité de votre serveur Active Directory (un utilisateur ou un groupe). Lorsque vous activez l’authentification externe, XenServer vérifie les informations d’identification utilisées pour créer une session par rapport aux informations d’identification root locales, puis par rapport à la liste des sujets. Pour autoriser l’accès, créez un sujet pour la personne ou le groupe auquel vous souhaitez accorder l’accès. Vous pouvez utiliser XenCenter ou l’interface de ligne de commande xe pour créer une entrée d’objet.
Si vous connaissez XenCenter, notez que l’interface de ligne de commande xe utilise une terminologie légèrement différente pour faire référence à Active Directory et aux fonctionnalités des comptes utilisateur :
| Terme XenCenter | Exe CLI Term |
|---|---|
| Utilisateurs, Ajouter des utilisateurs | Sujets, Ajouter des sujets |
Même si XenServer est basé sur Linux, XenServer vous permet d’utiliser des comptes Active Directory pour les comptes utilisateur XenServer. Pour ce faire, il transmet les informations d’identification Active Directory au contrôleur de domaine Active Directory.
Lorsque vous ajoutez Active Directory à XenServer, les utilisateurs et les groupes Active Directory deviennent des sujets XenServer. Les sujets sont appelés utilisateurs dans XenCenter. Les utilisateurs/groupes sont authentifiés à l’aide d’Active Directory lors de l’ouverture de session lorsque vous enregistrez un sujet auprès de XenServer. Les utilisateurs et les groupes n’ont pas besoin de qualifier leur nom d’utilisateur à l’aide d’un nom de domaine.
Pour qualifier un nom d’utilisateur, vous devez saisir le nom d’utilisateur au format Nom de connexion de bas niveau, par exemple, mydomain\myuser.
Remarque :
Par défaut, si vous n’avez pas qualifié le nom d’utilisateur, XenCenter tente de connecter les utilisateurs aux serveurs d’authentification AD à l’aide du domaine auquel il est joint. L’exception à cette règle est le compte LSU, que XenCenter authentifie toujours localement (c’est-à-dire sur le XenServer) en premier.
Le processus d’authentification externe fonctionne comme suit :
Les informations d’identification fournies lors de la connexion à un hôte sont transmises au contrôleur de domaine Active Directory pour authentification.
Le contrôleur de domaine vérifie les informations d’identification. S’ils ne sont pas valides, l’authentification échoue immédiatement.
Si les informations d’identification sont valides, le contrôleur Active Directory est interrogé pour obtenir l’identifiant du sujet et l’appartenance au groupe associés aux informations d’identification.
Si l’identifiant du sujet correspond à celui stocké dans le XenServer, l’authentification réussit.
Lorsque vous rejoignez un domaine, vous activez l’authentification Active Directory pour le pool. Toutefois, lorsqu’un pool rejoint un domaine, seuls les utilisateurs de ce domaine (ou d’un domaine avec lequel il entretient des relations d’approbation) peuvent se connecter au pool.
Remarque :
La mise à jour manuelle de la configuration DNS d’un PIF réseau configuré par DHCP n’est pas prise en charge et peut entraîner l’échec ou l’arrêt du fonctionnement de l’intégration d’AD, et donc de l’authentification de l’utilisateur.
XenServer prend en charge l’utilisation de serveurs Active Directory sous Windows 2008 ou version ultérieure.
Pour authentifier Active Directory pour les hôtes XenServer, vous devez utiliser le même serveur DNS pour le serveur Active Directory (configuré pour permettre l’interopérabilité) et pour l’hôte XenServer. Dans certaines configurations, le serveur Active Directory peut fournir le DNS lui-même. Cela peut être réalisé soit en utilisant le DHCP pour fournir l’adresse IP et une liste de serveurs DNS à l’hôte XenServer. Vous pouvez également définir les valeurs dans les objets PIF ou utiliser le programme d’installation lorsqu’une configuration statique manuelle est utilisée.
Nous vous recommandons d’activer DHCP pour attribuer des noms d’hôte. N’attribuez pas les noms d’hôte localhost ni linux aux hôtes.
Avertissement :
Les noms d’hôte XenServer doivent être uniques tout au long du déploiement de XenServer.
Tenez compte de ce qui suit :
XenServer étiquette son entrée AD sur la base de données AD à l’aide de son nom d’hôte. Si deux hôtes XenServer portant le même nom d’hôte sont joints au même domaine AD, le second XenServer remplace l’entrée AD du premier XenServer. L’écrasement se produit indépendamment du fait que les hôtes appartiennent au même pool ou à des pools différents. Cela peut empêcher l’authentification AD sur le premier XenServer de fonctionner.
Vous pouvez utiliser le même nom d’hôte sur deux hôtes XenServer, à condition qu’ils rejoignent des domaines AD différents.
Les hôtes XenServer peuvent se trouver dans des fuseaux horaires différents, car c’est l’heure UTC qui est comparée. Pour vous assurer que la synchronisation est correcte, vous pouvez utiliser les mêmes serveurs NTP pour votre pool XenServer et le serveur Active Directory.
Les pools à authentification mixte ne sont pas pris en charge. Vous ne pouvez pas avoir un pool dans lequel certains hôtes du pool sont configurés pour utiliser Active Directory alors que d’autres ne le sont pas.
L’intégration XenServer Active Directory utilise le protocole Kerberos pour communiquer avec les serveurs Active Directory. Par conséquent, XenServer ne prend pas en charge la communication avec les serveurs Active Directory qui n’utilisent pas Kerberos.
Pour que l’authentification externe à l’aide d’Active Directory soit réussie, les horloges de vos hôtes XenServer doivent être synchronisées avec celles de votre serveur Active Directory. Lorsque XenServer rejoint le domaine Active Directory, la synchronisation est vérifiée et l’authentification échoue en cas d’asymétrie trop importante entre les serveurs.
Avertissement :
Les noms d’hôtes ne doivent pas comporter plus de 63 caractères alphanumériques et ne doivent pas être purement numériques.
Une limitation des clients SSH récents signifie que SSH ne fonctionne pas pour les noms d’utilisateur contenant l’un des caractères suivants :
{}[]|&. Assurez-vous que vos noms d’utilisateur et les noms de serveurs Active Directory ne contiennent aucun de ces caractères.
Lorsque vous ajoutez un hôte à un pool après avoir activé l’authentification Active Directory, vous êtes invité à configurer Active Directory sur l’hôte qui rejoint le pool. Lorsque vous êtes invité à saisir les informations d’identification de l’hôte participant, saisissez les informations d’identification Active Directory avec des privilèges suffisants pour ajouter des hôtes à ce domaine.
Assurez-vous que les ports de pare-feu suivants sont ouverts pour le trafic sortant afin que XenServer puisse accéder aux contrôleurs de domaine.
| Port | Protocole | Utiliser |
|---|---|---|
| 53 | UDP/TCP | DNS |
| 88 | UDP/TCP | Kerberos 5 |
| 123 | UDP | NTP |
| 137 | UDP | Service de noms NetBIOS |
| 139 | TCP | Session NetBIOS (SMB) |
| 389 | UDP/TCP | LDAP |
| 445 | TCP | SMB sur TCP |
| 464 | UDP/TCP | Changements de mot de passe |
| 636 | UDP/TCP | LDAP sur SSL |
| 3268 | TCP | Recherche dans le catalogue global |
Pour plus d’informations, consultez Ports de communication utilisés par XenServer.
Remarques :
- Pour afficher les règles de pare-feu sur un ordinateur Linux à l’aide d’ iptables, exécutez la commande suivante :
iptables -nL.
XenServer utilise Winbind pour authentifier les utilisateurs Active Directory (AD) auprès du serveur AD et pour chiffrer les communications avec le serveur AD.
Winbind ne prend pas en charge les scénarios suivants :
Configurez le comportement de Winbind avec les options de configuration suivantes, qui peuvent être incluses dans le /etc/xapi.conf fichier :
winbind_machine_pwd_timeout: La valeur de cette option définit la fréquence, en secondes, à laquelle le mot de passe de la machine est modifié pour cet hôte XenServer. Définissez une valeur sous la forme d’un entier.
La valeur par défaut est 1209600 secondes (14 jours). Nous vous recommandons de conserver la valeur par défaut ou de ne pas la réduire en dessous de la valeur par défaut afin de garantir suffisamment de temps pour synchroniser le nouveau mot de passe entre les contrôleurs de domaine.
winbind_kerberos_encryption_type: Les valeurs de cette option sont fortes, héritées et toutes. La valeur par défaut est all.
La valeur all autorise les suites de chiffrement suivantes : aes256-cts-hmac-sha1-96aes128-cts-hmac-sha1-96, et arcfour-hmac-md5
La valeur strong autorise les suites de chiffrement suivantes : aes256-cts-hmac-sha1-96 et aes128-cts-hmac-sha1-96
La valeur legacy autorise les suites de chiffrement suivantes : arcfour-hmac-md5
L’ancienne option n’est pas sécurisée et nous vous recommandons de ne l’utiliser que pour résoudre les problèmes.
Pour améliorer la sécurité, nous vous recommandons d’appliquer le chiffrement AES. Procédure
aes256-cts-hmac-sha1-96 et aes128-cts-hmacsha1-96.Configurez le contrôleur de domaine pour activer L’autre domaine prend en charge le chiffrement Kerberos AES dans l’approbation de domaine.
Pour plus d’informations, voir Méthode 3 : configurer la confiance pour prendre en charge le chiffrement AES128 et AES 256 au lieu du chiffrement RC4 dans la documentation Microsoft.
winbind_kerberos_encryption_type pour utiliser la valeur strong.Redémarrez la pile d’outils.
Ne redémarrez pas la pile d’outils lorsque la haute disponibilité est activée. Si possible, désactivez temporairement HA avant de redémarrer la pile d’outils.
winbind_cache_time: Winbind met en cache certaines informations de domaine localement. La valeur de cette option définit le nombre de secondes entre chaque actualisation du cache. Le délai par défaut est de 60 secondes.
Après avoir mis à jour l’une de ces options de configuration, redémarrez la pile d’outils.
Comme pour les ordinateurs clients Windows, Winbind met automatiquement à jour le mot de passe du compte de la machine. Winbind met automatiquement à jour le mot de passe du compte machine tous les 14 jours ou comme spécifié par l’option winbind_machine_pwd_timeoutde configuration.
L’authentification externe utilisant Active Directory peut être configurée à l’aide de XenCenter ou de l’interface de ligne de commande à l’aide de la commande suivante.
xe pool-enable-external-auth auth-type=AD \
service-name=full-qualified-domain \
config:user=username \
config:pass=password
<!--NeedCopy-->
L’utilisateur spécifié doit disposer de Add/remove computer objects or workstations privilèges, ce qui est le privilège par défaut pour les administrateurs de domaine.
Si vous n’utilisez pas le protocole DHCP sur le réseau utilisé par Active Directory et vos hôtes XenServer, utilisez les approches suivantes pour configurer votre DNS :
Configurez l’ordre de recherche du suffixe DNS de votre domaine pour résoudre les entrées non FQDN :
xe pif-param-set uuid=pif_uuid_in_the_dns_subnetwork \
"other-config:domain=suffix1.com suffix2.com suffix3.com"
<!--NeedCopy-->
Configurez le serveur DNS à utiliser sur vos hôtes XenServer :
xe pif-reconfigure-ip mode=static dns=dnshost ip=ip \
gateway=gateway netmask=netmask uuid=uuid
<!--NeedCopy-->
Configurez manuellement l’interface de gestion pour utiliser un PIF qui se trouve sur le même réseau que votre serveur DNS :
xe host-management-reconfigure pif-uuid=pif_in_the_dns_subnetwork
<!--NeedCopy-->
Remarque :
L’authentification externe est une propriété par hôte. Toutefois, nous vous recommandons d’activer et de désactiver l’authentification externe par pool. Un paramètre par pool permet à XenServer de gérer les défaillances qui se produisent lors de l’activation de l’authentification sur un hôte particulier. XenServer annule également toutes les modifications nécessaires, garantissant ainsi une configuration cohérente dans l’ensemble du pool. Utilisez la commande
host-param-listpour inspecter les propriétés d’un hôte et déterminer l’état de l’authentification externe en vérifiant les valeurs des champs appropriés.
Utilisez XenCenter pour désactiver l’authentification Active Directory ou la commande xe suivante :
xe pool-disable-external-auth
<!--NeedCopy-->
Pour autoriser un utilisateur à accéder à votre hôte XenServer, vous devez ajouter un sujet pour cet utilisateur ou un groupe auquel il appartient. (Les appartenances aux groupes transitifs sont également vérifiées normalement. Par exemple, l’ajout d’un sujet pour un groupe A, où le groupe A contient le groupe B et user 1 est membre du groupe B autoriserait l’accès à user 1.) Si vous souhaitez gérer les autorisations des utilisateurs dans Active Directory, vous pouvez créer un groupe unique auquel vous pouvez ensuite ajouter et supprimer des utilisateurs vers/depuis. Vous pouvez également ajouter et supprimer des utilisateurs individuels de XenServer, ou une combinaison d’utilisateurs et de groupes selon vos exigences d’authentification. Vous pouvez gérer la liste des sujets à partir de XenCenter ou à l’aide de l’interface de ligne de commande comme décrit dans la section suivante.
Lors de l’authentification d’un utilisateur, les informations d’identification sont d’abord vérifiées par rapport au compte racine local, ce qui vous permet de récupérer un système dont le serveur AD est en panne. Si les informations d’identification (nom d’utilisateur et mot de passe) ne correspondent pas, une demande d’authentification est envoyée au serveur AD. Si l’authentification est réussie, les informations de l’utilisateur sont récupérées et validées par rapport à la liste des sujets locaux. L’accès est refusé en cas d’échec de l’authentification. La validation par rapport à la liste d’objets aboutit si l’utilisateur ou un groupe faisant partie de l’appartenance au groupe transitif de l’utilisateur figure dans la liste d’objets.
Remarque :
Lorsque vous utilisez des groupes Active Directory pour accorder l’accès aux utilisateurs Administrateur de pool qui ont besoin d’un accès SSH hôte, la taille du groupe AD ne doit pas dépasser 500 utilisateurs.
Pour ajouter un sujet AD à XenServer :
xe subject-add subject-name=entity_name
<!--NeedCopy-->
Le nom_entité est le nom de l’utilisateur ou du groupe auquel vous souhaitez accorder l’accès. Vous pouvez inclure le domaine de l’entité (par exemple, « xendt \ user1 » par opposition à « utilisateur1 ») bien que le comportement soit le même sauf si une désambiguïsation est requise.
Trouvez l’identifiant du sujet de l’utilisateur. L’identifiant est l’utilisateur ou le groupe contenant l’utilisateur. La suppression d’un groupe supprime l’accès à tous les utilisateurs de ce groupe, à condition qu’ils ne soient pas également spécifiés dans la liste des sujets. Utilisez la commande subject list pour rechercher l’identifiant du sujet de l’utilisateur. :
xe subject-list
<!--NeedCopy-->
Cette commande renvoie la liste de tous les utilisateurs.
Pour appliquer un filtre à la liste, par exemple pour rechercher l’identificateur de sujet d’un utilisateur user1 du domaine testad, utilisez la commande suivante :
xe subject-list other-config:subject-name='testad\user1'
<!--NeedCopy-->
Supprimez l’utilisateur à l’aide de la commande subject-remove, en transmettant l’identifiant de sujet que vous avez appris à l’étape précédente :
xe subject-remove subject-uuid=subject_uuid
<!--NeedCopy-->
Vous pouvez mettre fin à n’importe quelle session en cours que cet utilisateur a déjà authentifiée. Pour plus d’informations, consultez Arrêt de toutes les sessions authentifiées à l’aide de xe et Arrêt de sessions utilisateur individuelles à l’aide de xe dans la section suivante. Si vous ne mettez pas fin aux sessions, les utilisateurs dont les autorisations ont été révoquées peuvent continuer à accéder au système jusqu’à ce qu’ils se déconnectent.
Exécutez la commande suivante pour identifier la liste des utilisateurs et des groupes autorisés à accéder à votre hôte ou pool XenServer :
xe subject-list
<!--NeedCopy-->
Lorsqu’un utilisateur est authentifié, il peut accéder à l’hôte jusqu’à ce qu’il mette fin à sa session ou jusqu’à ce qu’un autre utilisateur mette fin à sa session. La suppression d’un utilisateur de la liste des sujets, ou sa suppression d’un groupe de la liste d’objets, ne révoque pas automatiquement les sessions déjà authentifiées de l’utilisateur. Les utilisateurs peuvent continuer à accéder au pool à l’aide de XenCenter ou d’autres sessions d’API qu’ils ont déjà créées. XenCenter et l’interface de ligne de commande permettent de mettre fin à des sessions individuelles ou à toutes les sessions actives avec force. Consultez la documentation XenCenter pour plus d’informations sur les procédures utilisant XenCenter, ou la section suivante pour les procédures utilisant l’interface de ligne de commande.
Exécutez la commande CLI suivante pour mettre fin à toutes les sessions authentifiées utilisant xe :
xe session-subject-identifier-logout-all
<!--NeedCopy-->
Déterminez l’identifiant du sujet dont vous souhaitez vous déconnecter de la session. Utilisez les commandes xe session-subject-identifier-list ou subject-list pour rechercher l’identificateur du sujet. La première commande affiche les utilisateurs qui ont des sessions. La deuxième commande affiche tous les utilisateurs mais peut être filtrée. Par exemple, en utilisant une commande comme xe subject-list other-config:subject-name=xendt\\user1. Vous aurez peut-être besoin d’une double barre oblique inverse (selon votre shell).
Utilisez la commande session-subject-logout en passant l’identificateur de sujet que vous avez déterminé à l’étape précédente en tant que paramètre, par exemple :
xe session-subject-identifier-logout subject-identifier=subject_id
<!--NeedCopy-->
Avertissement :
Lorsque vous quittez le domaine, tous les utilisateurs authentifiés auprès du pool ou de l’hôte avec des informations d’identification Active Directory sont déconnectés.
Utilisez XenCenter pour quitter un domaine AD. Pour plus d’informations, consultez la documentation XenCenter. Exécutez alternativement la commande pool-disable-external-auth, en spécifiant l’UUID du pool si nécessaire.
Remarque :
Le fait de quitter le domaine ne supprime pas les objets hôtes de la base de données AD. Consultez la documentation Active Directory pour savoir comment détecter et supprimer vos entrées d’hôte désactivées.