Ya para finalizar esta serie de notas sobre Relaciones de Confianza (“Trust Relationships”) en esta ocasión veremos características, y cómo se crean las Relaciones de Confianza de tipo Externas (“External Trusts”)
Este tipo de Relaciones de Confianza permiten el acceso específico entre Dominios, no Bosques como en los casos anteriores, entre Dominios de diferentes Bosques
Semejante al caso de la nota anterior, ya sea porque la organización cuenta con más de un Bosque, o porque se ha adquirido o absorbido otra organización, y se requiere acceso a recursos desde un Dominio a otro pero de otro Bosque. La característica específica en este caso es que la relación es mucho más limitada, esto es, Dominio a Dominio, y no a nivel de Bosques
Seguiré utilizando la misma infraestructura que vengo usando en todas las notas anteriores según el esquema mostrado. Si vienen siguiendo esta serie de notas, lo más sencillo es eliminar la relación creada en la nota anterior (“Forest Trust”), así podremos crear la nueva relación
En este caso plantearé una Relación de Confianza de tipo Externa, entre los Dominios “mza.root.guillermod.com.ar” y “child.empresa.net” de tipo unidireccional donde el primer Dominio confía en el segundo, lo cual permitirá que usuarios de “child” puedan acceder a recursos de “mza”
Recordemos que antes de comenzar cualquier procedimiento para crear la Relación de Confianza debemos asegurarnos la resolución de nombres DNS entre ambos, y por supuesto tener conectividad de red
Pego el mismo texto puesto en la nota anterior sobre cómo configurar la resolución de nombres:
Cómo hemos visto anteriormente en las notas sobre resolución de nombres podemos usar cualquiera de los siguientes métodos:
- Zonas Secundarias
- “Stub-Zones”
- Reenviadores (“Forwarders”)
- Reenviadores Condicionales (“Conditional Forwarders”)
Yo he usado el último de los nombrados (“Conditional Forwarders”) ya que me ha precido el más rápido de implementar en este caso. No mostaré la configuración que he hecho, si alguno no la recuerda puede consultar la nota “DNS: Resolución de Nombres Mediante Reenviadores Condicionales”
Lo importante, es verificar en cada uno de los Controladores de Dominio, usando NSLOOKUP por ejemplo, la correcta de resolución del nombre de todos los demás Controladores de Dominio de ambos Bosques (“Forests”). Aclaro que utilizo NSLOOKUP porque esto es independiente del cliente DNS (Resolver), y por lo tanto si corrijiera algo, la información no quedaría almacenada en memoria (“cached”)
¿Revisaron? ¿resuelve todos los nombres? Sí, ya sé, es tedioso y largo, pero no sigan adelante hasta no solucionar cualquier inconveniente, de otra forma no se establecerán, o no funcionarán las relaciones como deben ser
Seguimos entonces con esta nota
Pruebo tanto en “dc4.mza.root.guillermod.com.ar” como en “dc-b.child.empresa.net” tanto la resolución de nombres (NSLOOKUP) como la conectividad (PING)
Haré todo el procedimiento desde DC4 ya que conozco la contraseña de un “Enterprise Admin” de “empresa.net”. Así que comenzamos todo desde “Active Directory Domain and Trusts” (Dominios y Confianzas de Active Directory)
Crearemos la relación de confianza siguiendo el asistente
Recordemos que estamos en el Dominio MZA, y deseamos que este confíe en CHILD, así que elegimos “Outgoing” (Saliente)
Y como conocemos usuario y contraseña de un “Enterprise Admin” del otro Bosque, elegimos hacerlo desde este asistente para ambos Dominios
Ingresamos las correspondientes credenciales
Como en la nota anterior, seleccionamos “Domain-wide”
Pide confirmación de lo que estamos solicitando
E informa que la relación de confianza se ha creado exitosamente
Como en todos los casos, pregunta si queremos verificarla, lo cual haré
Y finalizamos
Nos da aviso de “SID Filtering”, esto puede ser importante desde el punto de vista seguridad. Trataré de explicarlo simple y rápido. Como un administrador de Dominio puede manipular el atributo “SID History” de cualquier cuenta, imaginen qué sucedería si un usuario de un Dominio tuviera en su atributo “SID History” el SID de un administrador del otro Dominio
Podemos verificar la creación de la relación de confianza en MZA
Y en CHILD
Estando todo listo ¿funcionará? Por si alguno se quedó con dudas, en la máquina “cl1.mza.root.guillermod.com.ar” iniciaré sesión con un usuario de prueba creado en “child.empresa.net” llamado “ChildUser”
Y por si alguien desconfía 😉
Con “IPCONFIG /ALL” muestro el nombre de la máquina, y con WHOAMI muestro el nombre de usuario
Con esta cuarta daré por finalizado, por lo menos por ahora, el tema relaciones de confianza. Hemos visto:
Relaciones de Confianza (Trusts) – “Parent-Child” y “Tree-Root”
Relaciones de Confianza (Trusts) – Optimizando la Autenticación y Autorización – “Shortcut Trusts”
