En el artículo de hoy vamos a realizar un proceso muy atractivo, además de desafiante: integrar las identidades de nuestros usuarios de "Active Directory" en la plataforma "Microsoft Azure", pero manteniendo las contraseñas de dichos usuarios en el entorno "on-premises" (es decir, en local). Dicho de otro modo, hacer que los usuarios, cuando vayan a iniciar sesión en el portal de "Office 365", se validen en la infraestructura local. ¿Cómo lo lograremos? Pues haciendo uso de la característica "AD Federation Services" de "Windows Server".
Antes que nada, en este tutorial se asume que el profesional que vaya a desplegar todo este proceso tiene conocimientos suficientes de "Powershell", además de conocer cómo funcionan los diversos servicios de "Windows Server" en una infraestructura de red corporativa. En cuanto a conocimientos de "Office 365", se irá guiando al profesional en este mismo artículo.
Necesitamos:
- Cuatro servidores: uno para "Active Directory" el cual albergará las identidades de nuestros usuarios; otro para "AD Federation Services", que se encargará de validar los usuarios para "Office 365"; otro para "Web Application Proxy" (que intermediará entre "Office 365" y "AD Federation Services"), y el último para "Azure AD Connect", el cual se encargará de sincronizar las identidades de "Active Directory" (en nuestro caso, sin sus contraseñas) a "Office 365".
- Un certificado válido, debido a que "Office 365" tendrá que validar todo el proceso con un servicio ("AD Federation Services") que, efectivamente, es quien dice ser.
- Un proveedor de DNS, ya que tendremos que exponer a Internet el servicio de "Web Application Proxy".
- Y una suscripción en "Microsoft Azure", que tendrá la extensión de nuestro directorio en local configurado con el mismo dominio (el cual será un dominio federado).
Para ilustrar este despliegue, el dominio que usaremos tanto en nuestro directorio local como en "Office 365" será "javantest.intelequia.com". Las tres máquinas ("AD Federation Services", "Web Application Proxy" y "Azure AD Connect") deberán estar unidas al dominio local, pudiéndolo hacer con el siguiente "cmdlet" en cada una de ellas:
Add-Computer -DomainName 'javantest.intelequia.com'
Como último requisito previo, en todas las máquinas necesitaremos tener instalado nuestro certificado. Más abajo dejaré un enlace para ampliar conocimientos sobre ello.
El esquema, una vez montado todo el entorno, será como en el siguiente diagrama:
Vemos que, en el momento que un usuario inicie sesión en "Office 365", su identidad de usuario será comprobada en el directorio de "Azure" (debido a que se están sincronizando las identidades de todos los usuarios desde "Active Directory" mediante el servicio de "Azure AD Connect"). Pero, al mismo tiempo, su validación será realizada mediante el servidor de federación, el cual será el que consulte las credenciales al anterior "Active Directory". Y una vez dicha validación sea correcta, entonces el usuario ya podrá iniciar sesión satisfactoriamente en "Office 365".
Preparación del dominio en "Office 365"
Lo primero que haremos será iniciar sesión en el portal de Office 365 con las credenciales de un administrador global para configurar nuestro dominio en la nube. A la izquierda, desplegamos el menú "Setup" y seleccionamos "Domain", para a continuación seleccionar arriba "Add domain...":
Introducimos el nombre de nuestro dominio, y ya el asistente nos indica que las direcciones de email de nuestros usuarios serán del tipo "nombredeusuario@dominio", que serán idénticas a las que tenemos en la infraestructura local.
Hacemos clic en "Next", y para poder verificar que el dominio nos pertenece, "Office 365" nos pide introducir un registro de tipo TXT en nuestro proveedor de DNS contratado:
Hacemos clic en "Verify", y si la verificación ha tenido éxito, pasaremos a configurar el método de manipulación de registros DNS. Como esto es una prueba, le diremos que nosotros mismos administraremos los registros DNS:
En la siguiente pantalla podremos configurar algunos servicios de "Office 365" adicionales:
De momento dejamos desmarcado todo, ya que únicamente queremos que los usuarios en el entorno puedan inicar sesión sin más en "Office 365".
Hacemos clic en "Next", y entonces habremos terminado de configurar el dominio, el cual estará listo para usarse con la infraestructura local:
A partir de entonces, pasaremos a configurar las máquinas.
Configurando "Active Directory"
Comenzaremos iniciando nuestro directorio con las siguientes líneas de "Powershell":
Install-WindowsFeature -name AD-Domain-Services `
-IncludeManagementTools
Install-ADDSForest -DomainName "nombrededominio"
Con ambos "cmdlets" será suficiente para iniciar un directorio sencillo (en nuestro ejemplo, donde dice "nombrededominio" lo sustituiríamos por "javantest.intelequia.com").
Una vez reiniciado el servidor, necesitaremos crear una cuenta de servicio para "AD Federation Services", haciéndolo en "Powershell" así (siendo "máquinadeldirectorio" la máquina que aloja el servicio de "Active Directory"):
# New service account
$SERVICE_ACCOUNT_NAME = 'fsaccount'
$SERVICE_ACCOUNT_DNS_HOSTNAME = 'máquinadeldirectorio.nombrededominio'
New-ADServiceAccount $SERVICE_ACCOUNT_NAME `
-DNSHostName $SERVICE_ACCOUNT_DNS_HOSTNAME
Es posible que ocurra un error debido a la seguridad interna de "Active Directory" en cuanto a creación de cuentas de servicio; para solventarlo, dado que estamos en un entorno de pruebas, ejecutaríamos la siguiente línea:
Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))
Y, esta vez sí, podremos crear la cuenta de servicio con el script de antes.
Para ir poblando nuestro directorio con algunos usuarios de ejemplo, haremos uso del siguiente script:
$PASSWORD = ConvertTo-SecureString -String 'P@55w0rd' `
-AsPlainText -Force
foreach ($i in @('ana','bibiana','carolina','david','emilio'))
{
if ($i -eq 'ana')
{
New-ADUser $i `
-AccountPassword $PASSWORD `
-UserPrincipalName "$i@nombrededominio" `
-DisplayName "$($i.substring(0,1).toupper()+$i.substring(1).tolower()) Álvarez Aguado" `
-GivenName $($i.substring(0,1).toupper()+$i.substring(1).tolower()) `
-Surname 'Álvarez Aguado' `
-EmailAddress "$i@nombrededominio"
}
elseif ($i -eq 'bibiana')
{
New-ADUser $i `
-AccountPassword $PASSWORD `
-UserPrincipalName "$i@nombrededominio" `
-DisplayName "$($i.substring(0,1).toupper()+$i.substring(1).tolower()) Bacallado Balaguer" `
-GivenName $($i.substring(0,1).toupper()+$i.substring(1).tolower()) `
-Surname 'Bacallado Balaguer' `
-EmailAddress "$i@nombrededominio"
}
elseif ($i -eq 'carolina')
{
New-ADUser $i `
-AccountPassword $PASSWORD `
-UserPrincipalName "$i@nombrededominio" `
-DisplayName "$($i.substring(0,1).toupper()+$i.substring(1).tolower()) Castaño Cervera" `
-GivenName $($i.substring(0,1).toupper()+$i.substring(1).tolower()) `
-Surname 'Castaño Cervera' `
-EmailAddress "$i@nombrededominio"
}
elseif ($i -eq 'david')
{
New-ADUser $i `
-AccountPassword $PASSWORD `
-UserPrincipalName "$i@nombrededominio" `
-DisplayName "$($i.substring(0,1).toupper()+$i.substring(1).tolower()) Díaz Dalmau" `
-GivenName $($i.substring(0,1).toupper()+$i.substring(1).tolower()) `
-Surname 'Díaz Dalmau' `
-EmailAddress "$i@nombrededominio"
}
elseif ($i -eq 'emilio')
{
New-ADUser $i `
-AccountPassword $PASSWORD `
-UserPrincipalName "$i@nombrededominio" `
-DisplayName "$($i.substring(0,1).toupper()+$i.substring(1).tolower()) Echeverría Escalona" `
-GivenName $($i.substring(0,1).toupper()+$i.substring(1).tolower()) `
-Surname 'Echeverría Escalona' `
-EmailAddress "$i@nombrededominio"
}
}
Lo que hacemos es implementar cinco usuarios de prueba, cada uno con una contraseña, nombre y apellidos válidos.
Configurando "AD Federation Services"
En el servidor de federación comenzaremos el proceso con el siguiente script, el cual implementará rápidamente el servicio ("dominioprincipal" se refiere al dominio que deberíamos tener en el atributo "CN" del certificado, "NOMBRE DEL SERVICIO" a un nombre que queramos que aparezca en el portal de nuestro servidor de federación, y "DOMINIO" es el nombre "NETBIOS" de nuestro directorio):
# Get the thumbprint of our valid certificate
$DOMAIN_CERT_SUBJECT = 'dominioprincipal'
$FINGERPRINT = (Get-ChildItem -Path cert:\LocalMachine\My\ `
| Where-Object { $_.Subject -match $DOMAIN_CERT_SUBJECT }).Thumbprint
# Federation Services
$SERVICE_ACCOUNT_NAME = 'fsaccount'
Install-windowsfeature adfs-federation –IncludeManagementTools
Import-Module ADFS
Install-AdfsFarm `
-CertificateThumbprint:$FINGERPRINT `
-FederationServiceDisplayName:"NOMBRE DEL SERVICIO" `
-FederationServiceName:"nombrededominio" `
-GroupServiceAccountIdentifier:"DOMINIO\$SERVICE_ACCOUNT_NAME$" `
-OverwriteConfiguration
Como configuración adicional en este apartado, en nuestro proveedor de DNS habrá que configurar un registro de tipo A, con nuestro nombre de directorio como valor, apuntando a la dirección pública que implementemos para nuestro servicio "Web Application Proxy".
Configurando "Web Application Proxy"
En el caso del servicio "Web Application Proxy", usaríamos este script:
# Web Access Proxy
$DOMAIN_CERT_SUBJECT = 'dominioprincipal'
$FINGERPRINT = (Get-ChildItem -Path cert:\LocalMachine\My\ `
| Where-Object { $_.Subject -match $DOMAIN_CERT_SUBJECT }).Thumbprint
Install-WindowsFeature Web-Application-Proxy `
-IncludeManagementTools
Install-WebApplicationProxy `
–CertificateThumbprint $FINGERPRINT `
-FederationServiceName "nombrededominio"
Nos pedirá las credenciales de una cuenta con los permisos necesario para administrar el servicio de "AD Federation Services", en este caso, nos será suficiente con la cuenta de administrador del dominio. Una vez tenga éxito la implementación, tendremos que reiniciar la máquina para completar la configuración.
Configurando "Azure AD Connect"
En la última máquina instalaremos el servicio de sincronización del directorio local con "Office 365". Descargamos el instalador de "Azure AD Connect" en este enlace y lo ejecutamos, aceptando los términos y condiciones de uso.
Para configurar el servicio de sincronización, seleccionaremos la opción "Customize", simplemente para poder personalizar con más detalle la sincronización (además, podremos indicar algunas opciones adicionales, como por ejemplo, un servidor SQL del que dispongamos, etc.). Como solo es una prueba simple, no marcamos nada, seleccionamos "Install".
Tras un breve periodo de tiempo, seleccionamos el tipo de inicio de sesión en "Office 365". El que nos interesa es la opción que dice "Federation with AD FS":
Nos pide ahora una cuenta de "Office 365" para recabar datos de la suscripción en "Azure". De todas las cuentas que podamos usar, tiene que ser una con al menos permisos de "Global administrator".
A continuación, le decimos qué directorio queremos sincronizar con "Office 365". Teniendo marcado el directorio con el que estamoos trabajando(en nuestro ejemplo, "javantest.intelequia.com"), hacemos clic en "Add", e introducimos unas credenciales con autorización sobre el dominio, esto es, que esté en el grupo de administradores del dominio.
Luego, podremos ver que el dominio para iniciar sesión está verificado, y que el atributo con el que los usuarios son sincronizados a "Office 365" es el "userPrincipalName" (de manera que a los usuarios en la nube los veremos con el tipo "usuario@nombrededominio"):
En la siguiente pantalla podremos indicar si queremos filtrar la sincronización por dominio y/o unidad organizativa. Como solo tenemos un directorio, le indicaremos que solo queremos sincronizar los usuarios que están en la unidad organizativa "Users":
La siguiente captura es muy importante, se trata de cómo "Office 365" identificará a los usuarios cuando tenga que validarlos, pudiendo indicarle que:
- En todos los directorios del bosque de "Active Directory" los usuarios están identificados una única vez, o por el contrario, identificarlos de manera unívoca mediante el atributo que le indiquemos (es decir, un mismo atributo común para las diferentes identidades en los directorios del bosque), y luego
- "Azure AD Connect" decida el atributo para diferenciar los usuarios en "Office 365". Por defecto, el atributo usado es el "mS-DS-ConsistencyGUID", pero podemos indicarle que sea otro, por ejemplo, el atributo "sAMAccountName".
Lo dejamos todo por defecto, ya que nos vale esta configuración:
Luego "Azure AD Connect" nos pregunta si queremos filtrar las identidades aún más, por ejemplo, por determinados grupos. Lo dejamos también tal como está, no filtraremos en esta ocasión.
Algunas opciones adicionales se nos presentan en la siguiente pantalla:
Teniendo en cuenta que son funcionalidades extras, habrá que consultar con el administrador que nos provea del servicio de "Office 365" por las diferentes cuantías que puedan suponernos. Por el momento, dejamos todo como está.
Ahora le indicaremos la configuración de nuestro servidor de federación, proporcionando tanto la dirección del servidor como las credenciales de un usuario con permisos en dicho servidor:
Hacemos clic en "Next", y seleccionamos el dominio con el que queremos que los usuarios se identifiquen en "Office 365" (en nuestro ejemplo, vendría a ser "javantest.intelequia.com"):
Finalmente, el programa nos avisará de que está listo para iniciar la sincronización:
Hacemos clic en "Install", y entonces "Azure AD Connect" comenzará a implementarlo todo; una vez que acabe, el programa nos pedirá verificar que el servidor de federación tiene conectividad desde Internet. Para ello, marcamos la opción "I have created DNS records that allow clients...", y seleccionamos "Verify", pudiendo comprobar que la verificación resultó satisfactoria:
Por último, hacemos clic en "Exit", y tras unos minutos, podremos ver que las identidades de los usuarios comienzan a aparecer en el directorio en "Office 365":
A partir de este momento, los usuarios ya podrían iniciar sesión en "Office 365".
Comprobando que un usuario puede iniciar sesión
El proceso de un usuario para poder iniciar sesión en "Office 365" es como sigue:
- A continuación, "Office 365" se comunica con nuestro servidor de federación, trasladándonos al mismo para poder validarnos allí:
- Una vez validados correctamente, el servidor de federación creará un "token" de validación para "Office 365", indicándonos este último que podemos iniciar sesión correctamente, y comprobándolo al llevarnos automáticamente de nuevo al portal de "Office 365":
En resumen...
Lo que acabamos de hacer es una sincronización típica de usuarios de un "Active Directory" local a la infraestructura de "Office 365" (es decir, un entorno híbrido en la convención de Microsoft), pero de tal manera que las contraseñas no salieran nunca del dominio local, de ahí que hiciéramos uso de un servicio "AD Federation Services" que validara a los usuarios que inician sesión en "Office 365". Así, al tiempo que los usuarios siguen haciendo uso normal de los recursos en la infraestructura local, podemos hacer que se beneficien de las ventajas y/o aplicaciones que existen en la plataforma "Office 365" de Microsoft. Por último, comentaros que en otro artículo futuro veremos cómo realizar todo el proceso pero con un directorio en Linux (en el que tan solo habrá que cambiar un poco el comportamiento tanto de "AD Federation Services" como de "Azure AD Connect").
Fuentes y bibliografías consultadas
https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/working-with-certificates
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/install-active-directory-domain-services--level-100-
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/whats-new-active-directory-federation-services-windows-server https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/install-the-ad-fs-role-service https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/configure-a-federation-server
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn383662(v=ws.11)
https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnecthttps://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-get-started-custom
https://support.office.com/en-us/article/office-365-admin-overview-c7228a3e-061f-4575-b1ef-adf1d1669870?ui=en-US&rs=en-US&ad=US https://products.office.com/en/business/microsoft-office-365-frequently-asked-questions https://support.office.com/en-us/article/add-a-domain-to-office-365-6383f56d-3d09-4dcb-9b41-b5f5a5efd611