Compartir a través de

Guía de solución de problemas de autenticación Kerberos

En esta guía se proporcionan conceptos fundamentales que debe seguir al solucionar problemas de autenticación Kerberos.

Importante

En este artículo se proporcionan instrucciones generales. Es posible que tenga que adaptar los procedimientos y ejemplos que se presentan aquí para que funcionen para su configuración específica.

Lista de comprobación de solución de problemas

El protocolo Kerberos se basa en varios componentes y servicios de infraestructura. Si alguno de estos componentes o servicios no está disponible o no funciona, puede experimentar problemas de autenticación.

1. Comprobación de eventos y registros

Compruebe los registros de eventos para obtener indicaciones de un problema. Use el Visor de eventos para revisar los registros de seguridad y sistema en los sistemas implicados en la operación de autenticación:

  • El cliente de autenticación
  • Servidor o servicio de destino
  • Controlador de dominio

En concreto, busque eventos de orígenes que puedan estar relacionados con la autenticación Kerberos o con los servicios de los que depende, por ejemplo, los siguientes orígenes:

  • Kerberos
  • Centro de distribución de claves (KDC)
  • LSA (LsaSrv)
  • Netlogon

En el servidor de destino, compruebe el registro de seguridad en busca de auditorías de errores. Estos errores pueden mostrar que el protocolo Kerberos se usa cuando se produce un error de autenticación.

Algunos eventos o errores indican problemas específicos. Si alguno de los equipos afectados registró alguno de los siguientes eventos o errores, seleccione el vínculo para obtener información de solución de problemas más detallada.

Evento o error Información para solución de problemas
Id. de evento 4, error KERB_AP_ERR_MODIFIED El cliente no pudo descifrar el vale de servicio. Dado que más de un problema puede provocar este error, compruebe si hay eventos relacionados. Por ejemplo, esta cadena puede significar que los relojes de cliente y servidor de destino no están sincronizados o que el SPN no es único. En un entorno de varios dominios, es posible que el nombre de la cuenta de servicio no sea único en el bosque (u otros bosques de confianza).
Para obtener más información, consulte El cliente kerberos recibió un error KRB_AP_ERR_MODIFIED del servidor y Kerberos genera un error KDC_ERR_S_PRINCIPAL_UNKNOWN o KDC_ERR_PRINCIPAL_NOT_UNIQUE.
Id. de evento 4, error KERB_AP_ERR_SKEW Asegúrese de que los relojes del equipo están sincronizados
Id. de evento 14 Error "etype no admitido" al acceder a un recurso en un dominio de confianza
Id. de evento 16 o id. de evento 27 El identificador de evento 16 o 27 de KDC se registra cuando DES para Kerberos está desactivado
Identificador de evento 27 errores de KDC en controladores de dominio de Windows Server 2003
Error 1069 Se produce un error en los inicios de sesión de servicio debido a que los SPN no se han establecido correctamente
Identificador de evento 5719, error 1311 o error 1355 Identificador de evento 5719, error 1311 o error 1355: no se encontró el controlador de dominio o el dominio

Si comprueba un problema que sabe cómo corregir, primero corrija ese problema e inténtelo de nuevo para autenticarse antes de continuar.

2. Comprobación de la infraestructura

a) Asegúrese de que la aplicación cliente y el servicio de destino no estén en el mismo equipo.

De forma predeterminada, si la aplicación cliente y el servicio de destino están instalados en un solo equipo, Kerberos está deshabilitado. Si no puede instalar la aplicación cliente y el servicio de destino en equipos independientes, debe cambiar la configuración específica relacionada con la seguridad en Windows. Además, es posible que tenga que cambiar una clave del Registro. Para obtener más información sobre los problemas relacionados con este escenario y la configuración específica que le afecta, consulte Mensaje de error al intentar acceder a un servidor localmente.

Si realizó algún cambio, inténtelo de nuevo para autenticarse antes de continuar.

b. Compruebe que el equipo cliente, el servidor de destino y los servidores de recursos estén unidos a los dominios adecuados.

Si es necesario, una el equipo cliente o el servidor de destino a un dominio adecuado. A continuación, inténtelo de nuevo para autenticarse.

Nota:

En este contexto, "dominios adecuados" son dominios dentro de un único bosque o dentro de un conjunto de bosques que tienen relaciones de confianza.

c. Compruebe el estado del servidor de destino y sus servicios auxiliares.

Asegúrese de que la aplicación o los servicios front-end (como los servicios web) y los servicios back-end (como el servicio SQL Server) se estén ejecutando.

Nota:

Es posible que reciba un mensaje similar a "Un servicio ha generado el error 1069: El servicio no se inició debido a un error de inicio de sesión". Si recibe este mensaje, consulte Los inicios de sesión de servicio fallan debido a una configuración incorrecta de los SPN.

d. Asegúrese de que los puertos correctos están disponibles

Compruebe todos los firewalls (incluido firewall de Windows en cada equipo) entre el equipo cliente, el controlador de dominio y el servidor de destino. Asegúrese de que el tráfico está permitido en los puertos siguientes.

Nota:

En esta lista se utiliza el formato servidor:puerto cliente,puerto servidor.

  • DHCP: 67 (UDP), 67 (UDP)
  • DNS: 49152 -65535 (TCP, UDP), 53 (TCP, UDP)
  • HTTPS, incluida la autenticación basada en certificados: 443 (TCP), 443 (TCP)
  • Kerberos: 49152 -65535 (TCP, UDP), 88 (TCP, UDP)
  • Cambio de contraseña de Kerberos: 49152 -65535 (TCP), 464 (TCP, UDP)
  • LDAP, incluido el localizador de DC: 49152 -65535 (TCP, UDP), 389 (TCP, UDP)
  • SSL LDAP: 49152 -65535 (TCP), 636 (TCP)
  • SMB: 49152 -65535 (TCP, UDP), 445 (TCP)
  • Asignador de puntos de conexión RPC: 49152 -65535 (TCP), 135 (TCP)
  • RPC para LSA, SAM, NetLogon: 49152 -65535 (TCP), 49152-65535 (TCP)
  • W32Time: 49152 -65535 (UDP), 123 (UDP)

Si realiza cambios en cualquier configuración de firewall, inténtelo de nuevo para autenticarse.

e. Comprobación de que los controladores de dominio están disponibles

Cuando el cliente intenta ponerse en contacto con un servicio o aplicación (denominado "servidor de destino"), tanto el cliente como el servidor de destino requieren un controlador de dominio para facilitar la autenticación, la autorización y la delegación.

En el equipo cliente, abra una ventana del símbolo del sistema con privilegios elevados y ejecute el siguiente comando:

nltest /dsgetdc:<DomainName> /force /kdc

Nota:

En este comando, <DomainName> representa el nombre del dominio del equipo desde el que se está consultando.

El nltest comando recupera una lista de controladores de dominio disponibles (aunque es posible que la lista no incluya todos los controladores de dominio disponibles). Registre los nombres de dominio completos y las direcciones IP de estos controladores de dominio para usarlos en procedimientos posteriores.

Si el cliente o el servidor de destino no pueden ponerse en contacto con un controlador de dominio, recibirá un mensaje similar al siguiente (a veces con la etiqueta "error 1355"):

El dominio especificado no existe o no se pudo establecer contacto con él.

Si recibe este mensaje, consulte Id. de evento 5719, Error 1311 o Error 1355: controlador de dominio o dominio no encontrado para obtener más información de solución de problemas. De lo contrario, continúe con esta lista de comprobación.

f. Compruebe que DNS funciona entre el cliente y el servidor de destino.

En el equipo cliente, abra una ventana de símbolo del sistema con privilegios de administrador y ejecute el siguiente comando:

nslookup <TargetName>

Nota:

En este comando, <TargetName> representa el nombre NetBIOS del servidor de destino.

Si el nslookup comando resuelve correctamente el nombre del servidor de destino, la configuración dns es correcta. Si el comando no resuelve el nombre del servidor de destino, siga estos pasos para comprobar la configuración del adaptador de red del equipo cliente:

  1. En el equipo cliente, ejecute el siguiente comando:

    ipconfig /all

  2. En la salida del comando, determine qué adaptador de red está en uso. Compruebe la siguiente configuración del adaptador:

    • Dirección IP de cliente

    • Máscara de subred

    • Puerta de enlace predeterminada

    • Sufijo DNS específico de la conexión

    • Direcciones IP del servidor DNS

      Registre las direcciones IP y observe qué servidor DNS se prefiere y cuál es secundario. Esta información es útil para la solución de problemas posterior.

    Si alguna de estas opciones de configuración es incorrecta, corrijalas o póngase en contacto con el administrador de DNS para obtener ayuda. Si ha realizado algún cambio, vuelva a ejecutar nslookup <TargetName> .

Si DNS sigue sin funcionar correctamente, siga estos pasos:

  1. Ejecute el siguiente comando en el equipo cliente:

    nslookup <ClientName> <DNSIPAddress>

    Nota:

    En este comando, <ClientName> representa el nombre NetBIOS del equipo cliente y <DNSIPAddress> representa la dirección IP de uno de los servidores DNS que el cliente está configurado para usar. En primer lugar, use la dirección IP del servidor DNS preferido que registró en el procedimiento anterior. Si el comando no funciona, inténtelo de nuevo mediante la dirección IP del servidor DNS secundario del cliente.

    Por ejemplo, si el nombre del equipo cliente es "client1" y la dirección IP del servidor DNS preferido del cliente es 10.0.0.1, ejecute el siguiente comando:

    nslookup client1 10.0.0.1

  2. Ejecute el mismo comando desde el servidor de destino. Ahora se parece al siguiente comando:

    nslookup <TargetName> <DNSIPAddress>

    Nota:

    En este comando, <TargetName> representa el nombre NetBIOS del servidor de destino y <DNSIPAddress> representa la dirección IP de uno de los servidores DNS que el servidor de destino está configurado para usar. En primer lugar, use la dirección IP del servidor DNS preferido que registró en el procedimiento anterior. Si el comando no funciona la primera vez que lo ejecuta, inténtelo de nuevo con la dirección IP del servidor dns secundario del servidor de destino.

    Por ejemplo, si el nombre del servidor de destino es "WebServer1" y la dirección IP del servidor dns preferido del servidor de destino es 10.0.0.1, ejecute el siguiente comando:

    nslookup WebServer1 10.0.0.1

    En la tabla siguiente se resumen los posibles resultados de las nslookup consultas y sus implicaciones.

    Objetivo de consulta
    Consigue    		 Consulta de destino
    Fallos
    Consulta de cliente
    Tiene éxito    		 No hay ningún problema de DNS Problema que afecta al destino o al menos a un servidor DNS
    Consulta de cliente
    Falla    		 Problema que afecta al cliente o al menos a un servidor DNS Problema que afecta a uno o varios servidores DNS

Si los resultados de la consulta indican que tiene un problema de DNS, consulte los artículos siguientes para obtener más ayuda:

Si resuelve el problema de DNS, pero el problema kerberos permanece, pruebe los siguientes métodos de solución de problemas.

g. Asegúrese de que los relojes del equipo están sincronizados

El equipo cliente o el servidor de destino pueden almacenar en caché tickets para su uso en el futuro. Sin embargo, cada ticket tiene marcas de tiempo que determinan su tiempo de validez (TTL). El servicio centro de distribución de claves Kerberos, que se ejecuta en los controladores de dominio, establece las marcas de tiempo.

La diferencia en el tiempo entre el controlador de dominio y el equipo cliente o el servidor de destino deben ser inferiores a cinco minutos. Normalmente, si los relojes no están sincronizados, Windows puede resincronizarlos automáticamente. Hay dos casos en los que es posible que tenga que tomar medidas:

  • Los relojes no están sincronizados en más de 48 horas.
  • El reloj fuera de sincronización no usa un controlador de dominio en su dominio como servidor de hora o no usa el mismo servidor de hora que los controladores de dominio.

Para resolver este problema, el equipo afectado tiene que volver a comprobar la red de los servidores de hora y, a continuación, volver a sincronizar su propio reloj. Para habilitar estas acciones, abra una ventana de terminal de comandos con privilegios administrativos y, a continuación, ejecute el siguiente comando:

w32tm /resync /computer:<Target> /rediscover

Nota:

En este comando, <Target> representa el equipo que está configurando. La opción /rediscover indica al equipo que compruebe en la red las fuentes de hora nuevas o actualizadas.

Para obtener más información sobre las opciones disponibles para el w32tm comando, vea Herramientas y configuraciones del servicio de hora de Windows: Parámetros de línea de comandos para W32Time.

Si vuelve a sincronizar los relojes, inténtelo de nuevo para autenticarse.

h. Comprobar el estado de Windows Update

Asegúrese de que todos los controladores de dominio, el equipo cliente y el servidor de destino tengan todas las actualizaciones pertinentes de Windows.

Si instaló alguna actualización, reinicie los equipos afectados e inténtelo de nuevo para autenticarse.

i. Comprobación del estado de actualización de la aplicación

Asegúrese de que las aplicaciones cliente y servidor estén actualizadas en el equipo cliente y en el servidor de destino. Si instala actualizaciones, reinicie los equipos afectados e inténtelo de nuevo para autenticarse.

j. Reinicio de los equipos

Si aún no ha reiniciado el equipo cliente, el servidor de destino o el controlador de dominio, reinícielos ahora. Después de reiniciar los equipos, inténtelo de nuevo para autenticarse.

Si la infraestructura es correcta y sigue teniendo un problema, continúe con los procedimientos de solución de problemas más avanzados.

3. Recopilar datos de seguimiento y vale

Los procedimientos siguientes usan la herramienta gratuita Network Monitor . Descargue e instale la herramienta en el equipo cliente y en el servidor de destino. Para obtener un ejemplo de cómo usar Network Monitor para recopilar datos de seguimiento e identificar mensajes Kerberos, consulte Errores de Kerberos en capturas de red.

a) Realiza trazas de red simultáneas

En el equipo cliente, siga estos pasos:

  1. Realice alguna de las siguientes acciones:

    • Reinicia el equipo cliente.
    • Cierre la sesión de la cuenta que está usando para solucionar problemas y vuelva a iniciar sesión.
    • Cierre la aplicación cliente y vuelva a abrirla.

  2. Inicie el seguimiento. Para hacer esto, sigue estos pasos:

    1. Seleccione Inicio y, a continuación, escriba netmon.
    2. En los resultados de la búsqueda, haga clic con el botón derecho en Microsoft Network Monitor 3.4 y seleccione Ejecutar como administrador (seleccione Sí en la ventana Control de cuentas de usuario).
    3. En Network Monitor, seleccione Iniciar.

  3. Abra una ventana de la línea de comandos como administrador y, a continuación, ejecute los siguientes comandos en el orden indicado:

    ipconfig /flushdns
nbtstat -RR
klist purge
klist -li 0x3e7 purge

En el servidor de destino, siga estos pasos:

  1. Abra Network Monitor como administrador y, a continuación, seleccione Iniciar.

  2. Abra una ventana del símbolo del sistema con privilegios de administrador y, a continuación, ejecute los siguientes comandos en el orden indicado:

    ipconfig /flushdns
nbtstat -RR
klist purge
klist -li 0x3e7 purge

Intente reproducir el problema y, a continuación, detenga y guarde los seguimientos en el equipo cliente y en el servidor de destino. Para ello, en Network Monitor, seleccione Detener y, a continuación, seleccione Guardar como.

b. Registrar información de tickets

Después de reproducir el problema y detener el seguimiento, compruebe los tickets de Kerberos que se generaron mientras grababa los datos de seguimiento. En el símbolo del sistema del equipo cliente y en el servidor de destino, ejecute el siguiente comando:

klist tickets

Este comando genera una lista de tickets. Puede copiar esta información en otra aplicación (como el Bloc de notas) para que pueda usarla en procedimientos de solución de problemas posteriores.

4. Compruebe los datos de seguimiento de los mensajes Kerberos.

Puede usar Network Monitor para revisar, filtrar y buscar datos en los archivos de captura. En concreto, busque eventos etiquetados mediante "KerberosV5". Estos eventos proporcionan información de estado. También pueden enumerar los nombres o direcciones IP de los controladores de dominio que fueron contactados y el nombre principal de servicio (SPN) del servicio al que el cliente intentó llegar.

Las descripciones de eventos que contienen cadenas similares a las siguientes forman parte de las funciones típicas de Kerberos:

  • KerberosV5:KRB_Error -KDC_ERR_PREAUTH_REQUIRED
  • Solicitud KerberosV5:AS
  • Respuesta KerberosV5:AS
  • Solicitud KerberosV5:TGS
  • Respuesta KerberosV5:TGS
  • Solicitud KerberosV5:AP
  • Respuesta kerberosV5:AP

Nota:

También puede usar Network Monitor para comprobar los datos de traza de los tickets en las solicitudes HTTP GET. Si falta la información del vale en la solicitud GET, se produjo un problema en el uso de la autenticación Kerberos.

Las descripciones de eventos que contienen cadenas similares a las siguientes significan que hay un problema. En la lista siguiente se incluyen algunos de los errores más comunes. Si ve una de estas cadenas, anote los nombres de servidor, las direcciones IP y los SPN para su uso posterior.

  • KDC_ERR_PRINCIPAL_NOT_UNIQUE o KDC_ERR_S_PRINCIPAL_UNKNOWN. El SPN solicitado está asociado a más de una cuenta o no está asociada a ninguna cuenta. Para obtener ayuda para resolver cualquiera de estos problemas, consulte Kerberos genera KDC_ERR_S_PRINCIPAL_UNKNOWN o KDC_ERR_PRINCIPAL_NOT_UNIQUE error.

  • KRB_AP_ERR_MODIFIED. El cliente no pudo descifrar el vale de servicio. Más de un problema puede provocar este error. Revise los datos de traza para otros errores que acompañan a KRB_AP_ERR_MODIFIED. Compruebe los registros de eventos de Event ID 4 y otros eventos relacionados, como se describe en 1. Compruebe los eventos y los registros.

  • ERB_AP_ERR_SKEW. Los relojes de cliente y servidor de destino no están sincronizados. Para obtener más información, vea Asegurarse de que los relojes del equipo están sincronizados.

  • KDC_ERR_ETYPE_NOTSUPP. Uno o varios de los componentes implicados en la autenticación usan un tipo de cifrado que está deshabilitado para otros componentes. Compruebe los registros de eventos para obtener más información sobre qué componentes y qué tipos de cifrado están implicados, como se describe en 1. Compruebe los eventos y los registros.

Problemas comunes y soluciones

HTTP 400: problema de solicitud incorrecta (encabezado de solicitud demasiado largo)

Si un usuario pertenece a un gran número de grupos (por ejemplo, más de 1000 grupos), Kerberos podría denegar el acceso del usuario porque no procesa correctamente la solicitud. Para obtener más información sobre este problema, consulte los artículos siguientes:

Problemas de servicio

Los problemas de servicio suelen implicar el SPN y la cuenta de servicio. Por ejemplo, el SPN podría ser incorrecto, falta, configurado en la cuenta incorrecta o configurado en más de una cuenta. Lista de verificación para la solución de problemas de este artículo a. Recopile seguimientos de red simultáneos en una sección anterior. Si ya ha determinado un problema común de SPN, consulte los artículos siguientes:

Problemas de inicio de sesión único (SSO)

El inicio de sesión único es un método de autenticación que permite a los usuarios iniciar sesión con un conjunto de credenciales en varios sistemas o aplicaciones dentro de una sola intranet. Para que funcione correctamente, tanto el servicio de destino (o el componente front-end del servicio de destino) como el cliente deben tener la configuración correcta. Para obtener información sobre cómo solucionar estos problemas de configuración, consulte Solución de problemas de inicio de sesión único de Kerberos.

Problemas de delegación

Cuando el servicio de destino tiene componentes front-end y back-end independientes, Kerberos puede delegar las credenciales de cliente (incluidos los permisos de acceso) a una cuenta de servicio. En términos simples, el cliente accede al servicio front-end y, a continuación, el servicio front-end accede al servicio back-end en nombre del cliente.

Kerberos admite tres tipos de delegación:

  • Delegación sin restricciones. Una vez que el cliente accede al servicio front-end, el servicio front-end puede acceder a cualquier otro servicio en nombre del cliente. Esta configuración es la más fácil de implementar, pero también es la menos segura. No se recomienda la delegación sin restricciones porque no restringe los servicios con los que la cuenta autenticada puede interactuar.
  • Delegación restringida. El servicio front-end mantiene una lista de servicios a los que puede acceder en nombre de un cliente.
  • Delegación restringida basada en recursos (RBCD). El servicio back-end mantiene una lista de permitidos de servicios front-end que pueden solicitar acceso al servicio back-end en nombre de un cliente.

Nota:

Si experimenta un problema al usar la delegación restringida con CIFS, consulte Delegación restringida para CIFS falla con error ACCESS_DENIED.

Importante

  • No configure la delegación restringida ni el RBCD en el mismo conjunto de servidores front-end y back-end.

    La delegación restringida y el RBCD son configuraciones diferentes y son mutuamente excluyentes. Cuando un servicio front-end solicita un ticket a un servicio back-end, el KDC comprueba primero el servicio front-end para la delegación limitada. Si la delegación restringida no está configurada para el servicio front-end, el KDC comprueba el servicio back-end para la delegación restringida basada en recursos. Debido a esta secuencia, la delegación restringida tiene prioridad sobre la delegación basada en recursos.

  • De forma predeterminada, Microsoft Edge no admite la delegación sin restricciones. Si usa la delegación sin restricciones, consulte Autenticación de doble salto sin restricciones de Kerberos con Microsoft Edge (Chromium) para obtener más información sobre la configuración que necesita.

  • No se recomienda la delegación sin restricciones porque no restringe los servicios con los que puede interactuar la cuenta autenticada.

Tipos de topología admitidos

Los distintos tipos de delegación colocan requisitos diferentes en la topología. En la tabla siguiente se enumeran tres tipos comunes de topología y qué tipos de delegación (si los hay) se admiten para cada tipo.

Tipo de topología Delegación sin restricciones Delegación restringida RBCD
Todos los servicios residen en un solo dominio Compatible (no recomendado) Compatible Compatible
Los servicios front-end y back-end residen en dominios diferentes Soportado (no recomendado) No está soportado Compatible
Los servicios front-end y back-end residen en bosques diferentes (de confianza) Soportado* (no recomendado) No está soportado Admitido*

* Asegúrese de que la cuenta de servicio del componente front-end pueda autenticarse a través de la relación de confianza con el controlador de dominio de confianza.

Solución de problemas de tipos de delegación específicos

Los detalles de configuración de la delegación difieren en función del tipo de delegación que use y del tipo de cuenta que usa el servicio front-end. Para solucionar problemas de delegación, consulte los siguientes artículos, según corresponda:

Uso de un escenario de prueba de análisis de registros para solucionar problemas de autenticación Kerberos

Para ver las pruebas avanzadas de Kerberos y la solución de problemas, consulte Uso de un escenario de prueba de análisis de registros para solucionar problemas de autenticación Kerberos.