Solucionar errores de Kerberos en Internet Explorer

  • Artículo
  • Tiempo de lectura: 16 minutos

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 disponibles para resolverlos.

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

Intenta acceder a un sitio web donde Windows se ha configurado Integrated Authenticated 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:

Captura de pantalla del mensaje de credenciales.

Aunque escriba un nombre de usuario y una contraseña válidos, se le pedirá de nuevo (tres avisos en total). A continuación, se muestra una pantalla que indica que no se puede 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.

Captura de pantalla del error H T T P 401.

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 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 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

Determinar si se usa Kerberos

Al solucionar un 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 ASP.NET de autenticación.

Si usa ASP clásico, puede usar la siguiente página 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 desarrollador en el explorador

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

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

Captura de pantalla de solicitudes de más de 4.000 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 1.400 bytes).

Captura de pantalla de solicitudes de menos de 1.400 bytes.

Después de determinar que la autenticación Kerberos está fallando, compruebe cada uno de los siguientes elementos en el orden determinado.

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.

¿Están 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 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 se encuentran en dos bosques diferentes.

Estos posibles escenarios se deba a la sección ¿Por qué falla la delegación Kerberos entre mis dos bosques? aunque solía funcionar en este artículo.

¿IIS está configurado para usar la autenticación integrada?

Captura de pantalla de Windows configuración de autenticación.

Está habilitada la autenticación integrada en Internet Explorer

Seleccione la opción Habilitar la autenticación Windows integrada en la página Opciones de Internet.

¿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 en 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á explorando.

Compruebe la zona en las propiedades de Internet Explorer.

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).

Compruebe si el inicio de sesión automático está seleccionado.

Nota

Incluso a través de esta configuración no es común (porque requiere que el cliente tenga acceso a un controlador de dominio), Kerberos se puede usar para una dirección URL en la zona de Internet. En este caso, a menos que se cambie la configuración predeterminada, el explorador siempre pedirá credenciales al usuario. La delegación Kerberos no funcionará en la zona de Internet. Esto se debe a que Internet Explorer permite la delegación Kerberos solo para una dirección URL en las zonas intranet y sitios de confianza.

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

Compruebe si 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, vea <providers> Windows Authentication Providers . Puede obtener acceso a la consola a través de la configuración Proveedores de los detalles de Windows autenticación en el administrador de IIS.

Configuración de proveedores en la autenticación.

Nota

De forma predeterminada, la propiedad NTAuthenticationProviders no está establecida. Esto hace que IIS envíe tanto los encabezados Negotiate Windows NT LAN Manager (NTLM).

¿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 DisableLoopBackCheck del Registro. Para obtener más información, vea KB 926642.

¿Puede el cliente obtener un vale Kerberos?

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

Nota

KLIST es una herramienta Windows nativa desde Windows Server 2008 para sistemas operativos del lado servidor y Windows 7 Service Pack 1 para sistemas operativos del lado cliente.

Use la herramienta KLIST para comprobar que el equipo cliente puede obtener un vale Kerberos para un nombre de entidad de seguridad de servicio determinado.

Cuando se produce un error en la solicitud de vale Kerberos, no se usa la autenticación Kerberos. Puede producirse la 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, vea el siguiente artículo:

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

¿El servidor web usa 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 diferentes puertos e identidades. En esta configuración, la autenticación Kerberos puede funcionar solo para sitios específicos incluso si todos los SPN se han declarado correctamente en Active Directory. Para solucionar este problema, debe establecer el valor FEATURE_INCLUDE_PORT_IN_SPN_KB908209 del Registro. (Vea la sección Claves de características de Internet Explorer para obtener información sobre cómo declarar la clave). Esta configuración fuerza a Internet Explorer a incluir el número de puerto en el SPN que se usa para solicitar el vale Kerberos.

¿Internet Explorer usa el SPN esperado?

Si se tiene acceso 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, se usa el nombre del equipo para crear el SPN y solicitar un vale Kerberos. Incluso si la dirección URL especificada en la barra de direcciones de Internet Explorer es , Internet Explorer solicita un SPN para HTTP/MYSERVER si MYWEBSITE es un http://MYWEBSITE alias (CNAME) de MYSERVER (ANAME). Puede cambiar este comportamiento mediante la clave FEATURE_USE_CNAME_FOR_SPN_KB911149 del Registro. (Vea las claves de características de Internet Explorer para obtener información sobre cómo declarar la clave).

Un seguimiento de Monitor de red 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:

¿La identidad del grupo de aplicaciones coincide con la cuenta asociada con 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 de seguridad (SSPI) (InitializeSecurityContext) al componente del sistema que está a cargo de la seguridad 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 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 conocido), 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. 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 encabezado y, a continuación, envía el Authorization: Negotiate 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 el vale se puede descifrar, la autenticación Kerberos se realiza correctamente. Todos los servicios asociados con el vale (suplantación, delegación si el vale lo permite, y así sucesivamente) están disponibles.

    • Si no se puede descifrar el vale, se devuelve un error 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 Windows de eventos.

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 de seguridad. En este caso, el vale Kerberos se crea 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 del equipo. En IIS, la cuenta del equipo se asigna al Servicio de red o ApplicationPoolIdentity.

Si el grupo de aplicaciones debe usar una identidad distinta de las identidades enumeradas, declare un SPN (mediante SETSPN). A continuación, asocie 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 forma determinista de saber si el vale Kerberos para el SPN http/mywebsite se cifrará mediante la contraseña UserAppPool1 o UserAppPool2. Normalmente, esta configuración genera KRB_AP_ERR_MODIFIED errores. Para determinar si está en este escenario de SPN duplicados mal, use las herramientas documentadas en el siguiente artículo:

Por qué aún 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 comando al declarar un nuevo SPN para su cuenta de setspn –X destino. Para obtener más información, vea Setspn.

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

¿Falla la 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 decodificación de vales Kerberos se realiza mediante la cuenta del equipo, no la identidad del grupo de aplicaciones. Este cambio le permite tener varios grupos de aplicaciones ejecutándose con identidades diferentes sin tener que declarar SPN.

Advertencia

Si se ha declarado un SPN para una cuenta de usuario específica (también se usa como identidad del grupo de aplicaciones), la autenticación del modo kernel no puede descifrar el vale Kerberos porque usa la cuenta del equipo. Este problema es típico en escenarios de granja de servidores web. Este escenario suele declarar un SPN para el nombre de host NLB (virtual). Para evitar este problema, use uno de los métodos siguientes:

  • Deshabilitar la autenticación del modo kernel. (No se recomienda desde un punto de vista de rendimiento).
  • Establezca useAppPoolCredentials en true. Al hacerlo, se conserva la ventaja de rendimiento de la autenticación en modo kernel, al tiempo que se permite descodificar el vale Kerberos en la identidad del grupo de aplicaciones. Para obtener más información, vea New in IIS 7 - Kernel Mode Authentication.

¿Por qué falla la delegación aunque la autenticación Kerberos funciona?

En este escenario, compruebe los siguientes elementos:

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

  • La cuenta de usuario del grupo de aplicaciones de IIS que hospeda el sitio debe tener la marca Confianza para delegación establecida en Active Directory.

Si aún 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, vea el README.md. Puede descargar la herramienta desde aquí.

¿Por qué se obtiene un rendimiento malo al usar 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 que se realiza al servidor. Es contrario a los métodos de autenticación que dependen de 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, Windows 2012 R2 en adelante, Kerberos también se basa en 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 sesión basada. De lo contrario, se basará en solicitudes. Tendrá peor rendimiento porque debemos incluir una mayor cantidad de datos para enviar al servidor cada vez. Para obtener más información, vea Request based versus Session based Kerberos Authentication (o el parámetro AuthPersistNonNTLM).

Nota

Puede que no sea buena idea usar ciegamente la autenticación Kerberos en todos los objetos. Usar la autenticación Kerberos para capturar cientos de imágenes mediante solicitudes GET condicionales que probablemente generen 304 respuestas no modificadas es como intentar matar una volada mediante un martillo. Este método tampoco proporcionará ganancias de seguridad obvias.

¿Por qué falla la delegación 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 Kerberos puede dejar de funcionar, aunque antes funcionaba y no ha 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 que Microsoft publicó 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) en los límites del bosque para todas las confianzas nuevas y existentes. Para obtener más información, vea Updates to TGT delegation across incoming trusts in 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 la máquina

Las claves de características deben crearse 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 respectiva. Dentro de la clave, se debe declarar un valor DWORD con iexplorer.exe nombre. El valor predeterminado de cada clave debe ser true o false, según 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 , es FEATURE_USE_CNAME_FOR_SPN_KB911149 false. Para completar, este es un ejemplo de exportación del Registro girando 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