vCenter Single Sign-On permite que los componentes de vSphere se comuniquen entre sí a través de un mecanismo de token seguro.

vCenter Single Sign-On utiliza los siguientes servicios.
  • Autenticación de usuarios a través de la federación de proveedores de identidad externo o el proveedor de identidad integrado de vCenter Server. El proveedor de identidad integrado admite cuentas locales, Active Directory u OpenLDAP, autenticación de Windows integrada (IWA) y mecanismos de autenticación diversos (tarjeta inteligente y RSA SecurID).
  • La autenticación de usuarios de soluciones a través de certificados.
  • Servicio de token de seguridad (Security Token Service, STS).
  • SSL para proteger el tráfico.

Proveedor de identidad integrado de vCenter Server

vCenter Server incluye un proveedor de identidad integrado. De forma predeterminada, vCenter Server utiliza el dominio vsphere.local como el origen de identidad (pero puede cambiar el dominio durante la instalación). Puede configurar el proveedor de identidad integrado de vCenter Server para que utilice Active Directory (AD) como su origen de identidad mediante LDAP/S, OpenLDAP/S y la autenticación de Windows integrada (IWA). Estas configuraciones permiten a los clientes iniciar sesión en vCenter Server a través de sus cuentas de AD.

vCenter Server y un proveedor de identidad externo

En vSphere 7.0 y versiones posteriores, puede configurar vCenter Server para un proveedor de identidad externo mediante la autenticación federada. En una configuración de este tipo, debe reemplazar a vCenter Server como el proveedor de identidad.

vSphere admite los siguientes proveedores de identidad.

  • vSphere 7.0 y versiones posteriores: Active Directory Federation Services (AD FS)
  • vSphere 8.0 Update 1 y versiones posteriores: Okta
  • vSphere 8.0 Update 2 y versiones posteriores: Microsoft Entra ID (anteriormente denominado Azure AD)
  • A partir de vSphere 8.0 Update 3: PingFederate

Cuando se configura vSphere para utilizar un proveedor de identidad externo, este interactúa con los orígenes de identidad en nombre de vCenter Server.

Inicio de sesión del usuario con autenticación federada del proveedor de identidad de vCenter Server

Cuando se utiliza un proveedor de identidad externo para autenticarse con la instancia de vCenter Server, la instancia de vCenter Server redirecciona la solicitud de inicio de sesión al proveedor de identidad externo. El proveedor de identidad externo autentica al usuario con su servicio de directorio y, a continuación, emite un token para que vCenter Server lo utilice a fin de iniciar sesión en el usuario.

Por ejemplo, la siguiente figura muestra una vista detallada del flujo de inicio de sesión de usuario para la federación de proveedores de identidad de vCenter Server mediante AD FS.

Figura 1. Inicio de sesión de usuario en vCenter Server mediante la federación de proveedores de identidad AD FS

Esta figura muestra el flujo del proceso de inicio de sesión de un usuario en vCenter Server con federación de proveedores de identidad AD FS.

vCenter Server, AD FS y Active Directory interactúan de la siguiente manera:

  1. El usuario comienza en la página de destino de vCenter Server e introduce allí un nombre de usuario.
  2. Si el nombre de usuario es para un dominio federado, vCenter Server redirecciona la solicitud de autenticación a AD FS.
  3. Si es necesario, AD FS solicita al usuario que inicie sesión con las credenciales de Active Directory.
  4. AD FS autentica al usuario con Active Directory.
  5. AD FS emite un token de seguridad con información de grupo de Active Directory.
  6. vCenter Server utiliza el token para iniciar la sesión del usuario.
Ahora el usuario está autenticado, y puede ver y modificar todos los objetos sobre los que tiene privilegios por su función.
Nota: Al principio, se asigna la función Sin acceso a cada usuario. Un administrador de vCenter Server debe asignar al menos la función Solo lectura al usuario para que pueda iniciar sesión. Consulte la documentación de Seguridad de vSphere.

En caso de que no se pueda acceder al proveedor de identidad externo, el proceso de inicio de sesión vuelve a la página de destino de vCenter Server, donde se muestra un mensaje de información adecuado. Los usuarios también pueden iniciar sesión con sus cuentas locales en el origen de identidad vsphere.local.

La interacción entre vCenter Server y Okta, Microsoft Entra ID o PingFederate es similar a la de AD FS, con la excepción de que vCenter Server utiliza VMware Identity Services. Consulte Proceso de autenticación de VMware Identity Services.

Inicio de sesión del usuario con el proveedor de identidad integrado de vCenter Server

En la siguiente figura, se muestra el flujo de inicio de sesión del usuario cuando vCenter Server actúa como el proveedor de identidad.

Figura 2. Inicio de sesión del usuario con el proveedor de identidad integrado de vCenter Server
Cuando el usuario inicia sesión en vSphere Client, el servidor Single Sign-On establece el protocolo de enlace de la autenticación.
  1. El usuario inicia sesión en vSphere Client con un nombre de usuario y una contraseña para acceder al sistema vCenter Server o a otro servicio de vCenter.
  2. vSphere Client pasa la información de inicio de sesión al servicio vCenter Single Sign-On, que comprueba el token SAML de vSphere Client. Si vSphere Client tiene un token válido, vCenter Single Sign-On comprueba si el usuario se encuentra en el origen de identidad configurado (por ejemplo, Active Directory).
    • Si solo se emplea el nombre de usuario, vCenter Single Sign-On comprueba el dominio predeterminado.
    • Si se incluye un nombre de dominio con el nombre de usuario (DOMAIN\user1 o user1@DOMAIN), vCenter Single Sign-On comprueba ese dominio.
  3. Si el usuario puede autenticarse en el origen de identidad, vCenter Single Sign-On devuelve un token que representa al usuario en vSphere Client.
  4. vSphere Client pasa el token al sistema vCenter Server.
  5. vCenter Server comprueba con el servidor de vCenter Single Sign-On que el token sea válido y que no haya caducado.
  6. El servidor de vCenter Single Sign-On devuelve el token al sistema vCenter Server mediante el marco de autorización de vCenter Server para otorgar acceso a los usuarios.
Ahora el usuario está autenticado, y puede ver y modificar todos los objetos sobre los que tiene privilegios por su función.
Nota: Al principio, se asigna la función Sin acceso a cada usuario. Un administrador de vCenter Server debe asignar al menos la función Solo lectura al usuario para que pueda iniciar sesión. Consulte la documentación de Seguridad de vSphere.

Inicio de sesión para usuarios de solución

Los usuarios de solución son conjuntos de servicios que se usan en la infraestructura de vCenter Server, por ejemplo, las extensiones de vCenter Server. Las extensiones de VMware y las posibles extensiones externas también pueden autenticarse en vCenter Single Sign-On.

Nota: vCenter Server utiliza certificados de usuarios de solución solo para comunicación interna. Los certificados de usuarios de solución no se utilizan para la comunicación externa.

En la siguiente figura, se muestra el flujo de inicio de sesión para usuarios de solución.

Figura 3. Inicio de sesión para usuarios de solución
El protocolo de enlace entre un usuario de solución, vCenter Single Sign-On y otros componentes de vCenter sigue los pasos detallados en el siguiente texto.
  1. El usuario de solución intenta conectarse a un servicio de vCenter Server.
  2. Se redirige al usuario de solución a vCenter Single Sign-On. Si el usuario de solución es nuevo en vCenter Single Sign-On, debe presentar un certificado válido.
  3. Si el certificado es válido, vCenter Single Sign-On asigna un token SAML (token de portador) al usuario de solución. vCenter Single Sign-On firma el token.
  4. El usuario de solución se redirige a vCenter Single Sign-On y puede realizar tareas según sus permisos.

    La próxima vez que el usuario de solución deba autenticarse, podrá usar el token SAML para iniciar sesión en vCenter Server.

De forma predeterminada, este protocolo de enlace se aplica automáticamente, ya que VMCA aprovisiona a los usuarios de solución con certificados durante el inicio. Si la directiva de la empresa exige certificados externos firmados por una entidad de certificación, se pueden utilizar esos certificados para reemplazar los certificados de los usuarios de solución. Si esos certificados son válidos, vCenter Single Sign-On asigna un token SAML al usuario de solución. Consulte Reemplazar certificados de usuario de solución por certificados personalizados mediante el administrador de certificados.

Cifrado compatible en vSphere

Se admite el cifrado AES, que es el nivel más alto de cifrado. El cifrado compatible también afecta a la seguridad cuando vCenter Single Sign-On utiliza Active Directory como un origen de identidad.

También afecta a la seguridad cada vez que un host ESXi o vCenter Server se une a Active Directory.