Estoy intentando Kerberizar un servidor Apache y permitir que el servidor principal creado inicie sesión en Active Directory. Seguí uno de los numerosos tutoriales disponibles en línea y parece funcionar bien. Estoy en el lado de Linux del proyecto y TI corporativa está en el lado de Windows.
TI me ha proporcionado una cuenta de servicio y un principal de servicio para ello. En este ejemplo, me referiré a él como HTTP/[correo electrónico protegido]. Me proporcionaron un archivo de tabla de claves para dicho director, que implica ejecutar una herramienta llamada ktpass.exe en el servidor AD.
He verificado que los KVNO del AD/KDC y el archivo de tabla de claves coinciden. Todo está bien.
Hay un registro A DNS adecuado para el nombre de host y un registro PTR adecuado para la IP. Ambos servidores están sincronizados en el tiempo.
Puedo solicitar un ticket de AD/KDC para la entidad de servicio mencionada anteriormente con el archivo keytab emitido, como este:
kinit -k -t http.keytab HTTP/[email protected]
Esto funciona. Obtengo un ticket y puedo usarlo para cosas como consultar el directorio AD/LDAP. La tabla de claves también funciona muy bien para ejecutar un sitio Apache de inicio de sesión único, que es en parte el objetivo de este ejercicio.
Pasa media hora.
Los intentos de iniciar sesión con el comando kinit anterior ahora fallan y muestran este mensaje:
Client not found in Kerberos database
No puedo autenticarme como principal del servicio, como si la principal se hubiera eliminado en el servidor AD.
Ahora se vuelve raro, al menos para mí:
A pedido, el administrador de AD ejecuta la herramienta ktpass.exe nuevamente, creando un archivo de tabla de claves nuevo para mi servicio. El KVNO (número de versión de clave) se incrementa en el servidor, lo que hace que nuestro servidor de prueba Apache deje de validar el inicio de sesión único de Kerberos. Esto es lo que se espera con mi configuración actual. Lo que nos sorprendió a todos fue que ahora el comando kinit volvió a funcionar. Nos ganamos otra media hora y luego dejó de funcionar nuevamente.
Nuestro departamento de TI está perdido y especulan que se trata de un problema con el propio servidor AD. Estoy pensando que es la configuración, pero según ellos, no hay límites de media hora en ninguna parte de su configuración.
he seguidohttp://www.grolmsnet.de/kerbtut/(ver sección 7) pero el método parece ser el mismo en toda la documentación que he encontrado. No he encontrado ninguna referencia a límites de tiempo para los principales de servicio.
EDITAR: Esto parece ser un problema de replicación. Aunque no se informan errores en el proceso de replicación, el valor SPN de la cuenta de servicio cambia (¿se revierte?) de "HTTP/[correo electrónico protegido]" a "[correo electrónico protegido]" despues de 30 minutos.
Respuesta1
Gracias por todas vuestras aportaciones, tíos. Incorporamos a Microsoft y nos ayudaron a depurar el proceso de autenticación en el lado de AD. Todo funcionó como se suponía, pero falló después de treinta minutos.
Mientras realizábamos una sesión de depuración remota, uno de los participantes notó que el UPN/SPN de la cuenta de servicio se restableció repentinamente deHTTP/[correo electrónico protegido]a[correo electrónico protegido]. Después de MUCHA investigación, incluida la depuración de la replicación de AD, encontramos al culpable:
Alguien había creado un script que se ejecutaba periódicamente (o probablemente por evento, ya que transcurrieron exactamente treinta minutos después de ejecutar ktpass.exe), que actualizaba el UPN/PSN a"garantizar la conectividad en la nube". No tengo ninguna información complementaria sobre los motivos para hacer esto.
El script se cambió para permitir valores UPN/SPN existentes que terminen en@mycorp.com, resolviendo eficazmente el problema.
Consejos para depurar problemas como este:
- Asegúrese de que todos los participantes en la autenticación admitan los mismos tipos de cifrado. Evite DES: está desactualizado e inseguro.
- Asegúrese de habilitar el cifrado AES-128 y AES-256 en la cuenta de servicio
- Tenga en cuenta que habilitar DES en la cuenta de servicio significa"use SÓLO DES para esta cuenta", incluso si habilitó cualquiera de los cifrados AES. hacer una búsqueda deUF_USE_DES_KEY_ONLYpara obtener detalles sobre esto.
- Asegúrese de que el valor UPN/SPN sea correcto y coincida con el valor en el archivo de tabla de claves emitido (es decir, a través de una búsqueda LDAP)
- Asegúrese de que el KVNO (número de versión de clave) en el archivo de tabla de claves coincida con el del servidor
- Inspeccionar el tráfico entre el servidor y el cliente (es decir, con tcpdump y/o WireShark)
- Habilite la depuración de la autenticación en el lado de AD: inspeccione los registros
- Habilite la depuración de la replicación en el lado de AD: inspeccione los registros
Nuevamente, gracias por tu aporte.
Respuesta2
También aprendí Kerberos comenzando con mod_auth_kerbel tutorial de Achim Grolms, realmente una buena documentación.
El keytabarchivo solo reemplaza la autenticación de contraseña. La contraseña está codificada en el archivo y estos bytes se utilizan en el desafío de autenticación con KDC. Cualquier cambio de contraseña en la cuenta de servicio invalidará la autenticación de tabla de claves y también aumentará el número kvno.
Para confirmar que un SPN de cuenta de servicio está disponible, a menudo me autentico con la contraseña de la cuenta de servicio:
kinit HTTP/[email protected]
Si no funciona, para confirmar que la cuenta de servicio no está deshabilitada, intente con la autenticación básica:
kinit account
Si no puede autenticarse, simplemente elimine la cuenta y cree una nueva con otro nombre de inicio de sesión para evitar problemas.
Existe una alta probabilidad de que otra pieza de software (por ejemplo, otro sistema con una tabla de claves generada antigua para el mismo SPN) intente autenticarse en esta cuenta de servicio y deshabilite la cuenta debido a una contraseña no válida.
Al configurar Kerberos SSO, las operaciones demasiado rápidas pueden provocar inconsistencias en Active Directory. Mi pauta general cuando estoy atascado en el proceso de configuración es seguir estos pasos:
- eliminar cuentas de servicio "antiguas" o "defectuosas" para sistemas de prueba y producción
- Verifique que
kvnoel SPN que espera configurar ya no existe en el reino. - verifique que
setspn -Xno haya SPN conflictivo en varias cuentas - cree una cuenta de servicio por sistema, dedicada a un único SPN totalmente calificado, con un nuevo nombre de inicio de sesión
- evitar el cambio de contraseña y la caducidad de la contraseña en la cuenta de servicio
- esperemos un poco para la sincronización DC
- establecer contraseña como
ktpassopción al generar tabla de claves - verifique FQDN SPN y alias con
setspn -l account
Aquí hay un conjunto de comandos para configurar la cuenta de servicio en DC:
ktpass -princ HTTP/[email protected] -mapuser [email protected]
-crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL
-pass long!$longp2ass3word -out c:\temp\http-mysite-mycorp-com.keytab
setspn -a HTTP/mysite mysiteAccount
setspn -l mysiteAccount
Si las operaciones se realizan demasiado rápido en diferentes DC entre MMC y la ejecución de ktpass para la generación de tablas de claves en una línea de comando administrativa, entonces la sincronización de DC puede generar resultados inesperados como el que usted describe. Así que esperemos un poco entre la creación de la cuenta y luego ktpasscualquier setspncomando adicional.
Y comandos para ejecutar en Linux para comprobar que todo funciona correctamente:
kinit [email protected]
kinit HTTP/[email protected]
kinit -k -t http-mysite-mycorp-com.keytab HTTP/[email protected]
kvno HTTP/mysite.mycorp.com
kvno HTTP/mysite