Compartir a través de

Delegación restringida de Kerberos para el inicio de sesión único (SSO) para las aplicaciones con el proxy de aplicación

Puede proporcionar un inicio de sesión único para las aplicaciones locales publicadas a través del proxy de aplicación que se protegen con la autenticación integrada de Windows. Estas aplicaciones requieren un vale Kerberos para el acceso. El proxy de aplicación usa la Delegación restringida de Kerberos (KCD) para admitir estas aplicaciones.

Para obtener más información sobre el inicio de sesión único (SSO), consulte ¿Qué es el inicio de sesión único?.

Puede habilitar el inicio de sesión único en las aplicaciones mediante la autenticación integrada de Windows (IWA) al conceder permiso a los conectores de red privados en Active Directory para suplantar a los usuarios. Los conectores usan este permiso para enviar y recibir tokens en su nombre.

Cómo funciona el inicio de sesión único con KCD

En el diagrama se explica el flujo cuando un usuario intenta acceder a una aplicación local que usa IWA.

Diagrama de flujos de autenticación de Microsoft Entra

  1. El usuario escribe la dirección URL para tener acceso a la aplicación local mediante el proxy de aplicación.
  2. El proxy de aplicación redirige la solicitud a los servicios de autenticación de Microsoft Entra para realizar la autenticación previa. En este momento, Microsoft Entra ID aplica cualquier autenticación correspondiente, así como directivas de autorización, como la autenticación multifactor. Si se valida el usuario, Microsoft Entra ID crea un token y lo envía al usuario.
  3. El usuario pasa el token al proxy de aplicación.
  4. El proxy de aplicación valida el token y recupera el nombre principal del usuario (UPN); a continuación, el conector extrae el UPN y el nombre de entidad de seguridad de servicio (SPN) a través de un canal seguro con autenticación dual.
  5. El conector realiza la negociación de la delegación limitada de Kerberos (KCD) con AD local, suplantando al usuario para obtener un token de Kerberos para la aplicación.
  6. Active Directory envía el token de Kerberos para la aplicación al conector.
  7. El conector envía la solicitud original al servidor de aplicaciones, con el token de Kerberos que recibió de AD.
  8. La aplicación envía la respuesta al conector y, después, se devuelve al servicio del proxy de aplicación y, por último, al usuario.

Requisitos previos

Antes de empezar a trabajar con el inicio de sesión único para aplicaciones con autenticación integrada de Windows, asegúrese de que el entorno está preparado con los siguientes ajustes y configuraciones:

Configurar Active Directory

La configuración de Active Directory varía, en función de si el conector de red privada y el servidor de aplicaciones están en el mismo dominio o no.

Conector y servidor de aplicaciones en el mismo dominio

  1. En Active Directory, vaya a Herramientas>Usuarios y equipos.

  2. Seleccione el servidor que ejecuta el conector.

  3. Haga clic en el botón derecho y seleccione Propiedades>Delegación.

  4. Seleccione Confiar en este equipo para la delegación solo a los servicios especificados.

  5. Seleccione Usar cualquier protocolo de autenticación.

  6. En Servicios a los que esta cuenta puede presentar credenciales delegadas, agregue el valor de la identidad SPN del servidor de aplicaciones. La configuración permite al conector de red privada suplantar a los usuarios de Active Directory en las aplicaciones que se definen en la lista.

    Captura de pantalla de ventana Conector-Propiedades SVR

Conector y servidor de aplicaciones en dominios diferentes

  1. Para obtener una lista de requisitos previos para trabajar con KCD entre dominios, vea Delegación limitada Kerberos entre dominios.

  2. Para habilitar la delegación de autenticación Kerberos desde el proxy de aplicación (conector), use la PrincipalsAllowedToDelegateTo propiedad de la cuenta de servicio de la aplicación web (webserviceaccount). El servidor de aplicaciones se ejecuta en webserviceaccounty el servidor de delegación es connectorcomputeraccount. Ejecute los siguientes comandos en un controlador de dominio (Windows Server 2012 R2 o posterior) en el mismo dominio que webserviceaccount. Utilice nombres simples (no basados en UPN) para ambas cuentas.

    Si webserviceaccount es una cuenta de equipo, use estos comandos:

    $connector= Get-ADComputer -Identity connectorcomputeraccount -server dc.connectordomain.com

Set-ADComputer -Identity webserviceaccount -PrincipalsAllowedToDelegateToAccount $connector

Get-ADComputer webserviceaccount -Properties PrincipalsAllowedToDelegateToAccount

    Si webserviceaccount es una cuenta de usuario, use estos comandos:

    $connector= Get-ADComputer -Identity connectorcomputeraccount -server dc.connectordomain.com

Set-ADUser -Identity webserviceaccount -PrincipalsAllowedToDelegateToAccount $connector

Get-ADUser webserviceaccount -Properties PrincipalsAllowedToDelegateToAccount

Configurar inicio de sesión único

  1. Publique la aplicación según las instrucciones en Publicar aplicaciones con el proxy de aplicación. Asegúrese de seleccionar Microsoft Entra ID como método de autenticación previa.

  2. Una vez que la aplicación aparezca en la lista de aplicaciones empresariales, selecciónela y seleccione Inicio de sesión único.

  3. Establezca el modo de inicio de sesión único en Autenticación integrada de Windows.

  4. Escriba el SPN de la aplicación interno del servidor de aplicaciones. En este ejemplo, el SPN de nuestra aplicación publicada es http/www.contoso.com. El SPN debe estar en la lista de servicios a los que el conector puede presentar credenciales delegadas.

  5. Elija la Identidad de inicio de sesión delegada que va a usar el conector en nombre de los usuarios. Para más información, consulte Trabajar con diferentes identidades locales y de nube.

    Configuración avanzada de aplicaciones

SSO para las aplicaciones no son de Windows

El flujo de delegación de Kerberos en el proxy de aplicación de Microsoft Entra se inicia cuando Microsoft Entra autentica al usuario en la nube. Una vez que la solicitud llega a las instalaciones, el conector de red privada de Microsoft Entra emite un vale Kerberos en nombre del usuario interactuando con el Directorio Activo local. El proceso se conoce como Delegación restringida de Kerberos (KCD).

En la fase siguiente, se envía una solicitud a la aplicación back-end con este vale Kerberos.

Hay varios mecanismos que definen cómo enviar el vale Kerberos en estas solicitudes. La mayoría de los servidores que no son de Windows esperan recibirlo en forma de token SPNEGO. El mecanismo se admite en el proxy de aplicación de Microsoft Entra, pero está deshabilitado de forma predeterminada. Se puede configurar un conector para SPNEGO o para un token Kerberos estándar, pero no para ambos.

Si configura una máquina de conector para SPNEGO, asegúrese de que todos los demás conectores del grupo de conectores también estén configurados con SPNEGO. Las aplicaciones que esperan un token Kerberos estándar deben enrutarse a través de otros conectores que no están configurados para SPNEGO. Algunas aplicaciones web aceptan ambos formatos sin necesidad de ningún cambio en la configuración.

Para habilitar SPNEGO:

  1. Abra un símbolo del sistema que se ejecute como administrador.

  2. Ejecute los siguientes comandos en los servidores conectores que necesitan SPNEGO.

    REG ADD "HKLM\SOFTWARE\Microsoft\Microsoft Entra private network connector" /v UseSpnegoAuthentication /t REG_DWORD /d 1
net stop WAPCSvc & net start WAPCSvc

Las aplicaciones que no son de Windows normalmente usan nombres de usuario o nombres de cuenta SAM en lugar de direcciones de correo electrónico de dominio. Si esa situación se aplica a las aplicaciones, debe configurar el campo de identidad de inicio de sesión delegado para conectar las identidades de nube a las identidades de la aplicación.

Trabajar con diferentes identidades locales y de nube

El proxy de aplicación supone que los usuarios tienen la misma identidad en la nube y en el entorno local. Sin embargo, algunas organizaciones deben usar identificadores alternativos para el inicio de sesión debido a directivas corporativas o requisitos de aplicación. Todavía puede habilitar KCD para el inicio de sesión único configurando una identidad de inicio de sesión delegada para cada aplicación. Esta configuración especifica la identidad que se va a usar para el inicio de sesión único.

Esta característica permite a las organizaciones habilitar el inicio de sesión único desde la nube a aplicaciones locales sin necesidad de que los usuarios administren diferentes nombres de usuario y contraseñas. Entre los escenarios habituales se incluyen los siguientes:

  • Usar varios dominios internos (por ejemplo, joe@us.contoso.com, joe@eu.contoso.com) con un único dominio en la nube (por ejemplo, joe@contoso.com).
  • Tener nombres de dominio internos no enrutables (por ejemplo, joe@contoso.usa) al usar nombres de dominio válidos en la nube.
  • Funcionamiento sin nombres de dominio internos (por ejemplo, joe).
  • Asignación de alias diferentes para usuarios locales y en la nube (por ejemplo, joe-johns@contoso.com frente a joej@contoso.com).

Con el proxy de aplicación, puede elegir la identidad que se usa para obtener el ticket Kerberos. Esta configuración se configura por aplicación y admite sistemas que requieren formatos nonemail o métodos de inicio de sesión alternativos.

Captura de pantalla de parámetro de identidad de inicio de sesión delegado

Si se usa la identidad de inicio de sesión delegada, es posible que el valor no sea único en todos los dominios o bosques de la organización. Puede evitar este problema al publicar estas aplicaciones dos veces con dos grupos diferentes de conector. Puesto que cada aplicación tiene una audiencia de usuarios diferente, puede unir sus conectores a un dominio diferente.

Si se usa el nombre de la cuenta SAM local para la identidad de inicio de sesión, el equipo que hospeda el conector debe agregarse al dominio en el que se encuentra la cuenta de usuario.

Configurar el inicio de sesión único para distintas identidades

  1. Configure Microsoft Entra Connect para que la identidad principal sea la dirección de correo electrónico (correo). La configuración se realiza como parte del proceso de personalización cambiando el campo Nombre principal de usuario en la configuración de sincronización. Esta configuración también determina cómo los usuarios inician sesión en Microsoft 365, equipos Windows y otras aplicaciones que usan Microsoft Entra ID como almacén de identidades.
    Captura de pantalla de la identificación de usuarios - lista desplegable de Nombre principal de usuario

  2. En las opciones de Configuración de la aplicación correspondientes a la aplicación que quiere modificar, seleccione la información en Identidad de inicio de sesión delegada que quiere usar:

    • Nombre principal de usuario (por ejemplo, joe@contoso.com).
    • Nombre principal de usuario alternativo (por ejemplo, joed@contoso.local).
    • Parte del nombre de usuario del nombre principal de usuario (por ejemplo, joe)
    • Parte del nombre de usuario de nombre principal de usuario alternativo (por ejemplo, joed)
    • Nombre de cuenta SAM local (depende de la configuración del controlador de dominio).

Solución de problemas de SSO para diferentes identidades

Si la aplicación del servidor responde con respuestas HTTP inesperadas, empiece a solucionar problemas comprobando el evento 24029 en el evento de inicio de sesión de la sesión del proxy de la aplicación en la máquina del conector. El campo "usuario" en los detalles del evento muestra la identidad usada para la delegación. Para habilitar los registros de sesión, vaya al Visor de eventos, abra el menú Ver y seleccione Mostrar registros analíticos y de depuración.

Pasos siguientes