En esta ocasión vamos a explicar lo más sencillamanete posible de qué se trata las Relaciones de Confianza (Trusts) entre Dominios Active Directory.
Bien, con lo que he puesto más arriba ya dimos el primer paso: las relaciones de confianza son entre Dominios, o entre estructuras de Dominios.
No son como muchos creen que se pueden hacer Relaciones de Confianza entre servidores de un Dominio con otros servidores.
A veces también se habla de la Relación de Confianza entre un equipo que es parte de un Dominio, respecto del mismo, pero ese es otro tema que veremos si podemos tratar más adelante.
Primero que nada hay que aclarar que para que se establezca una Relación de Confianza entre dos Dominios es necesario que ambos acepten dicha relación.
Vamos a hacer una analogía usando “humanos” en lugar de Dominios ya que así creo que es más sencillo de comprender, utilizaremos los nombres: UsuarioA y UsuarioB.
Supongamos que UsuarioA dice que confiará en UsuarioB, en realidad la relación no se establecerá hasta que UsuarioB acepte que UsuarioA confíe en él.
Recién a partir de que se ejecutaron ambas acciones, UsuarioA afirma que confía en UsuarioB, y UsuarioB acepta que UsuarioA confíe en él, se establece la relación de confianza.
Una vez establecido que UsuarioA confía en UsuarioB (que no implica reversibilidad) eso implica que si un “amigo de UsuarioB” (usuario del DominioB) le pide acceso (a un recurso), UsuarioA no tiene como saber si realmente es un “amigo de UsuarioB”, pero la relación de confianza es como si fuera una posible comunicación telefónica que le permite a UsuarioA llamar a UsuarioB para que valide si realmente es amigo (autentique) y qué tipo de amigo (información adicional como puede ser membresía en grupos)
Si UsuarioB confirma que quien dice ser “amigo del UsuarioB” es verdad y suministra datos sobre el mismo, entonces UsuarioA confía en la autenticación que hizo UsuarioB de su amigo (usuario del dominioB), y si tiene los privilegios necesarios le dará acceso.
De lo anterior podemos ver que se trata de una relación de confianza hecha manualmente y con un propósito, y que tiene sentido, esto es: UsuarioA (DominioA) confía en UsuarioB (DominioB)
Esto es en realidad: DominioA confía en la autenticación que hace DominioB de sus usuarios.
En algunos casos, como veremos, se pueden hacer relaciones bi-direccionales, o simplemente crear dos relaciones de confianza, donde DominioA confía en DominioB, y DominioB confía en DominioA.
Esto se representa como:
Una vez que tenemos comprendido el concepto, vamos a ver cómo las implementa Active Directory.
Como es de suponer, si tenemos único Dominio, no tenemos relaciones de confianza.
Pero en cuanto agreguemos otros dominios a nuestro Bosque (Forest), formando un Árbol (Tree) ya se crearán relaciones de confianza
Relaciones de Confianza Padre-Hijo (Parent-child trust)
que cumplirán con los siguientes características:
- Se crean automáticamente al crear sub-dominios
- Son requeridas, no las podemos eliminar
- Son bidireccionales. El “padre” confía en el “hijo”, y el “hijo” confía en el “padre”
- Son transitivas, esto es si “hijo1” confía en “padre”, y “padre” confía en “hijo2”, entonces “hijo1” confía en “hijo2”
En la siguiente figura están representadas con el número ①
Relaciones de Confianza Bosque-Árbol (Forest-Tree trust)
En nuestro Bosque podríamos tener más de un Árbol (Tree), aunque no es una configuración habitual salvo que necesitáramos mantener identidades separadas
Cuando agregamos Árboles al ya existente se crean automáticamente las relaciones de confianza Bosque-Árbol (Forest-Tree) que tienen exactamente las mismas características que las Padre-Hijo (Parent-Child)
En la figura anterior está representada con el número ②
Relaciones de Confianza Atajo (Shortcut trust)
A veces por temas de diseño de Active Directory, nos podemos encontrar con un Bosque con varios dominios donde los “dominios de los usuarios” quedan “muy lejos” de los “dominios de recursos”. Esta “lejanía” hace que la autenticación no sea eficiente, y por lo tanto lenta.
En este caso podemos crear una relación de tipo Atajo (Shortcut trust), que tiene las siguientes características:
- Deben crearse manualmente
- Por omisión son unidereccionales
- Son “parcialmente transitivas”
Esto es, podrían ser aprovechadas por sub-dominios de los dominios intervinientes
En la siguiente figura están representadas por el número ③
Relaciones de Confianza Entre Bosques (Forest trust)
Hay veces que por uniones de empresas, o por temas de diseño nos podemos encontrar con que tenemos dos Bosques separados, y necesitamos habilitar acceso entre Dominios de los mismos.
En este caso deberemos crear manualmente una relación de confianza entre los Bosques
Para poder crear una relación de este tipo, ambos Bosques deben tener nivel funcional igual o superior a Windows 2003
Estas relaciones tienen las siguientes características:
- Deben crearse manualmente
- Pueden ser uni o bi-direccionales
- Pueden ser total o parcialmente transitivas
Esto último implica que todos los dominios de cada Bosque puedan acceder a recursos autorizados en el otro, o sólo algunos
Estas relaciones de confianza pueden a su vez tener dos tipos de autenticación
- Forest Wide: cualquier usuario de uno de los Bosques puede acceder a los recursos del otro Bosque, con tal que tenga los permisos adecuados
- Selective Authentication: similar al caso anterior, pero en cada servidor donde estén los recursos hay que dar el permiso “Allowed to authenticate” en las propiedades de la cuenta de máquina
En la siguiente figura está identificada con el número ④
Otros tipos de Relaciones de Confianza
Además de los casos mencionados existen dos tipos más de relaciones de confianza:
- Externas: estas se arman manualmente dominio a dominio entre Bosques diferentes que no tienen ninguna relación de confianza.
Son unidireccionales y no-transitivas - Realm trusts: se crean manualmente contra Realms de Unix Kerberos.
Un Realm de Unix es equivalente al concepto de Dominio en Active Directory
Bien, creo que con esto ya tenemos un explicación de los conceptos básicos sobre las relaciones de confianza, y sus diferentes tipos y características.
WindowServer 
Comentarios
Excelente tu explicación gracias
Gracias Fernando por tu comentario
Mas claro que el agua.
¡Gracias! :)
Hola Guillermo, gracias por la información. te hago una consulta.
En la actualidad necesito hacer una relación de confianza entre dos dominios en dos ciudades distintas, tengo planeado una relación externa entre dominios (no me interesa que sean transitiva ni nada por el estilo pues solo tienen unos pocos usuarios, lo que necesito es que los usuarios de un dominio usen un servidor del otro domino, y el administrador de ese dominio me solicita una relación de confianza), el caso es que al configurar los reenviadores DNS obtengo lo siguiente:
dc1 hace ping a dc2 y resuelve los valores de lan y obtiene respuesta
dc2 hace ping a dc1 y resuelve los valores de lan pero no obtiene respuesta
«resuelve los valores de lan» quiero decir que me muestra la ip de ese equipo dentro de su propia lan
Hasta donde yo comprendo no me interesa que responda el ping sino que resuelva los dns (cosa que ya se tiene), al empezar a crear la relación de confianza en dc2 («digamos») y asociar el dominio dc1 me sale una ventana que me indica que los datos ingresados no corresponden a un dominio y me pregunta que si es un kerveros o un dominio. Al indicar que es un dominio me indica que que no es posible crear la relación de confianza y me habilita finalizar. lo mismo sucede si la configuración se hace en el dc1
No tengo la mas remota idea de por que falla, te agradecería cualquier ayuda. si necesitas imágenes para llevarte una mejor idea indícame y las envío.
Hay varias cosas a tener en cuenta
Primero si los usuarios del «Dominio1» tienen que acceder a los recursos de «Dominio2» entonces la relación de confianza debe ser «Dominio2» confía en «Dominio1». Las relaciones externas no son ni transitivas, ni bidireccionales (salvo que se hagan dos)
Para que resuelvan los DNSs entre sí, lo que debes usar son «Reenviadores Condicionales», no «Reenviadores», y esto hay que hacerlo en ambos dominios. U otro método de tener resolución de nombres
También, en ese caso hay que usar siempre nombres DNS de las máquinas (Nombre.Dominio.Sufijo). No puedes usar simplemente el nombre de máquina
Y quizás lo que creo que seguramente te está afectando es el tema de que no puede haber ningún tipo de filtrado de red en la conexión. No alcanza con PING, la conectividad a DC usa RPC por lo que puede usar cualquier puerto, y además lo hace en forma dinámica, luego tienen que estar abiertos los 65536 puertos
Esto normalmente se consigue haciendo una VPN Site-to-Site, pero no puede haber cortafuegos de por medio, y no puede haber NAT, sólo Routing
Como dato adicional, en algún caso he visto que además se necesita conectividad NetBIOS, que aunque en teoría no sería necesaria, en algún caso he tenido que usar LMHOSTS para solucionarlo
hola guillermo, existe alguna forma de configurar la relacion de confianza usando un NAT.
Hola Cristian, que yo sepa no vas a poder, porque uno de los problemas de NAT es que es unidireccional, además de la cantidad de puertos que habría que hacer el forwarding, prácticamente todos porque usan RPC
Estimado, tengo esta disyuntiva, necesito que usuarios del Dominio1 usen recursos del Dominio2, pero son empresas separadas de un mismo grupo en donde los administradores del Dominio2 no quieren hacer relación de confianza por aducir razones de poca cooperación al proyecto, como resolver esto a nivel del DNS ?, se pueden copiar todos los DNS del Dominio2 en el DNS del Dominio1 y llegarle a los recursos ?, o que alternativa puedes sugerir ?
Es un caso típico para ADFS («Active Directory Federation Service»), no es fácil de implementar, pero hay mucha información que puedes encontrar en la web.Siempre pensando que son Bosques separados