Relaciones de Confianza (Trusts) – Optimizando la Autenticación y Autorización – “Shortcut Trusts”

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”

 

Post a comment or leave a trackback: Trackback URL.

Comentarios

  • Jorge Cavallin  On 22/04/2014 at 15:42

    saludos Guillermo . Muy bueno. Gracias

  • Pavilion  On 22/04/2014 at 18:17

    Excelente, afilándome los dientes para la próxima nota jejeje.
    Gracias Guillermo.

    • Guillermo Delprato  On 22/04/2014 at 18:44

      Para las dos próximas va a ser difícil, porque tanto las “Forest Trusts” como las “External Trusts” requieren que haga otro Bosque diferente con dos Dominios para ver la transitividad
      Se van sumando las virtuales y el “host” ya está por decir “Basta” :-)

Trackbacks

Este espacio es para comentarios sobre la nota. No es un sitio de soporte

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: