Acceso al OWA

El acceso al OWA lo haremos como siempre, accediendo por la URL que hayamos definido para este servicio que en nuestro caso es https://exlab.olimpo.lab/owa.

Cuando accedamos en vez de mostrarnos el formulario clásico del OWA veremos una página llamada Home Realm Discovery donde deberemos seleccionar el proveedor que vamos a usar para autenticarnos, que en nuestro caso será apereolab.olimpo.lab.

Al hacer eso accederemos al formulario del CAS donde introducieremos las credenciales de acceso. Bastante sencillo, ¿no?

Pues vamos a introducir una mejora, en realidad a nosotros ya no nos interesa que el usuario se valide mediante Directorio Activo o que tenga que seleccionar un proveedor de identididades por que con estos dos comandos de PowerShell vamos a forzar que el proveedor sea el CAS.

{% highlight posh %} Set-AdfsRelyingPartyTrust -TargetName “Outlook on the web” -ClaimsProviderName “apereolab.olimpo.lab” Set-AdfsRelyingPartyTrust -TargetName “Exchange Control Panel” -ClaimsProviderName “apereolab.olimpo.lab” {% endhighlight %}

Una mejora de última hora

Ya había terminado de redactar este tutorial cuando realizando un par de pruebas encontré la forma de evitar que al cerrar sesión se muestre este mensaje tan feo.

Todo lo que hay que hacer es editar el fichero cas.properties de nuestro CAS y añadir la siguiente línea:

{% highlight conf %} cas.authn.saml-idp.logout.sign-logout-response=true {% endhighlight %}

Reiniciamos el CAS y listo, problema solucionado.

Y con esto damos por terminado este tutorial. Cualquier comentario, ya sabéis, a través de mis redes sociales.

• /etc/cas/config/cas.properties.
• /etc/cas/services/cas_saml-100.json.
• /etc/cas/services/adfs-101.json.
• /etc/cas/metadata/adfs-metadata.xml.

Antes de comenzar

En el fichero build.gradle del CAS Overlay se han añadido las implementaciones de IDP, JSON Service Registry y LDAP. Posteriormente hemos ejecutado el comando ./gradlew clean build para crear el fichero WAR que usaremos. Para ejecutar el CAS hemos usado el comando java -jar build/lib/cas.war

También tendremos que crear un usuario que nos permita autenticar contra Directorio Activo para poder obtener la información de los usuarios. En el caso de este laboratorio el usuario creado es “APEREO USER”.

Fichero /etc/cas/config/cas.properties

{% highlight conf %} as.server.name=https://apereolab.olimpo.lab:8443 cas.server.prefix=${cas.server.name}/cas logging.config=file:/etc/cas/config/log4j2.xml cas.authn.saml-idp.core.entity-id=https://apereolab.olimpo.lab/idp cas.service-registry.json.location: file:/etc/cas/services cas.authn.ldap[0].order=1 cas.authn.ldap[0].name=AD-OLIMPO cas.authn.ldap[0].ldap-url=ldap://exlab.olimpo.lab:389 cas.authn.ldap[0].base-dn=dc=olimpo,dc=lab cas.authn.ldap[0].bind-dn=CN=APEREO USER,OU=Administrators,DC=olimpo,DC=lab cas.authn.ldap[0].bind-credential=<TU_PASSWORD> cas.authn.ldap[0].type=AUTHENTICATED cas.authn.ldap[0].subtreeSearch=true cas.authn.ldap[0].searchFilter=(&(objectClass=person)(sAMAccountName={user})) cas.authn.ldap[0].principalAttributeList=sAMAccountName,mail,userPrincipalName {% endhighlight %}

Fichero /etc/cas/services/cas_saml-100.json

Aquí nuevamente hemos hecho un poco de trampas para que capture cualquier URL.

{% highlight conf %} { “@class”: “org.apereo.cas.services.RegexRegisteredService”, “serviceId”: “http://.+”, “name” : “cas_saml”, “id” : 100, “evaluationOrder” : 100 } {% endhighlight %}

Fichero /etc/cas/services/adfs-101.json

{% highlight conf %} { “@class”: “org.apereo.cas.support.saml.services.SamlRegisteredService”, “serviceId”: “http://fs.olimpo.lab/adfs/services/trust", “name”: “adfs”, “id”: 101, “evaluationOrder”: 101, “description”: “adfs lab service”, “logoutType”: “NONE”, “attributeReleasePolicy”: { “@class”: “org.apereo.cas.services.ReturnAllAttributeReleasePolicy”, }, “usernameAttributeProvider” : { “@class” : “org.apereo.cas.services.PrincipalAttributeRegisteredServiceUsernameProvider”, “usernameAttribute” : “mail”, }, “requiredNameIdFormat”: “urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress”, “metadataLocation”: “/etc/cas/metadata/adfs-metadata.xml”, “signAssertions”: true, “signResponses”: false } {% endhighlight %}

Fichero /etc/cas/metadata/adfs-metadata.xml

Este fichero se obtiene desde ADFS. Concretamente se debe acceder a la ruta https://fs.olimpo.lab/FederationMetadata/2007-06/FederationMetadata.xml y descargar el fichero XML para luego copiarlo en esta ruta.

Directorio /etc/cas/saml

Contiene la definición del IDP, certificado de firma, encriptación, etc.

{% highlight shell %} ls idp-encryption.crt idp-encryption.key idp-metadata.xml idp-signing.crt idp-signing.key metadata-backups {% endhighlight %}

Ya en la parte siguiente veremos algunas pruebas de funcionamiento y algunas mejoras que se pueden hacer para que todo vaya más fluido. Hasta el próximo episodio.

Claims Providers Trusts

Hemos llamado “apereolab.olimpo.lab” a la relación de confianza y para su generación hemos utilizado los metadatos públicados en la siguiente URL del CAS https://apereolab.olimpo.lab:8443/cas/idp/metadata. Esto nos facilita mucho el trabajo porque ya se encarga de realizar el resto de la configuración de esta relación de confianza.

A continuación mostramos dos capturas de pantalla de las dos pestañas más importantes. Recuerda que esta configuración puede variar en función de la configuración que tengas en el Apereo CAS.

La primera captura es de la pestaña Monitoring donde figura la URL de los metadatos junto con la configuración para que se actualice automáticamente la información.

La segunda captura muestra la configuración de la pestaña que contiene los puntos finales o Endpoints.

Acceptance Transform Rules

Solo vamos a tener un regla de transformación de notificación entrante para NameID que va a ser de tipo Email e indicaremos que pase a través todos los valores de las notificaciones. Recuerda que anteriormente ya hemos comentado que nos vamos a fiar que desde Apereo nos van a enviar una dirección de correo electrónico que existe en el Exchange Server y que además va a coincidir con el UPN de un usuario. Sí, es un poco de trampa, lo sé. 😋

Por si quereis echarle un vistazo a la consulta que se genera, es la siguiente:

{% highlight query %} c:[Type == “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier”, Properties[“http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format”] == “urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress”] => issue(claim = c); {% endhighlight %}

Y ya con esto nos vemos en el próximo capítulo donde hablaremos de la parte del Apereo CAS.

Vamos a suponer que ya tienes un controlador de dominio operativo, en nuestro caso sobre el dominio OLIMPO y que además ya cuentas con al menos un Exchange Server 2019 en marcha, recuerda que en este laboratorio está integrado en el mismo servidor que el controlador de dominio, es decir, en exlab.olimpo.lab.

Configuración de la federación ADFS

La federación de mi laboratorio está desplegada sobre el servidor adfslab.olimpo.lab y tiene la configuración que se muestra en la siguiente captura. Realmente se trata de la configuración por defecto donde el único cambio reseñable es que la federación tiene como nombre http://fs.olimpo.lab simplemente para diferenciarla del nombre del servidor que la alberga.

Relaying Trust Parties

En nuestro caso se van a generar dos relaciones de relaciones de confianza, una para Outlook Web App (OWA) y la otra para Exchange Control Panel (ECP). A la primera le hemos puesto el nombre de “Outlook on the web” y a la segunda “Exchange Control Panel”.

Recuerda que estos son los únicos servicios de Exchange que se pueden federar ya que tanto EAS como Outlook deben autenticarse mediante Directorio Activo.

Outlook on the web

Como se puede observa la segunda relación de confianza es casi igual que la primera solo que para el ECP. En la siguiente captura se puede observar la configuración de los identificadores que solo es uno hacia la URL del OWA.

En esta captura se puede observar la configuración de los puntos finales. En realidad solo tenemos uno de tipo POST hacia la URL de OWA.

Exchange Control Panel

Como se puede observa la segunda relación de confianza es casi igual que la primera solo que para el ECP. En la siguiente captura se puede observar la configuración de los identificadores que en este caso también es solo uno hacia la URL del ECP.

En esta captura se puede observar la configuración de los puntos finales. Como en el primer caso solo tenemos uno de tipo POST hacia la URL del ECP.

Issuance Transform Rules

En las reglas de transformación de notificaciones tenemos dos reglas, una para el UPN y otra para obtener el PrimarySID mediante uan búsqueda en el repositorio de Directorio Activo. Ambas reglas son exactamente iguales en ambas relaciones de confianza por lo que solo las describiremos una vez.

Regla UPN

En esta primera regla simplemente obtenemos la notificación entrante NameIdentifier que es de tipo email (esto lo veremos cuando configuremos el CAS) y emito una nueva notificación de tipo UPN con el valor que me llega.

{% highlight query %} c:[Type == “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier”] => issue(Type = “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", Value = c.Value); {% endhighlight %}

Es verdad que esto es bastante deficiente y estoy confiando en que me llegue la notificación con una dirección de correo valida y que coincida con el UPN del usuario en Directorio Activo pero recuerda que esto se trata de un laboratorio para aprender.

Regla PrimarySID

En esta segunda regla aprovechamos la notificació de tipo UPN recien creada para localizar el objectSID del usuario buscandolo por el UPN y por la dirección de correo electrónico por si no somos capaces de localizarlo por el UPN.

{% highlight query %} c1:[Type == “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier”] && c2:[Type == “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn”] => issue(store = “Active Directory”, types = (“http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"), query = “(&(objectCategory=person)(objectClass=user)(|(userPrincipalName={0})(&(mail={0})(!(userPrincipalName={0})))));objectSid;OLIMPO\random”, param = c2.Value); {% endhighlight %}

Aquí nuevamente hacemos un poco de truco porque estamos forzando el dominio del usuario al del laboratorio pero no he sido capaz de hacerlo funcionar de otra manera.

Bueno y con esto nos despedimos hasta el siguiente episodio donde veremos la parte de los proveedores de confianza de notificaciones o Claims Providers Trusts.

Listado de episodios

Comencemos con el listado de todos los artículos relacionados con este tutorial.

• Parte 1.
• Parte 2.
• Parte 3.
• Parte 4.
• Parte 5.

Esquema del laboratorio

Vamos a usar cuatro máquinas virtuales en este laboratorio aunque en un entorno real deberían ser al menos seis ya que he integrado el controlador de dominio con el servidor Exchange y, como no nos hacía falta para un laboratorio, no he publicado ADFS mediante un Web Application Proxy.

Como plataforma de virtualización se ha utilizado WMWare Workstation 16 pero se puede hacer con cualquier otra como VirtualBox, KVM o Hyper-V.

Los servidores Windows se han montado en Windows Server 2022 Standard, la estación de trabajo en Windows 10 Pro y el servidor de Apereo en CentOS 7.9 de 64 bits.

Se ha utilizado Exchange Server 2019 CU11 y para la implementación del CAS de Apereo se ha utilizado la 6.0.0 obtenida del overlay descargado desde su repositorio en GitHub en la URL https://github.com/apereo/cas-overlay-template.

Para el direccionamiento de red se ha usado un segmento de red de clase C en el segmente 172.16.53.0/24 con direccionamiento estático asignado a las máquinas.

La distribución final de los equipos en el laboratorio será la siguiente:

• Controlador de dominio y Exchange Server. 6 GB de RAM, 4 vCPU y dos discos de 100 GB. Dirección IP: 172.16.53.10.
• Servidor ADFS. 4 GB de RAM, 2 vCPU y 60 GB de disco. Dirección IP: 172.16.53.11.
• Servidor Apereo CAS. 2 GB de RAM, 2vCPU y 40 GB de disco. Dirección IP: 172.16.53.13.
• Estación de trabajo. 4 GB de RAM, 2vCPU y 60 GB de disco. Dirección IP: 172.16.53.20.

Voy a dar por supuesto que todos sabemos instalar el sistema operativo tanto de los servidores como de la estación de trabajo y también obtener las ISO de Windows y Exchange Server por lo que no voy a explicar esta parte. Tampoco voy a detallar cómo se instala el controlador de dominio o Exchange Server porque entiendo que si estás leyendo este artículo es porque ya sabes todo esto.

Hasta el siguiente episodio.