Synchronisation Microsoft Azure Active Directory avec Google Cloud Identity

Synchronisation Microsoft Azure Active Directory avec Google Cloud Identity

Introduction

Le présent article décrit l’automatisation et l’industrialisation de la synchronisation des utilisateurs et groupes d’utilisateurs administrés depuis un annuaire Microsoft Azure Active Directory (AD) dans l’univers Google Cloud Platform (GCP) via Google Cloud Identity. Pour information, GCP n’intègre pas d’annuaire d’identité utilisateur, mais s’appuie sur des composants tiers tel Cloud Identity, G Suite ou Gmail, etc.

La coordination est unidirectionnelle : l’AD Microsoft n’est jamais modifié par Google, les flux sont orientés uniquement depuis Microsoft vers Google.

Si votre organisation possède déjà un AD sur site (en anglais on-premise), pas d’inquiétude, il est possible d’utiliser l’AD locale de l’entreprise comme référence pour centraliser la gestion de l’ensemble de vos identités. Ceci aussi bien au niveau des solutions sur site que de multiples fournisseurs de solutions d’informatiques dans les nuages (en anglais cloud computing).

Il existe une solution pour synchroniser automatiquement vos ADs sur-site et dans le nuage sans passer par des exports et fichiers CSV.

Intérêt

Les avantages de la mise en place de cette solution sont doubles. D’un côté, elle simplifie l’accès aux outils de l’entreprise pour vos collaborateurs : chacun possède un identifiant et un mot de passe unique pour accéder à l’ensemble des services et applications (nuage et sur site). De l’autre, et c’est le principal bénéfice, cette solution accroît la sécurité de votre Système d’Information (SI). D’une part, la maintenance et l’évolution de votre politique de sécurité d’accès sont facilitées :

  • Unification de la stratégie de mots de passe[1].
  • Activation de l’Authentification Multiple (en anglais Multi-Factor Authentication, plus connus sous l’acronyme MFAcentralisée. Cette fonctionnalité est également appelée double authentification ou encore vérification en deux étapes (en anglais Two-Factor Authentication, connus sous l’acronyme 2FA).

D’autre part, la gestion de la rotation de votre personnel est optimisée : suite au départ d’un de vos collaborateurs, vous désactivez l’ensemble de ses accès d’une seule action. Ainsi, vous éliminez définitivement le risque lié à l’oubli de suppression d’accès à un ou plusieurs services.

Sous le capeau

Une image vaut mieux qu’un long discours, ci-dessous, le schéma d’interconnexion des différentes briques logicielles spécifiques à chaque plateforme, aussi bien dans le nuage que sur site.

Dans le cas où votre organisation possède déjà un AD sur site, l’utilisation du composant Azure AD Connect permet de synchroniser automatiquement votre AD dans le nuage à partir de votre AD locale. Par défaut, cette dernière est exécutée toutes les 30 minutes en mode de traitement par lot (en anglais batch). Pour plus d’information, consulter la documentation Azure https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler.

Par défaut, la synchronisation est unidirectionnelle, l’AD locale est l’unique référentiel. Dans ce contexte, si un utilisateur modifie son mot de passe depuis la plateforme d’informatique dans les nuages, ce dernier – stocké uniquement dans l’AD du nuage – sera écrasé lors de la prochaine synchronisation. L’option réécriture du mot de passe (en anglais password writeback) permet d’éviter ce comportement. L’utilisation de cette option sort du cadre de cet article, pour découvrir les fonctionnalités et les prérequis de cette dernière, consulter la documentation Azure https://docs.microsoft.com/fr-fr/azure/active-directory/authentication/concept-sspr-writeback. Pour la configuration, suivez le tutoriel Azure https://docs.microsoft.com/fr-fr/azure/active-directory/authentication/howto-sspr-writeback#configuring-password-writeback.

L’interconnexion entre les écosystèmes Microsoft Azure et Google est assurée côté Azure via l’application d’entreprise G Suite. Un composant approvisionne (en anglais provisionning) les utilisateurs et groupes. Un autre assure le rôle de fournisseur d’identité que Google Cloud Identity utilise comme fournisseur d’identité tiers (i.e. authentification unique ou en anglais Single Sign-On, plus connus sous l’acronyme SSO).

Lors de l’authentification unique, les échanges au sujet des identités entre les univers Microsoft et Google utilisent le protocole Security Assertion Markup Language v2.0, plus connus sous l’acronyme SAML. D’après Wikipédia, il s’agit d’un standard informatique définissant un protocole pour échanger des informations liées à la sécurité. Basé sur le langage XML, SAML a été développé par OASIS. Pour plus d’information, consulter https://fr.wikipedia.org/wiki/Security_assertion_markup_language.

Périmètre technique

Pour rappel, le but de cet article est de piloter la gestion des utilisateurs GCP via l’annuaire Azure AD. La configuration des différents services d’informatique dans les nuages de Microsoft et Google à l’exception des utilisateurs et groupes est hors périmètre.

Les services utilisés sont :

  • Composant Microsoft Azure AD
  • Google Cloud Identity
  • GCP avec les utilisateurs issus de Google Cloud Identity

Aucun service GCP n’est utilisé, la finalité de la manipulation est d’obtenir le succès d’authentification d’un utilisateur géré depuis Azure AD, mot de passe inclus. Suivant la même logique, le composant GCP Cloud IAM, en charge de la gestion des droits des utilisateurs n’est pas utilisé.

La démarche vise également à prendre en compte la modification des mots de passe utilisateur de façon homogène : lorsque l’utilisateur modifie son mot de passe depuis la plateforme GCP, celui-ci doit être pris en compte sur l’ensemble des plateformes (i.e. GCP et Azure AD).

Pré-requis

Licences

Écosystème Microsoft

A minima, il faut une licence Azure Active Directory Premium P1. Sans celle-ci, il n’est pas possible d’activer l’approvisionnement par groupe.

Pour plus d’information sur les différentes éditions et les tarifs, consulter https://azure.microsoft.com/fr-fr/pricing/details/active-directory/.

Si votre organisation possède déjà un abonnement Office 365, Dynamics CRM Online, Enterprise Mobility Suite ou autres services Microsoft, vous disposez d’accès gratuit à Azure AD. Pour plus d’information, consulter https://docs.microsoft.com/en-us/office365/securitycompliance/use-your-free-azure-ad-subscription-in-office-365.

Il est possible de tester gratuitement la version Azure Active Directory Premium P2 sans limite de fonctionnalités pendant 30 jours. Pour plus d’information, consulter ce lien. Une fois la période d’essai révolue, votre configuration n’est pas perdu, il est possible d’acheter une licence adaptée à vos besoins à posteriori.

Écosystème Google

Google Cloud Identity existe en deux versions : Free edition ou Premium. La première version est limitée à 14 jours et pour un nombre d’utilisateurs maximum de 50. Dès lors que cette valeur est franchie, vous devez basculer sur l’édition Premium. Pour plus d’information, consulter https://support.google.com/cloudidentity/answer/7668528?hl=fr&ref_topic=7385935

Accès

Pour configurer la jonction entre les deux plateformes, il faut :

  • Un compte administrateur Azure AD
  • Un compte super-administrateur G Suite[2]

En plus des deux comptes ci-dessus, il faut également un compte de service[3] “virtuel” super-administrateur G Suite. Ce dernier est utilisé par Azure Active Directory pour approvisionner les utilisateurs Azure AD dans l’écosystème Google. Au moment de la mise en place de l’interconnexion des deux services, la plateforme Azure prend en charge uniquement des comptes utilisateurs et non des comptes de services, d’où la notion de “virtuel”.

Phase exploratoire : automatisation des tâches répétitives

Pour faciliter la configuration et l’intégration des plateformes, il est pertinent de créer un jeu de test représentatif des utilisateurs et rôles qui composent les différents membres d’une organisation travaillant sur un SI axé autour de la science des données (en anglais Data Science). Ci-dessous, les utilisateurs et rôles affectés utilisés lors des tests :

Pour faciliter l’ajout/modification des utilisateurs et groupes, il convient de créer un fichier CSV. Ci-dessous, les colonnes qui composent ce fichier :

  • groups : le(s) groupe(s) auquel l’utilisateur appartient (séparé par des “|”)
  • jobTitle : la fonction de l’utilisateur dans l’organisation
  • firstName : le prénom de l’utilisateur
  • lastName : le nom de l’utilisateur

L’identifiant et l’adresse e-mail sont générés automatiquement à partir du prénom et nom de l’utilisateur.

Pour automatiser la création et suppression des utilisateurs, groupes et rattachement des utilisateurs à leur(s) groupe(s) respectif, il faut créer deux scripts PowerShell. L’automatisation de ces tâches rébarbatives permet un véritable gain de temps et d’énergie. En effet, supprimer, puis recréer une liste d’utilisateurs nécessite beaucoup de “clics” via la console d’administration Azure sans que l’action soit porteuse de valeur ajoutée !

Voici un aperçu macro des principales APIs utilisées dans le script d’insertion :

  • Authentification auprès d’Azure AD

Connect-AzureAD -TenantId $TenantId -Credential $Cred

  • Récupérer un utilisateur existant dans l’annuaire Azure AD

$AADUser = Get-AzureADUser -Filter « UserPrincipalName eq ‘$UPN' »

  • Créer un nouvel utilisateur dans l’annuaire Azure AD

New-AzureADGroup -DisplayName $Group -Description $Description -SecurityEnabled $true -MailEnabled $false -MailNickName $GroupMailNickName

  • Contraindre les utilisateurs ainsi importés à changer leur mot de passe lors de la première authentification

$PasswordProfile = New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile
$PasswordProfile.ForceChangePasswordNextLogin = $true
$PasswordProfile.Password = $NewUserPassword

 

Pour plus d’information sur les politiques de mot de passe et restrictions Azure AD, consulter https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-policy

Pour plus d’information sur le SDK PowerShell Azure AD, consulter https://docs.microsoft.com/en-us/powershell/module/azuread/?view=azureadps-2.0.

Au besoin, pour en savoir plus sur les fonctionnalitées PowerShell de base (CSV, …), consulter https://docs.microsoft.com/fr-fr/powershell/module/Microsoft.PowerShell.Utility/?view=powershell-6.

Sous Windows, PowerShell embarque un environnement de développement (en anglais, Integrated Development Environment, plus connus sous l’acronyme IDE).

L’interconnexion par programmatique avec Azure est assurée par le module AzureAD. Pour plus d’information, consulter https://docs.microsoft.com/en-us/powershell/azure/active-directory/install-adv2?view=azureadps-2.0.

Tutoriel pas à pas

Notion de groupe racine

Pour faciliter la gestion de vos utilisateurs au sein d’Azure AD, il est important de créer un groupe Azure AD “racine” auquel toute ressource – utilisateur ou groupe d’utilisateur – vouée à être utilisée dans l’écosystème Google appartient. Dans le présent article, ce groupe s’appelle Google Cloud Platform Resources. Cela offre deux principaux avantages :

  • Sélectionner de façon simple et transparente les ressources de l’annuaire Azure AD que l’on souhaite synchroniser avec l’annuaire Google Cloud Identity. Il n’est pas pertinent de porter tous vos utilisateurs et/ou groupes Azure AD dans l’écosystème Google (i.e. les utilisateurs Azure AD qui n’exploitent que les services Office 365).
  • Optimiser les coûts de licence de l’annuaire Google Cloud Identity. Au sein de ce dernier, chaque utilisateur présent dans l’annuaire, actif ou non est facturé. Contrairement à Azure, il n’y a pas de notion d’affectation d’utilisateurs ou groupes d’utilisateurs à une licence.

Dans l’exemple ci-dessous, l’utilisateur James (Organization Administrator) appartient aux trois groupes ci-dessous – dont le groupe racine (Google Cloud Platform Resources) :

 

Idem ci-dessous avec le groupe Organization Administrators, le groupe racine est également présent :

 

Activation de la licence Azure AD

Affecter la licence Azure Active Directory Premium P1 ou plus au groupe Google Cloud Platform Resources.

Depuis le portail Azure de votre organisation, sélectionner le composant Azure Active Directory

 

…puis suivre les étapes indiquées ci-dessous :

  1. Cliquer sur le menu Licence
  2. Selectionner la licence Azure Active Directory Premium P1
  3. Cliquer sur Assigner
  4. Cliquer sur Utilisateurs et groupes
  5. Sélectionner le groupe racine Google Cloud Platform Resources
  6. Cliquer sur Sélectionner

Installation de l’application d’entreprise G Suite

Ajoutez l’application G Suite à vos applications d’entreprises existantes.

 

Cette dernière s’installe depuis la galerie d’applications Azure comme illustré ci-dessous :

 

Note : pour la suite du tutoriel, toutes les opérations sont réalisées depuis l’application d’entreprise G Suite qui vient d’êtres installée. Cliquer sur G Suite pour débuter la configuration de cette dernière.

 

Sélection des ressources à approvisionner

Il existe deux options pour approvisionner les utilisateurs et groupes :

  • L’ensemble des utilisateurs et groupes contenu dans l’annuaire Azure AD
  • Les utilisateurs et groupes uniquement sélectionnés

Comme évoqué précédemment, il convient d’utiliser le deuxième choix. Rendez-vous dans la section “Utilisateurs et groupes” comme illustré ci-dessous :

 

Sélectionner le groupe Google Cloud Platform Resources puis cliquez sur le bouton “Assigné” :

 

Quelques secondes plus tard, voici le résultat obtenu :

 

Configuration de l’approvisionnement

C’est l’une des sections les plus complexe en termes de manipulation, un bon nombre d’options sont à configurer. Pour commencer, allez dans la section “Approvisionnement” puis suivre les cinq étapes ci-dessous :

 

1. Sélectionner le mode d’approvisionnement automatique

2. Utiliser le compte de service virtuel précédemment créé sur Google Cloud Identity (cf. section pré-requis, accès) pour autoriser l’application Azure AD auprès de Google.

3. La configuration du mapping des attributs n’est pas opérationnel par défaut. Suivre les recommandations ci-dessous. Ne pas changer les autres valeurs par défaut.

Tout d’abord, modifier le paramétrage du mapping des attributs “utilisateurs” de façon à obtenir la configuration ci-dessous :

 

Faire de même avec le mapping des attributs “groupes”

Sélectionner “utilisateurs et groupes assignés” comme périmètre de synchronisation.

5. La configuration de l’approvisionnement est terminée. Activer cette dernière en cochant la case à cocher “effacer l’état courant et réinitialiser la synchronisation” puis valider l’ensemble des modification.

 

Configuration de l’authentification unique

À présent, les utilisateurs et groupes Azure AD qui appartiennent au groupe Google Cloud Platform Ressources sont automatiquement synchronisés dans Google Cloud Identity.

Cependant, à ce stade, l’approvisionnement synchronise l’ensemble des informations sélectionnées précédemment dans la phase mapping des attributs : e-mail, prénom, nom, etc. En revanche, la gestion des secrets, à savoir la synchronisation des mots de passe, est hors périmètre. En l’état actuel, les utilisateurs sont contraints de gérer leurs mots de passe de façon distincte au sein des deux annuaires. Si ceux-ci le modifient dans l’univers Azure, leur mot de passe Google n’est pas modifié et vise et versa.

La mise en place de l’authentification unique résout ce problème. Le paramétrage s’effectue au sein des deux plateformes : Azure AD et Google Cloud Identity.

Avant d’aller plus loin dans la configuration, il est important de comprendre comment Google gère le basculement vers le fournisseur d’identité. Cela permet de se dispenser de nombreuses heures de recherches pour comprendre d’un problème inexistant si l’on utilise un compte super-administrateur lors des tests. En effet, c’est le fonctionnement normale de l’authentification unique de Google. Les deux paragraphes ci-dessous, sont issus de la documentation officielle :

Lorsque les super-administrateurs tentent de se connecter à un domaine SSO (avec ou sans masque de réseau) via admin.google.com, ils doivent saisir l’adresse e-mail complète de leur compte administrateur Google et le mot de passe associé (et non leurs nom d’utilisateur et mot de passe SSO), puis cliquer sur Connexion afin d’accéder directement à la console d’administration. Ils ne sont pas redirigés vers la page de connexion SSO (i.e. celle du fournisseur d’identité tiers, Azure dans notre cas).

Lorsque des super-administrators essaient de se connecter au service Google service.google.com/a/votre_domaine.fr et que le domaine dispose d’un masque de réseau, ils sont uniquement redirigés vers la page de connexion SSO s’ils se connectent à partir du masque de réseau de leur domaine. S’ils se trouvent en dehors de ce dernier ou si leur domaine ne possède pas de masque de réseau, Google les invite à saisir leurs nom d’utilisateur et mot de passe Google.

Seuls les utilisateurs non super-administrateur sont redirigés systématiquement vers la page de connexion d’authentification unique.

Pour plus d’information, consulter https://support.google.com/a/answer/6341409?hl=fr

Le schéma ci-dessous illustre le mécanisme de connexion d’un utilisateur à une application Google via un service d’authentification unique basé sur le protocole SAML v2. Pour rappel, dans le cas présent, le fournisseur d’identité tiers est Azure :

Pour plus d’information consulter https://support.google.com/a/answer/6262987?hl=fr.

Côté Azure AD

La première partie de la configuration se situe sur la plateforme Azure, dans la section “Authentification unique”.

 

 

1. Sélectionner “Authentification basée sur SAML”

2. Définir l’URL et domaine G Suite / Google Cloud Identity

Les deux valeurs à renseigner sont :

 

3. Supprimer les attributs du jeton SAML défini par défaut

Curieusement, avec les valeurs par défaut, la communication de l’authentification unique ne fonctionne pas.

4. Télécharger le certificat Azure AD SAML

Ce certificat est utilisé ultérieurement lors de la configuration de l’authentification unique avec un fournisseur tiers (section Côté Google Cloud Identity).

5. Récupérer l’URL d’authentification unique Azure AD (connexion et déconnexion)

6. Appliquer les changement

 

Côté Google Cloud Identity

Dernière ligne droite, il reste à activer l’authentification unique basée sur un fournisseur d’identité tiers côté Google. Pour se faire :

  1. Se connecter la console d’administration Google Cloud Identity (admin.google.com) avec un compte utilisateur super-administrateur
  2. Naviguer dans les menus Sécurité > Paramétrage authentification unique (SSO)
  3. Cocher la case à cocher paramétrage de l’authentification unique avec un fournisseur d’identité tiers
  4. Renseigner les informations relatives au fournisseur d’identité Azure

Indiquer les URLs de votre plateforme Azure :

  • Sign-in page URL : Page de redirection de l’authentification unique (i.e. celle précédemment obtenue lors de la configuration côté Azure AD à l’étape cinq.
  • Sign-out page URL : Page vers laquelle les utilisateurs seront redirigés lors de leur déconnexion. Cette dernière est générique à toute plateforme Azure AD.
  • Change password URL : Page vers laquelle les utilisateurs seront redirigés en cas de changement de mot de passe initié à partir de l’écosystème Google (i.e. Cloud Identity et GCP).

Attention, toutes les URLs doivent utiliser le protocole HTTPS

Dernier paramètre, le certificat : téléverser (en anglais upload) celui précédemment téléchargé lors de la configuration côté Azure AD à l’étape quatre.

Cocher la case “utiliser un domaine spécifique”

Laisser le masque réseau vide

Valider les modifications.

Tests de l’authentification unique depuis GCP

Félicitation ! La configuration de vos plateformes est terminée, testons si tout fonctionne correctement.

  1. Depuis votre navigateur web préféré, démarrer une nouvelle session de navigation privée puis saisir l’URL https://console.cloud.google.com/.
  2. Utiliser un des identifiants utilisé lors de la création du jeu de test
  3. Il s’agit de la première connexion de cet utilisateur, la politique de sécurité de mot de passe utilisée lors de la création du compte impose le changement du mot de passe à la première connexion.
  4. Bienvenue sur GCP !

 

Pour finir, testons si la modification du mot de passe depuis GCP est bien prise en charge par la plateforme Azure AD et non uniquement côté Google Cloud Identity.

Note : La redirection pour changer le mot de passe s’effectue correctement, cependant, une fois ce dernier correctement modifié, la plateforme Azure n’effectue pas de redirection vers la plateforme initiale (i.e. GCP).

Merci pour votre lecture et à bientôt pour un prochain article !

[1] Contrainte appliquée aux mots de passes utilisateurs : longueur minimale, caractères spéciaux obligatoire, absence de ressemblance avec l’identifiant, …

[2] L’interface d’administration des identités (https://admin.google.com) est commune à Google Cloud Identity et G Suite. Dans la documentation, le terme G Suite est principalement utilisé.

[3] Un compte de service (en anglais service account) est généralement réservé aux interactions machine-à-machine (en anglais machine-to-machine).