Compartir a través de

Solución de problemas de la delegación restringida de Kerberos

Los métodos de inicio de sesión único (SSO) varían de una aplicación a otra. El proxy de aplicación Microsoft Entra proporciona delegación restringida (KCD) de Kerberos de forma predeterminada. En el proxy de aplicación, un usuario se autentica en una aplicación privada mediante Kerberos.

En este artículo se describe cómo resolver los problemas más comunes en la configuración de KCD. Incluye pasos de diagnóstico que puede realizar para implementaciones más complejas.

En este artículo se da por supuesto lo siguiente:

  • El proxy de aplicación de Microsoft Entra se implementa y tiene acceso general a aplicaciones que no son de KCD.

    Para obtener más información, consulte Introducción al proxy de aplicación.

  • Una aplicación publicada se basa en Internet Information Services (IIS) y en la implementación de Microsoft de Kerberos.

  • Los hosts de servidor y aplicaciones se encuentran en un único dominio de Microsoft Entra.

    Para obtener más información sobre los escenarios entre dominios y bosques, consulte las notas del producto Descripción de la delegación restringida de Kerberos con el proxy de aplicación.

  • La aplicación se publica en un inquilino de Microsoft Entra con la autenticación previa habilitada. Se espera que los usuarios se autentiquen mediante la autenticación basada en formularios.

    Los escenarios de autenticación de cliente enriquecido no se tratan en este artículo.

Consideraciones

En la lista siguiente se describen las consideraciones fundamentales para la configuración y el uso de KCD con el proxy de aplicación Microsoft Entra:

  • La mayoría de los problemas son los errores básicos de configuración o los errores generales. Antes de comenzar a solucionar problemas, compruebe todos los requisitos previos en Usar KCD SSO con proxy de aplicación.

  • Los hosts del conector no están restringidos para comunicarse solo con un controlador de dominio (DC) de sitio local específico. Compruebe el controlador de dominio que utiliza porque podría cambiar.

  • Los escenarios entre dominios se basan en referencias que dirigen un host de conector a controladores de dominio que podrían estar fuera del perímetro de la red local. En estos casos, es igualmente importante enviar tráfico a los controladores de dominio que representan otros dominios respectivos. Si no lo hace, se produce un error en la delegación.

  • Evitar dispositivos activos del sistema de prevención de intrusiones (IPS) o del sistema de detección de intrusiones (IDS) entre los hosts de conectores y los controladores de dominio (DC) debido a la interferencia con el tráfico principal de llamadas a procedimientos remotos (RPC).

  • Pruebe la delegación en un escenario sencillo. Cuantas más variables introduzca en un escenario, más complejas serán la configuración y la solución de problemas. Para ahorrar tiempo, limite las pruebas a un solo conector. Agregue más conectores una vez que se resuelva el problema.

  • Los factores ambientales pueden contribuir a la causa de un problema. Para evitar estos factores, minimice la arquitectura tanto como sea posible durante las pruebas. Por ejemplo, las listas de control de acceso (ACL) de firewall interno mal configuradas son comunes. Si es posible, envíe todo el tráfico de un conector directamente a los controladores de dominio y a la aplicación back-end.

  • El mejor lugar para colocar los conectores es lo más cerca posible de sus objetivos. Un firewall que se encuentra en línea cuando se prueba el conector agrega complejidad innecesaria y puede prolongar sus investigaciones.

  • ¿Qué indica un problema de KCD? Varios errores comunes indican que el SSO de KCD está fallando. Los primeros signos de un problema aparecen en el navegador.

    Las dos capturas de pantalla siguientes muestran el mismo síntoma de error de SSO: Se deniega el acceso del usuario a la aplicación.

    Captura de pantalla que muestra un ejemplo de un error de configuración de KCD incorrecto, con el error Delegación restringida de Kerberos incorrecta resaltado.

    Captura de pantalla que muestra un ejemplo de error de autorización debido a la falta de permisos.

Solución de problemas

Puede solucionar problemas de KCD en tres etapas. Verifique estas partes del proceso KCD en el siguiente orden:

  • Autenticación previa del cliente
  • El servicio de delegación
  • La aplicación de destino

Autenticación previa del cliente

La autenticación previa del cliente se refiere a un usuario externo que se autentica en una aplicación a través de un navegador. La capacidad de autenticarse previamente en el identificador de Microsoft Entra es necesaria para que el SSO de KCD funcione.

Pruebe primero la autenticación previa del cliente y resuelva cualquier problema. La fase de autenticación previa no está relacionada con KCD ni con la aplicación publicada. Es fácil corregir cualquier discrepancia comprobando que la cuenta del sujeto existe en el identificador de Microsoft Entra. Comprueba que la aplicación no esté disponible o bloqueada. La respuesta de error en el navegador suele ser lo suficientemente descriptiva como para explicar la causa.

El servicio de delegación

El servicio de delegación de Kerberos es el conector de red privada que obtiene un vale de servicio de Kerberos de un centro de distribución de claves (KDC) de Kerberos. El usuario de la aplicación se autentica con la aplicación a través del ticket.

Las comunicaciones externas entre el cliente y el front-end de Azure no tienen ningún efecto en la delegación restringida. Estas comunicaciones solo garantizan que KCD funcione. Al servicio de proxy de aplicación se le asigna un identificador de usuario válido que obtiene un vale de Kerberos. Sin este identificador, KCD no puede producirse y se produce un error en el SSO.

Los mensajes de error del explorador proporcionan información útil sobre por qué se produce un error en el inicio de sesión. Registre los valores para TransactionID y Timestamp en la respuesta al inicio de sesión de la aplicación. La información ayuda a correlacionar el comportamiento con los eventos que aparecen en el registro de eventos del proxy de aplicación.

Captura de pantalla que muestra un mensaje de error de configuración de delegación restringida de Kerberos.

Las entradas correspondientes en el registro de eventos son los identificadores de evento 13019 o 12027. Para ver los registros de eventos del conector, vaya a Registros de aplicaciones y servicios Microsoft>>Entra private network>Connector>Admin.

Para solucionar un problema de delegación restringida:

  1. En el sistema de nombres de dominio (DNS) interno para la dirección de la aplicación, utilice un registro A, no un registro CNAME.
  2. Compruebe que el host del conector está configurado con permisos para delegar en el nombre principal de servicio (SPN) de la cuenta de destino. Compruebe que la opción Usar cualquier protocolo de autenticación esté seleccionada. Para obtener más información, consulte Configuración de SSO.
  3. Compruebe que solo existe una instancia del SPN en el identificador de Microsoft Entra. Para comprobar un único SPN, en un símbolo del sistema de cualquier host miembro del dominio, ejecute setspn -x.
  4. Compruebe que se aplica una directiva de dominio que limite el tamaño máximo de los tokens Kerberos emitidos . La política impide que el conector obtenga un token si el tamaño del token supera un máximo establecido.
  5. Ejecutar un seguimiento de red que capture los intercambios entre el host del conector y un KCD de dominio es el siguiente mejor paso para obtener más detalles sobre el problema. Para obtener más información, puede consultar las notas del producto detalladas Solución de problemas del proxy de aplicación Microsoft Entra.

Si la emisión de tickets funciona correctamente, es probable que los registros muestren un evento que indique que se produjo un error de autenticación porque la aplicación devolvió un error 401. Este evento indica que la aplicación de destino rechazó el vale de acceso. Vaya a la siguiente etapa de solución de problemas.

La aplicación

La aplicación de destino procesa el vale de Kerberos proporcionado por el conector. En esta etapa, el conector incluye un vale de servicio Kerberos como encabezado en la primera solicitud de aplicación al back-end.

Para solucionar un problema de aplicación:

  1. Asegúrese de que la aplicación sea accesible. Inicie sesión directamente desde el explorador en el host del conector mediante la dirección URL interna definida en Azure Portal. Si el inicio de sesión se realiza correctamente, se podrá acceder a la aplicación.

  2. Compruebe si el navegador y la aplicación utilizan Kerberos para la autenticación. Desde el host del conector, use DevTools de Internet Explorer (presione F12) o Fiddler para acceder a la aplicación a través de la dirección URL interna. Busque "Negotiate" o "Kerberos" en los encabezados de autorización web de la respuesta de la aplicación.

    La respuesta del explorador a la aplicación incluye un blob en Kerberos que comienza por YII, lo que confirma que Kerberos se está ejecutando. Por el contrario, una respuesta de Microsoft NT LAN Manager (NTLM) siempre comienza con TlRMTVNTUAAB. Cuando se descodifica desde Base64, esta respuesta lee NTLM Security Support Provider (NTLMSSP). Si los blobs comienzan por TlRMTVNTUAAB, Kerberos no está disponible. Si no es así, es probable que Kerberos esté disponible.

    Nota:

    Si usa Fiddler, debe deshabilitar temporalmente la protección extendida en la configuración de la aplicación en IIS.

    Captura de pantalla que muestra un cuadro de diálogo de inspección de red del navegador.

    El blob de esta captura de pantalla no comienza con TIRMTVNTUAAB. Por lo tanto, en este ejemplo, Kerberos está disponible y el blob de Kerberos no comienza con YII.

  3. En el sitio de IIS, quite temporalmente NTLM de la lista de proveedores. Acceda a la aplicación directamente desde Internet Explorer en el host del conector. NTLM ya no está en la lista de proveedores, por lo que solo puede acceder a la aplicación mediante Kerberos. Si se produce un error en el acceso, se indica un problema con la configuración de la aplicación. La aplicación no procesa la autenticación Kerberos.

  4. Si Kerberos no está disponible, compruebe la configuración de autenticación de la aplicación en IIS. Asegúrese de que Negociar aparezca en la parte superior y NTLM justo debajo. Si ve Not Negotiate, Kerberos o Negotiate, o PKU2U, continúe solo si Kerberos funciona.

    Captura de pantalla que muestra los proveedores de autenticación de Windows.

  5. Con Kerberos y NTLM en su lugar, en el portal, deshabilite temporalmente la autenticación previa para la aplicación. Intente acceder a la aplicación en un navegador mediante la URL externa. Se le solicitará que se autentique. Use la misma cuenta que usó en un paso anterior. Si no puede autenticarse e iniciar sesión, hay un problema con la aplicación back-end, no con KCD.

  6. Vuelva a habilitar la autenticación previa en el portal. Autentique a través de Azure intentando conectarse a la aplicación a través de su dirección URL externa. Si se produce un error en el inicio de sesión único, verá un mensaje de error "prohibido" en el explorador y el identificador de evento 13022 en el registro:

    Microsoft Entra private network connector can't authenticate the user because the backend server responds to Kerberos authentication attempts with an HTTP 401 error.

    Captura de pantalla que muestra un mensaje de error HTTP 401 prohibido.

  7. Compruebe la aplicación IIS. Asegúrese de que el grupo de aplicaciones configurado y el SPN estén configurados para usar la misma cuenta en el identificador de Microsoft Entra. En IIS, vaya a la carpeta como se muestra en la siguiente captura de pantalla:

    Captura de pantalla que muestra un cuadro de diálogo de configuración de la aplicación IIS.

    Compruebe la identidad y, a continuación, asegúrese de que esta cuenta está configurada con el SPN. En un símbolo del sistema, por ejemplo, ejecute setspn –q http/spn.contoso.com.

    Captura de pantalla que muestra la ventana de comandos de SetSPN.

  8. En el portal, compruebe el SPN definido con la configuración de la aplicación. Asegúrese de que el grupo de aplicaciones de la aplicación usa el mismo SPN que se establece para la cuenta de Microsoft Entra de destino.

  9. En IIS, seleccione la opción Editor de configuración de la aplicación. Vaya a system.webServer/security/authentication/windowsAuthentication. Asegúrese de que el valor de UseAppPoolCredentials es True.

    Captura de pantalla que muestra la opción de credenciales de grupos de aplicaciones de configuración de IIS.

    Cambie el valor a True si es necesario. Elimine todos los vales de Kerberos almacenados en caché del servidor back-end ejecutando el siguiente comando:

    Get-WmiObject Win32_LogonSession | Where-Object {$_.AuthenticationPackage -ne 'NTLM'} | ForEach-Object {klist.exe purge -li ([Convert]::ToString($_.LogonId, 16))}

  10. Si el modo kernel está habilitado, las operaciones de Kerberos mejoran. Pero el ticket para el servicio solicitado también debe descifrarse mediante la cuenta de la máquina. Esta cuenta también se denomina sistema local. Establezca este valor en True para interrumpir KCD cuando la aplicación esté alojada en más de un servidor de una granja de servidores.

  11. Como otra comprobación, deshabilite la protección extendida. En algunos escenarios de prueba, la protección extendida rompió KCD cuando se habilitó en configuraciones específicas. En esos casos, una aplicación se publicó como una subcarpeta del sitio web predeterminado. Esta aplicación solo está configurada para la autenticación anónima. Todos los cuadros de diálogo están inactivos, sin ninguna selección disponible, lo que sugiere que los objetos secundarios no heredarán ninguna configuración activa. Le recomendamos que pruebe, pero no olvide restaurar este valor a habilitado si es posible.

    Esta comprobación adicional le permite usar la aplicación publicada. Puede generar más conectores que también estén configurados para delegar. Para obtener más información, lea el tutorial técnico más detallado Solución de problemas del proxy de aplicación Microsoft Entra.

Si aún no puede resolver el problema de autenticación de la aplicación, cree una incidencia de soporte directamente en el portal.

Otros escenarios

El proxy de aplicación de Microsoft Entra solicita un vale de Kerberos antes de enviar una solicitud a una aplicación. Algunas aplicaciones no admiten este método de autenticación. Estas aplicaciones están configuradas para responder a pasos de autenticación más convencionales. La primera solicitud es anónima, lo que permite que la aplicación responda con los tipos de autenticación que admite a través de un error 401. Puede configurar este tipo de negociación de Kerberos completando los pasos descritos en Delegación restringida de Kerberos para SSO.

La autenticación de varios saltos se usa normalmente cuando una aplicación está en niveles. Los niveles incluyen un back-end y un front-end. Ambos niveles requieren autenticación. Por ejemplo, puede crear una aplicación en capas mediante SQL Server Reporting Services. Para obtener más información, consulte Configuración de la delegación restringida de Kerberos para páginas de proxy de inscripción web.

Contenido relacionado