Introduction & Présentation
Pour cet article, je vous propose de voir ensemble comment configurer Azure AD Connect dans un contexte Office 365. Pour rappel, Office 365 c’est la suite Cloud professionnelle de Microsoft qui embarque tous les outils de l’éditeur.
Moyennant un abonnement mensuel par utilisateur, une entreprise peut ainsi offrir de nombreux services à ses collaborateurs parmi lesquels :
- Une boîte email professionnelle (via Exchange Online),
- Un site web pour partager des documents et collaborer entre salariés (via SharePoint Online),
- Communications unifiées simplifiés (via Skype for Business),
- Stockage et partage de fichiers (via OneDrive for Business),
- Et bien d’autres choses encore (dépendant des options prises et du tarif payé).
Et l’intérêt c’est bien entendu que l’entreprise n’a pas besoin de maintenir ou faire évoluer tous les composants et serveurs car cette solution est entièrement infogérée par Microsoft.
Pour utiliser et provisionner vos utilisateurs dans Office 365, il y a plusieurs possibilités :
- Vous n’avez pas ou peu d’infrastructure on-premise (en propre). Vous pouvez donc créer vos utilisateurs directement dans Office 365 en « pure cloud ».
- Vous disposez d’une infrastructure locale existante avec notamment un Active Directory qui contient la liste de tous vos collaborateurs. C’est là qu’Azure AD Connect intervient car il va vous permettre de synchroniser ces identités vers Office 365.
C’est ce second cas qui va nous intéresser pour cet article. 🙂
Prérequis
Maintenant que les présentations sont faîtes, je vous propose de tester tout ça via un petit lab. Si vous souhaitez reproduire et tester de votre côté, voici ce dont vous aurez besoin :
- 1 tenant Office 365 (du type votredomaine.onmicrosoft.com). Dans mon cas, il s’agit d’un tenant de test via un souscription MSDN – je ne dispose pas de toutes les options mais ce n’est pas gênant pour le test. Il est possible d’avoir un tenant pour une période d’évaluation (contactez votre revendeur Microsoft).
- 1 infrastructure locale composée :
- 1 Domain Controller (Active Directory) avec 1 domaine configuré et une structure de base comprenant quelques utilisateurs et groupes à synchroniser.
- 1 serveur membre pour installer l’outil de synchronisation Azure AD Connect.
Schématiquement, cela donnerait ça :
Pour ma part, j’ai positionné ces 2 VM dans Azure pour les besoins de notre test. Mais vous pouvez réaliser ce test chez vous. Nommez vos machines et votre domaine comme vous le souhaitez cela n’a aucune importance.
Concernant, les quelques éléments à synchroniser voici ce que j’ai créé de mon côté :
- 2 OU (APAC + EMEA),
- Chacune d’elle contient 2 groupes AD et 2 comptes utilisateurs.
- Pour chacun, j’ai rempli les informations AD basiques ainsi que le champ mail.
- 1 compte de service pour l’AAD Connect avec des permissions spécifiques (j’y reviens un peu plus loin dans l’article).
- Recommandation : la valeur d’UPN (userPrincipalName) pour vos collaborateur doit être égale à l’adresse email du collaborateur pour plus de facilité pour l’utilisateur car c’est l’UPN que Office 365 utilisera comme identifiant.
Du côté du Tenant Office 365, aucun besoin spécifique à part votre compte administrateur avec l’identifiant et le mot de passe correspondant.
Installation et configuration de Azure AD Connect
Nous allons maintenant passer à l’installation et la configuration de l’AAD Connect. Pour télécharger la dernière version de l’outil, rendez-vous sur le site de Microsoft.
Envoyez l’utilitaire sur votre serveur membre et démarrez l’installation et nous allons y aller comme d’habitude étape par étape. S’il vous manque une capture d’écran, comme toujours, cela veut dire que vous utilisez les options par défaut.
L’assistant analyse le nom de votre forêt. Je vous propose dans cet article de faire la version Customize pour passer par un maximum de questions de l’assistant cela nous permettra de voir plus de choses. 🙂
Pour cette étape, choisissez les réglages suivants :
- Pas besoin de modifier l’emplacement d’installation.
- Pas besoin d’utiliser un SQL Server dédié si vous n’avez pas plusieurs milliers d’éléments à synchroniser.
- Utilisation d’un compte de service spécifique que vous aurez préparé en amont. Indiquez login et mot de passe. Les permissions souhaitées sont les suivantes (j’y reviens un peu plus tard dans l’article pour expliquer en détails) :
Enfin la dernière option, c’est pour éventuellement personnaliser les noms des groupes qui vont être créés localement sur le serveur pour la gestion d’AAD Connect. Dans la majorité des cas vous n’aurez pas besoin de le modifier. On ne coche donc pas cette option.
L’installation va normalement prendre quelques secondes…
Cette étape-ci est importante, c’est celle qui vous permet de choisir le type de synchronisation que vous souhaitez mettre en place. Globalement, dans les cas sur lesquels j’ai pu intervenir on peut distinguer 2 façons de faire :
- Password Synchronization : Vous avez confiance en Microsoft qui va stocker une copie de votre mot de passe – encrypté. C’est l’option le plus simple car du coup que vous changiez votre mot de passe sur Office 365 ou sur votre infrastructure on-premise, la synchronisation permettra de maintenir cette valeur à jour pour vos collaborateurs. Recommandé en général pour les petites et moyennes entreprises.
- Federation with AD FS : C’est en général l’option choisie par les grandes entreprises qui ne sont pas à l’aise avec l’idée de transmettre à Microsoft leurs mots de passe (même cryptés). Dans ce cas vous devez en effet monter une infrastructure AD FS (Active Directory Federation Service) en plus. Cette dernière est en générale composée d’1 serveur ADFS + 1 WAP (Web Application Proxy) et comme l’authentification est critique on double en général le tout soit 2 pour chaque rôle et donc 4 serveurs au total.
Si je devais faire un schéma de ce scénario ça donnerait quelque-chose comme ça : vous vous identifiez avec votre compte professionnel sur votre webmail ou portail O365, au moment où vous saisissez votre domaine d’entreprise Microsoft vous redirige vers votre page ADFS pour finaliser l’authentification en terminant le mot de passe. Si c’est OK, vous êtes ensuite redirigé vers la page que vous cherchiez à atteindre mais correctement identifié. Vous l’aurez compris ce scénario est un peu plus complexe.
Enfin, l’option Enable SSO vous permet dans le cas où les utilisateurs tentent des s’identifier depuis une machine de votre domaine de faciliter leur authentification par SSO (à activer ou non selon votre besoin).
Dans notre cas, nous allons continuer avec l’option Password Synchronisation.
Saisissez à présent un identifiant / mot de passe qui dispose du rôle Global Administrator sur votre Tenant Office 365. Si votre tenant est nouveau, l’adresse à utiliser est probablement du type vous@nomentreprise.onmicrosoft.com.
Une fois les credentials vérifiés, vous allez pouvoir choisir la configuration de votre forêt à synchroniser.
Indiquez le nom de votre forêt AD puis cliquez sur le bouton Add Directory. Vous devrez alors saisir la référence d’un compte de service qui aura les permissions pour lire votre AD et éventuellement effectuer des options de write-back. Si vous n’avez pas pré-créé votre compte et avez lancé l’assistant avec un compte Enterprise Admin, ce dernier va créer ce nouveau compte de service (de cette façon il positionnera les bonnes permissions tout seul).
Peu importe l’option choisie, vous devez en fin d’opération avoir le nom de votre forêt et un symbole valider pour pouvoir accéder au bouton Next.
Bien que j’essaie toujours de faire des labs proches de la réalité, cette partie va aussi dépendre de votre cas de figure. Dans mon cas il s’agit d’un tenant O365 de test, je n’ai donc pas configuré et associé un véritable domaine (j’utilise toujours le fameux entreprise.onmicrosoft.com). Il me met donc un warning sur ce point. En revanche, dans un vrai cas de production, vous aurez probablement déjà configuré le domaine à utiliser pour votre messagerie (entreprise.com ou entreprise.fr, etc.). Dans ce cas, vous n’aurez pas ce warning.
Pour ce test, je suis donc obligé de passer en cochant l’option Continue without any verified domains.
Enfin, comme je l’avais déjà évoqué précédemment, nous allons utiliser le UserPrincipalName comme identifiant principal pour authentifier les utilisateurs. C’est pourquoi il est recommandé d’avoir un UPN qui soit égal au mail afin que ce soit intuitif pour les collaborateurs lorsqu’ils s’identifient.
Dans l’étape suivante, vous allez pouvoir choisir les éléments à synchroniser par AAD Connect. Par défaut, l’ensemble du domaine est sélectionné. Si c’est la solution la plus simple et facile je vous recommande d’opter pour la seconde option.
Il est plus pertinent de synchroniser les comptes utilisateurs et groupes dont vous savez que vous aurez besoin plutôt que de polluer votre Azure Active Directory avec des éléments auxquels vous n’allez pas attribuer de services. Bien entendu, cela dépend aussi de votre AD source (et s’il est un minimum organisé – ce n’est pas toujours facile selon l’existant auquel vous devez faire face). Dans mon cas, je ne sélectionne que mes 2 OU de test.
Note : bien entendu vous pourrez modifier ce réglage plus tard sans avoir à tout réinstaller. 🙂
Pour cette étape, vous pouvez conserver les options par défaut proposées par Microsoft. Désormais, on utilise plus le ObjectSID comme référence.
Si vous avez déjà fait une sélection pertinente au niveau du choix des OU à synchroniser, vous pouvez conserver les options par défaut ici. Si cela ne vous a pas été possible, vous pouvez là encore exécuter un filtre additionnel pour ne synchroniser uniquement les éléments qui appartiendraient à un groupe particulier.
Dans cette partie, les options disponibles sont directement liées aux réglages que nous avons précédemment effectués. Dans notre cas, je vais choisir Password Synchronization pour permettre à l’AAD Connect de synchroniser les mots de passe dans le sens AD local vers Azure AD. Mais vous pouvez également choisir l’option Password writeback pour aussi mettre à jour votre AD si l’utilisateur effectuait un changement de passe directement depuis Office 365.
(Selon vos choix précédents) Cette avant-dernière étape va vous permettre de mettre en place le SSO pour les postes dans le domaine. Vous devez saisir les credentials d’un compte Enterprise admin pour qu’il puisse configurer votre forêt AD.
Et finalement, sélectionnez l’option Start… pour démarrer automatiquement une première synchronisation après l’installation et cliquez sur Install. Le staging mode permet de procéder à la configuration d’AAD Connect tout en empêchant les synchronisations de s’effectuer (dans des cas de tests par exemple où si vous voulez vérifier plus tard votre configuration).
Si vous avez le même warning que moi en dessous c’est que votre compte de service AAD Connect ne dispose pas des options nécessaires sur votre forêt AD. Les permissions à positionner (soit uniquement sur les OU spécifiques ou bien sur l’ensemble de la forêt AD) sont les suivantes :
La configuration est en train de se déployer…
Finalement, la configuration est terminée. Vous pouvez cliquer sur Exit et lancer depuis le menu Démarrer l’application Synchronization Service Manager.
Première synchronisation
Là, je ne vais malheureusement pas pouvoir entrer dans les détails car AAD Connect repose en partie sur un produit appelé FIM/MIM (Microsoft Identity Management) sur lequel on pourrait rédiger des quantités de doc. Toujours est-il que dans la fenêtre principale, vous pouvez voir dans Opérations que vos opérations de synchronisations ont été effectuées.
Mais ce que vous pouvez observer c’est que vous avez eu des opérations de Full Import, de Synchronization puis finalement d’Export. Et dans la ligne qui contient le nom de votre tenant O365 + la mention Export, vous verrez dans les statistiques d’exécutions que des éléments ont été créés (8 éléments ajoutés et 2 mis à jour). Cela correspond à nos 4 groupes, 4 utilisateurs de tests contenus dans nos 2 OU. 🙂
Je ne m’attarde pas non plus sur les autres apps installées : Synchronization Rule Editor ou WebService connector. Dans les cas les plus basiques, vous ne les utiliserez pas et ce n’est pas l’objet de l’article. Si besoin, posez vos questions dans les commentaires.
Vérifications
Le plus simple maintenant et de nous connecter sur notre portail admin Office 365 pour vérifier la liste des utilisateurs. Vous verrez tout de suite qu’une synchronisation AAD Connect a été effectuée avec succès grâce à la mention suivante sur le portail admin :
Et vous pourrez le confirmer en vérifiant la liste de vos comptes utilisateurs et voir que nos 4 utilisateurs sont bien présents dans la liste :
Même constat du côté des groupes :
Notez au passage que pour les utilisateurs ou groupes, vous pouvez voir la mention Synced with Active Directory pour tout ce qui a été synchronisé et donc créé via AAD Connect. Et vous verrez In cloud pour les objets créés uniquement/directement dans Office 365 !
Il ne vous reste alors plus qu’à activer les licences pour les utilisateurs souhaités afin de leur activer les services souhaités (en fonction de vos licences). Pour ma part et s’agissant d’un tenant de test, je n’ai qu’une seule et unique licence (pour mon compte admin) je ne peux donc pas en activer sur mes comptes de test.
Désormais, lorsque vous allez créer de nouveaux collaborateurs et/ou groupes ils seront automatiquement synchronisés sur Office 365 (s’ils sont bien dans les bonnes OU que vous avez sélectionné). Et si vous réalisez une modification d’un attribut AD – celle-ci sera également mise à jour lors de la prochaine synchronisation AAD Connect.
Par défaut, AAD Connect effectue une nouvelle synchronisation toutes les 30 minutes. Ce paramétrage peut être modifié en PowerShell pour éventuellement raccourcir ce délai. Même chose dans l’autre sens, si vous supprimez un compte qui disposait d’une licence O365 sur votre AD, le compte sera supprimé aussi dans Office 365.
Si vous avez des questions, n’hésitez pas à utiliser les commentaires ci-dessous ! 🙂
Bonjour thibault, merci super tuto
J’ai une question comment cela se passe lorsque la conf est déjà en place et que j’envisage de changer de tenant ?
Merci,
Donc si je comprends bien tu as déjà fait une synchronisation sur un tenant de certains objets et tu veux mettre tous ces objets vers un nouveau tenant… En principe, cela ne pose pas de soucis particuliers à mon avis. Par contre, tu vas être bloqué au moment de configurer le même domaine sur le nouveau Tenant à priori ça ne fonctionnera pas. Tu devrais donc supprimer le domaine sur l’ancien tenant. Et là je parle simplement des comptes synchronisés mais si tu avais déjà des data (mails, sharepoint, etc) sur l’ancien tenant tu risques de devoir faire face à des migrations pas forcément faciles à faire.