Déjà disponible en preview depuis quelques temps, Azure AD Connect apporte la synchronisation vers plusieurs tenants Azure AD en disponibilité générale (GA). Cette nouvelle fonctionnalité permet la réplication d’utilisateurs et de groupes présents dans un Active Directory vers plusieurs environnements Microsoft Cloud.
Pour arriver à cette situation, il faudra alors installer plusieurs agents Azure AD Connect sur différents serveurs (un par tenant à associer). Avant de rentrer ensemble dans la technique, voici un rappel de ce qu’Azure AD Connect apporte :
Quels sont les moyens actuels pour structurer un tenant Azure AD ?
Un tenant correspond le plus souvent une organisation souhaitant posséder et gérer environnement spécifique de services Microsoft Cloud (Azure / Office365).
Comme le recommande Microsoft, envisager l’utilisation de plusieurs tenants Azure AD ne doit pas être la norme. L’utilisation d’un seul tenant apporte les bénéfices suivants :
- Identité Cloud unique (un seul UPN pour se connecter)
- Simplification dans la gestion des services et des licences
- Simplification du management IT et de la sécurité
Bien qu’Azure AD soit construit en structure plate, il existe aussi les unités administratives. Ces dernières peuvent couvrir plusieurs besoins, dans lesquels un seul tenant suffira :
La gestion des identités dans le cas B2C ne nécessite pas non plus la création d’un nouveau tenant B2B :
Que reste-t-il donc pour justifier la création d’autres tenants Azure AD ?
- Création d’un environnement de test ou pour du développement applicatif
- Séparation de branches d’une même entreprise
- Exigences particulières de sécurité
- Besoin de disposer de plusieurs variantes d’Azure (Azure Gov, Azure China, Azure Germany)
- Limitations Azure AD
- Limitations Azure
Quels seront les inconvénients à multiplier les tenants Azure AD ?
Il ne faut pas oublier que l’utilisation de plusieurs identités Cloud va compliquer le quotidien, comme par exemple :
- Risque ou obligation de doublons de licence (erreur ou contrainte)
- Complexification pour les utilisateurs finaux
- Installation alourdie (une seule instance d’Azure AD Connect par serveur. Prévoir autant de serveur que de tenants à synchroniser. Prévoir également l’installations d’Azure AD Connect sur des serveurs de secours (redondance).
- Synchronisation limitée : certains objets comme les périphériques ou les groupes des tenants ne seront pas remontés dans Active Directory
- Gestion des mots de passe : synchronisation des hashs des mots de possible entre Active Directory et les tenants Azure AD sous certaines conditions
Test d’un changement de mot de passe pour un utilisateur synchronisé sur plusieurs tenants Azure AD
Microsoft signale justement une fonctionnalité intéressante concernant la gestion des mots de passe pour les utilisateurs synchronisés dans plusieurs tenants :
Il est possible de configurer la synchronisation du hachage de mot de passe depuis Active Directory avec plusieurs locataires Azure AD pour le même objet utilisateur. Si la synchronisation du hachage de mot de passe est activée pour un locataire, la réécriture du mot de passe peut également être activée, ce qui peut être fait sur plusieurs locataires : si le mot de passe est modifié sur un locataire, la réécriture du mot de passe est mise à jour dans Active Directory, et la synchronisation du hachage de mot de passe met à jour le mot de passe dans les autres locataires.
Microsoft Doc
Dans cet article, nous allons donc tester ensemble les différentes étapes pour mettre cette fonctionnalité en place.
Etape 0 : Rappel des prérequis
Comme toujours, des prérequis sont nécessaires pour réaliser cette démonstration d’Azure AD Connect :
- Un premier tenant, Tenant A, synchronisé avec l’Active Directory
- Un premier serveur, Serveur A, gérant un domaine Active Directory et avec l’agent Azure AD Connect d’installé
- Un second tenant, Tenant B, non synchronisé à l’Active Directory
- Un second serveur, Serveur B, joint au même domaine Active Directory
Serveur A : mon agent Azure AD Connect installé sur mon premier serveur synchronise déjà mes utilisateurs vers le tenant A
Tenant A : Filtrez vos utilisateurs pour ne voir que ceux provenant de la synchronisation de l’AD
Tenant B : Effectuez la même opération de filtrage pour constater l’absence d’utilisateurs synchronisés
Tenant B : un contrôle sur les propriétés Azure AD Connect du tenant B affiche un paramétrage encore vierge
Etape I : Installation d’Azure AD Connect sur le second serveur
Serveur B : connectez-vous en RDP sur ce second serveur pour y installer la dernière version d’Azure AD Connect, disponible sur cette page Microsoft
On ne conseille jamais d‘installer Azure AD Connect sur un contrôleur de domaine.
Laissez-vous guider par l’installeur
Etape II : Configuration d’Azure AD Connect sur le second serveur
Serveur B : acceptez les termes, puis cliquez sur Continuer
Cliquez sur Installer
Choisissez la synchronisation des hash des mots de passe, puis cliquez sur Suivant
Renseignez le compte Azure AD d’un administrateur global ou d’un administrateur de gestion des identités hybrides, puis cliquez sur Suivant
Ajoutez votre Active Directory grâce à l’utilisation d’un compte administrateur d’entreprise, puis cliquez sur Suivant
Cochez la case de confirmation de contrôle des UPN, puis cliquez sur Suivant
Définissez les OUs à synchroniser vers le tenant B, puis cliquez sur Suivant
Cliquez sur Suivant
Cliquez sur Suivant
Cochez la case concernant les mots de passe, puis cliquez sur Suivant
Cliquez sur Installer
Une fois la configuration terminée avec succès, fermez le configurateur Azure AD
Etape III : Vérifications de la synchronisation d’Azure AD Connect sur le second tenant
Serveur B : ouvrez Synchronisation Service Manager, disponible depuis le menu Démarrer
Vérifiez la bonne présence et le succès des 6 lignes de synchronisation
Cliquez sur la ligne d’exportation vers le tenant B pour y constater l’ajout d’utilisateurs
Tenant B : Retournez sur le portail Azure et rafraîchissez la liste des utilisateurs filtrés sur le tenant B
Etape IV : Test de l’authentification utilisateur sur le second tenant
Tenant B : testez l’authentification d’un utilisateur synchronisé depuis un navigateur privé avec son mot de passe AD
La connexion fonctionne bien et vous affiche la page d’accueil d’Office 365 :
Etape V : Premier test de changement de mot de passe sur le tenant B
Tenant B : essayez de changer mot de passe depuis le tenant B via le bouton de paramétrage en haut à droite
La réponse de Microsoft sur le tenant B est assez claire : il ne semble pas possible de modifier le mot de passe sur le tenant B, qui n’est pas le tenant « principal »
Fermez le navigateur privé
Etape VI : Second test de changement de mot de passe sur le tenant A
Tenant A : essayez à nouveau de changer mot de passe depuis le tenant A via la même procédure de navigateur privé
Aucun blocage pour ce second essai sur le tenant A, définissez-y alors un nouveau mot de passe sur cet utilisateur
Une fois modifié, fermez le navigateur privé
Optionnel : Si cela est possible, ouvrez une session RDP sur une machine du domaine AD avec le compte utilisateur modifié
Si la session Windows de l’utilisateur s’ouvre bien, le nouveau mot de passe a bien été pris en compte sur l’AD
Tenant B : ouvrez à nouveau un navigateur privé pour retenter l’opération d’authentification du même utilisateur avec le nouveau mot de passe sur le tenant B
Attendez quelques minutes et retentez l’opération avec le nouveau mot de passe sur le tenant B
Si la page d’accueil d’Office 365 s’ouvre bien, le mot de passe est été pris en compte sur l’Azure AD du tenant B
Conclusion
Comme nous le supposions, la gestion d’identités d’un Active Directory vers plusieurs tenants Azure AD est possible. Notre démonstration nous a aussi permis de tester la réplication des hashs des mots de passe sur plusieurs tenants sous certaines conditions.
Pour continuer sur la gestion de plusieurs tenants Azure, je trouvais intéressant de vous parler d’Azure AD Cross-Tenant Access
