layout: doc description: Use Active Directory to create additional users that can administer XenServer. Configure the user permissions with role-based access control.—
La definición de usuarios, grupos, funciones y permisos le permite controlar quién tiene acceso a los hosts y grupos de XenServer y qué acciones pueden realizar.
Al instalar 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.
La LSU, o raíz, es una cuenta de usuario especial destinada a la administración del sistema y tiene todos los permisos. En XenServer, la LSU es la cuenta predeterminada en la instalación. XenServer autentica la cuenta de LSU. La LSU no requiere ningún servicio de autenticación externo. Si se produce un error en un servicio de autenticación externo, la LSU aún puede iniciar sesión y administrar el sistema. La 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 ficha Usuarios de XenCenter o la CLI de xe. Si su entorno no usa Active Directory, está limitado a la cuenta de LSU.
Nota:
Al crear usuarios, XenServer no asigna automáticamente funciones RBAC a las cuentas de usuario recién creadas. Por lo tanto, estas cuentas no tienen acceso al grupo de XenServer hasta que se les asigne una función.
Estos permisos se otorgan a través de roles, como se explica en la sección Autenticación de usuarios con Active Directory (AD).
Si desea tener varias cuentas de usuario en un host o un grupo, debe usar las 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 grupo con sus credenciales de dominio de Windows.
Nota:
Puede habilitar el enlace de canales LDAP y la firma LDAP en sus controladores de dominio de AD. Para obtener más información, consulte Asesoramiento de seguridad de Microsoft.
Puede configurar distintos niveles de acceso para usuarios específicos habilitando la autenticación de Active Directory, agregando cuentas de usuario y asignando funciones a esas cuentas.
Los usuarios de Active Directory pueden usar la CLI xe (pasando los argumentos -u y -pw apropiados) y también conectarse al host mediante XenCenter. La autenticación se realiza por grupo de recursos.
Los sujetos controlan el acceso a las cuentas de usuario. En XenServer, un sujeto se asigna a una entidad del servidor Active Directory (un usuario o un grupo). Al habilitar la autenticación externa, XenServer comprueba las credenciales utilizadas para crear una sesión con las credenciales raíz locales y, a continuación, con la lista de asuntos. Para permitir el acceso, cree una entrada de asunto para la persona o el grupo al que quiere conceder acceso. Puede usar XenCenter o la CLI xe para crear una entrada de asunto.
Si está familiarizado con XenCenter, tenga en cuenta que la CLI xe utiliza una terminología ligeramente diferente para referirse a Active Directory y a las funciones de las cuentas de usuario:
| Término de XenCenter | Exe CLI Term |
|---|---|
| Usuarios, Agregar usuarios | Asignaturas, Agregar asignaturas |
Aunque XenServer está basado en Linux, XenServer le permite usar cuentas de Active Directory para las cuentas de usuario de XenServer. Para hacerlo, pasa las credenciales de Active Directory al controlador de dominio de Active Directory.
Al agregar 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 o grupos se autentican mediante Active Directory al iniciar sesión al registrar un asunto en XenServer. Los usuarios y los grupos no necesitan calificar su nombre de usuario mediante un nombre de dominio.
Para calificar un nombre de usuario, debe escribir el nombre de usuario en el formato Nombre de inicio de sesión de nivel inferior; por ejemplo, mydomain\myuser.
Nota:
De forma predeterminada, si no calificó el nombre de usuario, XenCenter intentará iniciar sesión en los servidores de autenticación de AD mediante el dominio al que está unido. La excepción a esto es la cuenta de LSU, que XenCenter siempre autentica primero de forma local (es decir, en el XenServer).
El proceso de autenticación externa funciona de la siguiente manera:
Las credenciales que se proporcionan al conectarse a un host se pasan al controlador de dominio de Active Directory para su autenticación.
El controlador de dominio comprueba las credenciales. Si no son válidas, la autenticación falla de inmediato.
Si las credenciales son válidas, se consulta al controlador de Active Directory para obtener el identificador del sujeto y la pertenencia al grupo asociados a las credenciales.
Si el identificador del 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 por DHCP no es compatible y puede provocar que la integración de AD y, por lo tanto, la autenticación de usuarios, fallen o dejen de funcionar.
XenServer admite el uso de servidores Active Directory con Windows 2008 o posterior.
Para autenticar Active Directory para los hosts de XenServer, debe usar el mismo servidor DNS tanto para el servidor Active Directory (configurado para permitir la interoperabilidad) como para el host de XenServer. En algunas configuraciones, el servidor Active Directory puede proporcionar el propio DNS. Esto se puede lograr mediante DHCP para proporcionar la dirección IP y una lista de servidores DNS al host de XenServer. Como alternativa, puede establecer los valores en los objetos PIF o usar el instalador cuando se usa una configuración estática manual.
Recomendamos habilitar DHCP para asignar nombres de host. No asigne los nombres de host localhost ni 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 con su nombre de host. Si dos hosts 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 se produce independientemente de si los hosts pertenecen al mismo grupo o a grupos diferentes. Esto puede provocar 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 dominios de AD diferentes.
Los hosts de XenServer pueden estar en diferentes zonas horarias, ya que se compara con la hora UTC. Para garantizar que la sincronización sea correcta, puede usar los mismos servidores NTP para el grupo de XenServer y el servidor Active Directory.
No se admiten los grupos de autenticación mixta. No puede tener un grupo en el que algunos hosts del grupo 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 Active Directory. Por lo tanto, XenServer no admite la comunicación con servidores Active Directory que no utilizan Kerberos.
Para que la autenticación externa mediante Active Directory se realice correctamente, los relojes de los hosts de XenServer deben estar sincronizados con los relojes del servidor Active Directory. Cuando XenServer se une al dominio de Active Directory, se comprueba la sincronización y se produce un error en la autenticación si hay demasiada asimetría entre los servidores.
Advertencia:
Los nombres de host deben constar únicamente de un máximo de 63 caracteres alfanuméricos y no deben ser puramente numéricos.
Una limitación en los clientes SSH recientes significa que SSH no funciona para nombres de usuario que contienen alguno de los siguientes caracteres:
{}[]|&. Asegúrese de que sus nombres de usuario y nombres de servidores de Active Directory no contengan ninguno de estos caracteres.
Cuando agrega un host a un grupo después de habilitar la autenticación de Active Directory, se le pide que configure Active Directory en el host que se une al grupo. Cuando se le soliciten las credenciales del host de unión, escriba las credenciales de Active Directory con privilegios suficientes para agregar hosts a ese dominio.
Asegúrese de que los siguientes puertos de firewall estén abiertos al tráfico saliente para que XenServer pueda acceder a los controladores de dominio.
| Puerto | Protocolo | Uso |
|---|---|---|
| 53 | UDP/TCP | DNS |
| 88 | UDP/TCP | Kerberos 5 |
| 123 | UDP | NTP |
| 137 | UDP | Servicio de nombres NetBIOS |
| 139 | TCP | Sesión NetBIOS (SMB) |
| 389 | UDP/TCP | LDAP |
| 445 | TCP | SMB a través de TCP |
| 464 | UDP/TCP | Cambios de contraseña de máquinas |
| 636 | UDP/TCP | LDAP por SSL |
| 3268 | TCP | Búsqueda en el catálogo global |
Para obtener más información, consulte Puertos de comunicación utilizados por XenServer.
Notas:
- Para ver las reglas de firewall en un equipo Linux usando iptables, ejecute el siguiente comando:
iptables -nL.
XenServer usa Winbind para autenticar a los usuarios de Active Directory (AD) en el servidor de AD y para cifrar las comunicaciones con el servidor de AD.
Winbind no admite los siguientes casos:
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 entero.
El valor predeterminado es 1209600 segundos (14 días). Se recomienda conservar el valor predeterminado o no reducirlo por debajo del valor predeterminado para garantizar el tiempo suficiente para sincronizar la nueva contraseña entre los controladores de dominio.
winbind_kerberos_encryption_type: Los valores de esta opción son sólidos, heredados y todo eso. El valor predeterminado es todos.
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 antigua no es segura y ñe recomendamos que solo la utilices para depurar problemas.
Para mejorar la seguridad, le recomendamos que aplique el cifrado AES. Para ello:
aes256-cts-hmac-sha1-96 y aes128-cts-hmacsha1-96.Configure el controlador de dominio para habilitar El otro dominio admite el cifrado AES Kerberos en la confianza del dominio.
Para obtener más información, consulte Método 3: configurar la confianza para que admita el cifrado AES128 y AES 256 en lugar del cifrado RC4 en la documentación de Microsoft.
winbind_kerberos_encryption_type opción para usar el valor strong.Reinicie la pila de herramientas.
No reinicie la pila de herramientas mientras la alta disponibilidad esté habilitada. Si es posible, inhabilite temporalmente HA antes de reiniciar la pila de herramientas.
winbind_cache_time: Winbind almacena en caché algunos datos de dominio de forma local. El valor de esta opción define el número de segundos entre cada actualización de la caché. El valor predeterminado es de 60 segundos.
Tras actualizar cualquiera de estas opciones de configuración, reinicie la pila de herramientas.
Al igual que en las máquinas cliente Windows, Winbind actualiza automáticamente la contraseña de la cuenta de la máquina. Winbind actualiza automáticamente la contraseña de la cuenta de la máquina cada 14 días o según lo especifique la opción winbind_machine_pwd_timeoutde configuración.
La autenticación externa mediante Active Directory se puede configurar mediante XenCenter o la CLI mediante el siguiente comando.
xe pool-enable-external-auth auth-type=AD \
service-name=full-qualified-domain \
config:user=username \
config:pass=password
<!--NeedCopy-->
El usuario especificado debe tener privilegios Add/remove computer objects or workstations, que es el valor predeterminado para los administradores de dominio.
Si no utiliza DHCP en la red que utilizan Active Directory y los hosts de XenServer, utilice los siguientes enfoques para configurar el DNS:
Configure el orden de búsqueda de sufijos DNS de dominio para resolver entradas que no sean de FQDN:
xe pif-param-set uuid=pif_uuid_in_the_dns_subnetwork \
"other-config:domain=suffix1.com suffix2.com suffix3.com"
<!--NeedCopy-->
Configure el servidor DNS para usarlo en los hosts de XenServer:
xe pif-reconfigure-ip mode=static dns=dnshost ip=ip \
gateway=gateway netmask=netmask uuid=uuid
<!--NeedCopy-->
Configure 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, le recomendamos que habilite y inhabilite la autenticación externa por grupo. Una configuración por grupo permite a XenServer tratar los errores que se producen al habilitar la autenticación en un host determinado. XenServer también revierte cualquier cambio que pueda ser necesario, lo que garantiza una configuración coherente en todo el grupo. Use el comando
host-param-listpara inspeccionar las propiedades de un host y para determinar el estado de la autenticación externa comprobando los valores de los campos relevantes.
Use XenCenter para inhabilitar la autenticación de Active Directory o el siguiente comando xe:
xe pool-disable-external-auth
<!--NeedCopy-->
Para permitir que un usuario acceda al host de XenServer, debe agregar un asunto para ese usuario o grupo en el que se encuentre. (Las pertenencias a grupos transitivos también se verifican de la manera normal. Por ejemplo, agregar un asunto 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 quiere administrar los permisos de usuario en Active Directory, puede crear un único grupo que, a continuación, agregue y elimine usuarios hacia/desde. Como alternativa, puede agregar y eliminar usuarios individuales de XenServer o una combinación de usuarios y grupos, según corresponda, según sus requisitos de autenticación. Puede administrar la lista de asuntos desde XenCenter o mediante la CLI como se describe en la siguiente sección.
Al autenticar a un usuario, las credenciales se comparan primero con la cuenta raíz local, lo que le permite recuperar un sistema cuyo servidor de AD ha fallado. Si las credenciales (nombre de usuario y contraseña) no coinciden, se realiza una solicitud de autenticación al servidor de AD. Si la autenticación tiene éxito, la información del usuario se recupera y valida en la lista de temas local. Se deniega el acceso si la autenticación falla. La validación con respecto a la lista de temas se realiza correctamente si el usuario o un grupo de la pertenencia al grupo transitivo del usuario está en la lista de asuntos.
Nota:
Cuando se usan grupos de Active Directory para conceder acceso a los usuarios del administrador de grupos que requieren acceso ssh de host, el tamaño del grupo de AD no debe superar los 500 usuarios.
Para agregar un asunto de AD a XenServer:
xe subject-add subject-name=entity_name
<!--NeedCopy-->
Entity_name es el nombre del usuario o grupo al que quiere 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 la desambiguación.
Busque el identificador de sujeto del usuario. El identificador es el usuario o el grupo que lo contiene. Al eliminar un grupo, se elimina el acceso a todos los usuarios de ese grupo, siempre que no se especifiquen también en la lista de asuntos. Use 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 buscar el identificador de asunto de un usuario user1 en el comando testad:
xe subject-list other-config:subject-name='testad\user1'
<!--NeedCopy-->
Elimine al usuario mediante el comando subject-remove y pase 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 Terminar todas las sesiones autenticadas con xe y Terminar sesiones de usuarios individuales con xe en la siguiente sección. Si no finaliza las sesiones, los usuarios con permisos revocados pueden seguir accediendo al sistema hasta que cierren sesión.
Ejecute el siguiente comando para identificar la lista de usuarios y grupos con permiso para acceder al host o grupo de XenServer:
xe subject-list
<!--NeedCopy-->
Cuando un usuario se autentica, puede acceder al host hasta que finalice su sesión o hasta que otro usuario finalice su sesión. Eliminar a un usuario de la lista de asuntos, o eliminarlo de un grupo en la lista de asuntos, no revoca automáticamente ninguna sesión ya autenticada que tenga el usuario. Los usuarios pueden seguir accediendo al grupo mediante XenCenter u otras sesiones de API que ya hayan creado. XenCenter y la CLI brindan facilidades para finalizar sesiones individuales o todas las sesiones activas de manera forzada. Consulte la documentación de XenCenter para obtener información sobre los procedimientos que utilizan XenCenter o la siguiente sección para conocer los procedimientos que utilizan la CLI.
Ejecute el siguiente comando de la CLI para finalizar todas las sesiones autenticadas con xe:
xe session-subject-identifier-logout-all
<!--NeedCopy-->
Determine el identificador de sujeto de cuya sesión quiere cerrar sesión. Use los comandos session-subject-identifier-list o subject-list xe para buscar el identificador de sujeto. El primer comando muestra a los usuarios que tienen sesiones. El segundo comando muestra todos los usuarios, pero se puede filtrar. Por ejemplo, mediante el uso de un comando como xe subject-list other-config:subject-name=xendt\\user1. Es posible que necesite una barra invertida doble (como se muestra en función de su caparazón).
Ejecute el comando session-subject-logout, pasando el identificador de asunto que ha determinado en el paso anterior como parámetro, por ejemplo:
xe session-subject-identifier-logout subject-identifier=subject_id
<!--NeedCopy-->
Advertencia:
Al salir del dominio, todos los usuarios que se hayan autenticado en el grupo o el host con credenciales de Active Directory se desconectan.
Use XenCenter para dejar un dominio de AD. Para obtener más información, consulte la documentación de XenCenter. Ejecute alternativamente el comando pool-disable-external-auth, especificando el UUID del grupo si es necesario.
Nota:
Dejar 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 inhabilitadas.