Active Directory 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 !

Ressources en vrac

Azure : Synchronisation AD On-Premise <> Azure AD

Sat, 20 Nov 2021 04:03:05 +0100

Azure AD" />

Objectif

L'objectif de ce document est de mettre en place une synchronisation des utilisateurs, des mots de passes, et des groupes d'un Active directory local vers une infrastructure Azure AD et d'attribuer des licences Microsoft 365 aux utilisateurs du domaine. Ceux-ci n'auront qu'une seule identité entre le domaine local et leurs services Microsoft 365.

Contexte

Contrôleur de domaine local : SRV-AD (Windows Serveur 2019 Standard)
Domaine local : starwars-bzh.local
Tenant Azure AD : starwarsbzh.onmicrosoft.com
Architecture du domaine local :

Vérifier l’activation de la corbeille Active Directory

En PowerShell :

Get-ADOptionalfeature -Filter {name -like "Recycle Bin Feature"}

Si la valeur EnabledScope est vide, cela signifie que la corbeille Active Directory n'est pas activée.

Activer la corbeille Active Directory

En PowerShell :

Enable-ADOptionalFeature "Recycle Bin Feature" -Scope ForestOrConfigurationSet -Target "starwars-bzh.local" -server srv-ad

Les options -Target et -Server doivent être adapté avec l'infrastructure du domaine local. Un message d'avertissement apparait car c'est une action irréversible mais ça peut sauver des vies.

Maintenant, la corbeille Active Directory est activée.

Configurer l’alias UPN

Le domaine local est starwars-bzh.local et le domaine Microsoft 365 public associé est starwarsbzh.onmicrosoft.com. Pour que la synchronisation fonctionne, un alias UPN doit être mis en place dans le domaine local. L'idée est de remplacer le @starwars-bzh.local par @starwarsbzh.onmicrosoft.com pour tous les utilisateurs qui seront synchronisés vers Azure.

Sur le contrôleur de domaine, ouvrir la MMC Domaines et approbation Active Directory :

domain.msc

Effectuer un clic droit sur le nom de la console et cliquer sur Propriétés :

Renseigner la zone Autres suffixes UPN avec le domaine Microsoft 365 déclaré soit starwarsbzh.onmicrosoft.com puis appliquer.

Ensuite, il faut modifier en masse l'UPN par défaut des utilisateurs qui seront synchronisés dans Azure AD. Si on regarde les propriétés d'un compte utilisateur dans l'AD, on voit que l'on peut changer l'UPN par défaut.

Changer l'UPN par défaut :

Au lieu de la faire à la main sur chaque utilisateur, il est possible de le faire en masse.

En PowerShell :

Get-ADUser -Filter * -SearchBase "OU=Services,OU=Starwars-BZH,DC=starwars-bzh,DC=local" | Foreach{

$UPNNew = $_.UserPrincipalName -replace "@starwars-bzh.local","@starwarsbzh.onmicrosoft.com"

Set-ADUser -UserPrincipalName $UPNNew -Identity $_.SamAccountName

}

L'option -SearchBase est à adapter selon les OU contenant les utilisateurs qui seront à synchroniser. La cmdlet Get-ADUser est récursive.

Installer Azure AD Connect

Télécharger l'outil à l'adresse suivante : https://www.microsoft.com/en-us/download/details.aspx?id=47594
Puis lancer l'installation sur le contrôleur de domaine local.
Accepter les termes de la licence puis continuer :

Un message d'avertissement s'affiche indiquant que le domaine local n'est pas routable sur Internet. Une installation personnalisée est donc préférable :

Aucune des options suivantes n'est nécessaire. Il n'y a donc rien à cocher. Cliquer sur Installer :

Dans la partie Connexion utilisateur, Synchronisation de hachage du mot de passe est coché. Cela permet de synchroniser le mot de passe de l'AD local avec Azure AD. Le mot de passe ne transite pas en clair mais uniquement son hash. La case Activer l'authentification unique peut être cochée si on souhaite mettre en place du SSO (Single-Sign-On). Ainsi l'utilisateur n'aura pas à ressaisir sont mot de passe du domaine lors de l'accès aux services Azure (Microsoft 365).

Dans la partie Connexion à Azure AD, un compte administrateur général du tenant Azure est requis :

Dans la partie Connexion de vos annuaires, la forêt locale est bien détectée. Cliquer sur Ajout d'un annuaire. Il est préférable de créer un nouveau compte dans l'AD local qui sera utilisé par les outils effectuant la synchronisation entre l'AD local et Azure AD. Un compte administrateur du domaine est requis afin de pouvoir créer cet utilisateur. Cet utilisateur sera stocké dans le container Users. Il ne devra être en aucun cas modifié ou supprimé.

La connexion à l'AD local est configurée :

Les suffixes UPN apparaissent comme Non ajouté. Cela est tout à fait normal car il n'y a pas de domaines DNS spécifiques du type starwarsbzh.fr. Si un domaine DNS en .fr a été ajouté au tenant Azure, celui-ci sera noté comme Vérifié. Nom d'utilisateur principal doit être sur userPrincipalName. La case Continuer sans faire correspondre tous les suffixes UPN à des domaines vérifiés est à cocher.

Sélectionner les OU à synchroniser entre l'AD local et Azure AD :

Dans la partie Identification de manière unique de vos utilisateurs, laisser le choix par défaut :

Dans la partie Filtrer les utilisateurs et appareils, laisser le choix par défaut :

Dans la partie Fonctionnalités facultatives, laisser par défaut. A noter que la Réécriture du mot de passe peut être intéressante afin de permettre aux utilisateurs de réinitialiser leur mot de passe directement à partir de Microsoft 365. Toutefois cela demande un niveau de licence Azure AD Premium P1. Sans cette option, le mot de passe est écrit dans l'Active Directory et synchronisé sur votre tenant, et non l'inverse.

Le processus de synchronisation peut démarrer :

Pour modifier la configuration, il suffit de relancer l'assistant en cliquant sur l'icône Azure AD Connect présente sur le bureau puis sur le bouton Configurer (Modification des OU à synchroniser, ajout de nouvelles fonctionnalités).

Vérifier la bonne présence des utilisateurs et des groupes dans le portail d'administration de Azure AD.

Affecter les licences Microsoft 365

Afin de pouvoir affecter une licence Microsoft 365 à un utilisateur, il va falloir dans 1er temps lui attribuer un Lieu d'utilisation. Ce paramètre se trouve dans le profil de l'utilisateur dans Azure AD :

Attention, une fois le Lieu d'utilisation affecté à un utilisateur. Un délai de 5 minutes peut être nécessaire avant de pouvoir lui attribuer une licence.

Une licence Microsoft 365 peut ensuite être attribué à un utilisateur :

Vérifier la synchronisation

Un outil nommé Synchronization Service Manager a également été installé sur le contrôleur de domaine local permettant de vérifier l'état de la synchronisation. Par défaut celle-ci s'effectue toutes les 30 minutes.

A noter que si un mot de passe est modifié dans l'AD local, celui-ci sera répliqué sous 2 minutes au sein d'Azure AD.