Gérer les utilisateurs

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 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 l’utilisateur super local (LSU), ou root, que XenServer authentifie localement.

Le LSU, ou root, est un compte utilisateur spécial destiné à l’administration système et dispose 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 d’autres 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 de rôles RBAC aux comptes utilisateur nouvellement créés. Par conséquent, ces comptes n’ont aucun accès au pool XenServer tant que vous ne leur avez pas attribué de rôle.

Ces autorisations sont accordées via des rôles, comme indiqué dans la section Authentification des utilisateurs avec Active Directory (AD).

Authentifier les utilisateurs avec Active Directory (AD)

Si vous souhaitez avoir plusieurs comptes utilisateur sur un hôte ou un pool, vous devez utiliser des comptes utilisateur Active Directory pour l’authentification. Les comptes AD permettent aux utilisateurs de XenServer de se connecter à un pool en utilisant 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 Microsoft Security Advisory ADV190023.

Vous pouvez configurer différents niveaux d’accès pour des utilisateurs spécifiques en activant l’authentification Active Directory, en ajoutant des comptes utilisateur et en attribuant des rôles à ces comptes.

Les utilisateurs d’Active Directory peuvent utiliser l’interface de ligne de commande xe (en passant 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 utilisateur. Un sujet dans XenServer correspond à une entité sur votre serveur Active Directory (soit un utilisateur, soit 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 une entrée de 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 de sujet.

Si vous êtes familiarisé avec XenCenter, notez que l’interface de ligne de commande xe utilise une terminologie légèrement différente pour désigner les fonctionnalités d’Active Directory et de comptes utilisateur :

Bien que XenServer soit 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 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 la connexion lorsque vous enregistrez un sujet avec XenServer. Les utilisateurs et les groupes n’ont pas besoin de qualifier leur nom d’utilisateur en utilisant un nom de domaine.

Pour se connecter à un hôte XenServer, les utilisateurs Active Directory doivent avoir l’autorisation au niveau du domaine de se connecter à l’ordinateur qui héberge le compte machine de XenServer. Par défaut, dans un domaine Windows Server 2019, tous les utilisateurs sont autorisés à se connecter à n’importe quel ordinateur du domaine. Cependant, si vous avez modifié ce paramètre, assurez-vous que les utilisateurs que vous souhaitez autoriser à accéder à un hôte XenServer sont autorisés à se connecter au niveau du domaine.

Pour qualifier un nom d’utilisateur, vous devez taper le nom d’utilisateur au format de nom de connexion de niveau inférieur (Down-Level log on Name), 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 en utilisant le domaine auquel il est joint. L’exception à cela 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 :

1. Les informations d’identification fournies lors de la connexion à un hôte sont transmises au contrôleur de domaine Active Directory pour authentification.

2. Le contrôleur de domaine vérifie les informations d’identification. Si elles sont invalides, l’authentification échoue immédiatement.

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

4. 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. Cependant, lorsqu’un pool rejoint un domaine, seuls les utilisateurs de ce domaine (ou d’un domaine avec lequel il a des relations de confiance) peuvent se connecter au pool.

Remarque :

La mise à jour manuelle de la configuration DNS d’une interface PIF réseau configurée par DHCP n’est pas prise en charge et peut entraîner l’échec ou l’arrêt du fonctionnement de l’intégration AD, et par conséquent de l’authentification des utilisateurs.

Configurer l’authentification Active Directory

XenServer prend en charge les serveurs Active Directory exécutant Windows Server 2016 ou version ultérieure. Pour sécuriser la connexion à vos contrôleurs de domaine, vous pouvez configurer LDAPS, comme décrit dans LDAP sécurisé (LDAPS).

Remarque :

XenServer 9 ne prend pas en charge les suites de chiffrement AD héritées telles que RC4_HMAC_MD5, DES_CBC_MD5 et DES_CBC_CRC. Vous devez vous assurer que votre serveur AD prend en charge au moins l’une des suites AES128_HMAC_SHA1 ou AES256_HMAC_SHA1.

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 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 DHCP pour fournir l’adresse IP et une liste de serveurs DNS à l’hôte XenServer. Alternativement, vous pouvez définir les valeurs dans les objets PIF ou utiliser l’installateur lorsqu’une configuration statique manuelle est utilisée.

Nous recommandons d’activer le DHCP pour attribuer les noms d’hôte. N’attribuez pas les noms d’hôte localhost ou linux aux hôtes.

Avertissement :

Les noms d’hôte XenServer doivent être uniques dans l’ensemble du déploiement XenServer.

Notez ce qui suit :

• XenServer étiquette son entrée AD dans la base de données AD en utilisant son nom d’hôte. Si deux hôtes XenServer avec le même nom d’hôte sont joints au même domaine AD, le second XenServer écrase l’entrée AD du premier XenServer. L’écrasement se produit que les hôtes appartiennent au même pool ou à des pools différents. Cela peut entraîner l’arrêt du fonctionnement de l’authentification AD sur le premier XenServer.

  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 garantir une synchronisation 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 où certains hôtes sont configurés pour utiliser Active Directory et d’autres non.

• L’intégration de 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 réussisse, 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 s’il y a un décalage trop important entre les serveurs.

Avertissement :

Les noms d’hôte ne doivent pas être purement numériques. Étant donné que XenServer s’enregistre dans Active Directory en utilisant le nom NetBIOS de l’hôte, le nom d’hôte ne doit pas dépasser 15 caractères (caractères alphanumériques et tirets, ne commençant ni ne se terminant par un tiret).

Une limitation des clients SSH récents signifie que SSH ne fonctionne pas pour les noms d’utilisateur qui contiennent l’un des caractères suivants : {}[]|&. Assurez-vous que vos noms d’utilisateur et les noms de vos 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 rejoignant le pool. Lorsque vous êtes invité à saisir les informations d’identification sur l’hôte rejoignant, saisissez les informations d’identification Active Directory avec des privilèges suffisants pour ajouter des hôtes à ce domaine.

Intégration Active Directory

Assurez-vous que les ports suivants sont ouverts pour les connexions sortantes de XenServer vers les contrôleurs de domaine Active Directory.

Pour plus d’informations, consultez Ports de communication utilisés par XenServer.

Remarque :

Si les utilisateurs d’un domaine approuvé doivent se connecter à XenServer, assurez-vous que les ports précédents sont également ouverts pour les connexions sortantes de XenServer vers les contrôleurs de domaine du domaine approuvé.

Winbind

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 :

• Espace au début ou à la fin d’un nom d’utilisateur de domaine ou de groupe de domaine.
• Noms d’utilisateur de domaine contenant 64 caractères ou plus.
• Noms d’utilisateur de domaine qui incluent l’un des caractères spéciaux +<>”=/%@:,;\`
• Noms de groupe de domaine qui incluent l’un des caractères spéciaux ,;\`

Configuration de Winbind

Configurez le comportement de Winbind avec les options de configuration suivantes, qui peuvent être incluses dans le fichier /etc/xapi.conf :

• winbind_machine_pwd_timeout : La valeur de cette option définit la fréquence, en secondes, de rotation du mot de passe machine pour cet hôte XenServer. Définissez une valeur entière.

  La valeur par défaut est de 1209600 secondes (14 jours). Nous vous recommandons de conserver la valeur par défaut ou de ne pas la réduire en dessous de cette valeur afin de garantir un temps suffisant pour synchroniser le nouveau mot de passe entre les contrôleurs de domaine.

• winbind_kerberos_encryption_type : Les valeurs pour cette option sont strong, legacy et all. La valeur par défaut est strong.

  • La valeur all autorise les suites de chiffrement suivantes : aes256-cts-hmac-sha1-96, aes128-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 la suite de chiffrement suivante : arcfour-hmac-md5

    L’option héritée est non sécurisée et nous vous recommandons de l’utiliser uniquement pour déboguer des problèmes.

  Pour une sécurité améliorée, nous vous recommandons d’appliquer le chiffrement AES. Pour ce faire,

  1. Assurez-vous que le contrôleur de domaine prend en charge aes256-cts-hmac-sha1-96 et aes128-cts-hmacsha1-96.

  2. 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, consultez Méthode 3 : Configurer l’approbation pour prendre en charge le chiffrement AES128 et AES 256 au lieu du chiffrement RC4 dans la documentation Microsoft.

  3. Mettez à jour l’option winbind_kerberos_encryption_type pour utiliser la valeur strong.

  4. Redémarrez le toolstack.

     Ne redémarrez pas le toolstack tant que la haute disponibilité est activée. Si possible, désactivez temporairement la haute disponibilité avant de redémarrer le toolstack.

  Remarque :

  Sous Windows Server 2016, l’attribut msDS-SupportedEncryptionTypes est défini par défaut sur RC4 uniquement. Définissez les types de chiffrement AES sur tous les utilisateurs existants et réinitialisez leurs mots de passe afin que le contrôleur de domaine régénère les clés Kerberos AES.

• winbind_set_machine_account_kerberos_encryption_type : Les valeurs pour cette option sont true et false. La valeur par défaut est false.

  • La valeur true définit msDS-SupportedEncryptionTypes sur strong sur l’objet ordinateur Active Directory pour l’hôte XenServer.

  • La valeur false ne configure pas msDS-SupportedEncryptionTypes sur l’objet ordinateur Active Directory pour l’hôte XenServer.

• 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. La valeur par défaut est 60 secondes.

Après avoir mis à jour l’une de ces options de configuration, redémarrez la pile d’outils.

Comment XenServer gère-t-il le mot de passe du compte machine pour l’intégration AD ?

De manière similaire aux machines clientes Windows, Winbind met automatiquement à jour le mot de passe du compte machine. Winbind met automatiquement à jour le mot de passe du compte machine tous les 14 jours ou comme spécifié par l’option de configuration winbind_machine_pwd_timeout.

Activer l’authentification externe sur un pool

L’authentification externe à l’aide d’Active Directory peut être configurée à l’aide de XenCenter ou de la CLI à l’aide de la commande suivante.

xe pool-enable-external-auth auth-type=AD \
  service-name=fully-qualified-domain \
  config:user=username \
  config:pass=password
<!--NeedCopy-->

L’utilisateur spécifié doit disposer du privilège Add/remove computer objects or workstations, ce qui est la valeur par défaut pour les administrateurs de domaine.

Si vous n’utilisez pas DHCP sur le réseau utilisé par Active Directory et vos hôtes XenServer, utilisez les approches suivantes pour configurer votre DNS :

1. Configurez l’ordre de recherche du suffixe DNS de votre domaine pour la résolution des 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-->
   

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

3. Définissez manuellement l’interface de gestion pour qu’elle utilise 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. Cependant, 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 échecs qui se produisent lors de l’activation de l’authentification sur un hôte particulier. XenServer annule également toutes les modifications qui pourraient être nécessaires, garantissant une configuration cohérente sur l’ensemble du pool. Utilisez la commande host-param-list pour 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 pertinents.

Utilisez XenCenter pour désactiver l’authentification Active Directory, ou la commande xe suivante :

xe pool-disable-external-auth
<!--NeedCopy-->

Activer la mise en cache de l’authentification AD

L’infrastructure AD de Windows contient des délais intrinsèques lors de la réplication d’informations sur les utilisateurs, telles que bloqué/débloqué, mot de passe et d’autres champs, lors de la réplication entre différents sites AD. Cela peut entraîner une très longue durée d’authentification AD, en particulier lors d’opérations à grande échelle dans des déploiements AD mondiaux. L’activation de la mise en cache de l’authentification permet au système de mémoriser les décisions d’authentification pendant une durée limitée, ce qui contribue à accélérer la connexion lorsque l’authentification externe Active Directory (AD) est lente. Cette fonctionnalité est désactivée par défaut.

Pour activer la mise en cache de l’authentification AD :

xe pool-param-set uuid=<pool-uuid> ext-auth-cache-enabled=true
<!--NeedCopy-->

Par défaut, les décisions d’authentification sont mémorisées pendant 300 secondes. Cela peut être ajusté :

xe pool-param-set uuid=<pool-uuid> ext-auth-cache-expiry=<seconds>
<!--NeedCopy-->

Pour désactiver la mise en cache de l’authentification AD :

xe pool-param-set uuid=<pool-uuid> ext-auth-cache-enabled=false
<!--NeedCopy-->

LDAP sécurisé (LDAPS)

Par défaut, XenServer sécurise la connexion à vos contrôleurs de domaine Active Directory en signant et en scellant le trafic LDAP. Vous pouvez en outre protéger ce trafic avec LDAPS (LDAP sur SSL/TLS, sur le port 636), qui encapsule le trafic d’annuaire dans un tunnel TLS. XenServer valide le tunnel par rapport aux certificats d’autorité de certification (CA) approuvés que vous importez dans le pool.

Remarque :

XenServer valide la chaîne de certificats du contrôleur de domaine uniquement par rapport aux certificats d’autorité de certification (CA) importés. Les certificats feuilles ou auto-signés (non-CA) ne sont pas pris en charge pour LDAPS. Vous devez importer au moins un certificat CA avant d’activer LDAPS, sinon l’activation de l’authentification externe échouera.

Préparer le certificat CA

LDAPS doit être activé sur vos contrôleurs de domaine, et vous devez fournir le certificat CA qui a signé les certificats des contrôleurs de domaine. Pour préparer les certificats, reportez-vous à la documentation Microsoft suivante :

• (Facultatif) Si vous n’utilisez pas déjà une autorité de certification publique ou d’entreprise, vous pouvez en configurer une. Pour plus d’informations, consultez Installer l’autorité de certification.
• Pour activer LDAPS sur le contrôleur de domaine, consultez Configurer les certificats pour LDAP sur SSL et Activer le protocole LDAP (Lightweight Directory Access Protocol) sur SSL (Secure Sockets Layer).
• Pour exporter le certificat d’autorité de certification public (sans la clé privée) au format PEM (Base-64), consultez certutil ou Export-Certificate. Le fichier exporté doit avoir une extension .pem pour être importé dans XenServer.

Importer le certificat d’autorité de certification

Importez le certificat d’autorité de certification qui a signé le certificat de serveur du contrôleur de domaine pour LDAPS, balisé pour LDAPS :

xe pool-install-trusted-certificate uuid=<pool-uuid> purpose=ldaps ca=true filename=<path-to-ca.pem>
<!--NeedCopy-->

Où :

• purpose=ldaps balise le certificat pour LDAPS.
• ca=true indique qu’il s’agit d’un certificat d’autorité de certification qui vérifie une chaîne, plutôt qu’un certificat feuille épinglé.
• filename est le chemin d’accès au certificat d’autorité de certification, au format PEM, sur la machine qui exécute la commande xe.

Si les certificats des contrôleurs de domaine ont été émis par une autorité de certification intermédiaire, importez plutôt l’autorité de certification intermédiaire (le certificat racine est utile à avoir).

Activer ou désactiver LDAPS

Pour activer LDAPS lorsque vous activez l’authentification externe, ajoutez config:ldaps=true à la commande pool-enable-external-auth :

xe pool-enable-external-auth auth-type=AD \
  service-name=fully-qualified-domain \
  config:user=username \
  config:pass=password \
  config:ldaps=true
<!--NeedCopy-->

Pour activer ou désactiver LDAPS sur un pool qui a déjà rejoint le domaine, utilisez la commande pool-external-auth-set-ldaps :

xe pool-external-auth-set-ldaps uuid=<pool-uuid> ldaps=true
<!--NeedCopy-->

xe pool-external-auth-set-ldaps uuid=<pool-uuid> ldaps=false
<!--NeedCopy-->

La modification est appliquée à chaque hôte du pool et vérifiée par rapport au domaine. En cas d’échec, la modification est automatiquement annulée sur tous les hôtes.

Pour lister les certificats balisés pour LDAPS :

xe certificate-list purpose=ldaps
<!--NeedCopy-->

Utiliser une chaîne d’autorités de certification pour plusieurs contrôleurs de domaine

Lorsqu’un pool s’authentifie via LDAPS, XenServer peut se connecter à n’importe quel contrôleur de domaine du domaine, et le contrôleur de domaine qu’il utilise peut varier entre les opérations. Chaque contrôleur de domaine présente son propre certificat de serveur pour LDAPS, que XenServer valide par rapport aux certificats d’autorité de certification que vous avez importés. Si le certificat d’un contrôleur de domaine a été signé par une autorité de certification que vous n’avez pas importée, XenServer peut rencontrer des échecs intermittents.

Suivez ces recommandations :

• Émettez le certificat de serveur de chaque contrôleur de domaine pour LDAPS à partir de la même autorité de certification racine, et importez les certificats racines dans XenServer avec purpose=ldaps comme certificat de confiance.
• Si votre environnement utilise un domaine de jonction et un domaine de confiance signés par différentes autorités de certification, importez tous les certificats d’autorité de certification pour tous ces domaines.

Authentification de l’utilisateur

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 de groupe transitives sont également vérifiées de manière normale. Par exemple, l’ajout d’un sujet pour le groupe A, où le groupe A contient le groupe B et user 1 est membre du groupe B permettrait l’accès à user 1.) Si vous souhaitez gérer les autorisations des utilisateurs dans Active Directory, vous pouvez créer un seul groupe auquel vous ajoutez et supprimez ensuite des utilisateurs. Alternativement, vous pouvez 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 depuis XenCenter ou en utilisant la CLI 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 root local, ce qui vous permet de récupérer un système dont le serveur AD a échoué. 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é si l’authentification échoue. La validation par rapport à la liste des sujets réussit si l’utilisateur ou un groupe dans l’appartenance de groupe transitive de l’utilisateur se trouve dans la liste des sujets.

Remarque :

Lorsque vous utilisez des groupes Active Directory pour accorder l’accès aux utilisateurs Administrateur de pool qui nécessitent un accès SSH à l’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-->

L’entity_name 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 à ‘user1’), bien que le comportement soit le même, sauf si une désambiguïsation est nécessaire.

Recherchez l’identifiant de 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 trouver l’identifiant de sujet de l’utilisateur. :

xe subject-list
<!--NeedCopy-->

Cette commande renvoie une liste de tous les utilisateurs.

Pour appliquer un filtre à la liste, par exemple pour trouver l’identifiant de sujet d’un utilisateur user1 dans le 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 à toute session en cours que cet utilisateur a déjà authentifiée. Pour plus d’informations, consultez Mettre fin à toutes les sessions authentifiées à l’aide de xe et Mettre fin aux 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-->

Supprimer l’accès pour un utilisateur

Lorsqu’un utilisateur est authentifié, il peut accéder à l’hôte jusqu’à ce qu’il mette fin à sa session, ou qu’un autre utilisateur mette fin à sa session. La suppression d’un utilisateur de la liste des sujets, ou sa suppression d’un groupe dans la liste des sujets, 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 API qu’ils ont déjà créées. XenCenter et la CLI fournissent des fonctionnalités pour mettre fin individuellement aux sessions, ou à toutes les sessions actives de force. Consultez la documentation XenCenter pour plus d’informations sur les procédures utilisant XenCenter, ou la section suivante pour les procédures utilisant la CLI.

Mettre fin à toutes les sessions authentifiées à l’aide de xe

Exécutez la commande CLI suivante pour mettre fin à toutes les sessions authentifiées à l’aide de xe :

xe session-subject-identifier-logout-all
<!--NeedCopy-->

Mettre fin aux sessions utilisateur individuelles à l’aide de xe

1. Déterminez l’identifiant de sujet dont vous souhaitez déconnecter la session. Utilisez les commandes xe session-subject-identifier-list ou subject-list pour trouver l’identifiant de 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 pourriez avoir besoin d’une double barre oblique inverse comme indiqué, selon votre shell).

2. Utilisez la commande session-subject-logout, en passant l’identifiant de sujet que vous avez déterminé à l’étape précédente comme paramètre, par exemple :

   xe session-subject-identifier-logout subject-identifier=subject_id
   <!--NeedCopy-->
   

Quitter un domaine AD

Avertissement :

Lorsque vous quittez le domaine, tous les utilisateurs qui se sont 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. Vous pouvez également exécuter la commande pool-disable-external-auth, en spécifiant l’UUID du pool si nécessaire.

Remarque :

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.