vCenter Server Federación de proveedor de identidad

En vSphere 7.0 o versiones posteriores, vCenter Server admite la autenticación federada para iniciar sesión en vCenter Server.

Para habilitar la autenticación federada en vCenter Server, debe configurar una conexión con un proveedor de identidad externo. La instancia del proveedor de identidad que se configura reemplaza a vCenter Server como el proveedor de identidad. Actualmente, vCenter Server admite Active Directory Federation Services (AD FS), Okta, Microsoft Entra ID (anteriormente denominado Azure AD) y PingFederate como proveedores de identidad externos. vCenter Server admite AD FS en vSphere 7.0 y versiones posteriores, Okta en vSphere 8.0 Update 1 y versiones posteriores, Microsoft Entra ID en vSphere 8.0 Update 2 y versiones posteriores y PingFederate a partir de vSphere 8.0 Update 3.

Nota: VMware recomienda utilizar la autenticación federada a medida que vSphere avanza hacia la autenticación basada en token. vCenter Server sigue teniendo cuentas locales para acceso administrativo y recuperación de errores.

Cómo funciona la federación de proveedores de identidad de vCenter Server

La federación de proveedores de identidad de vCenter Server le permite configurar un proveedor de identidad externo para autenticación federada. En esta configuración, el proveedor de identidad externo interactúa con el origen de identidad en nombre de vCenter Server.

Conceptos básicos de la federación de proveedores de identidad de vCenter Server

En vSphere 7.0 y versiones posteriores, vCenter Server admite la autenticación federada. En este escenario, cuando un usuario inicia sesión en vCenter Server, vCenter Server redirecciona el inicio de sesión del usuario al proveedor de identidad externo. Ya no se proporcionan las credenciales de usuario directamente a vCenter Server. En su lugar, el usuario proporciona las credenciales al proveedor de identidad externo. vCenter Server confía en el proveedor de identidad externo para realizar la autenticación. En el modelo de federación, los usuarios nunca proporcionan credenciales directamente a ningún servicio ni aplicación, sino solo al proveedor de identidad. Como resultado, con el proveedor de identidad puede "federar" las aplicaciones y los servicios, como vCenter Server.

Compatibilidad con proveedores de identidad externos de vCenter Server

vCenter Server admite los siguientes proveedores de identidad externos:

• AD FS (vSphere 7.0 y versiones posteriores)
• Okta (vSphere 8.0 Update 1 y versiones posteriores)
• Microsoft Entra ID, anteriormente denominado Azure AD (vSphere 8.0 Update 2 y versiones posteriores)
• PingFederate (a partir de vSphere 8.0 Update 3)

Ventajas de la federación de proveedores de identidad de vCenter Server

La federación de proveedores de identidad de vCenter Server proporciona las siguientes ventajas.

• Puede utilizar Single Sign-On con las aplicaciones y la infraestructura federada existentes.
• Puede mejorar la seguridad del centro de datos porque vCenter Server no controla nunca las credenciales del usuario.
• Puede utilizar mecanismos de autenticación, como la autenticación multifactor, compatible con el proveedor de identidad externo.

Arquitectura de la federación de proveedores de identidad de vCenter Server

Para establecer una relación de confianza entre vCenter Server y un proveedor de identidad externo, debe establecer la información de identificación y un secreto compartido entre ellos. vCenter Server usa el protocolo OpenID Connect (OIDC) para recibir un token de identidad que autentique al usuario con vCenter Server.

Los pasos detallados para configurar un proveedor de identidad externo con vCenter Server incluyen:

1. Establecer una confianza de usuario autenticado entre vCenter Server y el proveedor de identidad externo mediante la creación de una configuración de OIDC. Para AD FS, cree un grupo de aplicaciones o una aplicación. Para Okta, Microsoft Entra ID y PingFederate, cree una aplicación nativa con OpenID Connect como método de inicio de sesión. La configuración de OIDC consta de una aplicación de servidor y una API de Web. Los dos componentes especifican la información que vCenter Server usa para confiar y comunicarse con el proveedor de identidad externo.
2. Crear un proveedor de identidad correspondiente en vCenter Server.
3. Configurar la pertenencia a grupos en vCenter Server para autorizar el inicio de sesión de usuarios en el dominio del proveedor de identidad externo.

El administrador del proveedor de identidad debe proporcionar la siguiente información para crear la configuración del proveedor de identidad de vCenter Server:

• Identificador del cliente: la cadena UUID que se genera en AD FS al crear el grupo de aplicaciones (o la aplicación) y que identifica al grupo de aplicaciones (o la aplicación), o bien que se genera en Okta, Microsoft Entra ID o PingFederate al crear la aplicación OpenID Connect.
• Secreto compartido: el secreto que se genera en AD FS al crear el grupo de aplicaciones (o la aplicación) o que se genera en Okta, Microsoft Entra ID o PingFederate al crear la aplicación de OpenID Connect y que se utiliza para autenticar vCenter Server con el proveedor de identidad externo.
• Dirección de OpenID: la dirección URL del endpoint de detección de proveedores de OpenID correspondiente al servidor del proveedor de identidad externo, que especifica una dirección conocida que suele ser el endpoint del emisor concatenado con la ruta de acceso /.well-known/openid-configuration. A continuación se muestra un ejemplo de dirección de OpenID para una configuración de AD FS:

  https://webserver.example.com/adfs/.well-known/openid-configuration

  Del mismo modo, a continuación se muestra un ejemplo de dirección de OpenID para una configuración de Okta:

  https://example.okta.com/oauth2/default/.well-known/openid-configuration

  A continuación se muestra un ejemplo de dirección de OpenID para una configuración de Microsoft Entra ID:

  https://login.microsoftonline.com/11111111-2222-3333-4444-555555555555/v2.0/.well-known/openid-configuration

  A continuación se muestra un ejemplo de dirección de OpenID para una configuración de PingFederate:

  https://pingfederate-fqdn-and-port/.well-known/openid-configuration

VMware Identity Services y autenticación federada

En vSphere 8.0 Update 1 y versiones posteriores, VMware Identity Services proporciona una integración con los proveedores de identidad externos como proveedores de identidad federados. Puede pensar en la VMware Identity Services como una versión "reducida" de VMware Workspace ONE que está integrada en vSphere.

Al actualizar a vSphere 8.0 Update 1 o una versión posterior, o bien al instalarlo, VMware Identity Services se activa de forma predeterminada en vCenter Server. Al configurar Okta, Microsoft Entra ID o PingFederate como proveedores de identidad externos, vCenter Server utiliza VMware Identity Services para comunicarse con el servidor de Okta, Microsoft Entra ID o PingFederate.

vCenter Server admite Okta, Microsoft Entra ID y PingFederate como proveedores de identidad externos en una configuración de Enhanced Linked Mode. A pesar de que, en este tipo de configuración, varios sistemas de vCenter Server ejecutan VMware Identity Services, solo una instancia de vCenter Server y su instancia de VMware Identity Services se comunican con el servidor proveedor de identidad externo. Por ejemplo, si tiene una configuración de Enhanced Linked Mode de tres sistemas de vCenter Server (A, B y C) y configura el proveedor de identidad de Okta en vCenter Server A, vCenter Server A es el único sistema que controla todos los inicios de sesión de Okta. vCenter Server B y vCenter Server C no se comunican directamente con el servidor Okta. Para configurar VMware Identity Services en otras instancias de vCenter Server de la configuración de ELM para interactuar con el servidor de IDP externo, consulte Proceso de activación para proveedores de identidad externos en configuraciones de Enhanced Linked Mode.

Nota: Al configurar Okta como proveedor de identidad externo, todos los sistemas vCenter Server en una configuración de Enhanced Linked Mode deben ejecutar al menos vSphere 8.0 Update 1. Para Microsoft Entra ID, el requisito es al menos vSphere 8.0 Update 2. Para PingFederate, el requisito es al menos vSphere 8.0 Update 3.

Advertencia: Cuando se utiliza una configuración de Enhanced Linked Mode con Okta, Microsoft Entra ID o PingFederate, no se puede eliminar la instancia de vCenter Server que ejecuta VMware Identity Services y que se comunica con el proveedor de identidad desde la configuración de ELM.

Proceso de autenticación de VMware Identity Services

Al configurar vCenter Server para utilizar VMware Identity Services a fin de comunicarse con el proveedor de identidad externo, se produce el siguiente proceso de autenticación:

1. Un usuario inicia sesión en vCenter Server con vSphere Client.
2. vCenter Single Sign-On delega la autenticación del usuario y redirecciona la solicitud de usuario a VMware Identity Services.
3. El proceso de VMware Identity Services solicita un token del proveedor de identidad externo para establecer la sesión de usuario.
4. El proveedor de identidad externo autentica al usuario (puede usar la autenticación multifactor [MFA] o las credenciales de SSO) y devuelve el token a VMware Identity Services.

   El token contiene las notificaciones de usuario.

5. El proceso de VMware Identity Services valida el token del proveedor de identidad, genera un token de VMware Identity Services correspondiente y lo envía a vCenter Single Sign-On.
6. vCenter Single Sign-On valida el token y concede la solicitud de inicio de sesión.

Nota: AD FS no utiliza VMware Identity Services para la autenticación federada.

Cómo interactúa vCenter Server con usuarios y grupos insertados por SCIM

Al configurar su proveedor de identidad externo, vCenter Server utiliza el sistema para la administración de identidades entre dominios (SCIM) a fin de administrar usuarios y grupos. SCIM es un estándar abierto para automatizar el intercambio de información de identidad de usuario. Una aplicación de SCIM que crea en el servidor de IDP externo administra los usuarios y los grupos en el proveedor de identidad externo que desea insertar en vCenter Server. vCenter Server también utiliza SCIM al buscar usuarios y grupos para asignar permisos a objetos de vCenter Server.

Nota: Una configuración de AD FS busca en Active Directory mediante LDAP. No utiliza SCIM.

Componentes de la federación de proveedores de identidad de vCenter Server

Los siguientes componentes incluyen una configuración de federación de proveedores de identidad de vCenter Server:

• Un vCenter Server
  • Para AD FS: vCenter Server 7.0 o versiones posteriores
  • Para Okta: vCenter Server 8.0 Update 1 o una versión posterior
  • Para Microsoft Entra ID: vCenter Server 8.0 Update 2 o una versión posterior
  • Para PingFederate: vCenter Server 8.0 Update 3
• Un servicio de proveedor de identidad configurado en vCenter Server
• Un proveedor de identidad externo (AD FS, Okta, Microsoft Entra ID o PingFederate)
• Una configuración de OpenID Connect (OIDC):
  • Para AD FS: un grupo de aplicaciones (también denominado aplicación)
  • Para Okta, Microsoft Entra ID o PingFederate: una aplicación de OpenID Connect
• Una aplicación del Sistema para la administración de identidades entre dominios (SCIM) para la administración de usuarios y grupos (solo para Okta, Microsoft Entra ID o PingFederate)
• Grupos y usuarios de proveedores de identidad externos que se asignan a grupos y usuarios de vCenter Server
• VMware Identity Services habilitado en vCenter Server (solo para Okta, Microsoft Entra ID o PingFederate)
• De forma opcional, para PingFederate, el certificado SSL o la cadena de certificados del servidor PingFederate, si este certificado no fue emitido por una entidad de certificación pública y conocida. Importe el certificado de SSL de PingFederate a vCenter Server.

Interoperabilidad y advertencias de la federación de proveedores de identidad de vCenter Server

La federación de proveedores de identidad de vCenter Server puede interoperar con muchas otras funciones de VMware.

Cuando planee la estrategia de federación de proveedores de identidad de vCenter Server, considere las posibles limitaciones de interoperabilidad.

Mecanismos de autenticación

En una configuración de la federación de proveedores de identidad de vCenter Server, el proveedor de identidad externo controla los mecanismos de autenticación (contraseñas, MFA, biometría, etc.).

AD FS y compatibilidad con un único dominio de Active Directory

Al configurar la federación de proveedores de identidad de vCenter Server para AD FS, el asistente Configurar proveedor de identidad principal solicita que introduzca la información de LDAP del dominio de AD único que contiene los usuarios y los grupos a los que desea acceder vCenter Server. vCenter Server deriva el dominio de AD que se utilizará para la autorización y los permisos del DN base de usuarios que especifique en el asistente. Puede agregar permisos en los objetos de vSphere solo para usuarios y grupos de este dominio de AD. Los usuarios o los grupos de dominios secundarios de AD u otros dominios del bosque de AD no son compatibles con la federación de proveedores de identidad de vCenter Server.

Compatibilidad con Okta, Microsoft Entra ID y PingFederate para varios dominios

Al configurar la federación de proveedores de identidad de vCenter Server para Okta, Microsoft Entra ID o PingFederate, el asistente Configurar proveedor de identidad principal solicita que introduzca la información de LDAP de múltiples dominios que contienen los usuarios y los grupos a los que desea acceder vCenter Server.

Directivas de contraseñas, bloqueos y tokens

Cuando vCenter Server actúa como proveedor de identidad, se controlan las directivas contraseñas, bloqueos y tokens de vCenter Server para el dominio predeterminado (vsphere.local o el nombre de dominio que introdujo al instalar vSphere). Cuando se utiliza la autenticación federada con vCenter Server, el proveedor de identidad externo controla las directivas de contraseñas, bloqueo y token para las cuentas almacenadas en el origen de identidad, como Active Directory.

Auditoría y conformidad

Cuando se utiliza la federación de proveedores de identidad de vCenter Server, vCenter Server continúa creando entradas de registro para inicios de sesión de usuarios correctos. Sin embargo, el proveedor de identidad externo es responsable de realizar un seguimiento de las acciones de registro, como los bloqueos de cuentas de usuario y los intentos de entrada de contraseña fallidos. vCenter Server no registra estos eventos porque ya no están visibles para vCenter Server. Por ejemplo, cuando AD FS es el proveedor de identidad, realiza un seguimiento de los errores de inicios de sesión federados y los registra. Cuando vCenter Server es el proveedor de identidad para los inicios de sesión locales, vCenter Server realiza un seguimiento de los errores y los registra para los inicios de sesión locales. En una configuración federada, vCenter Server continúa registrando las acciones del usuario después del inicio de sesión.

Integración de productos VMware existentes con proveedores de identidad externos

Los productos de VMware integrados con vCenter Server (por ejemplo, VMware Aria Operations, vSAN, NSX, etc.) siguen funcionando como antes.

Productos que se integran después del inicio de sesión

Los productos que se integran después del inicio de sesión (es decir, que no requieren un inicio de sesión independiente) continúan funcionando como antes.

Autenticación simple para el acceso a API, SDK y CLI

Los scripts, los productos y otras funcionalidades existentes que se basan en los comandos de API, SDK o CLI que utilizan autenticación simple (es decir, nombre de usuario y contraseña) continúan funcionando como antes. Internamente, la autenticación se realiza pasando el nombre de usuario y la contraseña. Este paso del nombre de usuario y de la contraseña compromete algunas de las ventajas de utilizar la federación de identidades, ya que expone la contraseña a vCenter Server (y sus scripts). Considere la posibilidad de migrar a la autenticación basada en tokens siempre que sea posible.

Acceder a la interfaz de administración de vCenter Server

Si el usuario es miembro del grupo de administradores de vCenter Server, se admite el acceso a la interfaz de administración de vCenter Server (anteriormente denominada "interfaz de administración del dispositivo de vCenter Server" o VAMI).

Introducir texto de nombre de usuario en la página de inicio de sesión de AD FS

La página de inicio de sesión de AD FS no admite el envío de texto para rellenar previamente el cuadro de texto de nombre de usuario. Por ello, durante los inicios de sesión federados con AD FS, después de que introduzca el nombre de usuario en la página de destino de vCenter Server y de que se le redirija a la página de inicio de sesión de AD FS, debe volver a introducir el nombre de usuario en la página de inicio de sesión de AD FS. El nombre de usuario que introduzca en la página de destino de vCenter Server es necesario para redirigir el inicio de sesión al proveedor de identidad adecuado. Asimismo, el nombre de usuario en la página de inicio de sesión de AD FS es necesario para autenticarse con AD FS. La imposibilidad de transferir el nombre de usuario a la página de inicio de sesión de AD FS es una limitación de AD FS. No puede configurar ni cambiar este comportamiento directamente desde vCenter Server.

Compatibilidad con direcciones IPv6

AD FS, Microsoft Entra ID y Ping Federate admiten direcciones IPv6. Okta no admite direcciones IPv6.

Configuración de instancia única de VMware Identity Services

De forma predeterminada, cuando instala o actualiza a vSphere 8.0 Update 1 o posterior, la instancia de VMware Identity Services se habilita en vCenter Server. Cuando establezca Okta, Microsoft Entra ID o PingFederate en una configuración de Enhanced Link Mode, utilice VMware Identity Services en un único sistema de vCenter Server. Por ejemplo, si usa Okta en una configuración de Enhanced Mode Link que consta de tres sistemas de vCenter Server, solo se utiliza una instancia de vCenter Server de VMware Identity Services para comunicarse con el servidor de Okta.

Advertencia:

En una configuración de ELM que utiliza VMware Identity Services, si el sistema de vCenter Server que se comunica con el proveedor de identidad externo deja de estar disponible, puede configurar VMware Identity Services en otro vCenter Server de la configuración de ELM para interactuar con el servidor IDP externo. Consulte Proceso de activación para proveedores de identidad externos en configuraciones de Enhanced Linked Mode.

Reconfigurar el identificador de red principal

Para volver a configurar el identificador de red principal (Primary Network Identifier, PNID) del vCenter Server, es necesario actualizar la configuración del proveedor de identidad externo de la siguiente manera.

• AD FS: agregue los nuevos URI de redireccionamiento al servidor de AD FS.
• Okta: vuelva a configurar Okta. Consulte Configurar la federación de proveedores de identidad de vCenter Server para Okta y siga los pasos para crear el proveedor de identidad en vCenter Server.
• Microsoft Entra ID: reconfigurar Entra ID. Consulte Configurar la federación de proveedores de identidad de vCenter Server para Microsoft Entra ID y siga los pasos para crear el proveedor de identidad en vCenter Server.
• PingFederate: reconfigurar PingFederate. Consulte Configurar la federación de proveedores de identidad de vCenter Server para PingFederate y siga los pasos para crear el proveedor de identidad en vCenter Server.

Ciclo de vida de la federación de proveedores de identidad de vCenter Server

Al administrar el ciclo de vida de la federación de proveedores de identidad de vCenter Server, hay algunas consideraciones específicas.

Puede administrar el ciclo de vida de la federación de proveedores de identidad de vCenter Server de las siguientes maneras.

Migrar de Active Directory a un proveedor de identidad externo

Si utiliza Active Directory como origen de identidad para vCenter Server, la migración a un proveedor de identidad externo es sencilla. Si las funciones y los grupos de Active Directory coinciden con las funciones y los grupos de proveedor de identidad, no es necesario realizar ninguna acción adicional. Cuando los grupos y las funciones no coinciden, debe realizar algunos trabajos adicionales. Si vCenter Server es un miembro del dominio, considere quitarlo del dominio, ya que no es necesario ni se utiliza para la federación de identidades.

Redireccionar y migrar entre dominios

La federación de proveedores de identidad de vCenter Server admite el redireccionamiento entre dominios, es decir, el movimiento de una instancia de vCenter Server de un dominio SSO de vSphere a otro. La instancia de vCenter Server redireccionada recibe la configuración de proveedor de identidad replicada del sistema, o los sistemas, de vCenter Server a los que se ha señalado.

En general, no es necesario realizar ninguna reconfiguración adicional de proveedor de identidad para un redireccionamiento entre dominios, a menos que se cumpla una de las siguientes condiciones.

1. La configuración de proveedor de identidad de la instancia de vCenter Server redireccionada difiere de la configuración de proveedor de identidad de la instancia de vCenter Server a la que se ha señalado.
2. Esta es la primera vez que la instancia de vCenter Server redireccionada recibe una configuración de proveedor de identidad.

En estos casos, se requiere algo de trabajo adicional. Por ejemplo, para AD FS, debe agregar los URI de redireccionamiento del sistema de vCenter Server al grupo de aplicaciones correspondiente en el servidor de AD FS. Por ejemplo, si la instancia de vCenter Server 1 con el grupo de aplicaciones de AD FS A (o ninguna configuración de AD FS) se redirecciona a la instancia de vCenter Server 2 con el grupo de aplicaciones de AD FS B, debe agregar los URI de redireccionamiento de la instancia de vCenter Server 1 al grupo de aplicaciones B.

Sincronización de usuarios y grupos/copia de seguridad y restauración de vCenter Server

En función de cuándo sincronice los usuarios y grupos con vCenter Server y de cuándo realice una copia de seguridad de vCenter Server, si debe restaurar vCenter Server, es posible que deba volver a sincronizar los usuarios y grupos que SCIM insertó.

Para restaurar un usuario o un grupo eliminado, no puede simplemente insertar el usuario o el grupo desde el proveedor de identidad externo en vCenter Server. Debe actualizar la aplicación SCIM 2.0 en el proveedor de identidad externo con el usuario o el grupo faltante. Consulte Restaurar usuarios y grupos de SCIM eliminados.