Solución 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 La autenticación integrada de Windows y espera usar el protocolo de autenticación Kerberos. En esta situación, el explorador le pedirá 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 (tres avisos totales). A continuación, se muestra una pantalla que indica que no tiene permiso para 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 usuarios.

En el servidor de 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 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 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

Determinar si se usa Kerberos

Al solucionar problemas de error de autenticación Kerberos, se recomienda simplificar la configuración al mínimo. Es decir, un cliente, un servidor y un sitio de 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 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
• Las herramientas de desarrollo del 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 kerberos. La solicitud siguiente 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 de más de 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 menor (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.

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

En las secciones siguientes se describen las cosas 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, pero en dos dominios del mismo bosque.
• El cliente y el servidor se encuentran en dos bosques diferentes.

Estos posibles escenarios se describen en la sección Why does Kerberos delegation fail between my two forest (¿Por qué produce un error en la delegación de Kerberos entre mis dos bosques aunque solía trabajar en esta sección?).

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 sitios siguientes:

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

Puede comprobar la zona en la que el explorador decide incluir el sitio. Para ello, abra el menú Archivo de Internet Explorer y 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).

Es el servidor IIS configurado 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, consulte 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.

¿El cliente y el servidor están instalados 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, consulte KB 926642.

¿Puede el cliente obtener un vale kerberos?

Puede usar la herramienta Lista de Kerberos (KLIST) para comprobar que el equipo cliente puede obtener un vale 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 kerberos, no se usa la autenticación Kerberos. Puede producirse una reserva NTLM, ya que 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 siguiente artículo:

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 kerberos. Puede ser un problema si usa IIS para hospedar varios sitios en distintos puertos e identidades. En esta configuración, la autenticación Kerberos solo puede funcionar para sitios específicos, incluso si todos los SPN se han declarado correctamente en Active Directory. Para corregir este problema, debe establecer el valor del FEATURE_INCLUDE_PORT_IN_SPN_KB908209 Registro. (Consulte el 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 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 de alias en un nombre de equipo (ANAME). A continuación, el nombre del equipo se usa para compilar el SPN y solicitar un vale 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 el 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 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 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 del 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 kerberos. Internet Explorer solo llama a las API de SSPI.

3. LSASS usa el SPN que se pasa para solicitar un vale kerberos a un controlador de dominio. Si el controlador de dominio puede atender la solicitud (SPN conocida), crea un vale kerberos. A continuación, cifra el vale mediante una clave que se construye a partir del hash de la contraseña de la cuenta de usuario para la cuenta asociada al SPN. 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 host especificado.

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

   • Si se puede descifrar el vale, 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 el vale no se puede descifrar, se devuelve un error de Kerberos (KRB_AP_ERR_MODIFIED). Este error es un error genérico que indica que el billete se modificó de alguna manera durante su transporte. Por lo tanto, no se puede descifrar el vale. 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 en una de las siguientes identidades del grupo de aplicaciones:

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

Pero no se recomiendan estas identidades, ya que son un riesgo de seguridad. En este caso, el vale kerberos se compila mediante un SPN predeterminado que se crea en Active Directory cuando se agrega un equipo (en este caso, el servidor en el que se ejecuta IIS) al dominio. 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ócielo a la cuenta que se usa para la identidad del grupo de aplicaciones. Un error común es crear SPN similares que tienen 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 kerberos para el SPN http/mywebsite se cifrará mediante la contraseña UserAppPool1 o UserAppPool2. Esta configuración normalmente genera errores KRB_AP_ERR_MODIFIED. Para determinar si está en este escenario de SPN duplicado incorrecto, use las herramientas documentadas en el siguiente artículo:

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, consulte Setspn.

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

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

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

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

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

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

• Se aumenta el rendimiento, ya que ya no se realizan transiciones en modo kernel a modo de usuario.
• La descodificación de vales de Kerberos se realiza mediante la cuenta de máquina que no es 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:

• La zona de Internet Explorer que se usa para la dirección URL. Solo se permite la delegación de Kerberos 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 de IIS que hospeda el sitio debe tener la marca De confianza para la delegación establecida en Active Directory.

Si se produce un error en la delegación, considere la posibilidad de usar Kerberos Configuration Manager 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 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 está basado 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 versiones más recientes de IIS, desde Windows 2012 R2 en adelante, 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 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 convertirá en una sesión basada en la sesión. De lo contrario, se basará en la solicitud. 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, consulte Request based versus Session based Kerberos Authentication (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?

Considere el caso siguiente:

• 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 solía funcionar anteriormente y no ha realizado ningún cambio en los 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 actualizaciones de seguridad de Windows Server publicadas por Microsoft en marzo de 2019 y julio de 2019. Estas actualizaciones deshabilitan la delegación 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 Actualizaciones de la delegación de TGT en 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ísticas 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 se deben crear 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, en función del valor deseado de la característica. De forma predeterminada, el valor de ambas claves FEATURE_INCLUDE_PORT_IN_SPN_KB908209 de característica y FEATURE_USE_CNAME_FOR_SPN_KB911149, es false. Por motivos de integridad, esta es una exportación de ejemplo del Registro mediante la activación de la clave de característica para incluir 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áginas de diagnóstico para la solución de problemas de autenticación integrada de Windows