Solucionar problemas de las configuraciones de delegación restringida de Kerberos (KCD) con el proxy de aplicación de Microsoft Entra

Los métodos de inicio de sesión único varían de una aplicación a otra. El proxy de aplicación de Microsoft Entra proporciona la delegación restringida de Kerberos (KCD) de forma predeterminada. Los usuarios se autentican en aplicaciones privadas mediante Kerberos.

En este artículo se ofrece un punto de referencia único para solucionar y remediar los problemas más comunes. También le ofrece un diagnóstico de los problemas de implementación más complejos.

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

• La implementación del proxy de aplicación de Microsoft Entra y el acceso general a aplicaciones sin KCD. Para obtener más información, consulte Introducción al proxy de aplicación.
• La aplicación publicada se basa en Internet Information Services (IIS) y la implementación de Kerberos de Microsoft.
• Los hosts de servidor y aplicación residen en un único dominio de Microsoft Entra. Encontrará más información acerca de los escenarios de bosque y entre dominios en las notas del producto para KCD.
• 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 enriquecidos no se detallan en este artículo.

Requisitos previos

Las configuraciones erróneas más simples o los errores generales son los que causan la mayoría de los problemas. Compruebe todos los requisitos previos de Uso del inicio de sesión único de KCD con el proxy de aplicación antes de pasar a solucionar problemas.

Los hosts de conector no tienen restringida la comunicación solo con los controladores de dominio (DC) de sitios locales específicos. Compruebe el controlador de dominio que se está usando, ya que podría cambiar.

Asimismo, los escenarios entre dominios se basan en referencias que dirigen a un host de conector hacia controladores de dominio que pueden residir fuera del perímetro de la red local. En estos casos, es igualmente importante enviar tráfico hacia los controladores de dominio que representan otros dominios respectivos. De lo contrario, se produce un error en la delegación.

Evite dispositivos activos de un sistema de prevención de intrusiones (IPS) o un sistema de detección de intrusiones (IDS) entre hosts de conectores y controladores de dominio. Estos dispositivos son demasiado invasivos e interfieren con el tráfico principal de la llamada a procedimiento remoto (RPC).

Pruebe la delegación en escenarios simples. Cuantas más variables introduzca, con más tendrá que trabajar. Para ahorrar tiempo, limite las pruebas a un solo conector. Agregue más conectores después de resolver el problema.

Algunos factores del entorno también podrían provocar un problema. Para evitar estos factores, minimice arquitectura tanto como sea posible durante las pruebas. Por ejemplo, es común encontrar listas de control de acceso (ACL) mal configuradas en el firewall interno. Si es posible, envíe todo el tráfico de un conector directamente a los controladores de dominio y a la aplicación de back-end.

El mejor lugar para colocar los conectores es lo más cerca posible de sus destinos. Insertar un firewall al realizar pruebas, agrega complejidad innecesaria y puede prolongar sus investigaciones.

¿Qué muestra un problema de KCD? Hay varias indicaciones comunes de que el inicio de sesión único de KCD está fallando. Los primeros signos de un problema aparecen en el navegador.

Ambas imágenes muestran el mismo síntoma: error de inicio de sesión único. Se denegó el acceso de usuario a la aplicación.

Solución de problemas

Separe la solución de problemas en las tres fases.

Autenticación previa del cliente

El usuario externo se autentica mediante un explorador. Es fundamental poder realizar la autenticación previa en Microsoft Entra ID para que el inicio de sesión único (SSO) de KCD funcione. Debe probar y abordar este asunto si hay algún problema. La fase de autenticación previa no guarda relación con KCD ni con la aplicación publicada. Debería ser bastante fácil corregir cualquier discrepancia con una comprobación de que la cuenta existe en Microsoft Entra ID. Compruebe que la aplicación no está deshabilitada o bloqueada. La respuesta de error en el explorador suele ser lo bastante descriptiva como para entender la causa.

Servicio de delegación

Conector de red privada que obtiene un vale de servicio Kerberos para los usuarios de un centro de distribución de claves (KCD) de Kerberos.

Las comunicaciones externas entre el cliente y el front-end de Azure no tienen ninguna relación con KCD. Estas comunicaciones solo sirven para comprobar que KCD funciona. Por lo tanto, se proporciona al servicio de proxy de aplicación un identificador de usuario válido que se usará para obtener un vale de Kerberos. Sin este id., KCD no funciona y se produce un error.

Los mensajes de error del explorador suelen proporcionar buenos indicios de por qué se producen errores. Registre los campos activity ID y timestamp en la respuesta. La información ayuda a poner en correlación el comportamiento de eventos reales en el registro de eventos de proxy de aplicación.

Las entradas correspondientes en el registro de eventos se muestran como los eventos 13019 o 12027. Busque los registros de eventos del conector en Registros de aplicaciones y servicios>Microsoft>Red privada de Microsoft Entra>Conector>Administración.

1. Use un registro A en el sistema de nombres de dominio (DNS) interno de la dirección de la aplicación, en lugar de unCName.
2. Vuelva a confirmar que el host de conector tenga derecho para delegar en el nombre de entidad de seguridad de servicio (SPN) de la cuenta de destino designada. Vuelva a confirmar que seleccionó Use any authentication protocol (Usar cualquier protocolo de autenticación). Para obtener más información, consulte el artículo de configuración del SSO.
3. Compruebe que existe solo una instancia de SPN en Microsoft Entra ID. Emita setspn -x desde un símbolo del sistema en cualquier host de miembro de dominio.
4. Compruebe que se aplica una política de dominio que limite el tamaño máximo de los tokens de Kerberos emitidos. La política impide que el conector obtenga un token si es excesivo.

El siguiente paso que se recomienda para obtener más información de bajo nivel sobre los problemas, es realizar un seguimiento de red que capture los intercambios entre el host de conector y una delegación restringida de Kerberos (KDC) de dominio. Para obtener más información, consulte la información que se proporciona acerca de la solución de problemas.

Si la generación de vales no presenta problemas, verá un evento en los registros que indica que se produjo un error en la autenticación porque la aplicación devolvió un error 401. Este evento indica que la aplicación de destino rechazó su vale. Vaya al paso siguiente.

Aplicación de destino

Es el consumidor del vale de Kerberos que proporciona el conector. En esta fase, espere a que el conector envíe un vale de servicio de Kerberos al back-end. El vale es un encabezado en la primera solicitud de la aplicación.

1. Mediante la dirección URL interna de la aplicación definida en el portal, compruebe que la aplicación sea accesible directamente desde el explorador en el host de conector. Entonces podrá iniciar sesión correctamente. Encontrará detalles sobre el conector en la página de solución de problemas.

2. Confirme que la autenticación entre el explorador y la aplicación esté utilizando Kerberos.

3. Ejecute DevTools (F12) en Internet Explorer o use Fiddler desde el host de conector. Use la dirección URL interna para ir a la aplicación. Para asegurarse de que Negotiate o Kerberos esté presente, inspeccione los encabezados de autorización web ofrecidos que se devuelven en la respuesta de la aplicación.

   • El siguiente blob de Kerberos que devuelve el explorador en respuesta a la aplicación, comienza con YII. Estas letras indican que Kerberos se está ejecutando. Por otra parte, Microsoft NT LAN Manager (NTLM) siempre empieza por TlRMTVNTUAAB, que se convierte en el Proveedor de compatibilidad para seguridad de NTLM (NTLMSSP) cuando se descodifica desde Base64. Si ve TlRMTVNTUAAB al principio del blob, significa que Kerberos no está disponible. Si no ve TlRMTVNTUAAB, es probable que Kerberos esté disponible.

     Nota:

     Si usa Fiddler, este método requiere deshabilitar temporalmente la protección ampliada en la configuración de la aplicación en IIS.

     

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

4. Elimine temporalmente NTLM de la lista de proveedores en el sitio de IIS. Acceda a la aplicación directamente desde Internet Explorer en el host del conector. NTLM ya no se encuentra en la lista de proveedores. Puede acceder a la aplicación usando solo Kerberos. Si el acceso falla, puede haber un problema con la configuración de la aplicación. La autenticación Kerberos no funciona.

   • Si Kerberos no está disponible, compruebe la configuración de autenticación de la aplicación en IIS. Asegúrese de que Negotiate aparece en la parte superior, con NTLM justo debajo de él. Si ve No negociar, Kerberos o Negotiate, o PKU2U, continúe solo si Kerberos funciona.

     

   • Con Kerberos y NTLM listos, debe deshabilitar temporalmente la autenticación previa de la aplicación en el portal. Pruebe a acceder a ella desde Internet mediante la dirección URL externa. Se le pedirá que se autentique. Puede hacerlo con la misma cuenta que usó en el paso anterior. Si no, es que hay un problema con la aplicación de back-end, y no con KCD.

   • Vuelva a habilitar la autenticación previa en el portal. A continuación, autentíquese con Azure; para ello, intente conectarse a la aplicación mediante su dirección URL externa. Si se produce un error de SSO, verá un mensaje de error en el explorador, además del evento 13022 en el registro:

     Conector de red privada de Microsoft Entra no puede autenticar al usuario porque el servidor back-end responde a los intentos de autenticación Kerberos con un error HTTP 401.

     

   • Comprobar la aplicación de IIS. Asegúrese de que el grupo de aplicaciones y el SPN estén configurados para que puedan usar la misma cuenta en Microsoft Entra ID. Navegue por IIS, tal como se muestra en la siguiente ilustración.

     

     Después de conocer la identidad, asegúrese de que esta cuenta esté configurada con el SPN en cuestión. Un ejemplo es setspn –q http/spn.wacketywack.com. Escriba lo siguiente en una ventana del símbolo del sistema.

     

   • Compruebe el SPN que se definió según la configuración de la aplicación en el portal. Asegúrese de que usa el mismo SPN configurado con el destino de la cuenta de Microsoft Entra por grupo de aplicaciones de la aplicación.

   • Vaya a IIS y 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 UseAppPoolCredentials está establecido en True.

     

     Cambie el valor a True. Para quitar todos los vales de Kerberos en la caché desde el servidor de back-end, ejecute el comando.

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

Si deja el modo Kernel habilitado, mejora el rendimiento de las operaciones de Kerberos. Asimismo, también provoca que el vale del servicio solicitado se descifre mediante la cuenta de la máquina. Esta cuenta también se llama Sistema Local. Establezca este valor en True para interrumpir el proceso de KCD cuando la aplicación esté alojada en más de un servidor de una granja de servidores.

• Como comprobación adicional, deshabilite también la protección extendida. En algunos casos, la protección extendida interrumpe el proceso de KCD cuando se habilita en configuraciones específicas. En esos casos, una aplicación se publica como una subcarpeta del sitio web predeterminado. Esta aplicación está configurada para que solo pueda realizarse una autenticación anónima. Además, todos los cuadros de diálogo están atenuados, lo que sugiere que los objetos secundarios no heredarán ninguna configuración activa. Es recomendable que haga pruebas con esto, pero no olvide restaurar este valor a habilitado, cuando le sea posible.

  Este control adicional le permite usar la aplicación publicada. Puede poner en marcha más conectores que también están configurados para realizar procesos de delegado. Para obtener más información, lea la guía técnica detallada Solución de problemas del proxy de aplicación de Microsoft Entra.

Si aún no puede realizar ningún progreso, póngase en contacto con el servicio de soporte técnico de Microsoft para obtener ayuda. Cree una incidencia de soporte técnico directamente en el portal.

Otros escenarios

El proxy de aplicación de Microsoft Entra solicita un vale de Kerberos antes de enviar su solicitud a una aplicación. Algunas aplicaciones no permiten este método de autenticación. Estas aplicaciones esperan que se lleven a cabo negociaciones 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 mediante un error 401. Este tipo de negociación de Kerberos se puede habilitar con los pasos descritos en este documento: Delegación restringida de Kerberos para el inicio de sesión único.

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

Pasos siguientes

Configurar KCD en un dominio administrado.