Autenticación de doble salto sin restricciones kerberos con Microsoft Edge (Chromium)

  • Artículo
  • Tiempo de lectura: 13 minutos

Se aplica a:   Internet Information Services

Introducción

Configurar Windows Autenticación basada en el protocolo de autenticación Kerberos puede ser un esfuerzo complejo, especialmente cuando se trata de escenarios como la delegación de identidad de un sitio front-end a un servicio back-end en el contexto de IIS y ASP.NET. Siga los pasos de este artículo para configurar la delegación de vales de autenticación y usar servicios con un explorador moderno como Microsoft Edge versión 87 o posterior.

En este artículo se supone que está configurando una arquitectura similar a la representada en el diagrama siguiente:

Diagrama que muestra la arquitectura de Windows autenticación basada en el protocolo de autenticación Kerberos.

  • El equipo Workstation-Client1 forma parte del mismo active directory que el servidor web principal, denominado Primary-IIS-SRV y el servidor web back-end, denominado Backend-Web-SRV.
  • Los usuarios del equipo Workstation-Client1 iniciarán sesión en el equipo con Windows cuenta de Active Directory.
  • A continuación, iniciarán un explorador (Microsoft Edge), navegarán a un sitio web ubicado en Web-Server, que es el nombre de alias usado para Primary-IIS-SRV y se autenticarán a través de la autenticación Windows con Kerberos.
  • El sitio web ubicado en Web-Server realizará llamadas HTTP con las credenciales del usuario autenticado a API-Server (que es el alias de Backend-Web-SRV) para recuperar los datos de la aplicación en nombre de los usuarios, mediante la delegación de credenciales Kerberos.

Los pasos siguientes le ayudarán a solucionar este escenario: la instalación funciona con Internet Explorer, pero cuando los usuarios adoptan Microsoft Edge, ya no pueden usar la característica de delegación de credenciales. Para usar la delegación de credenciales Kerberos, consulte Solucionar problemas de Kerberos en Internet Explorer en primer lugar.

Delegación restringida o sin restricciones

En el escenario anterior, ambas configuraciones permiten a los usuarios delegar credenciales de su sesión de usuario en la máquina Workstation-Client1 al servidor de API back-end mientras se conectan a través del servidor front-end web.

En una configuración de delegación Kerberos sin restricciones, la identidad del grupo de aplicaciones se ejecuta en Web-Server y se configura en Active Directory para que sea de confianza para la delegación en cualquier servicio. La cuenta del grupo de aplicaciones que se ejecuta en Web-Server puede delegar las credenciales de los usuarios autenticados del sitio web hospedado en ese servidor a cualquier otro servicio del active directory. Por ejemplo, un servidor SMTP, un servidor de archivos, un servidor de bases de datos, otro servidor web, etc. Esto se denomina delegación sin restricciones porque la cuenta del grupo de aplicaciones tiene el permiso (no está entrenado) para delegar credenciales a cualquier servicio al que se pone en contacto.

En una configuración de delegación restringida, la cuenta de Active Directory que se usa como identidad de grupo de aplicaciones solo puede delegar las credenciales de los usuarios autenticados en una lista de servicios autorizados para delegar. Si la aplicación web que reside en el servidor denominado Web-Server también debe ponerse en contacto con una base de datos y autenticarse en nombre del usuario, este nombre de entidad de seguridad de servicio (SPN) debe agregarse a la lista de servicios autorizados.

La delegación restringida es más segura que la delegación sin restricciones basada en el principio de privilegios mínimos. A una aplicación se le conceden los derechos que necesita para funcionar y nada más, mientras que la delegación sin restricciones permite a una aplicación ponerse en contacto con los recursos con los que no debe ponerse en contacto en nombre del usuario.

¿Cómo saber si el vale Kerberos obtenido en el cliente para enviar al Web-Server usa una delegación restringida o sin restricciones?

Use la herramienta de comandos klist presente en Windows para enumerar la memoria caché de vales Kerberos del equipo cliente (Workstation-Client1 en el diagrama anterior). Busque un vale denominado HTTP/ <Name of Web-Server> . Nota: es el SPN del servicio con el que <Name of Web-Server> desea ponerse en contacto y autenticarse a través de Kerberos. El vale también contiene algunas marcas. Dos de ellos son de interés: forwardable y ok_as_delegate .

  • La primera marca, , indica que KDC (centro de distribución de claves) puede emitir un nuevo vale con una nueva máscara forwardable de red si es necesario. Esto permite que un usuario inicie sesión en un sistema remoto y que el sistema remoto obtenga un nuevo vale en nombre del usuario para iniciar sesión en otro sistema back-end como si el usuario hubiera iniciado sesión en el sistema remoto localmente.

  • La segunda marca indica que la cuenta de servicio del servicio en la que el usuario está intentando autenticarse (en el caso del diagrama anterior, la cuenta del grupo de aplicaciones del grupo de aplicaciones de IIS que hospeda la aplicación web) es de confianza para la delegación sin ok_as_delegate restricciones.

Si estos servicios usan una delegación sin restricciones, los vales del equipo cliente contienen las ok_as_delegate marcas forwardable y. En la mayoría de los casos, cuando se configura la delegación restringida, los vales no contienen la ok_as_delegate marca, pero contienen la forwardable marca.

¿Por qué la delegación sin restricciones funciona en Internet Explorer y no en Microsoft Edge?

Cuando se intenta autenticar en un sitio web mediante autenticación basada en Kerberos, el explorador llama a una API de Windows para configurar el contexto de autenticación. La API en cuestión es InitializeSecurityContext . Esta API puede recibir una serie de marcas para indicar si el explorador permite el delegatable vale que el usuario ha recibido. El vale se marca como porque el servicio al que el usuario está intentando autenticarse tiene derecho a delegar credenciales de forma delegatable sin restricciones. Sin embargo, eso no significa que la aplicación que intente autenticarse (en este caso, el explorador) use esta capacidad.

De forma predeterminada, Internet Explorer pasa la marca a , lo que indica que si el vale se puede delegar, InitializeSecurityContext debe serlo. Microsoft Edge de la versión 87 y posterior no pasa la marca solo porque el InitializeSecurityContext vale está marcado con la ok_as_delegate marca. No se recomienda usar la delegación sin restricciones en las aplicaciones porque proporciona a las aplicaciones más privilegios de los necesarios. Las aplicaciones podrían delegar la identidad del usuario en cualquier otro servicio del dominio y autenticarse como el usuario, lo que no es necesario para la mayoría de las aplicaciones que usan la delegación de credenciales. Las aplicaciones deben ponerse en contacto solo con los servicios de la lista que se especificó al configurar la delegación restringida.

De forma predeterminada, Microsoft Edge funciona con delegación restringida, donde el sitio web de IIS que se ejecuta en Web-Server solo tiene derecho a ponerse en contacto con el sitio de api back-end hospedado en API-Server, como se muestra en la configuración de la cuenta de identidad del grupo de aplicaciones de Active Directory que se muestra a continuación:

Captura de pantalla de la configuración de la cuenta de identidad del grupo de aplicaciones.

Habilitar Edge-Chromium para trabajar con la delegación sin restricciones en Active Directory

Por motivos de compatibilidad, si debe mantener una aplicación con una delegación sin restricciones a través de Kerberos, habilite Microsoft Edge permitir la delegación de vales. Los pasos siguientes se detallan en las siguientes secciones de este artículo:

  1. Instale las plantillas administrativas para el Almacén central de directivas de grupo en Active Directory (si aún no está presente).
  2. Instale las Microsoft Edge administrativas.
  3. Crear un nuevo objeto de directiva de grupo.
  4. Edite la configuración de la directiva de grupo para permitirla delegación sin restricciones al autenticar en servidores .
  5. (Opcional) Compruebe si Microsoft Edge está usando las marcas de delegación correctas.

Paso 1: Instalar las plantillas administrativas para Active Directory

  1. Descargue las plantillas de plantillas administrativas (.admx) (para Windows Server 2019).

  2. Descargue el instalador y extraiga el contenido en una carpeta de su elección. Simplemente puede extraerlo en la ubicación predeterminada especificada del paquete, que es C:\Program Files (x86)\Microsoft Group Policy\Actualización de octubre de 2018 de Windows 10 (1809) v2\PolicyDefinitions.

  3. Una vez que se descomprima el paquete, busque la carpeta Sysvol en el controlador de dominio. La ruta de acceso a la carpeta es C:\Windows\SYSVOL\sysvol \. Dentro de la carpeta Sysvol hay una carpeta con el mismo nombre que el nombre de Active Directory (en el ejemplo aquí, Oddessy.local). Desde allí, vaya a la carpeta Directivas. Si no existe, cree una carpeta denominada Definiciones de directiva como se muestra a continuación:

    Captura de pantalla de la carpeta definiciones de directiva en la carpeta Directivas.

  4. Copie el contenido de la carpeta PolicyDefinitions (que se extrajo del instalador en la carpeta PolicyDefinitions) que creó dentro del dominio en la carpeta sysvol del controlador de dominio.

    Nota

    Los archivos extraídos por el instalador también contienen contenido localizado. Para ahorrar espacio, transfiera los archivos localizados solo para los idiomas deseados. Por ejemplo, la carpeta denominada fr-FR contiene todo el contenido localizado en francés.

  5. Una vez completada la transferencia, compruebe que las plantillas están disponibles en Active Directory. Para ello, abra el complemento Administración de directivas de grupo de Microsoft Management Console (presione Windows+R y, a continuación, escriba gpmc.msc para iniciar). Dentro de la administración de directivas de grupo, busque un objeto de directiva de grupo y ediélo.

    Captura de pantalla del objeto de directiva de grupo en el Editor de administración de directivas de grupo.

    Como se muestra en la captura de pantalla anterior, en el nodo Configuración del equipo, se encuentra un nodo Directivas y un nodo Plantillas administrativas.

Paso 2: Instalar las plantillas Microsoft Edge administrativas

Aunque es posible que tenga las plantillas administrativas de directiva en el controlador de dominio para empezar, tendrá que instalar los archivos de directiva de Microsoft Edge para tener acceso a la directiva diseñada para habilitar la delegación sin restricciones de salto doble a través de este explorador. Para instalar los archivos Microsoft Edge directiva, siga estos pasos:

  1. Vaya al sitio de descarga Microsoft Edge para empresas.

  2. Seleccione la versión que desea descargar del desplegable canal/versión. Se recomienda la versión estable más reciente.

  3. Selecciona la compilación que quieras en el desplegable de compilación y, por último, el sistema operativo de destino en el desplegable de la plataforma. Una vez realizada la selección, aparecerán dos botones más (un botón y un vínculo).

    Captura de pantalla de descarga e implementación Microsoft Edge página para empresas.

  4. Haga clic en OBTENER ARCHIVOS DE DIRECTIVA y acepte el contrato de licencia para descargar el archivo denominado MicrosoftEdgePolicyTemplates.cab. Este archivo contiene los archivos de definición de directiva para Microsoft Edge.

  5. Haga doble clic en el archivo para explorar el contenido (un archivo zip con el mismo nombre).

  6. Extraiga el contenido del archivo zip en una carpeta del disco local. El contenido extraído contendrá una carpeta denominada Windows en la que encontrará una subcarpeta denominada Admx. Esto contendrá las plantillas administrativas, así como sus versiones localizadas (debe necesitarlas en un idioma distinto del inglés).

    Captura de pantalla de la carpeta admx.

  7. Transferir los archivos .admx dentro de la misma carpeta en el directorio Sysvol al que se transfirieron las plantillas administrativas de la anterior (en el ejemplo anterior: C:\Windows\SYSVOL\sysvol\odessy.local\Policies\PolicyDefinitions).

  8. Abra el Editor de directivas de grupo de Active Directory y seleccione un objeto de directiva de grupo existente para editarlo para comprobar la presencia de las plantillas Microsoft Edge transferidas recientemente. Estos se ubicarán en una carpeta denominada Microsoft Edge ubicada debajo de la carpeta Plantillas administrativas en la vista de árbol:

    Captura de pantalla del Microsoft Edge en el Editor de administración de directivas de grupo.

Paso 3: Crear un nuevo objeto de directiva de grupo

Este es el modo de crear un nuevo objeto de directiva de grupo mediante el complemento MMC del Administrador de directivas de grupo de Active Directory:

  1. Presione la Windows+R para abrir el menú Ejecutar en el controlador de dominio.
  2. Escriba Gpmc.msc para abrir La Consola de administración de Microsoft y cargar el complemento Administrador de directivas de grupo de Active Directory.
  3. Busque el nodo Objetos de directiva de grupo en la vista de árbol de la consola y haga clic con el botón secundario en el nodo para abrir el menú contextual.
  4. Seleccione el elemento de menú Nuevo, rellene el nombre de la directiva de grupo que desea crear y, a continuación, haga clic en Aceptar.

Captura de pantalla del nuevo elemento de menú en el Editor de administración de directivas de grupo.

Paso 4: Editar la configuración de la directiva de grupo para permitir la delegación sin restricciones al autenticarse en servidores

El último paso es habilitar la directiva que permite al explorador de Microsoft Edge pasar la marca a la llamada api al realizar la autenticación mediante Kerberos a un sitio web Windows ok_as_delegate InitializeSecurityContext habilitado para integración. Si no sabe si el explorador Microsoft Edge está usando Kerberos para autenticar (y no NTLM), consulte Solucionar errores kerberos en Internet Explorer.

En el Editor de directivas de grupo de Active Directory, seleccione el objeto de directiva de grupo que se aplicará a los equipos de Active Directory desde los que tiene previsto permitir que los usuarios finales se autentiquen a través de la autenticación Kerberos y tengan sus credenciales delegadas en servicios back-end a través de una delegación sin restricciones. La directiva que habilitará la delegación sin restricciones de Microsoft Edge se encuentra en la carpeta de autenticación Http de las plantillas de Microsoft Edge como se muestra a continuación:

Captura de pantalla de la carpeta de autenticación H T T P en el Editor de administración de directivas de grupo.

Use esta configuración para configurar una lista de servidores para los que se permite la delegación de vales Kerberos.

Nota

Se debe proporcionar una lista de servidores. En el ejemplo usado al principio de este artículo, tendría que agregar el nombre del servidor Web-Server a la lista para permitir que la aplicación web de Web-Server front-end delegue las credenciales en la API-Server back-end.

Captura de pantalla de una lista de servidores.

Después de aplicar el objeto de directiva de grupo recién editado a los equipos cliente dentro del dominio, vaya ala página de autenticación de prueba en Solucionar errores kerberos en Internet Explorer y descargue desde la página de prueba de autenticación ASP.NET . Se mostrará una configuración ImpersonationLevel de Delegate en lugar de suplantar la señalización de que la delegación de credenciales ahora está permitida.

Captura de pantalla de la página de configuración ImpersonationLevel.

Para comprobar si la directiva se aplicó correctamente en la estación de trabajo cliente, abra una nueva pestaña Microsoft Edge y escriba edge://policy.

Captura de pantalla edge://policy página.

La directiva debe establecerse para indicar los valores de los nombres de servidor para los que Microsoft Edge puede realizar la delegación AuthNegotiateDelegateAllowlist de vales Kerberos. Si la directiva no aparece en la lista, no se ha implementado o se ha implementado en equipos incorrectos.

Paso 5 (opcional): compruebe si Microsoft Edge está usando las marcas de delegación correctas

Este es el paso de solución de problemas/comprobación opcional.

Una vez configurada e implementada la directiva, deben seguirse los siguientes pasos para comprobar si Microsoft Edge está pasando las marcas de delegación correctas a IntializeSecurityContext . Los pasos usan herramientas que ya están integradas en Microsoft Edge o que están disponibles como servicios en línea.

  1. Use la característica de registro disponible en Microsoft Edge para registrar lo que el explorador está haciendo al solicitar un sitio web. Para habilitar el registro:

    1. Abra una nueva Microsoft Edge y escriba edge://net-export/.

    2. Use la opción Incluir cookies y credenciales al realizar el seguimiento. Sin esta opción se omitirán los datos de nivel de seguimiento de autenticación.

      Captura de pantalla edge://net-export/ página.

    3. Haga clic en el botón Iniciar registro en disco y proporcione el nombre de archivo con el que desea guardar el seguimiento.

    4. Abra otra Microsoft Edge, vaya al sitio web en el que desea realizar la autenticación Windows con Microsoft Edge.

    5. Una vez que haya intentado autenticarse, vuelva a la pestaña anterior donde se ha habilitado el seguimiento y haga clic en el botón Detener registro. La interfaz de seguimiento indicará dónde se ha escrito el archivo que contiene el seguimiento.

  2. Use el archivo JSON que contiene el seguimiento para ver los parámetros que el explorador ha pasado a la función al InitializeSecurityContext intentar autenticarse. Para analizar el seguimiento, use el netlog_viewer.

  3. Dentro del seguimiento de análisis hay un registro de eventos similar al siguiente:

    t=3076 [st=12]       +AUTH_LIBRARY_INIT_SEC_CTX  [dt=3]
                      --> flags = {"delegated":false,"mutual":false,"value":"0x00000000"}
                      --> spn = "HTTP/web-server.odessy.local"

    Este registro muestra lo siguiente:

    • AUTH_LIBRARY_INIT_SEC_CTX significa que el explorador llama a la InitializeSecurityContext función.
    • "delegated":false significa que el vale no debe delegarse incluso si el vale está marcado como delegatable .
    • "mutual":false significa que el cliente (explorador) no requiere que el servidor también se autentique en el cliente y pruebe su identidad. Solo el cliente debe autenticarse en el servidor para demostrar su identidad.
    • HTTP/web-server.odessy.local es el SPN usado por el explorador al realizar la llamada de autenticación.