---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Module 4: Implementing Distributed Active Directory ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- LON-DC1, LON-SRV1, LON-RTR se restauran a antes de configurar workfolders NYC-DC1 dominio contoso.com bosque adatum TREY-DC1 dominio treyresearch.com en bosque nuevo Cuando firmamos con DNSSEC una zona por defecto des habilita la transferencia de zona Todos los dominios de un mismo bosque tienen creadas, por defecto, relaciones de confianza entre ellos. Estas relaciones sin bidireccionales y transitivas. Las relaciones de confianza siempre tienen un sentido (o direccion) de aplicación. Las relaciones de confianza se establecen entre 2 dominios:

- Trusting Domain: es el dominio que contiene los recursos a los que se quiere acceder (carpeas, impresoras, …)

- Trusted Domain: Es el dominio que contiene los usuarios que van a acceder a los recursos. Las relaciones de confianza se representan con flechas que van del dominio trusting al dominio trusted:

Ing --------� Ed Decimos que el dominio trusting “confia en” el dominio Trusted. Si adatum confia en Trey research, los usuarios de trey research podrian acceder a recursos de adatum. La transitividad es: Los amigos de mis amigos son mis amigos

Dominio: Un dominio es una agrupacion de objetos (usuarios, grupos, equipos, recursos, …) con fines de seguridad y administrativos. Solo hay, por defecto, dos grupos que tienen privilegios en todo el bosque:

- Enterprise admin - Schema admins

El resto de grupos de seguridad solo tienen privilegios administrativos en el dominio al que pertenecen. Se implementa con una base de datos (ntds.dit), que cuenta con multiples particiones. Algunas de ellas se replican en todo el bosque (schema, configuration, DNSForestZone) y otras solo en el dominio (DNSDomainZones) Cuando trabajamos con GPOs, el nivel mas alto al que podmeos aplicarlas es el dominio. El enlazado de GPOs en un dominio padre no se hereda en el dominio hijo. Arbol: Conjunto de dominios con un espacio de nombres comun: Contoso.com -> madrid.contoso.com -> barcelona.contoso.com Bosque: Conjunto de arboles. En una unidad administrativa. Tenemos el grupo enterprise admins con control completo sobre todo el bosque. Dividir en diferentes bosques tiene sentido cuando nuestra principal preocupacion es la seguridad. Por defecto, todos los dominios de un bosque confian en el resto de dominios de ese bosque, pero no confian en dominios de otro bosque. Catalogo global: Es un subconjunto de atributos (PAS Partial Attibutes Set) que se replica en todo el bosque Configuracion Partition:

- Sitios y subredes - Partners de replicacion (Site replication) - Controladores de dominio en cada sitio - Configuracion de DHCP y DHCP Failover - DAC

Directorio activo en la nube:

- Puede que en determinado escenario sea interesante contar con el servicio de directorio activo en la nube o Usuarios moviles o BYOD o Acceso a servicios como office 365, Sharepoint online, …

Hay 2 opciones: - Windows Azure AD: Es un servicio al que accedemos mediante suscripcion cuando contratamos office 365,

sharepoint online, … Microsoft nos cede “una parte” de ese AD que tiene instalado en sus servidores Azure. Podemos sincronizarlo con nuestro AD on-premise. Esta limitado en el numero de servicios que ofrece. Identidad y gestion de acceso estan incluido

- AD in Windows Azure: usamos una maquina virtual en Azure para instalar el rol de AD DS y promocionarla a DC

AD in Windows Azure tiene alfunas consideraciones:

- Las maquina en windows Azure no pueden tener direcciones IP estaticas. Para evitar problemas, microsoft hace que nunca caduque una direccion ip entregada por el DHCP de windows azure.

- Por razones de mantenimiento, microsoft suele hacer roll back de las maquinas virtuales de Azure. Para evitar problemas, el DC debemos instalarlo sobre windows server 2012 o windows server 2012 R2, que soporta VM-Generation ID

Niveles funcionales: Cuando hablamos de niveles funcionales tenemos:

- Nivel funcional de dominio - Nivel funcional de bosque

La diferencia entre los diferentes niveles funcionales son las caracteristicas que tenemos https://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels%28v=ws.10%29.aspx Para que el dominio este en un nivel funcional concreto, todos los DCs de ese dominio deben tener un sistemas de operativo igual o superior a ese nivel. Por ejemplo, para que el nivel del dominio sea windows server 2008 R2, todos los DCs deber ser windows 2008 R2 o superior. Para que el bosque este a un nivel funcional concreto, todos los dominios deben tener ese nivel funcional. Por ejemplo, para que el nivel funcional del bosque sea windows server 2012, todos los dominios deben tener el nivel funcional windows server 2012 o superior. El nivel funcional, tanto del dominio como del bosque, solo pueden subir, no se puede bajar.

Actualizar el nivel funcional del dominio: Para elevar el nivel funcional del dominio a windows server 2012 R2 tenemos 2 opciones:

- In-place upgrade: todos los DCs windows server 2008 (x64). Windows server 2008 R2 y windows server 2012 R2 solo tienen version de x64

- Añadir controladores de dominio windows Server 2012 R2 e ir eliminando (decomission) las windows server 2008, 2008 R2 y 2012. Es la opcion recomendada.

Las 2 opciones necesitan un nivel funcional de 2012 r2 minimo Los cambios en el schema se pueden hacer de 2 maneras

- Al instalar el Rol ADDS con permisos de enterprise admin se modifica el schema - Adprep viene en el cd de windows dentro de la carpeta support

Reorganizar la estructuracion de AD: Puede que en algunos casos queramos reorganizar la estructura de dominio y bosques, opero no hay opcion en AD de desconectar un dominio de un bosque y conectarlo en otro. En estos casos, la unica opcion es una migracion. Los usuarios, grupos y equipos de un dominio en un bosque los llevamos a otro dominio en otro bosque. Tenemos que migrar los Principals. Para hacer la migracion, usamos la herramienta ADMT (Active Directory Migration Tool). La ultima version es la 3.2 y no puede instalarse sobre windows server 2012, tenemos que instalarla en una maquina windows server 2008 R2

Cuando migramos cuentas a otro dominio, reciben un nuevo SID en base a ese nuevo dominio. En este caso, los usuarios, grupos y equipos perderian el acceso a los recursos a los que podian acceder desde el dominio origen.

El acceso a los recursos (carpetas y archivos) se controla mediante ACLs en cada recurso que contienen el SID del usuario y los permisos que tiene otorgados. La solucion para que los usuarios puedan seguir accediendo a los recursos a los que accedian desde el dominio origen es guardar un historial de los SIDs de cada principal. Esta caracteristica se denomina SID-History Tipos de relaciones de confianza Las relaciones parent/child y tree se denominan relaciones intra-forest y siempre son trantisitivas y bidireccionales. Ing (recursos) ----> ed (usuarios) Tipos:

- External : un dominio de un bosque confia en un dominio de otro bosque. Puede ser unidireccional y bidireccional. Es NO transitiva

- Forest : Se establece entre los dominio raiz de dos bosques. Puede ser unidireccional o bidireccional. Es transitiva

- Realm : Relacion de confianza entre un bosque de AD y cualquier otro sistema de directorio e indentidad no-Microsoft. No transisiva

Hay otra relacion intra-forest:

- Shortcut : Relacion entre dos dominios de un mismo bosque que busca optimizar los tiempos de auntentificacion

Vamos a configurar una relacion entre adatum y treyresearch tipo forest tipo unidireccional Los usuarios de trey podran entrar en adatum pero no al reves En LON-DC1 Primero añadimos trey en condicional forwarder

Esta opcion esta disponible desde windows 2012

Y ya esta terminado Asi se ve desde adatum

Y asi desde treyresearch

Ahora vamos a convertirla en two-way Seguimos los mismo pasos y se da cuenta que ya tenemos una relacion

Y ahora ya tenemos la conexión bidireccional

Autenticacion en una relacion de Confianza: Cuando creamos una relacion de confianza de tipo forest, por defecto es transitiva. De esta forma, los usuario, grupos y equipos del dominio trusted podrian autenticarse con cualquier controlador del dominio de cualquier dominio del bosque trusting. Esto se denomina “forest-wide authentication”. Para mejorar la seguridad, podemos restringir la autenticacion solo a determinados servidores del bosque trusting. Esto se denomina “selective authentication” Ejemplo: queremos que usuarios de treyresearch puedan autenticarse solo en LON-SRV1 pero no en LON-DC1 Esta opcion es la que permite a los usuarios de trey entrar en adatum

Pulsamos en propiedades. Y cambiamos el tipo de authentication

Ahora tenemos que dar permisos en los equipos que queramos que puedan autenticar

Nos vamos a DSA.msc

Tenemos que dar permiso de autenticacion Para que se vea la pestaña seguridad activar la vis ta avanzada

Para elegir en que maquinas se autentican utilizar autenticacion selectiva

Activar inicio de sesion en controladores de dominio

Relaciones de confianza entre bosques:

- Forest: Transitiva - External: NO transitiva

IMPORTANTE¡ EN EL EXAMEN SI FUNCIONA CON RELACION T IPO EXTERNAL SI FUNCIONA

En cualquiera de ellas, tenemos que considerar 3 caracteristicas de seguridad:

- Selective authentication : Cuando establecemos una relacion de confianza entre bosques, la autenticacion puede ser:

o Forest-wide: los usuarios del bosque trusted, pueden acceder a cualquier servidor de cualquier dominio dentro del bosque trusting. Cualquier usuarios y grupo del dominio trusted se incluye automaticamente en el grupo authenticated users del dominio trusting.

o Selective: Bloqueamos la posibilidad de autenticar usuarios del dominio trusted en cualquier servidor del dominio trusting y tenemos que habilitar ese privilegio en cada equipo. Esto es lo que se denomina Firewall de autenticacion.

- SID Filtering : Cuando migramos usuarios, grupos y equipos a otro bosque, la forma de mantener el acceso a los recursos en el bosque origen es SID History. El principal no solo guarda el SID actual (asociado al dominio en el que se encuentra ahora), sino los SIDs de todos los dominios por los que ha pasado. Este SID history puede ser un problema de seguridad, ya que no se hace la comprobacion de que los SIDs que aparecen en el historial de un principal han sido realmente suyos. Un administrador de dominio o enterprise cuando realmente no lo es.

Para evitar este problema de autenticacion,en una relacion de confianza esta habilitado por defecto el SID Filtering, es decir, el dominio trusting acepta el token de autenticacion de un principal del dominio trusted, excepto el SID history. No tiene en cuenta el historial, “quien fue” el usuario cuando pertenecia a otro bosque o a otro dominio Solo cuando vamos a hacer migraciones es necesario deshabilitar el SID filtering, los usuarios migrados podran seguir accediendo a recursos del bosuqe en el que se encontraban antes. Para esto, es necesario que haya una relacion de confianza entre el bosque nuevo y el antiguo. La relacion de confianza habilita la autenticacion y el SID History la autorizacion (permiso de lectura, escritura, modificacion, …) Deshabilitar SID Filtering depende del tipo de confianza, forest o external.

Por ejemplo, si tenemos una relacion de confianza de tipo forest entre el bosque de adatum y el bosque de trey. Queremos que el usuario que hemos migrado siga accediendo a recursos de adatum sin tener que asignar nuevamente los permisos Comando para activar SID History relacion tipo fore st Netdom trust adatum.com (trusting) /domain:treyresearch.com (trusted) /enableSIDHistory:yes /usero:administrator@adatum.com /passwordo:P4$$w0rd (usuario y contraseña dominio trusting) Comando para activar SID History relacion tipo exte rnal Netdom trust adatum.com (trusting) /domain:treyresearch.com (trusted) /quarantine:no /usero:administrator@adatum.com /passwordo:P4$$w0rd (usuario y contraseña dominio trusting)

- Name Suffix Routing : Por defecto, cuando establecemos la relacion de confianza de tipo forest, los sufijos unicos del bosque trusting se publican en el bosque trusted. En nuestro caso, cuando establecemos relacion de confianza entre adatum y trey, todos los sufijos unicos de adatum se publican en trey:

o *.adatum.com o *.contoso.com

Y viceversa si la relacion es bidireccional, el adatum se publican los sufijos de trey_ o *.Treyresearch.com

Esta publicacion de sufijos se llama name suffx routing. Si queremos evitar que usuario de trey puedan localizar recursos de contoso.com, podemos deshabilitar este sufijo del enrutamiento. Se quita desde el dominio trusted en la relacion saliente