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”
Relaciones de Confianza (Trusts) – “Forest Trusts”
WindowServer 
Comentarios
Te has pasado con esta serie, a manera de resumen quisiera saber cuales serian las ventajas de hacerlo desde cero (creando bosques y dominios) o mediante relaciones de confianza con Dominios y Bosques creados, por lo que veo, de cualquier manera se puede lograr que los usuarios se autentifiquen y compartan recursos.
No conocía el comando WHOAMI, en este blog se aprende algo en cada nota.
Gracias por tan buen aporte Guillermo!!! Ah por último, esta serie es válida para 2008R2?
¡Un gusto que te sirva! Gracias
Esto es totalmente válido desde Windows Server 2003, siempre y cuando el nivel funcional del Forest sea 2003
Pero no comprendo el «hacerlo desde cero» :-(
Las «Parent-Child» y «Tree-Root» son desde la creación de los Dominios
Las «Shortcut» son para optimizar en un Forest ya creado
Las «Forest Trusts» y «External Trusts» son para cuando ya hay Forests creados con anterioridad. Por ejemplo, si una organización con 1000 usuarios, se unificara con otra de 500 usuarios ¿vas a crear todo de nuevo en uno de los Forests? :-) y además no te olvides de migrar todos los servidores y servicios
Con estas últimas relaciones de confianza, se puede interoperar, y mientras vas pensando cómo se van a unificar (Por ejemplo con ADMT)
Hola, existe alguna diferencia destacable entre montar un forest trust o un external trust cuando tienes dos bosques con cada un un único dominio? Obviamente entiendo que si luego con el tiempo la estructura varía habría diferencias pero digo suponiendo que el escenario es invariable a ese nivel.
Hola Jesús, en las condiciones que nombras no hay importantes diferencias, siempre y cuando la infraestructura no crezca luego :)
Una diferencia podría ser que las «External Trusts» son siempre de un único sentido, aunque lógicamente se podrían hacer dos, «ida y vuelta»
En el caso planteado no hay diferencias prácticamente
Hola Guillermo, buen día!
Creo que esta es la infraestructura mas grande que has hecho para un laboratorio, seguro que con el Server 2016 será aun mas compleja :)
En el caso de que una empresa adsorba o se unifique con otra, y esta tenga en sus redes internas las mismas redes privadas, duplicándose las IP de los controladores de dominio, servidores y clientes, se tendría que renumerar la red? hay otra forma de solventarlo? que otras consideraciones se deben tener en cuenta para evitar algún conflicto futuro (best practice)?
Hola Coldran, sí, tal como dices, esta fue la que tuvo mayor número de máquinas, aunque no sé si fue la más «pesada». El tema es que los DCs se pueden tener con muy poca RAM. Hay otras donde he usado virtual en virtual que virtualiza donde el consumo de RAM era al límite
Hacer que dos redes separdas físicamente con el mismo direccionamiento IP es imposible porque no hay forma que para enviar a un Router una dirección IP que el sistema considera local
Creo que en algún post lo puse, nunca conviene usar en ambiente productiva nada que comience con; 10.0, 10.1, 172.16, 192.168.0, 192.168.1
¿Por qué? porque lo usan casi todos. Para usar esas redes, considerar usar el primero octet libre con un número que te parezca lo más raro o improbable, tipo 10.34, 10.1.187, 172.45 o 192.168.127 por ejemplo
Además usar las redes «comunes» tambien facilita si hubiera un acceso externo no deseado, siempre se prueba esas redes porque las suele usar todo el mundo :)
Ve preparando tu infraestructura que hay varias cosas que estoy preparado: Nano Server, Containers, Storage Space Direct. La semana que viene sale «Virtual Smart Cards» que ahora con W2016 ya se puede hacer en virtual
Menos mal que estos problemas de duplicación de IPs se solucionará pronto con la implementación de IPv6 :)
No se si mi máquina soportará para realizar un laboratorio de este tamaño pero con WS2016 y las nuevas características que mencionas, ya que ahora estoy casi al límite con este, la próxima usaré la opción de enrutar de la nota «router del hombre pobre» jeje, por lo menos los laboratorios sueltos si los realizaré sin problemas y la infraestructura hasta donde de :(
En mi caso para esta nota, fue porque aproveché la estructura que ya tenía creado del Forest Grande, y llegué al límite. Creo recordar que para que llegara a funcionar, había puesto un sólo Controlador de Dominio de cada uno de los Dominios
Hace tiempo, con una nota que requería más recursos de los que disponía en la máquina, recuerdo haberlo hecho todo conectando las virtuales sobre la red física, y usando una máquina vieja, que aunque sea para dos VMs me servía. Todo condimentado con mucha paciencia :)