Administrar usuarios

La definición de usuarios, grupos, roles y permisos le permite controlar quién tiene acceso a sus hosts y pools de XenServer® y qué acciones pueden realizar.

Cuando instala XenServer por primera vez, se agrega automáticamente una cuenta de usuario a XenServer. Esta cuenta es el superusuario local (LSU) o root, que XenServer autentica localmente.

El LSU, o root, es una cuenta de usuario especial destinada a la administración del sistema y tiene todos los permisos. En XenServer, el LSU es la cuenta predeterminada en la instalación. XenServer autentica la cuenta LSU. LSU no requiere ningún servicio de autenticación externo. Si un servicio de autenticación externo falla, el LSU aún puede iniciar sesión y administrar el sistema. El LSU siempre puede acceder al servidor físico de XenServer a través de SSH.

Puede crear más usuarios agregando las cuentas de Active Directory a través de la pestaña Usuarios de XenCenter o la CLI de xe. Si su entorno no utiliza Active Directory, está limitado a la cuenta LSU.

Nota:

Cuando crea usuarios, XenServer no asigna automáticamente roles RBAC a las cuentas de usuario recién creadas. Por lo tanto, estas cuentas no tienen acceso al pool de XenServer hasta que les asigne un rol.

Estos permisos se otorgan a través de roles, como se explica en la sección Autenticación de usuarios con Active Directory (AD).

Autenticar usuarios con Active Directory (AD)

Si desea tener varias cuentas de usuario en un host o un pool, debe usar cuentas de usuario de Active Directory para la autenticación. Las cuentas de AD permiten a los usuarios de XenServer iniciar sesión en un pool utilizando sus credenciales de dominio de Windows.

Nota:

Puede habilitar el enlace de canal LDAP y la firma LDAP en sus controladores de dominio de AD. Para obtener más información, consulte Microsoft Security Advisory ADV190023.

Puede configurar diferentes niveles de acceso para usuarios específicos habilitando la autenticación de Active Directory, agregando cuentas de usuario y asignando roles a esas cuentas.

Los usuarios de Active Directory pueden usar la CLI de xe (pasando los argumentos -u y -pw apropiados) y también conectarse al host usando XenCenter. La autenticación se realiza por cada pool de recursos.

Los sujetos controlan el acceso a las cuentas de usuario. Un sujeto en XenServer se asigna a una entidad en su servidor de Active Directory (ya sea un usuario o un grupo). Cuando habilita la autenticación externa, XenServer verifica las credenciales utilizadas para crear una sesión con las credenciales raíz locales y luego con la lista de sujetos. Para permitir el acceso, cree una entrada de sujeto para la persona o grupo al que desea otorgar acceso. Puede usar XenCenter o la CLI de xe para crear una entrada de sujeto.

Si está familiarizado con XenCenter, tenga en cuenta que la CLI de xe utiliza una terminología ligeramente diferente para referirse a las características de Active Directory y las cuentas de usuario:

Aunque XenServer se basa en Linux, XenServer le permite usar cuentas de Active Directory para las cuentas de usuario de XenServer. Para ello, pasa las credenciales de Active Directory al controlador de dominio de Active Directory.

Cuando añade Active Directory a XenServer, los usuarios y grupos de Active Directory se convierten en sujetos de XenServer. Los sujetos se denominan usuarios en XenCenter. Los usuarios/grupos se autentican mediante Active Directory al iniciar sesión cuando se registra un sujeto en XenServer. Los usuarios y grupos no necesitan calificar su nombre de usuario con un nombre de dominio.

Para iniciar sesión en un host de XenServer, los usuarios de Active Directory deben tener permiso a nivel de dominio para iniciar sesión en el equipo que aloja la cuenta de máquina de XenServer. De forma predeterminada, en un dominio de Windows Server 2019, todos los usuarios tienen permiso para iniciar sesión en cualquier equipo del dominio. Sin embargo, si ha cambiado esta configuración, asegúrese de que los usuarios a los que desea dar acceso a un host de XenServer tengan permiso para iniciar sesión a nivel de dominio.

Para calificar un nombre de usuario, debe escribir el nombre de usuario en formato de nombre de inicio de sesión de nivel inferior (Down-Level log on Name), por ejemplo, mydomain\myuser.

Nota:

De forma predeterminada, si no calificó el nombre de usuario, XenCenter intenta iniciar sesión de los usuarios en los servidores de autenticación de AD utilizando el dominio al que está unido. La excepción a esto es la cuenta LSU, que XenCenter siempre autentica localmente (es decir, en el XenServer) primero.

El proceso de autenticación externa funciona de la siguiente manera:

1. Las credenciales proporcionadas al conectarse a un host se pasan al controlador de dominio de Active Directory para su autenticación.

2. El controlador de dominio comprueba las credenciales. Si no son válidas, la autenticación falla inmediatamente.

3. Si las credenciales son válidas, se consulta al controlador de Active Directory para obtener el identificador de sujeto y la pertenencia a grupos asociados con las credenciales.

4. Si el identificador de sujeto coincide con el almacenado en XenServer, la autenticación se realiza correctamente.

Cuando se une a un dominio, habilita la autenticación de Active Directory para el grupo. Sin embargo, cuando un grupo se une a un dominio, solo los usuarios de ese dominio (o un dominio con el que tiene relaciones de confianza) pueden conectarse al grupo.

Nota:

La actualización manual de la configuración DNS de un PIF de red configurado con DHCP no es compatible y puede provocar que la integración de AD y, por lo tanto, la autenticación de usuario, falle o deje de funcionar.

Configurar la autenticación de Active Directory

XenServer admite servidores de Active Directory que se ejecutan en Windows Server 2016 o posterior. Para proteger la conexión a sus controladores de dominio, puede configurar LDAPS, como se describe en LDAP seguro (LDAPS).

Nota:

XenServer 9 no admite conjuntos de cifrado de AD heredados como RC4_HMAC_MD5, DES_CBC_MD5 y DES_CBC_CRC. Debe asegurarse de que su servidor AD admita al menos uno de AES128_HMAC_SHA1 o AES256_HMAC_SHA1

Para autenticar Active Directory para los hosts de XenServer, debe usar el mismo servidor DNS tanto para el servidor de Active Directory (configurado para permitir la interoperabilidad) como para el host de XenServer. En algunas configuraciones, el servidor de Active Directory puede proporcionar el DNS por sí mismo. Esto se puede lograr utilizando DHCP para proporcionar la dirección IP y una lista de servidores DNS al host de XenServer. Alternativamente, puede establecer los valores en los objetos PIF o usar el instalador cuando se utiliza una configuración estática manual.

Recomendamos habilitar DHCP para asignar nombres de host. No asigne los nombres de host localhost o linux a los hosts.

Advertencia:

Los nombres de host de XenServer deben ser únicos en toda la implementación de XenServer.

Tenga en cuenta lo siguiente:

• XenServer etiqueta su entrada de AD en la base de datos de AD usando su nombre de host. Si dos hosts de XenServer con el mismo nombre de host se unen al mismo dominio de AD, el segundo XenServer sobrescribe la entrada de AD del primer XenServer. La sobrescritura ocurre independientemente de si los hosts pertenecen al mismo grupo o a grupos diferentes. Esto puede hacer que la autenticación de AD en el primer XenServer deje de funcionar.

  Puede usar el mismo nombre de host en dos hosts de XenServer, siempre que se unan a diferentes dominios de AD.

• Los hosts de XenServer pueden estar en diferentes zonas horarias, porque es la hora UTC la que se compara. Para asegurar que la sincronización sea correcta, puede usar los mismos servidores NTP para su pool de XenServer y el servidor de Active Directory.

• Los pools de autenticación mixta no son compatibles. No puede tener un pool donde algunos hosts estén configurados para usar Active Directory y otros no.

• La integración de XenServer Active Directory utiliza el protocolo Kerberos para comunicarse con los servidores de Active Directory. Por lo tanto, XenServer no admite la comunicación con servidores de Active Directory que no utilicen Kerberos.

• Para que la autenticación externa mediante Active Directory sea exitosa, los relojes de sus hosts de XenServer deben estar sincronizados con los relojes de su servidor de Active Directory. Cuando XenServer se une al dominio de Active Directory, se comprueba la sincronización y la autenticación falla si hay demasiada desviación entre los servidores.

Advertencia:

Los nombres de host no deben ser puramente numéricos. Dado que XenServer se registra en Active Directory utilizando el nombre NetBIOS del host, el nombre de host no debe tener más de 15 caracteres (caracteres alfanuméricos y guiones, sin empezar ni terminar con un guion).

Una limitación en los clientes SSH recientes significa que SSH no funciona para nombres de usuario que contengan cualquiera de los siguientes caracteres: {}[]|&. Asegúrese de que sus nombres de usuario y los nombres de los servidores de Active Directory no contengan ninguno de estos caracteres.

Cuando añade un host a un pool después de habilitar la autenticación de Active Directory, se le pedirá que configure Active Directory en el host que se une al pool. Cuando se le soliciten las credenciales en el host que se une, escriba las credenciales de Active Directory con privilegios suficientes para añadir hosts a ese dominio.

Integración de Active Directory

Asegúrese de que los siguientes puertos estén abiertos para las conexiones salientes de XenServer a los controladores de dominio de Active Directory.

Para obtener más información, consulte Puertos de comunicación utilizados por XenServer.

Nota:

Si los usuarios de un dominio de confianza necesitan iniciar sesión en XenServer, asegúrese de que los puertos anteriores también estén abiertos para las conexiones salientes de XenServer a los controladores de dominio del dominio de confianza.

Winbind

XenServer utiliza Winbind para autenticar usuarios de Active Directory (AD) con el servidor AD y para cifrar las comunicaciones con el servidor AD.

Winbind no admite los siguientes escenarios:

• Espacio al principio o al final de un nombre de usuario de dominio o de grupo de dominio.
• Nombres de usuario de dominio que contengan 64 caracteres o más.
• Nombres de usuario de dominio que incluyan cualquiera de los caracteres especiales +<>”=/%@:,;\`
• Nombres de grupo de dominio que incluyan cualquiera de los caracteres especiales ,;\`

Configuración de Winbind

Configure el comportamiento de Winbind con las siguientes opciones de configuración, que se pueden incluir en el archivo /etc/xapi.conf:

• winbind_machine_pwd_timeout: El valor de esta opción define la frecuencia, en segundos, con la que se rota la contraseña de la máquina para este host de XenServer. Defina un valor como un número entero.

  El valor predeterminado es 1209600 segundos (14 días). Recomendamos que mantenga el valor predeterminado o que no lo disminuya por debajo del valor predeterminado para garantizar tiempo suficiente para sincronizar la nueva contraseña entre los controladores de dominio.

• winbind_kerberos_encryption_type: Los valores para esta opción son strong, legacy y all. El valor predeterminado es strong.

  • El valor all permite los siguientes conjuntos de cifrado: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96 y arcfour-hmac-md5

  • El valor strong permite los siguientes conjuntos de cifrado: aes256-cts-hmac-sha1-96 y aes128-cts-hmac-sha1-96

  • El valor legacy permite los siguientes conjuntos de cifrado: arcfour-hmac-md5

    La opción heredada es insegura y recomendamos que solo la utilice para depurar problemas.

  Para mejorar la seguridad, recomendamos que aplique el cifrado AES. Para ello,

  1. Asegúrese de que el controlador de dominio admita aes256-cts-hmac-sha1-96 y aes128-cts-hmacsha1-96.

  2. Configure el controlador de dominio para habilitar El otro dominio admite el cifrado Kerberos AES en la confianza de dominio.

     Para obtener más información, consulte Método 3: Configure la confianza para admitir el cifrado AES128 y AES 256 en lugar del cifrado RC4 en la documentación de Microsoft.

  3. Actualice la opción winbind_kerberos_encryption_type para usar el valor strong.

  4. Reinicie el toolstack.

     No reinicie el toolstack mientras HA esté habilitado. Si es posible, deshabilite temporalmente HA antes de reiniciar el toolstack.

  Nota:

  En Windows Server 2016, el atributo msDS-SupportedEncryptionTypes solo acepta RC4 de forma predeterminada. Establezca los tipos de cifrado AES en todos los usuarios existentes y restablezca sus contraseñas para que el controlador de dominio regenere las claves AES de Kerberos.

• winbind_set_machine_account_kerberos_encryption_type: Los valores para esta opción son true y false. El valor predeterminado es false.

  • El valor true establece msDS-SupportedEncryptionTypes en strong en el objeto de equipo de Active Directory para el host de XenServer.

  • El valor false no configura msDS-SupportedEncryptionTypes en el objeto de equipo de Active Directory para el host de XenServer.

• winbind_cache_time: Winbind almacena en caché parte de la información del dominio localmente. El valor de esta opción define el número de segundos entre cada actualización de la caché. El valor predeterminado es 60 segundos.

Después de actualizar cualquiera de estas opciones de configuración, reinicie el toolstack.

¿Cómo gestiona XenServer la contraseña de la cuenta de máquina para la integración de AD?

De forma similar a las máquinas cliente de Windows, Winbind actualiza automáticamente la contraseña de la cuenta de máquina. Winbind actualiza automáticamente la contraseña de la cuenta de máquina cada 14 días o según lo especificado por la opción de configuración winbind_machine_pwd_timeout.

Habilitar la autenticación externa en un grupo

La autenticación externa mediante Active Directory se puede configurar utilizando XenCenter o la CLI con el siguiente comando.

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

El usuario especificado debe tener el privilegio Add/remove computer objects or workstations, que es el predeterminado para los administradores de dominio.

Si no está utilizando DHCP en la red utilizada por Active Directory y sus hosts de XenServer, utilice los siguientes enfoques para configurar su DNS:

1. Configure el orden de búsqueda del sufijo DNS de su dominio para resolver entradas no FQDN:

   xe pif-param-set uuid=pif_uuid_in_the_dns_subnetwork \
      "other-config:domain=suffix1.com suffix2.com suffix3.com"
   <!--NeedCopy-->
   

2. Configure el servidor DNS que se utilizará en sus hosts de XenServer:

   xe pif-reconfigure-ip mode=static dns=dnshost ip=ip \
     gateway=gateway netmask=netmask uuid=uuid
   <!--NeedCopy-->
   

3. Establezca manualmente la interfaz de administración para usar un PIF que esté en la misma red que su servidor DNS:

   xe host-management-reconfigure pif-uuid=pif_in_the_dns_subnetwork
   <!--NeedCopy-->
   

Nota:

La autenticación externa es una propiedad por host. Sin embargo, recomendamos que habilite y deshabilite la autenticación externa por grupo. Una configuración por grupo permite a XenServer gestionar los fallos que se producen al habilitar la autenticación en un host particular. XenServer también revierte cualquier cambio que pueda ser necesario, asegurando una configuración consistente en todo el grupo. Utilice el comando host-param-list para inspeccionar las propiedades de un host y determinar el estado de la autenticación externa comprobando los valores de los campos relevantes.

Utilice XenCenter para deshabilitar la autenticación de Active Directory, o el siguiente comando xe:

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

Habilitar el almacenamiento en caché de la autenticación de AD

La infraestructura de AD de Windows contiene retrasos intrínsecos al replicar información sobre usuarios, como bloqueado/desbloqueado, contraseña y otros campos durante la replicación entre diferentes sitios de AD. Esto puede hacer que la autenticación de AD tarde mucho tiempo, especialmente cuando se opera a escala en implementaciones globales de AD. Habilitar el almacenamiento en caché de la autenticación permite que el sistema recuerde las decisiones de autenticación durante un tiempo limitado, lo que ayuda a acelerar el inicio de sesión cuando la autenticación externa de Active Directory (AD) es lenta. Esta función está deshabilitada de forma predeterminada.

Para habilitar el almacenamiento en caché de la autenticación de AD:

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

De forma predeterminada, las decisiones de autenticación se recuerdan durante 300 segundos. Esto se puede ajustar:

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

Para deshabilitar el almacenamiento en caché de la autenticación de AD:

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

LDAP seguro (LDAPS)

De forma predeterminada, XenServer protege la conexión a sus controladores de dominio de Active Directory firmando y sellando el tráfico LDAP. Además, puede proteger este tráfico con LDAPS (LDAP sobre SSL/TLS, en el puerto 636), que envuelve el tráfico del directorio en un túnel TLS. XenServer valida el túnel contra certificados de CA de confianza que usted importa al grupo.

Nota:

XenServer valida la cadena de certificados del controlador de dominio solo contra certificados de CA importados. Los certificados hoja o autofirmados (que no son de CA) no son compatibles con LDAPS. Debe importar al menos un certificado de CA antes de habilitar LDAPS; de lo contrario, la habilitación de la autenticación externa fallará.

Preparar el certificado de CA

LDAPS debe estar habilitado en sus controladores de dominio, y debe proporcionar el certificado de CA que firmó los certificados de los controladores de dominio. Para preparar los certificados, consulte la siguiente documentación de Microsoft:

• (Opcional) Si aún no utiliza una entidad de certificación pública o empresarial, puede configurar una. Para obtener más información, consulte Instalar la entidad de certificación.
• Para habilitar LDAPS en el controlador de dominio, consulte Configurar certificados para LDAP a través de SSL y Habilitar el Protocolo ligero de acceso a directorios (LDAP) a través de la capa de sockets seguros (SSL).
• Para exportar el certificado de CA público (sin la clave privada) en formato PEM (Base-64), consulte certutil o Export-Certificate. El archivo exportado debe tener una extensión .pem para poder importarlo en XenServer.

Importar el certificado de CA

Importe el certificado de CA que firmó el certificado de servidor del controlador de dominio para LDAPS, etiquetado para LDAPS:

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

Donde:

• purpose=ldaps etiqueta el certificado para LDAPS.
• ca=true indica que este es un certificado de CA que verifica una cadena, en lugar de un certificado hoja anclado.
• filename es la ruta al certificado de CA, en formato PEM, en la máquina que ejecuta el comando xe.

Si los certificados de los controladores de dominio se emitieron a través de una CA intermedia, importe la CA intermedia en su lugar (el certificado raíz es bueno tenerlo).

Habilitar o deshabilitar LDAPS

Para habilitar LDAPS al habilitar la autenticación externa, agregue config:ldaps=true al comando 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-->

Para activar o desactivar LDAPS en un grupo que ya se ha unido al dominio, utilice el comando 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-->

El cambio se aplica a todos los hosts del grupo y se verifica con el dominio. Si falla, el cambio se revierte automáticamente en todos los hosts.

Para listar los certificados etiquetados para LDAPS:

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

Usar una cadena de CA para varios controladores de dominio

Cuando un grupo se autentica a través de LDAPS, XenServer puede conectarse a cualquiera de los controladores de dominio del dominio, y el controlador de dominio que utiliza puede variar entre operaciones. Cada controlador de dominio presenta su propio certificado de servidor para LDAPS, que XenServer valida con los certificados de CA que usted importó. Si el certificado de un controlador de dominio fue firmado por una CA que usted no importó, XenServer puede sufrir fallos intermitentes.

Siga estas recomendaciones:

• Emita el certificado de servidor de cada controlador de dominio para LDAPS desde la misma CA raíz e importe los certificados raíz a XenServer con purpose=ldaps como certificado de confianza.
• Si su entorno utiliza un dominio de unión y un dominio de confianza firmados por diferentes CA, importe todos los certificados de CA para todos esos dominios.

Autenticación de usuario

Para permitir que un usuario acceda a su host XenServer, debe agregar un sujeto para ese usuario o un grupo al que pertenezca. (Las pertenencias a grupos transitivas también se comprueban de la forma habitual. Por ejemplo, agregar un sujeto para el grupo A, donde el grupo A contiene el grupo B y user 1 es miembro del grupo B, permitiría el acceso a user 1.) Si desea administrar los permisos de usuario en Active Directory, puede crear un único grupo al que luego agregue y elimine usuarios. Alternativamente, puede agregar y eliminar usuarios individuales de XenServer, o una combinación de usuarios y grupos según sea apropiado para sus requisitos de autenticación. Puede administrar la lista de sujetos desde XenCenter o utilizando la CLI como se describe en la siguiente sección.

Al autenticar un usuario, las credenciales se comprueban primero con la cuenta raíz local, lo que le permite recuperar un sistema cuyo servidor AD ha fallado. Si las credenciales (nombre de usuario y contraseña) no coinciden, se realiza una solicitud de autenticación al servidor AD. Si la autenticación es correcta, la información del usuario se recupera y se valida con la lista de sujetos local. Se deniega el acceso si la autenticación falla. La validación con la lista de sujetos se realiza correctamente si el usuario o un grupo en la pertenencia a grupos transitiva del usuario está en la lista de sujetos.

Nota:

Cuando se utilizan grupos de Active Directory para conceder acceso a usuarios administradores de grupos que requieren acceso SSH al host, el tamaño del grupo de AD no debe superar los 500 usuarios.

Para agregar un sujeto de AD a XenServer:

xe subject-add subject-name=entity_name
<!--NeedCopy-->

El entity_name es el nombre del usuario o grupo al que desea conceder acceso. Puede incluir el dominio de la entidad (por ejemplo, ‘xendt\user1’ en lugar de ‘user1’), aunque el comportamiento es el mismo a menos que se requiera una desambiguación.

Busque el identificador de sujeto del usuario. El identificador es el usuario o el grupo que contiene al usuario. La eliminación de un grupo elimina el acceso a todos los usuarios de ese grupo, siempre que no estén también especificados en la lista de sujetos. Utilice el comando subject list para buscar el identificador de sujeto del usuario. :

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

Este comando devuelve una lista de todos los usuarios.

Para aplicar un filtro a la lista, por ejemplo, para encontrar el identificador de sujeto de un usuario user1 en el dominio testad, utilice el siguiente comando:

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

Elimine el usuario usando el comando subject-remove, pasando el identificador de sujeto que aprendió en el paso anterior:

xe subject-remove subject-uuid=subject_uuid
<!--NeedCopy-->

Puede finalizar cualquier sesión actual que este usuario ya haya autenticado. Para obtener más información, consulte Finalización de todas las sesiones autenticadas mediante xe y Finalización de sesiones de usuario individuales mediante xe en la siguiente sección. Si no finaliza las sesiones, los usuarios con permisos revocados pueden seguir accediendo al sistema hasta que cierren la sesión.

Ejecute el siguiente comando para identificar la lista de usuarios y grupos con permiso para acceder a su host o pool de XenServer:

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

Eliminar el acceso de un usuario

Cuando un usuario está autenticado, puede acceder al host hasta que finalice su sesión, o hasta que otro usuario finalice su sesión. Eliminar un usuario de la lista de sujetos, o eliminarlo de un grupo en la lista de sujetos, no revoca automáticamente ninguna sesión ya autenticada que tenga el usuario. Los usuarios pueden seguir accediendo al pool utilizando XenCenter u otras sesiones de API que ya hayan creado. XenCenter y la CLI proporcionan facilidades para finalizar sesiones individuales, o todas las sesiones activas de forma forzada. Consulte la documentación de XenCenter para obtener información sobre los procedimientos que utilizan XenCenter, o la siguiente sección para los procedimientos que utilizan la CLI.

Finalizar todas las sesiones autenticadas mediante xe

Ejecute el siguiente comando de CLI para finalizar todas las sesiones autenticadas mediante xe:

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

Finalizar sesiones de usuario individuales mediante xe

1. Determine el identificador de sujeto de cuya sesión desea cerrar. Utilice los comandos xe session-subject-identifier-list o subject-list para encontrar el identificador de sujeto. El primer comando muestra los usuarios que tienen sesiones. El segundo comando muestra todos los usuarios, pero se puede filtrar. Por ejemplo, usando un comando como xe subject-list other-config:subject-name=xendt\\user1. Es posible que necesite una doble barra invertida como se muestra, dependiendo de su shell).

2. Utilice el comando session-subject-logout, pasando el identificador de sujeto que ha determinado en el paso anterior como parámetro, por ejemplo:

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

Abandonar un dominio de AD

Advertencia:

Cuando abandona el dominio, cualquier usuario que se haya autenticado en el pool o host con credenciales de Active Directory se desconecta.

Utilice XenCenter para abandonar un dominio de AD. Para obtener más información, consulte la documentación de XenCenter. Alternativamente, ejecute el comando pool-disable-external-auth, especificando el UUID del pool si es necesario.

Nota:

Abandonar el dominio no elimina los objetos de host de la base de datos de AD. Consulte la documentación de Active Directory para obtener información sobre cómo detectar y eliminar las entradas de host deshabilitadas.