Migration tenant à tenant Microsoft 365 : stratégies et bonnes pratiques
Avec la croissance des fusions, acquisitions et réorganisations internes, la migration de tenant à tenant dans Microsoft 365 est un...
Azure Active Directory : Mise en œuvre de comptes guest synchronisés
Temps de lecture : 15 mins
Le Rhino
Pour qui connaît Azure AD, les comptes guest sont des comptes ‘full cloud’, permettant à des utilisateurs externes à votre organisation d’utiliser des ressources Cloud (par exemple Teams). Ils permettent la collaboration en mode B2B.
Voici un exemple de compte guest, donc non « directory synced ». Ils sont notamment reconnaissables à la chaîne #EXT# présente dans l’UPN (User Principal Name) et au champ ‘User Type’.
—
Dans certains scénarios nécessitant une authentification Kerberos (ex. Windows Virtual Desktop), ou contextes historiques comme la gestion des comptes dans un outil IAM, il peut être intéressant d’utiliser des comptes Guests « Synchronisés », donc gérés via un AD et l’Azure AD.
Les avantage des comptes Guest, quels qu’ils soient :
- Moins de permissions par défaut, cf. :
- Distinction pour des scenarios de conditionnal access
Merci à Marie Sukiasyan qui m’a fait découvrir cette fonctionnalité, dont je vous détaille la mise en œuvre ci-après.
Mise en œuvre
Scénario, prérequis
Il faut choisir un discriminant pour distinguer les comptes AD ‘Guest’ des comptes que je qualifierai de ‘classiques’.
Dans ce scénario, je retiens l’attribut AD ‘msDS-cloudExtensionAttribute1’, qui, mis à la valeur ‘Guest’, convertira le compte Azure AD.
Il est possible d’utiliser un autre champs tel que le domaine dans l’UPN d’un compte (@partner.entreprise.com pour les guests, @entreprise.com pour les comptes classiques)
Côté Azure AD, c’est l’attribut ‘UserType’, qui une fois passé à ‘Guest’ au lieu de ‘Member’ taggue le compte comme tel.
La modification de cet attribut est supportée à partir de la version Azure AD Connect 1.5.30.0. Assurez vous d’avoir la dernière version !
Pour info, ce scenario est dérivé de la documentation Microsoft… étape par étape.
Assurez-vous de tester tout ceci sur un lab et de sauvegarder aux différentes étapes !
Configuration étape par étape
Nous créons tout d’abord un compte AD classique. Ici dans une OU dédiée et synchronisé par Azure AD Connect.
Ce compte servira de base à une transformation en guest :
Il est dit « Member », de source « Windows Server AD », donc synchronisé par Azure AD connect.
Sur le serveur Azure AD Connect, nous stoppons la synchronisation et vérifions qu’elle ne soit pas en cours (‘SyncCycleInProgress’ à ‘False’).
Dans le Manager des règles de Synchronisation, nous ajoutons les attributs nécessaires via les propriétés de chaque connecteur.
Pour AD, c’est l’attribut de base choisi dans le scénario, ‘msDS-cloudExtensionAttribute1’.
C’est de la configuration avancée, nous validons donc.
Pour Azure AD, l’attribut ‘UserType’ doit être ajouté.
Ce message ne nous fait maintenant plus peur…
Laissons cet outil de côté.
Il faut maintenant éditer les règles de synchronisation des comptes. Il est important de ne PAS modifier les règles existantes car celles-ci peuvent potentiellement être mises à jour en même temps qu’Azure AD Connect (identifiées par id / tag et écrasées si besoin). Les règles personnalisées sont à positionner sur une précédence de 1 (le plus fort) à 99.
Dans la direction ‘Inbound’ (entrante) :
Nous ajoutons une règle sur le connecteur de notre AD.
La règle doit être nommée, je vous préconise de réutiliser la nomenclature existante, et d’ajouter une description pour la repérer (le CUSTOM est parlant !).
Nous sélectionnons en entrée le domaine AD, les objets de type ‘user’ dans l’AD et de type ‘person’ dans le metaverse d’Azure AD Connect.
Le type de lien est ‘join’ et la précédence est positionnée arbitrairement à 10 (attention si des règles custom existent déjà, elles ne doivent pas être sur la même précédence).
Le filtre de ‘scoping’ ou portée, permet de limiter les comptes à manipuler. Le filtre positionné est identique à la règle ‘In from AD – User Common’ pour traiter les mêmes comptes. Passons l’écran ‘add join rules’, non nécessaire.
La règle de modification de l’attribut ‘UserType’ est faite sur la base de la valeur msDS-cloudExtensionAttribute1.
Pour le champs Source : IIF(CBool(InStr(LCase([msDS-cloudExtensionAttribute1]), »guest »)=1), »Guest », »Member »)
Un œil averti comprendra… sinon : https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-sync-functions-reference
Une fois la règle ajoutée, une synchronisation complète devra être faite.
Dans la direction ‘Outbound’ (sortante) :
Nous ajoutons une règle sortante sur le connecteur Azure AD.
Nous sélectionnons le domaine Azure AD, les objets de type ‘user’ dans l’AD et de type ‘person’ dans le metaverse d’Azure AD Connect.
Le type de lien est ‘join’ et la précédence est positionnée à 11.
Le scoping est réalisé sur les objets de type ‘User’ qui ne sont pas gérés par Azure AD. Nous passons les règles de jointure.
Enfin la règle modifie l’attribut Azure AD userType sur la base de sa valeur dans le Metaverse.
Cette règle nécessitera également une nouvelle synchronisation.
Validation
Un second compte est créé et l’attribut est positionné sur les 2 comptes.
Nous pourrons donc tester la modification du compte existant et le cas d’un nouveau.
De retour dans le manager de synchronisation, nous lançons un import complet du connecteur AD :
L’ajout et la mise à jour du connecteur font apparaître les modifications AD : l’attribut ‘msDS-cloudExtensionAttribute1’ est bien récupéré avec la valeur AD.
Même opération sur le connecteur Azure AD :
Sept mises à jour vont être traitées.
Cela correspond à 7 comptes ‘Member’ & ‘Sync’ de ce tenant Azure AD (moins le compte de synchro AAD Connect).
UserType est bien ajouté sur les comptes et peuplé de la valeur d’Azure AD.
Maintenant Synchronisons ! C’est là que les règles vont être évaluées.
Une fois la synchronisation passée, en faisant une recherche sur le connecteur Azure AD, nous évaluons les résultats de l’export à venir.
‘Search Connector Space’ > ‘Pending Export’ > cases ‘Add Modify Delete’ cochées > ‘search’. Nous y retrouvons les 2 modifications à envoyer dans l’Azure AD.
La valeur est ‘Guest’ sur les 2 comptes !
Dernière opération, export vers l’Azure AD, qui nous donne 1 ajout et 1 mise à jour.
L’export vers l’AD n’est pas nécessaire ici car aucun attribut n’est à propager dans ce sens.
La vue des deux comptes dans le portail Azure AD, ceux-ci sont bien de Source ‘Windows Server AD’ & ‘Guest’ !
N’oublions pas de remettre la synchronisation !
That’s all !
Maintenant il nous reste à vérifier le retour arrière en modifiant l’attribut source dans l’AD, vérifier que le compte revienne bien en ‘Member’. Je vous laisse tester !
Dans la vraie vie !
Il y a parfois des erreurs…
Ici c’est après les 2 imports, les 2 synchronisations, 6 comptes Azure AD ‘member’ étaient impactés. Azure AD connect donnait en export vers Azure AD un résultat ‘to delete’ pour l’attribut UserType à ces 6 comptes.
Croyant temporairement à la magie du Cloud (bon ok, la fatigue, tout ça, mais bon des fois que, qui ne fait pas d’erreur ?).
L’export vers Azure AD, une fois lancé n’a pas fonctionné pour les comptes en question :
Moi :
Ces erreurs étaient visibles dans le portail et l’alerte envoyée par mail.
Il s’avère que cela pouvait venir de la version Azure AD Connect (pourtant en autoupdate, elle était restée à plus d’un an de décalage…), ou de la règle de transformation.
Hélas, je n’ai pas pu trouver le discriminant car j’ai réalisé plusieurs tests en parallèle. Cependant, la version de mon Azure AD Connect est selon moi la meilleure piste, étant trop persuadé qu’il était à jour.
Pour conclure, cette configuration sort de l’assistant classique Azure AD Connect (sera-t-elle intégrée plus tard ?) et est simple à mettre en place, maîtrisable. Il ne faut pas oublier une phase de test et la documentation associée !