Continuando la nota anterior “Relaciones de Confianza (Trusts) – “Parent-Child” y “Tree-Root”” en esta vamos a desarrollar cómo podemos optimizar los procesos de autenticación y autorización de acceso a recursos compartidos en un ambiente de múltiples Dominios Active Directory, mediante las Relaciones de Confianza de tipo “Shortcut Trust”
Antes de comenzar con el tema debemos comprender alguno de los conceptos básicos de la autenticación mediante protocolo Kerberos que es el que se utiliza en ambientes de Dominio. Trataré de hacerlo de la forma más comprensible y sencilla que pueda
A partir de Windows Server 2000 en ambiente de Dominio Active Directory la autenticación para poder acceder a un recurso, inclusive la propia máquina, se hace con protocolo (Kerberos) que tiene muchas ventajas comparado con anteriores, como NTLM por ejemplo
Para acceder a un recurso, cualquiera sea, el usuario debe ser autenticado, es decir verificar su identidad. Y para demostrarlo, cuando va a acceder al recurso presenta a la máquina que posee dicho recurso un “Ticket de Kerberos”
En este "Ticket de Kerberos" hay información suficiente como para que la máquina con el recurso pueda verificar que fue correctamente autenticado por un Controlador de Dominio del mismo Dominio donde está la máquina y el recurso
Resumiendo, una determinada máquina acepta únicamente “Tickets de Kerberos” otorgados por un Controlador de Dominio de su propio Dominio
El problema, es que un usuario sólo puede pedirle “Ticket de Kerberos” a un Controlador de Dominio, del Dominio del propio usuario.
Y entonces cuando un usuario en, por ejemplo DominioA, quiere acceder a una máquina/recurso en DominioB, hay todo un proceso intermedio
Vamos a nuestro ejemplo. Recuerdo la infraestructura
Supongamos que un usuario (U1) en el Dominio mza.root.guillermod.com.ar necesita acceder a un recurso compartido en un servidor que está en Dominio neuquen.local, por ejemplo llamado srv1.neuquen.local
A los únicos Controladores de Dominio a los que el usuario puede hacer el pedido son DC4 y DC5, que de ninguna forma pueden autorizarlo a un recurso de NEUQUEN.
Pero le pueden dar un “Ticket de Kerberos” para que contacte a uno de los Controladores de Dominio del Dominio ROOT (por la reción de confianza)
Así que una vez que U1 tiene este “Ticket de Kerberos”, contacta a un Controlador de Dominio de ROOT, haciéndole el mismo pedido (srv1.neuquen.local). Que por supuesto no podrán dárselo. Pero por la reción de confianza entre ROOT y NEUQUEN podrán darle un “Ticket de Kerberos” para que contacte a un Controlador de Dominio de NEUQUEN
Que recién cualquiera de estos Controladores de Dominio de NEUQUEN le podrán dar un “Ticket de Kerberos” para srv1.neuquen.local
Resumiendo:
- Usuario contacta a Controlador de Dominio de MZA
- Usuario contacta a Controlador de Dominio de ROOT
- Usuario contacta a Controlador de Dominio NEUQUEN
- Al fin .. 🙂
No es que no funcione, al contrario, pero convengamos que si muchos usuarios de MZA tuvieran que acceder frecuentemente a recursos compartidos en NEUQUEN, por lo menos no es eficiente el proceso
Todo esto lo podemos optimizar si existiera una relación de confianza directa entre NEUQUEN y MZA
Esto es el motivo justamente para crear una “Shortcut Trust”, donde para el caso planteado NEUQUEN debe confiar en MZA, y es lo que vamos a hacer
Vamos primero a un Controlador de Dominio de ROOT, pero con un “Enterprise Admins” como usuario y procederemos a crear la relación de confianza que recordemos es desde NEUQUEN a MZA. Podríamos hacerlo también desde un Controlador de Dominio de NEUQUEN, aunque invirtiendo el sentido de la relación
Como comenzamos en MZA, indicamos que el otro dominio es NEUQUEN
Observen que podemos elegir que la relación sea bi-direccional, o la dirección de la misma. Como comenzamos sobre MZA, y que queremos que los usuarios de MZA sean aceptados por NEUQUEN, elegimos “Incoming” (entrante)
Como he inciado sesión con un usuario “Enterprise Admins” tengo privilegios para crear relaciones de confianza en todos los Dominios del Bosque, así que elijo para crear ambas “puntas”, “incoming” y “outgoing”, o sea tanto en MZA como en NEUQUEN
Ingreso las credenciales necesarias
Me confirma que fue creada de un lado
Y del otro también
Como buena práctica, le pediré que la confirme
Todo finalizado
Dejo por ahora acá, pero continuaré. Voy a continuar con “Forest Trusts” y “External Trusts”
