Azure AD: Gobernanza de Office 365 y Recursos de Azure (Parte 2)

Después del primer artículo sobre AzureAD y sus implicaciones, hoy voy a comentar como sincronizar nuestro Active Directory On-Premises con Azure. Esto nos permite tener una identidad única tanto en On-Premises como en Cloud, permitiendo que los usuarios utilicen su misma cuenta de usuario para acceder a casi cualquier recurso corporativo. A este concepto se le conoce como identidad híbrida con AzureAD y, con ella podemos utilizar tres métodos de autenticación (tenéis los enlaces de cada método para ampliar información):

• Sincronización de hash de contraseña (PHS): Sincronización de hash de contraseñas con inicio de sesión único
• Autenticación de paso a través (PTA): Autenticación de paso a través e inicio de sesión único
• Federación (AD FS): Inicio de sesión único federado con AD FS

“Básicamente”, para conseguir un entorno híbrido “basta” con sincronizar nuestro Active Directory con nuestro AzureAD, esto se consigue con una herramienta que Microsoft pone a nuestra disposición: Azure AD Connect. Nos permite sincronizar usuario, grupos y equipos con AzureAD, lo que posteriormente nos permite:

• Autenticar en aplicaciones registradas en AzureAD (entre ellas la suite Office 365)
• Autenticar y conceder acceso a recursos en Azure (próximo artículo)
• Delegar tareas de administración a usuarios sincronizados
• Reglas de Acceso Condicional
• Administración de Dispositivos
• Etc..

En este artículo de hoy, lo que haremos será configurar un entorno de identidad híbrida entre nuestro Active Directory y AzureAD:

Objetivos:

• Sincronizar nuestros usuarios y grupos de Active Directory con AzureAD
• Asignación de licencias de Office 365 (Exchange, Teams, SharePoint, OneDrive, etc..)
• Aplicar permisos sobre recursos de Office 365 (SharePoint) utilizando grupos de seguridad de On-Premises

Tareas:

• Instalar AzureAd Connect
• Configurar AzureAd Connect
• Crear sufijos UPN
• Sincronización incial de AzureAd Connect
• Creación de estructura de grupos jerárquica
• Aplicar permisos en SharePoint con grupos de Active Directory sincronizados

Ya teniendo claro todas las tareas que debemos realizar para cumplir nuestros objetivos, pues lo primero, descargarnos la última versión de AzureAD Connect: Microsoft Azure Active Directory Connect. Pero antes de esto, vamos al portal de Azure – AzureAD Connect y aquí será donde veamos la configuración que tenemos al respecto, pero ahora mismo como no hemos hecho configuración alguna únicamente tenemos esto:

Pues ahora si, nos descargamos el AzureAD Connect e iniciamos su instalación:

Aceptamos los términos de la licencia

Como mi dominio es un dominio no enrutable, sin algunos cambios (en los siguientes pasos del este artículo) en los usuarios, no podríamos tener usuarios con nuestro dominio personalizado si su UPN no se corresponde con el dominio registrado en Office 365 en este caso. Esto lo veremos más adelante, ahora mismo pulsamos en personalizar:

Si queremos o tenemos alguna particularidad a cubrir ahora es el momento, sino es así y es una instalación desde cero, pulsamos en instalar sin marcar ninguna opción:

Primer punto en donde tenemos que prestar atención, debemos elegir como queremos que nuestros usuarios inicien sesión. En mi caso y para este artículo, configuraré la primera opción: Sincronización de hasta de contraseña (en siguientes artículos comentaré algunos de los otros métodos de autenticación):

Ahora debemos introducir un usuario con el rol de administrador global en AzureAD y pulsamos en siguiente:

El siguiente paso nos solicita agregar el dominio o dominios que tengamos, los seleccionamos y pulsamos en Agregar directorio

Para la ejecución de periódica (sincronización automática) del AzureAD Connect se instalará como un servicio y para ello necesita una cuenta de ejecución con los privilegios necesarios. Si tenemos una cuenta ya con los privilegios necesarios la podemos especificar, en caso contrario podemos dejar que la cree el propio asistente (opción Crear una cuenta de AD), pero para ello debemos también introducir un usuario con privilegios en el Active Directory y su contraseña:

Si hemos introducido correctamente los datos, veremos como ya tenemos configurados los directorios a sincronizar:

Otro punto importante a tener en cuenta, como el dominio que yo tengo creado no es enrutable (.local), me indica que sino tengo el sufijo UPN configurado en los usuarios igual que el dominio registrado en Office 365 los usuarios se crearán en AzureAD con el sufijo nombre-tenant.onmicrosoft.com

Esto es algo vital, sino nunca podremos tener a nuestros usuarios con un inicio de sesión con nuestro dominio. Básicamente, lo que tenemos que hacer es configurar los sufijos UPN que necesitemos.

En mi caso como el dominio registrado es santiagobuitraoreis.com, pues es el sufijo UPN que tengo que configurar

Y ahora en todos los usuarios que vayamos a sincronizar y queramos que tengan como nombre de usuario con el dominio registrado, pues tenemos que cambiar el sufijo en las propiedades de la cuenta:

Aquí os muestro el dominio registrado en Office 365, si queremos tener usuarios con el dominio santiagobuitragoreis.com debemos completar los pasos anteriormente descritos:

Volvemos al asistente de instalación de AzureAD Connect y pulsamos en el botón de refrescar y vemos que ya tenemos el sufijo creado como disponible para ser sincronizado. Igualmente, por razones obvias tenemos que marcar la casilla de Continuar sin relacionar todos los sufijos UPN con los dominios verificados y se nos habilita la opción de siguiente la cual debemos pulsar.

Aquí debemos indicar que OU queremos sincronizar, yo siempre soy partidario de filtrar o definir que OU queremos sincronizar y es lo que haré, una vez que hemos seleccionadas las OU a sincronizar (usuarios, grupos y equipos), pulsamos en siguiente. 

Como hemos elegido como método de autenticación sincronización de hash de contraseñas, ya tenemos marcada la casilla correspondiente y que no podemos desmarcar. En mi caso y para este artículo no tocaré nada más, pulsamos en Siguiente

Y por último, marcamos la casilla Inicie el proceso de sincronización cuando se complete la configuración. Solo debemos tener un AzureAD Connect por dominio en modo escritura, pero podemos tener otro servidor con el AzureAD Connect en modo “pruebas”, si fuese así, podríamos marcar la casilla habilitar modo de almacenamiento provisional. Esto hará que se simule todo el proceso, pero no escribirá nada en AzureAD, esto nos viene bien por si lo queremos tener de respaldo o pruebas de exportaciones.

Una vez elegida la primera opción, pulsamos en instalar y esperamos a que se complete el proceso:

Una vez que se haya completado el proceso, podemos pulsar en salir  para cerrar el asistente de instalación y configuración de Azure AD Connect.

Si ahora volvemos al portal de Azure, a la sección de Azure Active Directory y opción Azure Ad Connect veremos que se ha habilitado la sincronización y la última vez que se ha completado la sincronización (por defecto cada 30 minutos).

Pues bien, ahora desde la sección de Azure AD dentro del portal de Azure, vamos a la sección de usuarios y vemos que ya tenemos nuestros usuarios sincronizados. Si os fijáis tenemos un usuario que no tiene el sufijo con el dominio que tengo registrado sino con el dominio santiagobuitragoreis.onmicrosoft.com, esto es porque a este usuario no le he cambiado la cuenta de usuario con un sufijo UPN que coincida con uno de los dominios que tengamos registrados.

Antes de explicar como se soluciona este “problema”, si os fijáis en la columna de origen veis que pone Windows Server AD, es la forma rápida de saber que el usuario es sincronizado vía Azure AD Connect:

Lo único que tenemos que hacer es cambiar el sufijo de la cuenta de usuario

Para no tener que espera mucho tiempo hasta que se cumplan los 30 minutos para que se inicie otro proceso de sincronización, lo forzamos con el siguiente cmdlet: Start-ADSyncSyncCycle -PolicyType Delta

Ahora en cuestión de menos de 1 min tenemos el usuario actualizado

Una vez que tenemos los usuarios sincronizados podemos asignarles las licencias correspondientes, esto podemos hacerlo desde varios sitios:

• PowerShell
• AzureAD
• Centro de administración de Office 365

Ya que estamos hablando de Azure, vamos a ver como se haría desde dicho portal. Para ello, desde la misma consola de Azure y Azure AD tenemos una sección con el nombre Licencias al cual debemos acceder:

Pulsamos en Todos los productos

Seleccionamos la licencia que queremos asignar y luego pulsamos en Asignar

Buscamos los usuarios a los cuales les queremos aplicar la licencia

Los seleccionamos y pulsamos en seleccionar

Ahora en Asignar

Y en cuestión de segundos tenemos los usuarios con sus correspondientes licencias

Aquí vemos a los usuarios con la licencia asignada

Como le hemos añadido la licencia de E3, veremos que ya se le ha creado la cuenta de correo correspondiente

Ahora vamos a ver que ocurre cuando sincronizamos los grupos de Directorio Activo, la verdad es que lo haces perfecto, puesto que, mantiene las anidaciones de grupos tal cual los tenemos en On-Premises y esto nos permite aprovecharnos de las membresías para aplicar permisos sobre recursos (SharePoint Online, Exchange Online, Azure, etc…). Aquí os dejo un esquema de grupos típico en cualquiera empresa:

Y a continuación algo más pequeño para este artículo, pero que representaría algo similar donde tenemos grupos de usuarios  (globales) y grupos (domain local) a los cuales le asignaremos los permisos en los diferentes recursos. Como están correctamente anidados, los usuarios que están en los grupos globales tendrán acceso a los recursos protegidos por los grupos locales de dominio.

Primero vamos a ver los grupos sincronizados con Azure AD, aquí estoy filtrando por los grupos de origen Windows Server AD. Los grupos que tienen como prefijo Grp los utilizo para agrupar roles y usuarios, los Acl son los que utilizo para aplicar permisos (lo que está entre () indica el permiso que aplica):

Y aquí vemos el Grp Empresa (principal en la jerarquía)  y sus miembros:

Si esto mismo lo vemos en el Active Directory de On-Premises vemos que está exactamente igual

Vemos que el Grp Empresa es miembro del Acl SPO SantiagoBuitrago Reis (R) (permiso de lectura sobre el Site SantiagoBuitragoReis), con esto queremos hacer que todos los usuarios que sean miembros de Grp Empresa bien directamente (miembros directos) o indirectos (por ser miembros por anidaciones de otros grupos) tendrá acceso de lectura al SPO (ahora explico la configuración de este permiso en SPO):

Y aquí vemos la configuración en al Active Directory

Y por último, vemos a las cuentas de usuario en su rol (Grp Sistemas Tecnico)

Pues con esta configuración, podemos ver a que grupos pertenece un usuario y sabemos ya a que recursos tiene acceso. Ahora bien, nos toca configurar los grupos Acl XXX XXX XXX (R) en el recursos a proteger, en este caso voy a hacerlo con SPO.

Es muy sencillo, vamos a la configuración de permisos de SPO (Site Settings)

Site Permissions

Yo tengo varios grupos de SPO ya creados con los permisos configurados, recordad que utilizando grupos de Active Directory podemos anidarlos dentro de estos grupos, porque SPO non soporta la anidación entre sus propios grupos.

Pues ahora lo que nos queda es entrar en cada grupo de SPO y añadir los grupos de Active Directory correspondiente (en función del permisos asociado)

Como vemos, ahora al buscar por el nombre de los grupos van apareciendo y sólo queda seleccionar el que se corresponda con el grupo de SPO. En este caso, el grupo es de Contributor pues elegimos el grupo Acl SPO SantiagoBuitragoReis (C). Recordad que esto solo es un nombre, pero que debería identificar el permiso que se configura sobre ellos. De esta forma, cuando comprobemos las membresias de los usuarios y lo vemos, ya sabemos a que recursos tiene acceso y con que nivel.

Esto tenemos que hacerlo con todos los grupos que tengamos configurados

Por último, antes de iniciar sesión con los usuarios, podemos comprobar los permisos efectivos, para ello pulsamos en Check Permissions

Escribimos el nombre de usuario que queremos comprobar sus permisos

Y vemos que tiene permisos de lectura, porque si recordáis, en el grupo Grp Empresa es miembro del grupo Acl SPO SantiagoBuitragoRies (R) y todo lo que está por debajo de él anidado, tienen permiso de lectura (viva las anidaciones!!)

Y ahora si, probamos a iniciar sesión con alguno de los usuarios

Vemos que tenemos acceso al SPO

Y en modo lectura!!

Como vemos, esto lo he hecho para aplicar permisos en SPO, pero se puede aplicar a:

• Azure AD
• Azure (recursos): próximo artículo de gobernanza de Azure
• Office 365: roles de servicios (Exchange Online, SharePoint, Teams, etc..)

El tener un entorno sincronizado es esencial, sino es una locura gestionar desde un entorno de 50 usuarios a 100000.

Espero que os haya gustado, ahora os toca probarlo a vosotros!!!