Federation on slash-root.fr

Keycloak : Federation d’un annuaire LDAPS (Active Directory)

Tue, 23 Aug 2022 15:10:58 +0200

Cet article a pour but de décrire la mise en place de la fédération d'un annuaire LDAPS (Active Directory) au sein d'un royaume Keycloak.

Testé avec un domaine Active Directory On-Premises et avec Azure Active Directory.

Contexte de l’infrastructure

L'infrastructure sur laquelle je vais m'appuyer est la suivante :

1 contrôleur de domaine Active Directory (AD DS) avec sa PKI (AD CS) sous Windows Serveur 2019 Standard
- Domaine : aukfood.lan
- FQDN du contrôleur de domaine : dc01.aukfood.lan
1 serveur Keycloak en version 19.0.1
- Déployé dans docker swarm avec ce stack : /docker-swarm-stack-keycloak-v19-latest/
- URL : keycloak.example.com

Certificat TLS

Note : Les commandes de ce chapitre sont réalisées depuis le serveur hébergeant le conteneur keycloak.

Récupération du certificat

Pour commencer, il va falloir récupérer le certificat TLS utilisé pour la liaison LDAPS.

LDAP = Port 389 TCP

LDAPS = Port 636 TCP

Avec l'utilitaire openssl, il est possible de tester que la liaison LDAPS est fonctionelle ainsi que de récupérer différentes informations (dont le certificat du serveur) :

openssl s_client -connect dc01.aukfood.lan:636

Voici le retour pour cette infra :

depth=0 CN = dc01.aukfood.lan
---
Certificate chain
 0 s:CN = dc01.aukfood.lan
 i:DC = lan, DC = aukfood, CN = aukfood-DC01-CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHLzCCBRegAwIBAgITTAAAAAczDQgCtUWEjAAAAAAABzANBgkqhkiG9w0BAQsF
[...]
AniSQdTOnACZrX//9tDg73RV9w==
-----END CERTIFICATE-----
subject=CN = dc01.aukfood.lan
issuer=DC = lan, DC = aukfood, CN = aukfood-DC01-CA

Copier le Server certificate commençant par -----BEGIN CERTIFICATE----- et se terminant par -----END CERTIFICATE----- dans un fichier server-ldaps.cer :

cat <<EOF > server-ldaps.cer
-----BEGIN CERTIFICATE-----
MIIHLzCCBRegAwIBAgITTAAAAAczDQgCtUWEjAAAAAAABzANBgkqhkiG9w0BAQsF
[...]
AniSQdTOnACZrX//9tDg73RV9w==
-----END CERTIFICATE-----
EOF

Création du keystore

Maintenant que le certificat TLS du contrôleur de domaine a été récupéré, il va falloir l'importer dans un keystore.

Tout d'abord, installer openjdk-11-jre :

sudo apt install openjdk-11-jre

Puis importer le certificat server-ldaps.cer dans un keystore nommé keystore.jks :

keytool -import -trustcacerts -alias dc01.aukfood.lan-CA -file server-ldaps.cer -keystore keystore.jks

Saisir un mot de passe à appliquer au keystore :

Entrez le mot de passe du fichier de clés : 
Ressaisissez le nouveau mot de passe :

Vérifier la présence du certificat dans le keystore généré :

keytool -list -keystore keystore.jks

Après avoir entrer le mot de passe du keystore, le certificat est bien présent :

Entrez le mot de passe du fichier de clés : 
Type de fichier de clés : PKCS12
Fournisseur de fichier de clés : SUN

Votre fichier de clés d'accès contient 1 entrée

dc01.aukfood.lan-ca, 22 août 2022, trustedCertEntry, 
Empreinte du certificat (SHA-256) : 61:EA:83:97:92:[...]:B5:59:EE:2C:8A:2D:EA

Déclaration du keystore

Maintenant que le keystore a été généré avec le certificat TLS du contrôleur de domaine, il va falloir le déclarer au sein de Keycloakpour qu'il puisse être exploité.

Dans la stack keycloak (voir lien en début d'article), un volume conf est monté pour la persistance des données du répertoire /opt/keycloak/conf dans le conteneur.

Envoyer le keystore précédement généré dans le conteneur :

docker cp ./keystore.jks $(docker ps -qf name=keycloak):/opt/keycloak/conf/

Puis ajouter les variables suivantes sur la stack de keycloak :

services:
 app:
 [...]
 environment:
 [...]
 # Indiquer le mot de passe du keystore
 KC_SPI_TRUSTSTORE_FILE_FILE: /opt/keycloak/conf/keystore.jks
 KC_SPI_TRUSTSTORE_FILE_PASSWORD: MotDePasseTresSecure
 [...]

Le MotDePasseTresSecure est celui qui a été indiqué lors de la création du keystore.

Lister les stacks dans docker swarm :

docker stack ls

Identifier l'ID du service docker exécutant

NAME SERVICES ORCHESTRATOR
keycloak 1 Swarm
nextcloud 2 Swarm
portainer 2 Swarm
rocketchat 2 Swarm
swarmpit 4 Swarm
traefik 1 Swarm

La stack faisant tourner le keycloack en v19 est nommé keycloak dans ce cluster docker.

Supprimer la stack keycloak :

docker stack rm keycloak

Puis relancer la stack kycloak pour prendre en compte les nouvelles variables d'environnement concernant le truststore :

docker stack deploy -c ./keycloak/stack.yml keycloak

Le fichier stack.yml est stocké dans un répertoire nommé keycloak de mon répertoire courant. A adapter suivant son emplaccement dans le FHS.

Logs

Avant de passer à la configuration de la fédération de l'annuaire Active Directory via LDAPS à Keycloak, il est important de vérifier et de de s'assurer du bon redémarrage du conteneur.

Pour cela, lister les services en cours au sein du cluster docker :

docker service ls

Identifier le service adéquat (ici : keycloak_app) :

ID NAME MODE REPLICAS IMAGE PORTS
2degmsl8r3se dashy replicated 0/0 lissy93/dashy:latest 
7jq3dje5b0t8 keycloak_app replicated 1/1 quay.io/keycloak/keycloak:latest 
ubq1dvhwv0st nextcloud_app replicated 1/1 nextcloud:latest 
arz4ca4gvfgv nextcloud_mariadb replicated 1/1 mariadb:latest 
vr2c7ptq6a8k portainer_agent global 5/5 portainer/agent:latest 
h6h5merxg9a2 portainer_portainer replicated 1/1 portainer/portainer-ce:latest 
mzsq3uof6c1r rocketchat_mongodb replicated 1/1 bitnami/mongodb:4.4 
tmu3kz5n7xq9 rocketchat_rocketchat replicated 1/1 registry.rocket.chat/rocketchat/rocket.chat:latest 
kos1zg1wowxi swarmpit_agent global 5/5 swarmpit/agent:latest 
gtjs3mikbtaf swarmpit_app replicated 1/1 swarmpit/swarmpit:latest 
nx6s2mt19bzx swarmpit_db replicated 1/1 couchdb:2.3.0 
n5oq9gx05bnd swarmpit_influxdb replicated 1/1 influxdb:1.7 
u7b8rsym5lzp traefik_traefik replicated 1/1 traefik:latest

Vérifier la bonne exécution du service en gardant un shell ouvert avec la lecture des logs en temps réel :

docker service logs -f keycloak_app

Configuration de la fédération LDAPS

Note : A partir de maintenant, la configuration est à effectuer à travers la console web d'administration du service Keycloak.

User federation

Sélectionner le royaume adéquat ou en créer un nouveau (1), puis se rendre sur User federation (2) :

Ajouter un fournisseur LDAP :

Note : Pour les explications des différents champs, leurs fonctions, leurs utilités, etc... qui vont suivre, se référer à cet article que j'ai écris en 2021 sur l'intégration d'un annuaire LDAP (OpenLDAP, huhu) : /keycloak-integration-ldap-externe/

Tous les paramètres de synchronisation y sont traités :

Gestion du stockage des utilisateurs
L'influence du mode Import Users sur les requêtes LDAP (LDAPS, même combat)
L'Edit Mode et ses différents paramètres
Les types de Vendor
Les différents champs Users DN ou Bind DN
Les configurations possibles pour la synchronisation ainsi que leurs périodicités

General options

(1) Console display name : Entrer un nom afin d'identifier cette fédération d'utilisateurs au sein de Keycloak.
(2) Vendor : Indiquer le type d'annuaire.

Connection and authentication settings

(1) Connection URL : Renseigner l'URL de connexion à l'annuaire LDAPS sous la forme ldaps://FQDN_DC:636. Cette URL doit correspondre au "Common Name" du certificat. Celui-ci peut être identifié lors de l'utilisation de la commande openssl au début de cet article.

(2) Use Truststore SPI : Indiquer l'utilisation du truststore javax.net.ssl.trustStore (pour le keystore.jks) uniquement pour ldaps.

(3) Bind DN : Indiquer le DistinguishedName de l'utilisateur de l'annuaire qui sera utilisé par Keycloak. Pour le récupérer facilement :

Get-ADUser UTILISATEUR_AD | FT DistinguishedName

(4) Bind credentials : Mettre le mot de passe de l'utilisateur indiqué au point précédent.

A noter que pour le moment, il manque des informations dans le paramétrage de la liaison LDAPS. De ce fait, le "Test connection" et le "Test authentication" ne sont pas encore réalisables (Une des différences avec les versions de Keycloak sous Wildfly en version 16 et inférieure).

LDAP searching and updating

(1) Edit mode : Définir le mode d'édition de l'annuaire.

(2) Users DN : Indiquer le DistinguishedName de l'OU contenant les utilisateurs à fédérer.

Tests et import utilisateurs

Il est maintenant possible de tester la connexion LDAPS et l'authenfication.

Ces 2 tests doivent aboutir :

Ensuite, en haut à droite de la page, bien s'assurer que cette fédération soit enabled. Puis dans action (1), déclencher la synchronisation (2) de tous les utilisateurs :

L'importation des utilisateurs aboutie :

Dans les utilisateurs du royaume Keycloak, je retrouve bien les utilisateurs contenus dans l'OU définit dans la fédération.

Mappers

Dans ce contexte, l'utilisateur "Julien LOUIS", se retrouve avec un username contenant des espaces. Cela est dû au faites que l'attribut cn de l'annuaire a été mappé vers l'attribut username de Keycloak.

Pour voir tous les utilisateurs du royaume keycloak (fédération incluse), rechercher ***** comme utilisateur.

De plus, pour l'utilisateur final, cela ne correspondra pas au login auquel il est habitué d'utiliser.

Pour modifier ce comportement, il faut mapper l'attribut sAMAccountName de l'anuaire Active Directory vers l'attribut username de Keycloak.

Se rendre sur les paramétrages de la fédération précédement réalisée, puis dans l'onglet Mappers (1), éditer le mapper username (2) :

Modifier le champ LDAP Attribute pour y inscrire sAMAccountName :

Puis, enregistrer la modification en bas de page.

Ensuite, dans l'onglet Settings, modifier l'Username LDAP attribute en y inscrivant sAMAccountName :

Puis, enregistrer la modification en bas de page.

En relançant la synchronisation de tous les utilisateurs de l'annuaire vers Keycloak, les utilisateurs sont mis à jour :

A présent, le login des utilisateurs importés dans Keycloak est correctement paramétré.

Nextcloud : Intégration d’une authentification SSO avec AD FS

Fri, 08 Jul 2022 12:00:33 +0200

Cet article fait office de PoC (Proof of Concept) sur la mise en place d'une authentification SSO (Single-Sign-On) à travers le service ADFS (Active Directory Federation Services) de Microsoft et l'application Open Source Nextcloud.

Cela va permettre aux utilisateurs de la plateforme Nextcloud de s'authentifier avec leur compte Active Directory en utilisant le protocole SAML dans des contextes réseaux totalement différents.

Environnement

Environnements déjà déployés :
- Nextcloud v24.0.2
- Contrôleur de domaine Windows Serveur 2019
Informations :
- Domaine AD : aukfood.lan
- Nom serveur AD : adfs-dev
- Domaine publique utilisé : example.com (remplace les parties floutées dans les captures d'écrans)
- URL Nextcloud : https://nc-dev.example.com
- Enregistrement DNS pour l'ADFS : adfs2-dev.example.com

Génération du certificat Let’s Encrypt

A effectuer sur le serveur Windows (Tous les services seront déployés sur le contrôleur de domaine) :

Installation de IIS en Powershell :

Install-WindowsFeature -name Web-Server -IncludeManagementTools

Faire un enregistrement de type A dans une zone DNS publique pour le serveur IIS :
```
adfs2-dev IN A xxx.xxx.xxx.xxx
```
Dans ce PoC, le domaine publique utilisé sera example.com.
Créer la racine du site web pour résoudre le challenge :
```
mkdir c:\inetpub\adfs2-dev.example.com
```
Créer un fichier index.html dans la racine du site web :
```
notepad c:\inetpub\adfs2-dev.example.com\index.html
```
Insérer le contenu suivant puis enregistrer :
```
Hello world
```
Ouvrir la console de Gestionnaire des services Internet (IIS).
Supprimer le site web par défaut.
Ajouter un nouveau site web :
Télécharger le client ACME pour Let's Encrypt ici : https://www.win-acme.com/

A l'heure actuelle, la dernière version : https://github.com/win-acme/win-acme/releases/download/v2.1.22.1267/win-acme.v2.1.22.1267.x64.pluggable.zip
Décompresser l'archive et déplacer le fichier Web_Config.xml à la racine du site web.
Redémarrer le site web.
Lancer une ligne de commandes et se positionner dans le répertoire préalablement extrait.
Exécuter wacs.exe :
Créer un nouveau certificat (Choix N).
Sélectionner le site ajouté au préalable dans IIS :
Peu importe si le certificat est de type wildcard ou non.
Le certificat est généré avec une tâche planifiée qui va renouveller le certificat automatiquement :
Une liaison https (vhost) a été automatiquement générée pour le site web :
Ce certificat est celui qui sera exploité par le service AD FS.

Exportation du certificat au format pfx

Re-lancer l'outil wacs.exe.
Faire le choix A (Manage renewals) :
Afficher les détails avec D, puis noter le .pfx password :

Ouvrir le dossier des certificats Let's Encrypt :

explorer C:\ProgramData\win-acme\acme-v02.api.letsencrypt.org\Certificates\

Sélectionner le certificat .pfx correspondant puis démarrer l'assistant d'importation du certificat au niveau de l'ordinateur local (Pour rappel : c'est le DC) :
Saisir le mot de passe de la clé privée (.pfx password noté au préalable) et cocher Marquer cette clé comme exportable :
Sélectionner automatiquement le magasin de certificats.
Terminer l'assistant d'importation du certificat.
Ouvrir la gestion des certificats de l'ordinateur local :
```
certlm.msc
```
Dans "Personnel\Certificats" (1), sélectionner le certificat préalablement importé (2). Dans "Toutes les tâches" (3), sélectionner "Exporter" (4) :
Il est maintenant possible d'exporter la clé privée du certificat :
Exporter toutes les propriétés étendues :
Saisir un mot de passe pour protéger la clé privée :
Spécifier le nom du fichier à exporter au format pfx.
Terminer l'assistant d'exportation du certificat.

Installation AD FS

Installer le service ADFS-Federation en Powershell :

Install-WindowsFeature -name ADFS-Federation -IncludeManagementTools

Créer la clé racine du service de distribution de clés en Powershell :
```
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
```
La configuration du service se fera en mode graphique à travers le gestionnaire de serveur servermanager.exe :
Créer le premier serveur de fédération dans une batterie de serveurs de fédération.
Importer le certificat préalablement exporté au format .pfx (1). Puis, entrer un nom pour le service FS (2) :
Spécifier un compte de service :
Une base de données SQL Server peut être exploitée. Dans ce PoC, une base de données interne Windows est utilisée.
Après examen des options, la configuration peut être lancée :
Redémarrer le serveur Windows.

Activer la page de login de l'ADFS en Powershell :

Set-AdfsProperties -EnableIdpInitiatedSignonPage $true

Tester la connexion : https://adfs2-dev.example.com/adfs/ls/IdpInitiatedSignon.aspx

Paramétrage Nextcloud

Se connecter en SSH sur le serveur Nextcloud et se positionner à la racine du projet web :
```
cd /var/www/nc-dev.example.com/www/
```

Installer l'application user_saml avec occ (A adapter selon le propriétaire du projet web) :

sudo -u nextcloud php8.0 occ app:install user_saml
# user_saml 5.0.2 installed
# user_saml enabled

Se connecter à l'interface web du Nextcloud en admin.
Se rendre dans "Paramètres" (1) / "Authentification SSO & SAML" (2). Puis "Utiliser l'authentification SAML intégrée" (3) :
Dans la partie "Général", entrer l'Attribut pour relier l'UID :
```
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
```
C'est l'UPN du compte de l'utilisateur dans l'AD qui fera office de nom d'utilisateur au sein de l'instance Nextcloud.
Configurer les options IdP :
- Identifiant de l'entité IdP : http://adfs2-dev.example.com/adfs/services/trust
- URL cible du fournisseur d'identités à qui le fournisseur de service enverra la requête d'authentification : https://adfs2-dev.example.com/adfs/ls
Cliquer sur "Hide optional Identity Provider settings" pour accéder au champ Certificat public X.509 de l'IdP.
Sur le serveur Windows, ouvrir la console de gestion de l'ADFS :
```
%windir%\ADFS\Microsoft.IdentityServer.msc
```
Dans "Service" / "Certificats" (1), Afficher le certificat (2) utilisé pour la signature de jetons :
Dans l'onglet "Détails", copier dans un fichier :
Exporter au format : *X.509 encodé en base 64 (.cer)**
Spécifier un nom de fichier pour l'export.
Copier le contenu de ce fichier exporté au format .cer et le coller dans le champ Certificat public X.509 de l'IdP dans Nextcloud :
Mapper les attributs suivants au minimum :
- Attribut pour relier le nom d'utilisateur : http://schemas.microsoft.com/identity/claims/displayname
- Attribut pour relier l'adresse mail : http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
Télécharger le fichier metadata.xml :
Pour avoir la possibilité de garder l'authentification avec la base utilisateur interne de Nextcloud, cocher Autoriser l'utilisation de plusieurs systèmes d'authentification :

Bien vérifier l'enregistrement du paramétrage en quittant le menu "Authentification SSO & SAML" et en y revenant (Surtout sur le paramétrage du point précédent).

Paramétrage AD FS

Sur le serveur Windows, ouvrir la console de gestion de l'AD FS :
```
%windir%\ADFS\Microsoft.IdentityServer.msc
```
Ajouter une approbation de partie de confiance :
Prendre en charge les revendications.
Importer les données concernant la partie de confiance à partir du fichier metadata.xml téléchargé préalablement :
Saisir un nom pour cette approbation et éventuellement des notes.
Sélectionner une stratégie de contrôle d'accès. Dans ce PoC, tout le monde sera autorisé :
La partie de confiance a été configurée à l'aide du fichier metadata.xml fourni.
Editer la stratégie d'émission de revendication :
2 règles de revendication de transformations sont à ajouter au minimum :
- userPrincipalName
- Email
Le modèle de régle de revendication à suivre est : Envoyer les attributs LDAP en tant que revendications.
Règle userPrincipalName :
Règle Email :
Appliquer les 2 règles ajoutées.

Vérification de l’authentification

Se connecter à Nextcloud, et choisir de s'authentifier au travers une Connection SSO & SAML :
Utiliser un compte de l'Active Directory autoriser à se connecter à travers l'AD FS :
Congratulations !