Autenticación entre bosques de AD: grupos que faltan en PAC

10

Tengo una configuración de Active Directory que consta de 2 bosques:

  • 1 bosque multidominio con 1 dominio raíz del bosque y 2 dominios secundarios directos
  • 1 bosque de dominio único para fines de publicación DMZ

He creado 3 fideicomisos salientes en el dominio DMZ, 1 fideicomiso forestal transitivo contra el dominio raíz del bosque y 2 fideicomisos externos no transitivos (también conocidos como Fideicomisos de acceso directo).

Todos los DC en los cuatro dominios son servidores del Catálogo Global.

He intentado visualizarlo a continuación: DMZ / Relaciones de confianza interna

Ahora aquí está el problema. Cuando otorgo acceso en un recurso dmzRoot.tlda un grupo de seguridad en el childAdominio, funciona para los usuarios childAque son miembros del grupo de Seguridad, pero no para los usuarios del childBdominio, aunque sean miembros del grupo de seguridad en childA.

Digamos que quiero dar acceso de administrador local a un servidor miembro en, dmzRoot.tldpor ejemplo. Agrego childA.ForestRoot.tld\dmzAdministratorsal grupo local de Administradores integrados en el servidor miembro.

childA.ForestRoot.tld\dmzAdministrators tiene los siguientes miembros:

  • childA \ dmzAdmin
  • childB \ superUser

Ahora, si me autentico como childA\dmzAdmin, puedo iniciar sesión en el servidor miembro como Administrador local, y si miro el resultado whoami /groups, el childA.ForestRoot.tld\dmzAdministratorsgrupo está claramente en la lista.

childB\superUserSin embargo, si me autentico , recibo un mensaje de que la cuenta no está autorizada para el inicio de sesión remoto. Si verifico whoami /groupsla childB\superUsercuenta, el childA.ForestRoot.tld\dmzAdministratorsgrupo NO está en la lista.

Casi parece que los childASID del grupo nunca se incluyen en el PAC al autenticar a los childBusuarios, a pesar de que todos los DC son GC.

Inhabilité la validación de PAC en la máquina en dmzRoot.tld en el que lo probé, pero esto no ayudó.

¿Alguna sugerencia sobre cómo soluciono esto de manera efectiva? ¿Cómo sigo el rastro de autenticación para determinar dónde falla?

active-directory windows-server-2008-r2 authentication Mathias R. Jessen
fuente
2
@Lizz Por supuesto, A y B tienen una confianza entre ellos. Están en el mismo bosque.
MDMarra

Respuestas:

6

Resulta que el acceso directo confía estaba causando el problema.

Cuando la autenticación AD Kerberos viaja a través de dominios, el reino de destino (es decir dmzRoot.tld) identifica una relación de confianza a través de la cual el dominio de origen de los usuarios (por ejemplo childA.ForestRoot.tld) es un dominio de confianza.

Dado que tanto la confianza forestal transitiva hacia ForestRoot.tldcomo la confianza externa (confianza de acceso directo) hacia childAcoincide con esa condición, el reino objetivo debe elegir una, y la confianza de acceso directo tiene prioridad (porque es explícita) sobre la relación de confianza implícita en la confianza forestal .

Dado que la cuarentena del filtro SID está habilitada en los fideicomisos salientes de forma predeterminada, solo los SID del dominio de confianza (en este caso, el childAdominio) serán respetados tras la autenticación, los SID extranjeros se filtrarán.

En conclusión, hay dos soluciones para esto:

  • Elimine los fideicomisos externos y confíe en la confianza del bosque. Dado que la confianza del bosque es transitiva, todos los SID de todo el bosque permanecerán en su token.
  • Deshabilite la cuarentena de filtro SID en la confianza saliente del dmzRoot.tlddominio

Espero que tenga sentido

Mathias R. Jessen
fuente
Esto es interesante y bueno saberlo. ¿Hay alguna razón por la que tenías los métodos abreviados para comenzar? Necesitaría un máximo de 1 referencia, independientemente de la topología mostrada, ¿fue un problema por alguna razón?
MDMarra
1
Creo que se debe a un momento en que el dominio forestRoot.tld no estaba altamente disponible, o por ignorancia, no lo diseñé, simplemente asumí la responsabilidad del entorno de los equipos anteriores :)
Mathias R. Jessen
Ah, bastante justo. Sin embargo, esta es buena, vale la pena marcarla.
MDMarra
En realidad, algunos de los dominios secundarios (la imagen es una simplificación excesiva de mi topología, tengo más de 2 dominios secundarios) solo tienen DC en sitios alejados de la ubicación física donde se encuentran los DC de dmzRoot y forestRoot. Incluso simplemente eliminando la necesidad de una referencia adicional al atajar el dominio raíz del bosque podría haber hecho una diferencia en el día en que se establecieron los dominios secundarios, y la creación de redes entre ubicaciones no fue tan rápida.
Mathias R. Jessen