Páginas de diagnóstico para la solución de problemas de autenticación integrada de Windows

Solucionar problemas de escenarios de error de autenticación integrada de Windows puede ser difícil, especialmente cuando se trata de la delegación de credenciales kerberos. Aunque hay una lista de comprobación detallada sobre cómo asegurarse de que tiene la configuración correcta de Internet Information Services (IIS) para trabajar con la autenticación integrada de Windows y, opcionalmente, usar la delegación de credenciales, este artículo tiene como destino específicamente los siguientes escenarios:

• Puede iniciar sesión en el sitio web de destino desde el equipo cliente, pero no está seguro de si usa NTLM o Kerberos como mecanismo de autenticación.
• Puede iniciar sesión en el sitio web de destino, pero se le pedirá que inicie sesión solo después de escribir una combinación de nombre de usuario y contraseña.
• Puede acceder al sitio web de destino en el servidor front-end, pero se produce un error al iniciar una acción que requiera que el servidor front-end llame a un punto de conexión HTTP de back-end mediante las credenciales del usuario autenticado.

Para los fines de este artículo, tenga en cuenta el siguiente diseño:

• El cliente 1 es la estación de trabajo unida a un dominio o un portátil desde el que el usuario hipotético iniciará todos los intentos de conexión.

• Web-serv1 es el servidor IIS front-end que hospeda un sitio web de ASP.NET (en .NET Framework) que usa la autenticación integrada de Windows y se ejecuta mediante la identidad de una cuenta de servicio: domain\serviceaccount.

• Web-serv2 es el servidor web back-end que también hospeda un sitio de ASP.NET (en .NET Framework) que expondrá puntos de conexión de API para la aplicación front-end. También está configurado para permitir solicitudes que usan la autenticación integrada de Windows y se ejecutan en un grupo de aplicaciones que usa domain\serviceapiaccount como una identidad del grupo de aplicaciones.

Para facilitar la recopilación de datos para estos escenarios y no confiar en herramientas externas de recopilación de datos como Fiddler o WireShark (dado que las conexiones entre los tres equipos pueden usar HTTPS y, por tanto, todos los intercambios entre ellos se cifrarán), use las dos páginas de diagnóstico autocontenida en ASP.NET Páginas independientes para solucionar problemas de autenticación integrada de Windows en IIS.

Páginas de solución de problemas

Las dos páginas se codifican en ASP.NET Formularios web. Están diseñados para agrupar el código y el marcado de la página en un archivo que se puede copiar en la raíz de la aplicación web que está intentando solucionar, sin necesidad de compilación o implementación. Las páginas son:

• WhoAmI.aspx: esta página permite el volcado de información relacionada con la autenticación, como:

  • Método de autenticación usado para acceder al sitio de destino. Si el método se basa en el proveedor Negotiate para la autenticación integrada de Windows, la página muestra si Se usa Kerberos o NTLM para autenticar al usuario.

  • Identidad de la cuenta que ejecuta el grupo de aplicaciones que hospeda el sitio.

  • Nivel de suplantación para el usuario autenticado. Si se usa Kerberos para la autenticación y se permite la delegación de credenciales sin restricciones, el nivel de suplantación se marca como delegado. Si no es así, se marcará como suplantación en el caso de delegación restringida o suplantación simple.

  • La identidad del usuario autenticado y los grupos a los que pertenece el usuario.

  • La identidad de la cuenta que ejecuta el código de la página (puede ser un usuario autenticado o un usuario del grupo de aplicaciones, en función de la configuración de suplantación ).

  • Todos los valores de los encabezados de solicitud para las solicitudes que entran en la página de WhoAmI.aspx tal como se recuperan de las variables del servidor IIS.

    

• ScrapperTest.aspx: esta página se realiza para trabajar con la página de WhoAmI.aspx, lo que permite que las solicitudes del servidor front-end se dirijan a las direcciones URL del servidor back-end. La página presenta una interfaz de usuario que permite a un usuario:

  • Escriba la dirección URL deseada del recurso del servidor back-end que la página debe intentar cargar.

  • Determine si se autentican al cargar la página de ScrapperTest.aspx y, si se autentican, qué usuarios se autentican como.

  • En el escenario en el que el usuario se autentica realmente, una casilla permite volver a usar las credenciales del usuario al intentar cargar el recurso de back-end indicado en el cuadro de texto URL.

    

Implementación

Dado que ambas páginas son independientes, lo único necesario es:

1. Descargue las páginas del repositorio de GitHub.
2. Copie la página WhoAmI.aspx o ambas páginas en la raíz de las aplicaciones web de destino que se ejecutan dentro de IIS.
3. Realice una solicitud a la dirección URL del sitio anexando /WhoAmI.aspx o /ScrapperTest.aspx, en función de la página a la que desee acceder.

Uso

El primer escenario de uso consiste en intentar determinar qué método de autenticación se usa para acceder a un sitio web o una aplicación web determinada hospedada en IIS. En este caso, puede realizar solicitudes a la página de WhoAmI.aspx que ha implementado previamente en el sitio.

• En la primera solicitud, la página mostrará la información de autenticación. Si se usa el proveedor Negotiate para la autenticación integrada de Windows, también enumerará el protocolo de autenticación que se usa: Kerberos o NTLM.

• Las solicitudes posteriores en un escenario en el que Negotiate se usa como proveedor para la autenticación integrada de Windows solo mostrarán la etiqueta Basada en sesión junto al tipo de autenticación. Para obtener más información, consulte Autenticación Kerberos basada en solicitudes frente a autenticación Kerberos basada en sesión (o el parámetro AuthPersistNonNTLM).

• Toda la demás información de autenticación, como el usuario del grupo de aplicaciones, el usuario autenticado, los detalles del usuario de ejecución y los encabezados de la solicitud entrante, se mostrarán en cada solicitud.

La página WhoAmI.aspx también muestra un formulario pequeño en la parte inferior. Este formulario permite emitir POST solicitudes al servidor para probar cómo se comporta el explorador al emitir estos tipos de solicitudes. Si la página está inactiva durante más de 60 segundos, la conexión del Protocolo de control de transmisión (TCP) usada para descargar la página al explorador y autenticada por el servidor se verá grave debido a la inactividad. Por lo tanto, al realizar una POST solicitud, se abre una nueva conexión TCP y se debe volver a autenticar. Hay una sutileza con POST las solicitudes:

1. El explorador envía primero los encabezados de solicitud HTTP POST .
2. A continuación, emite el cuerpo de la POST solicitud, que contiene la información capturada de los distintos campos de entrada en el formulario HTTP mostrado en la página.

Si el explorador no espera después de enviar los encabezados de la POST solicitud, sino que envía el cuerpo directamente en una conexión no autenticada, pueden producirse los siguientes problemas:

• El servidor recibe los POST encabezados de solicitud y, dado que la conexión no está autenticada (suponiendo que se use la autenticación integrada de Windows u otra autenticación basada en desafíos), emite una respuesta 401 con el encabezado HTTP de respuesta de autenticación adecuado (WWW-Authenticate).
• Durante este tiempo, el explorador ya ha enviado el cuerpo de la POST solicitud antes de recibir la respuesta 401 del servidor.
• A continuación, el servidor recibe un cuerpo de solicitud no autenticado POST en una conexión que ha indicado previamente al cliente que requiere autenticación.
• Esto da como resultado el bloqueo de la conexión TCP subyacente por el servidor y el explorador podría mostrar un mensaje "Página web no está disponible".

La página ScrapperTest.aspx se usa para probar la delegación de escenarios de credenciales desde el servidor front-end al punto de conexión del servidor back-end. Una vez solicitada la página desde el explorador cliente, ofrecerá una interfaz de usuario que permita:

• Escriba la dirección URL del punto de conexión back-end al que debe conectarse el servidor front-end.
• Comprobar que el usuario está autenticado en el front-end y qué nombre de usuario se usa para conectarse al servidor front-end.
• Decidir (en caso de que la autenticación se use para acceder a la página de ScrapperTest.aspx ) si las credenciales del usuario autenticado deben pasarse con la solicitud al servidor back-end (si es posible suplantar y delegar).

Una vez seleccionado el botón Página de extracción , el código de la página de ScrapperTest.aspx emitirá una GET solicitud para la dirección URL de destino indicada. Si la casilla Usar credenciales está activada y se necesita autenticación para acceder al punto de conexión de back-end especificado, las credenciales del usuario autenticado también se usan para realizar la solicitud. Si una solicitud se realiza correctamente, el resultado se muestra en el control de área de texto de la página como salida HTTP sin formato de la respuesta recibida.

Un escenario de uso que se prevé es colocar la página de ScrapperTest.aspx y la página de WhoAmI.aspx dentro de la aplicación de ASP.NET que se contactaría en el servidor back-end. Por lo tanto, la respuesta HTTP recuperada por la página ScrapperTest.aspx será la salida HTML de la página WhoAmI.aspx cuando se ejecute en el back-end. A continuación, esta salida se puede evaluar para comprender cómo se autenticó la solicitud en el back-end y qué cuentas se usaron.

Más información

Para comprender aún más la configuración de la autenticación integrada de Windows mediante Kerberos, consulte:

• Solución de problemas de errores de Kerberos en Internet Explorer
• Autenticación de doble salto sin restricciones kerberos con Microsoft Edge (Chromium)
• Solicitud basada en la autenticación Kerberos basada en sesión (o el parámetro AuthPersistNonNTLM)