Fondo:
Tenemos varias redes (dominios) de AD que están conectadas a través de VPN y han establecido relaciones de confianza de AD. Disponemos de un servidor web alojado externamente y hemos configuradoautenticación perfectapara cualquier usuario dentro de la red confiable. Esto funciona, pero el equipo de red considera que la presencia de la VPN en un servidor web externo no administrado por nuestro departamento de TI representa un riesgo de seguridad demasiado grande.
No tengo acceso de administrador a las redes internas, pero sí tengo acceso de administrador completo a los servidores web.
Querer:
Establezca la misma autenticación perfecta sin una VPN mediante el uso de un controlador de dominio de solo lectura en una DMZ para procesar todas las solicitudes de autenticación.
Detalles:
- Tenemos varios dominios de AD en los que confían entre sí y están conectados a través de túneles VPN.
- Tenemos un DC de solo lectura en una DMZ conectado a la red AD principal
- Servidores web LAMP externos: estamos utilizando una única instancia para probar la nueva configuración
Tareas completadas:
- Se agregó DMZ DC al archivo de hosts.
- Se actualizó el archivo krb5.conf y se asoció un único reino y dominio (dominio1) con DMZ DC
- Autenticación probada en la línea de comando con kinit (funcionó)
- Se actualizó el archivo krb5.conf con dominios adicionales y asignaciones de dominios con todos los dominios apuntando a DMZ DC.
- Se probó la autenticación en la línea de comando con un usuario de uno de los dominios adicionales y falló.
Ejemplo de configuraciones actuales
/etc/hosts/ : (He reemplazado la IP real con x y los nombres de dominio reales por razones de confidencialidad)
xxx.xxx.xxx.xxx dc01.domain1.com, dc01.domain2.com, dc01.domain3.com, dc01.domain4.com
/etc/krb5.conf:
[libdefaults]
default_realm = REALM1.COM
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
clockskew = 12000
kdc_timesync = 1
[realms]
REALM1.COM = {
kdc = dc01.domain1.com
admin_server= dc01.domain1.com
}
REALM2.COM = {
kdc = dc01.domain2.com
admin_server= dc01.domain2.com
}
REALM3.COM = {
kdc = dc01.domain3.com
admin_server= dc01.domain3.com
}
REALM4.COM = {
kdc = dc01.domain4.com
admin_server= dc01.domain4.com
}
Asuntos:
La DMZ no procesa solicitudes de autenticación para los dominios confiables. No sé si esto es el resultado de la configuración del DC o de la configuración de Kerberos, de ahí la petición de ayuda.
He pasado unas cuantas horas resolviendo otras preguntas sobre la falla del servidor, buscando en Google y leyendo tutoriales, pero nada parece coincidir con nuestro escenario.
¿Podemos hacer lo que estamos intentando y, de ser así, qué debemos hacer para que funcione? ¿Se trata simplemente de configurar la DMZ como proxy para los kdc de otros reinos?
En respuesta a Nathan C, el registro de seguridad muestra solicitudes de tickets de servicio Kerberos como este:
Auditoría exitosa 05/14/2014 11:05 Microsoft-Windows-Security-Auditing 4769 Operaciones de ticket de servicio Kerberos "Se solicitó un ticket de servicio Kerberos.
Información de la cuenta: Nombre de la cuenta: [correo electrónico protegido] Dominio de cuenta: DOMAIN1.COM GUID de inicio de sesión: {C93D9AAC-6968-6C00-83EF-2C2D54E2363B}
Información del servicio: Nombre del servicio: RODC01$ ID del servicio: DOMINIO1\RODC01$
Información de red: Dirección del cliente: ::1 Puerto del cliente: 0
Información adicional: Opciones de ticket: 0x40810000 Tipo de cifrado de ticket: 0x17 Código de error: 0x0 Servicios en tránsito: -
Este evento se genera cada vez que se solicita acceso a un recurso como una computadora o un servicio de Windows. El nombre del servicio indica el recurso al que se solicitó acceso.
Este evento se puede correlacionar con los eventos de inicio de sesión de Windows comparando los campos GUID de inicio de sesión en cada evento. El evento de inicio de sesión ocurre en la máquina a la que se accedió, que a menudo es una máquina diferente al controlador de dominio que emitió el ticket de servicio.
Las opciones de ticket, los tipos de cifrado y los códigos de falla se definen en RFC 4120."
Desafortunadamente, el extracto del registro que me enviaron no coincide con las veces que intenté la autenticación, por lo que no sé con qué se relaciona realmente esa entrada del registro. He solicitado otro extracto.
Información de la cuenta:
Nombre de cuenta: jameel.rahmaa
Nombre de dominio proporcionado: DOMINIO1.COM
ID de usuario: SID NULO
Servicio de información:
Nombre del servicio: krbtgt/DOMAIN1.COM
ID de servicio: NULL SID
Información de red:
Dirección del cliente: [IP WEB OCULTA]
Puerto de cliente: 34567
Información adicional:
Opciones de boleto: 0x40800000
Código de resultado: 0x6
Tipo de cifrado de ticket: 0xffffffff
Tipo de autenticación previa: -
Información certificada:
Nombre del emisor del certificado:
Número de serie del certificado:
Huella digital del certificado:
La información del certificado solo se proporciona si se utilizó un certificado para la autenticación previa.
Los tipos de autenticación previa, las opciones de ticket, los tipos de cifrado y los códigos de resultado se definen en RFC 4120.
No estoy seguro de por qué, pero el carácter final de mi nombre ha sido cortado.
Respuesta1
0x6. KDC_ERR_C_PRINCIPAL_UNKNOWNahí está... investiga esto. Parece que sus SPN no están configurados correctamente o está intentando utilizar una cuenta que ni siquiera existe. Wireshark es otra buena herramienta que puede ejecutar en el servidor web para ver qué obtiene del DC al realizar solicitudes.