Solución de problemas de errores de Kerberos en Internet Explorer

Este artículo le ayuda a aislar y corregir las causas de varios errores al acceder a sitios web configurados para usar la autenticación Kerberos en Internet Explorer. El número de posibles problemas es casi tan grande como el número de herramientas que están disponibles para resolverlos.

Síntoma común cuando se produce un error en Kerberos

Intenta acceder a un sitio web donde se ha configurado Windows Integrated Authenticated y espera usar el protocolo de autenticación Kerberos. En esta situación, el explorador le pide inmediatamente las credenciales, como se indica a continuación:

Aunque escriba un nombre de usuario y una contraseña válidos, se le pedirá de nuevo (total de tres mensajes). A continuación, se muestra una pantalla que indica que no se le permite acceder al recurso deseado. La pantalla muestra un código de estado HTTP 401 similar al siguiente error:

No autorizado
Error HTTP 401. El recurso solicitado requiere autenticación de usuario.

En el servidor Microsoft Internet Information Services (IIS), los registros del sitio web contienen solicitudes que terminan en un código de estado 401.2, como el registro siguiente:

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken  
DateTime IP GET /whoami.aspx - 80 – IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 1270  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 8

O bien, la pantalla muestra un código de estado 401.1, como el siguiente registro:

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 105  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 1 2148074245 18

Determinación de si se usa Kerberos

Al solucionar el error de autenticación Kerberos, se recomienda simplificar la configuración al mínimo. Es decir, un cliente, un servidor y un sitio IIS que se ejecuta en el puerto predeterminado. Además, puede seguir algunos pasos básicos de solución de problemas. Por ejemplo, use una página de prueba para comprobar el método de autenticación que se usa. Si usa ASP.NET, puede crear esta página de prueba de autenticación de ASP.NET.

Si usa ASP clásico, puede usar la siguiente página de Testkerb.asp:

<%
    authType=UCase(Request.ServerVariables("AUTH_TYPE"))
    authHeader=Request.ServerVariables("HTTP_AUTHORIZATION")
    response.write " Authentication Method : " & authType & "<BR>"
    LenAuthHeader = len(authHeader)
    response.write " Protocol : "
    if Len(authType ) =0 then response.write " Anonymous" else if authType<>"NEGOTIATE" then response.write authType else if LenAuthHeader>1000 then response.write "Kerberos" else response.write  "NTLM"
%>

También puede usar las siguientes herramientas para determinar si se usa Kerberos:

• Fiddler
• HttpWatch
• Monitor de red
• Herramientas para desarrolladores en el explorador

Para obtener más información sobre cómo se pueden generar estos seguimientos, consulte seguimiento del lado cliente.

Cuando se usa Kerberos, la solicitud enviada por el cliente es grande (más de 2000 bytes), ya que el HTTP_AUTHORIZATION encabezado incluye el vale de Kerberos. La siguiente solicitud es para una página que usa la autenticación de Windows basada en Kerberos para autenticar a los usuarios entrantes. El tamaño de la solicitud GET es superior a 4000 bytes.

Si se usa el protocolo de enlace NTLM, la solicitud será mucho más pequeña. La siguiente captura del lado cliente muestra una solicitud de autenticación NTLM. La solicitud GET es mucho más pequeña (menos de 1400 bytes).

Después de determinar que se produce un error en la autenticación Kerberos, compruebe cada uno de los siguientes elementos en el orden especificado.

Elementos para comprobar si se produce un error en la autenticación Kerberos

En las secciones siguientes se describen los elementos que puede usar para comprobar si se produce un error en la autenticación Kerberos.

¿Son el cliente y el servidor en el mismo dominio?

El uso de Kerberos requiere un dominio, ya que el controlador de dominio (DC) entrega un vale de Kerberos. Los escenarios avanzados también son posibles cuando:

• El cliente y el servidor no están en el mismo dominio, sino en dos dominios del mismo bosque.
• El cliente y el servidor están en dos bosques diferentes.

Estos posibles escenarios se describen en la sección ¿Por qué se produce un error en la delegación de Kerberos entre mis dos bosques?

¿ESTÁ CONFIGURADO IIS para usar la autenticación integrada?

Está habilitada la autenticación integrada en Internet Explorer

¿La dirección URL que se usa se resuelve en una zona de seguridad para la que se pueden enviar credenciales?

Ejecute siempre esta comprobación para los siguientes sitios:

• Sitios que coinciden con la zona intranet local del explorador.
• Sitios de la zona Sitios de confianza.

Puede comprobar en qué zona decide incluir el sitio el explorador. Para ello, abra el menú Archivo de Internet Explorer y, a continuación, seleccione Propiedades. La ventana Propiedades mostrará la zona en la que el explorador ha decidido incluir el sitio al que está navegando.

Puede comprobar si la zona en la que se incluye el sitio permite el inicio de sesión automático. Para ello, abra el menú opciones de Internet de Internet Explorer y seleccione la pestaña Seguridad . Después de seleccionar la zona deseada, seleccione el botón Nivel personalizado para mostrar la configuración y asegúrese de que el inicio de sesión automático está seleccionado. (Normalmente, esta característica está activada de forma predeterminada para las zonas Intranet y Sitios de confianza).

¿Está configurado el servidor IIS para enviar el encabezado WWW-Authenticate: Negotiate?

Si IIS no envía este encabezado, use la consola del Administrador de IIS para establecer el encabezado Negotiate a través de la propiedad de configuración NTAuthenticationProviders . Para obtener más información, vea Proveedores> de autenticación de <Windows. Puede acceder a la consola a través de la configuración Proveedores de los detalles de autenticación de Windows en el administrador de IIS.

¿Están instalados el cliente y el servidor en el mismo equipo?

De forma predeterminada, Kerberos no está habilitado en esta configuración. Para cambiar este comportamiento, debe establecer la clave del DisableLoopBackCheck Registro. Para obtener más información, vea KB 926642.

¿Puede el cliente obtener un vale de Kerberos?

Puede usar la herramienta Lista de Kerberos (KLIST) para comprobar que el equipo cliente puede obtener un vale de Kerberos para un nombre de entidad de servicio determinado. En este ejemplo, el nombre de entidad de seguridad de servicio (SPN) es http/web-server.

Cuando se produce un error en la solicitud de vale de Kerberos, no se usa la autenticación Kerberos. Puede producirse una reserva NTLM, porque el SPN solicitado es desconocido para el controlador de dominio. Si el controlador de dominio no es accesible, no se produce ninguna reserva NTLM.

Para declarar un SPN, consulte el artículo siguiente:

Cómo usar SPN al configurar aplicaciones web hospedadas en Internet Information Services.

¿Usa el servidor web un puerto distinto del predeterminado (80)

De forma predeterminada, Internet Explorer no incluye la información del número de puerto en el SPN que se usa para solicitar un vale de Kerberos. Puede ser un problema si usa IIS para hospedar varios sitios en diferentes puertos e identidades. En esta configuración, la autenticación Kerberos solo puede funcionar para sitios específicos aunque todos los SPN se hayan declarado correctamente en Active Directory. Para solucionar este problema, debe establecer el valor del FEATURE_INCLUDE_PORT_IN_SPN_KB908209 Registro. (Consulte la sección Claves de características de Internet Explorer para obtener información sobre cómo declarar la clave). Esta configuración obliga a Internet Explorer a incluir el número de puerto en el SPN que se usa para solicitar el vale de Kerberos.

¿Usa Internet Explorer el SPN esperado?

Si se accede a un sitio web mediante un nombre de alias (CNAME), Internet Explorer usa primero la resolución DNS para resolver el nombre del alias en un nombre de equipo (ANAME). A continuación, el nombre del equipo se usa para compilar el SPN y solicitar un vale de Kerberos. Incluso si la dirección URL especificada en la barra de direcciones de Internet Explorer es http://MYWEBSITE, Internet Explorer solicita un SPN para HTTP/MYSERVER si MYWEBSITE es un alias (CNAME) de MYSERVER (ANAME). Puede cambiar este comportamiento mediante la clave del FEATURE_USE_CNAME_FOR_SPN_KB911149 Registro. (Consulte las claves de características de Internet Explorer para obtener información sobre cómo declarar la clave).

Un seguimiento de Network Monitor es un buen método para comprobar el SPN asociado al vale de Kerberos, como en el ejemplo siguiente:

- Http: Request, GET /whoami.aspx , Using GSS-API Authorization
    Command: GET
  - URI: /whoami.aspx
     Location: /whoami.aspx
    ProtocolVersion: HTTP/1.1
    Accept:  image/gif, image/jpeg, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, */*
    Accept-Language:  en-US,en;q=0.5
    UserAgent:  Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; WOW64; Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729)
    Accept-Encoding:  gzip, deflate
    Host:  web-server
    Connection:  Keep-Alive
  - Authorization: Negotiate
   - Authorization:  Negotiate YIILcAYGKwYBBQUCoIILZDCCC2CgMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCCyoEggsmYIILIgYJKoZIhvcSAQICAQBuggsRMIILDaADAgEFoQMCAQ6iBwMFACAAAACjggRtYYIEaTCCBGWgAwIBBaEOGwxPREVTU1kuTE9DQUyiKjAooAMCAQKhITAfGwRIVFRQG
      WhiteSpace:  
    - NegotiateAuthorization:
       Scheme: Negotiate
     - GssAPI: 0x1
      - InitialContextToken:
       + ApplicationHeader:
       + ThisMech: SpnegoToken (1.3.6.1.5.5.2)
       - InnerContextToken: 0x1
        - SpnegoToken: 0x1
         + ChoiceTag:
         - NegTokenInit:
          + SequenceHeader:
          + Tag0:
          + MechTypes: Prefer MsKerberosToken (1.2.840.48018.1.2.2)
          + Tag2:
          + OctetStringHeader:
          - MechToken: 0x1
           - MsKerberosToken: 0x1
            - KerberosInitToken:
             + ApplicationHeader:
             + ThisMech: KerberosToken (1.2.840.113554.1.2.2)
             - InnerContextToken: 0x1
              - KerberosToken: 0x1
                 TokId: Krb5ApReq (0x100)
               - ApReq: KRB_AP_REQ (14)
                + ApplicationTag:
                + SequenceHeader:
                + Tag0:
                + PvNo: 5
                + Tag1:
                + MsgType: KRB_AP_REQ (14)
                + Tag2: 0x1
                + ApOptions:
                + Tag3:
                - Ticket: Realm: ODESSY.LOCAL, Sname: HTTP/web-server.odessy.local
                 + ApplicationTag:
                 + SequenceHeader:
                 + Tag0:
                 + TktVno: 5
                 + Tag1:
                 + Realm: ODESSY.LOCAL
                 + Tag2: 0x1
                 + Sname: HTTP/web-server.odessy.local
                 + Tag3: 0x1
                 + EncPart:
                + Tag4:

¿Coincide la identidad del grupo de aplicaciones con la cuenta asociada a SPN?

Cuando se envía un vale de Kerberos desde Internet Explorer a un servidor IIS, el vale se cifra mediante una clave privada. La clave privada es un hash de la contraseña que se usa para la cuenta de usuario asociada al SPN. Por lo tanto, solo una aplicación que se ejecuta en esta cuenta puede descodificar el vale.

El siguiente procedimiento es un resumen del algoritmo de autenticación Kerberos:

1. Internet Explorer determina un SPN mediante la dirección URL especificada en la barra de direcciones.

2. El SPN se pasa a través de una API de interfaz de proveedor de soporte técnico de seguridad (SSPI) (InitializeSecurityContext) al componente del sistema que se encarga de la seguridad de Windows (el proceso del servicio de subsistema de autoridad de seguridad local (LSASS). En esta fase, puede ver que el código de Internet Explorer no implementa ningún código para construir el vale de Kerberos. Internet Explorer solo llama a las API de SSPI.

3. LSASS usa el SPN que se pasa para solicitar un vale de Kerberos a un controlador de dominio. Si el controlador de dominio puede atender la solicitud (SPN conocido), crea un vale de Kerberos. A continuación, cifra el vale mediante una clave construida a partir del hash de la contraseña de la cuenta de usuario para la cuenta asociada al SPN. A continuación, LSASS envía el vale al cliente. En lo que respecta a Internet Explorer, el vale es un blob opaco.

4. Internet Explorer encapsula el vale kerberos proporcionado por LSASS en el Authorization: Negotiate encabezado y, a continuación, envía el vale al servidor IIS.

5. IIS controla la solicitud y la enruta al grupo de aplicaciones correcto mediante el encabezado de host especificado.

6. El grupo de aplicaciones intenta descifrar el vale mediante las API de SSPI/LSASS y siguiendo estas condiciones:

   • Si el vale se puede descifrar, la autenticación Kerberos se realiza correctamente. Todos los servicios asociados al vale (suplantación, delegación si el vale lo permite, etc.) están disponibles.

   • Si no se puede descifrar el vale, se devuelve un error de Kerberos (KRB_AP_ERR_MODIFIED). Este error es un error genérico que indica que el vale se modificó de alguna manera durante su transporte. Por lo tanto, el vale no se puede descifrar. Este error también se registra en los registros de eventos de Windows.

Si no declara explícitamente un SPN, la autenticación Kerberos solo funciona con una de las siguientes identidades de grupo de aplicaciones:

• Servicio de red
• ApplicationPoolIdentity
• Otra cuenta del sistema, como LOCALSYSTEM o LOCALSERVICE

Pero estas identidades no se recomiendan, porque son un riesgo para la seguridad. En este caso, el vale kerberos se crea mediante un SPN predeterminado que se crea en Active Directory cuando se agrega al dominio un equipo (en este caso, el servidor en el que se ejecuta IIS). Este SPN predeterminado está asociado a la cuenta de equipo. En IIS, la cuenta de equipo se asigna a Network Service o ApplicationPoolIdentity.

Si el grupo de aplicaciones debe usar una identidad distinta de las identidades enumeradas, declare un SPN (mediante SETSPN). A continuación, asóciela a la cuenta que se usa para la identidad del grupo de aplicaciones. Un error común es crear SPN similares que tengan cuentas diferentes. Por ejemplo:

• SETSPN http/mywebsite UserAppPool1
• SETSPN http/mywebsite UserAppPool2

Esta configuración no funcionará, ya que no hay ninguna manera determinista de saber si el vale de Kerberos para el SPN http/mywebsite se cifrará mediante la contraseña UserAppPool1 o UserAppPool2. Esta configuración suele generar errores de KRB_AP_ERR_MODIFIED. Para determinar si se encuentra en este escenario de SPN duplicados incorrectos, use las herramientas documentadas en el artículo siguiente:

Por qué todavía puede tener SPN duplicados en AD 2012 R2 y AD 2016

A partir de Windows Server 2008, también puede usar una versión actualizada de SETSPN para Windows que permita la detección de SPN duplicados mediante el setspn –X comando al declarar un nuevo SPN para la cuenta de destino. Para obtener más información, vea Setspn.

También se recomienda revisar los artículos siguientes:

• Problemas de autenticación Kerberos: problemas de nombre principal de servicio (SPN): parte 1

• Problemas de autenticación Kerberos: problemas de nombre principal de servicio (SPN): parte 2

• Problemas de autenticación Kerberos: problemas de nombre principal de servicio (SPN): parte 3

¿Se produce un error de autenticación Kerberos en IIS 7 y versiones posteriores aunque funcione en IIS 6?

La autenticación en modo kernel es una característica que se introdujo en IIS 7. Proporciona las siguientes ventajas:

• El rendimiento aumenta, ya que ya no se realizan transiciones de modo kernel a modo de usuario.
• La descodificación de vales kerberos se realiza mediante la cuenta de equipo y no la identidad del grupo de aplicaciones. Este cambio le permite tener varios grupos de aplicaciones que se ejecutan en identidades diferentes sin tener que declarar SPN.

¿Por qué se produce un error en la delegación aunque funciona la autenticación Kerberos?

En este escenario, compruebe los siguientes elementos:

• Zona de Internet Explorer que se usa para la dirección URL. La delegación de Kerberos solo se permite para las zonas Intranet y Sitios de confianza. (En otras palabras, Internet Explorer establece la ISC_REQ_DELEGATE marca cuando llama a InitializeSecurityContext solo si la zona que se determina es Intranet o Sitios de confianza).

• La cuenta de usuario del grupo de aplicaciones iis que hospeda el sitio debe tener establecida la marca Trusted for delegation (Confianza para delegación ) en Active Directory.

Si se sigue produciendo un error en la delegación, considere la posibilidad de usar la Configuration Manager Kerberos para IIS. Esta herramienta le permite diagnosticar y corregir configuraciones de IIS para la autenticación Kerberos y para los SPN asociados en las cuentas de destino. Para obtener más información, consulte el README.md. Puede descargar la herramienta desde aquí.

¿Por qué obtengo un rendimiento incorrecto cuando uso la autenticación Kerberos?

Kerberos es un protocolo de autenticación basado en solicitudes en versiones anteriores de Windows Server, como Windows Server 2008 SP2 y Windows Server 2008 R2. Significa que el cliente debe enviar el vale de Kerberos (que puede ser un blob bastante grande) con cada solicitud realizada al servidor. Es contrario a los métodos de autenticación que se basan en NTLM. De forma predeterminada, NTLM se basa en sesión. Significa que el explorador autenticará solo una solicitud cuando abra la conexión TCP al servidor. Cada solicitud posterior en la misma conexión TCP ya no requerirá autenticación para que se acepte la solicitud. En las versiones más recientes de IIS, a partir de Windows 2012 R2, Kerberos también se basa en la sesión. Solo el servidor debe autenticar la primera solicitud en una nueva conexión TCP. Las solicitudes posteriores no tienen que incluir un vale de Kerberos.

Puede cambiar este comportamiento mediante la propiedad authPersistNonNTLM si se ejecuta en IIS 7 y versiones posteriores. Si la propiedad se establece en true, Kerberos se basará en la sesión. De lo contrario, se basará en solicitudes. Tendrá un rendimiento peor porque tenemos que incluir una mayor cantidad de datos para enviar al servidor cada vez. Para obtener más información, vea Autenticación Kerberos basada en solicitudes frente a basada en sesión (o el parámetro AuthPersistNonNTLM).

¿Por qué se produce un error en la delegación de Kerberos entre mis dos bosques aunque solía funcionar?

Imagine la siguiente situación:

• Los usuarios de la aplicación se encuentran en un dominio dentro del bosque A.
• La aplicación se encuentra en un dominio dentro del bosque B.
• Tiene una relación de confianza entre los bosques.

En este escenario, la delegación de Kerberos puede dejar de funcionar, aunque se haya usado para trabajar anteriormente y no haya realizado ningún cambio en bosques o dominios. La autenticación Kerberos sigue funcionando en este escenario. Solo se produce un error en la delegación.

Este problema puede producirse debido a las actualizaciones de seguridad de Windows Server publicadas por Microsoft en marzo de 2019 y julio de 2019. Estas actualizaciones deshabilitan la delegación de Kerberos sin restricciones (la capacidad de delegar un token kerberos de una aplicación a un servicio back-end) a través de los límites del bosque para todas las confianzas nuevas y existentes. Para obtener más información, vea Novedades a la delegación de TGT entre las confianzas entrantes en Windows Server.

Claves de características de Internet Explorer

Estas claves son claves del Registro que activan o desactivan algunas características del explorador. Las claves se encuentran en las siguientes ubicaciones del Registro:

• HKEY_USERS\<UserSID>\Software\Microsoft\Internet Explorer\Main\FeatureControl : si se define en el nivel de usuario
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\ : si se define en el nivel de máquina

Las claves de característica se deben crear en una de estas ubicaciones, en función de si desea activar o desactivar la característica:

• para todos los usuarios del equipo
• solo para una cuenta específica

Estas claves deben crearse en la ruta de acceso correspondiente. Dentro de la clave, se debe declarar un valor DWORD denominado iexplorer.exe . El valor predeterminado de cada clave debe ser true o false, dependiendo de la configuración deseada de la característica. De forma predeterminada, el valor de ambas claves de característica, FEATURE_INCLUDE_PORT_IN_SPN_KB908209 y FEATURE_USE_CNAME_FOR_SPN_KB911149, es false. Para mayor integridad, este es un ejemplo de exportación del registro al convertir la clave de característica para incluir los números de puerto en el vale kerberos en true:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_INCLUDE_PORT_IN_SPN_KB908209]
"iexplore.exe"=dword:00000001

Más información

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