XenServer

Gérer les utilisateurs

La définition d’utilisateurs, de groupes, de rôles et d’autorisations vous permet de contrôler qui a accès à vos hôtes et pools XenServer et les actions qu’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 utilisateur spécial destiné à l’administration du 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. LSU ne nécessite aucun service d’authentification externe. En cas d’échec d’un service d’authentification externe, 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 les rôles RBAC aux comptes d’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 avec Active Directory (AD) section.

Authentifier les utilisateurs avec Active Directory (AD)

Si vous souhaitez avoir plusieurs comptes d’utilisateur sur un hôte ou un pool, vous devez utiliser des comptes d’utilisateur Active Directory pour l’authentification. Les comptes AD permettent aux utilisateurs 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 d’utilisateur et en attribuant des rôles à ces comptes.

Les utilisateurs Active Directory peuvent utiliser l’interface de ligne de commande xe (en passant les -u et -prisonnier de guerre ) et se connecter à l’hôte à l’aide de XenCenter. L’authentification s’effectue sur la base d’un pool de ressources.

Sujets Contrôler l’accès aux comptes utilisateurs. Un sujet dans XenServer est mappé à une entité sur 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 racine locales, puis par rapport à la liste des sujets. Pour autoriser l’accès, créez une entrée d’objet 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 êtes familier avec 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 de compte d’utilisateur :

Terme XenCenter xe CLI Terme
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 d’utilisateurs 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 se connecter à un hôte XenServer, les utilisateurs d’Active Directory doivent disposer de l’autorisation au niveau du domaine pour se connecter à l’ordinateur qui héberge le compte d’ordinateur 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. Toutefois, si vous avez modifié ce paramètre, assurez-vous que les utilisateurs auxquels vous souhaitez avoir accès à 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 Nom de connexion de bas niveau, par exemple, mondomaine\monutilisateur.

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 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 l’authentification.

  2. Le contrôleur de domaine vérifie les informations d’identification. S’ils ne sont pas valides, l’authentification échoue immédiatement.

  3. Si les informations d’identification sont valides, le contrôleur Active Directory est interrogé pour obtenir l’identificateur d’objet et l’appartenance au groupe associés aux informations d’identification.

  4. Si l’identifiant de l’objet correspond à celui stocké dans le XenServer, l’authentification réussit.

Lorsque vous joignez 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 a des relations d’approbation) peuvent se connecter au pool.

Remarque :

La mise à jour manuelle de la configuration DNS d’un fichier PIF réseau configuré 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 donc de l’authentification de l’utilisateur.

Configurer l’authentification Active Directory

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 l’hôte XenServer. Dans certaines configurations, le serveur Active Directory peut fournir le DNS lui-même. Cela peut être réalisé à l’aide de 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 ou Linux aux hôtes.

Avertissement :

Les noms d’hôte XenServer doivent être uniques tout au long du déploiement de XenServer.

Notez les points suivants :

  • 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 deuxième XenServer remplace 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 dans deux hôtes XenServer, à condition qu’ils joignent 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 d’authentification mixte ne sont pas pris en charge. Vous ne pouvez pas avoir un pool où certains hôtes du pool sont configurés pour utiliser Active Directory et d’autres non.

  • 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 réussisse, les horloges de vos hôtes XenServer doivent être synchronisées avec les horloges 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 trop d’asymétrie entre les serveurs.

Avertissement :

Les noms d’hôte ne doivent pas comporter plus de 63 caractères alphanumériques et ne doivent pas être purement numériques.

Une limitation dans les 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 noms de serveur 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é à entrer les informations d’identification sur l’hôte de jonction, tapez les informations d’identification Active Directory avec des privilèges suffisants pour ajouter des hôtes à ce domaine.

Intégration d’Active Directory

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 Veuillez 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 Modifications du mot de passe de la machine
636 UDP/TCP LDAP sur SSL
3268 TCP Recherche dans le catalogue mondial

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 de iptables, exécutez la commande suivante : iptables -nL.

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 domaines.
  • Noms d’utilisateur de domaine contenant 64 caractères ou plus.
  • Noms d’utilisateur de domaine contenant l’un des caractères spéciaux +<>”=/%@:,;\`
  • Noms de groupes de domaine contenant l’un des caractères spéciaux , ;\'

Configuration de Winbind

Configurez le comportement de Winbind à l’aide des options de configuration suivantes, qui peuvent être incluses dans le /etc/xapi.conf lime:

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

    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 diminuer 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 strong, legacy, etc. La valeur par défaut est all.

    • La valeur tout Autorise les suites de chiffrement suivantes : AES256-CTS-HMAC-SHA1-96, AES128-CTS-HMAC-SHA1-96et arcfour-hmac-md5

    • La valeur fort Autorise les suites de chiffrement suivantes : AES256-CTS-HMAC-SHA1-96 et AES128-CTS-HMAC-SHA1-96

    • La valeur héritage Autorise les suites de chiffrement suivantes : arcfour-hmac-md5

      L’option héritée n’est pas sécurisée et nous vous recommandons de ne l’utiliser que pour déboguer les problèmes.

    Pour une sécurité renforcée, nous vous recommandons d’appliquer le chiffrement AES. Procédure

    1. Assurez-vous que le contrôleur de domaine prend en charge AES256-CTS-HMAC-SHA1-96 et AES128-CTS-HMACSHA1-96.
    2. Configurer le contrôleur de domaine pour activer L’autre domaine prend en charge le chiffrement AES Kerberos 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 le winbind_kerberos_encryption_type pour utiliser la valeur fort.
    4. Redémarrez la pile d’outils.

      Ne redémarrez pas la pile d’outils lorsque HA est activé. 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.

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

À l’instar des machines clientes Windows, Winbind met automatiquement à jour le mot de passe du compte de la machine. Winbind met automatiquement à jour le mot de passe du compte de la 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 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 Ajouter/supprimer des objets informatiques ou des postes de travail privilège, 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 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-->
    
  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. Configurez manuellement l’interface de gestion pour qu’elle utilise un code 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 pour chaque 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 qui peuvent être nécessaires, garantissant ainsi une configuration cohérente dans l’ensemble du pool. Utilisez le liste-param-hôte 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 appropriés.

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

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

Authentification utilisateur

Pour permettre à un utilisateur d’accéder à votre hôte XenServer, vous devez ajouter un objet pour cet utilisateur ou un groupe dans lequel il se trouve. (Les appartenances aux groupes transitifs sont également vérifiées de la manière habituelle. Par exemple, l’ajout d’un sujet pour le groupe Un, où le groupe Un Contient le groupe B et Utilisateur 1 est membre du groupe B permettrait l’accès à Utilisateur 1.) Si vous souhaitez gérer les autorisations des utilisateurs dans Active Directory, vous pouvez créer un groupe unique auquel vous ajoutez et supprimez des utilisateurs. Vous pouvez également ajouter et supprimer des utilisateurs individuels de XenServer, ou une combinaison d’utilisateurs et de groupes, selon vos besoins d’authentification. Vous pouvez gérer la liste d’objets à 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 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 réussit, les informations de l’utilisateur sont récupérées et validées par rapport à la liste d’objets locale. L’accès est refusé en cas d’échec de l’authentification. La validation par rapport à la liste d’objets réussit si l’utilisateur ou un groupe appartenant 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 de l’administrateur de pool qui ont besoin d’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-->

Le 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 requise.

Recherchez l’identificateur de l’objet de l’utilisateur. L’identificateur 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 objets. Utilisez le liste des sujets pour trouver l’identificateur de l’objet 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’identificateur d’objet d’un utilisateur utilisateur1 dans le testad domaine, utilisez la commande suivante :

  xe subject-list other-config:subject-name='testad\user1'
<!--NeedCopy-->

Supprimez l’utilisateur à l’aide de l’icône sujet-supprimer , en passant l’identificateur 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 Résiliation 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 disposant d’autorisations 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 d’un utilisateur

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 d’objets ou d’un groupe dans la liste d’objets ne révoque pas automatiquement les sessions déjà authentifiées dont dispose 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 de manière forcée. Voir le Documentation de 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.

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 à des sessions d’utilisateurs individuels à l’aide de xe

  1. Déterminez l’identificateur d’objet dont vous souhaitez vous déconnecter de la session. Utilisez l’une ou l’autre des options liste-identifiant-sujet-de-session ou liste-sujets xe pour trouver l’identificateur du sujet. La première commande montre aux 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 liste-sujet other-config :nom-sujet=xendt\\utilisateur1. Vous aurez peut-être besoin d’une double barre oblique inverse comme indiqué en fonction de votre shell).

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

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 page Documentation de XenCenter. Vous pouvez également exécuter le 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. Reportez-vous à la documentation d’Active Directory pour plus d’informations sur la détection et la suppression de vos entrées d’hôte désactivées.

Gérer les utilisateurs