Si comme beaucoup d’entreprises, vous utilisez toujours votre infrastructure ADFS, il est tout de même possible /conseillé d’activer l’option “Password Hash Sync” (PHS). Le but est de toujours utiliser ADFS en tant que STS, mais de se laisser la possibilité à des fins de DRP d’autoriser une migration d’urgence du STS d’ADFS vers Azure AD.
Avant de commencer, quelques idées reçues :
- Synchronisation de mots de passe dans Azure AD : Faux, il s’agit de la synchronisation du hash du mot de passe.
- Je dois migrer l’ensemble de mes Relying Party Trust avant de basculer en PHS : Faux, M365 est un RPT comme les autres. L’ensemble des RPT doivent être migrées pour supprimer ADFS.
Dans les deux liens ci-dessous, vous trouverez des informations sur PHS :
- https://docs.microsoft.com/fr-fr/azure/active-directory/hybrid/whatis-phs
- https://www.microsoft.com/security/blog/2019/05/30/demystifying-password-hash-sync/
Le point de départ est une architecture On-Premise (AD, AADC, ADFS) hybridée sur AAD. Dans un premier temps, la partie On-Premise (AD, AADC, ADFS) sera inaccessible ce qui nécessitera un DRP en basculant l’authentification sur Azure AD. Puis pour finir le retour en production de l’infrastructure On-Premise.
Ce scénario correspond à l’option “Federation with Password Hash Sync” dans le diagramme de choix d’architecture proposé par Microsoft.
L’idée de ce scénario est vraiment un cas de DRP suite à la perte de la partie On-Premise. en effet, la restauration d’une infrastructure d’identitée On-Premise peut être long, même très long.
J’ai en mémoire :
- L‘incident OVH de 2021 sur le datacenter de Strasbourg.
- Des d’infrastructures ayant subi des attaques de type cryptolocker.
Dans ces deux cas, la reconstruction de l’infrastructure à durée plusieurs semaines.
L’idée est de rendre le service d’authentification (indispensable pour bon nombre de services de type SaaS) aux utilisateurs. Notament les applications M365, mais aussi par toutes les applications de type SaaS donc l’authentification repose sur Azure AD.
Ne pas confondre PHS, la méthode de fédération et PHS l’option de synchronisation des mots de passe.
Uniquement la source s’authentification des utilisateurs est modifiée. Il ne s’agit pas d’une migration d’utilisateurs synchronisés à cloud.
Toutes les manipulations sont réalisées avec un compte Break Glass. Il s’agit d’un compte de secours qui doit posséder certaines caractéristiques dont le fait d’être un compte cloud, global admin et au format “@teddyhybrid01.onmicrosoft.com“.
Au passage, cette maquette n’est pas réalisée sur le directory par defaut de mon Azure AD, mais sur un second.
Azure AD Connect version 2.0.3.0 a été utilisée pour cette maquette.
Activer PHS
La première étape est d’activer PHS sur votre infrastructure On-Premise. Généralement, les ACL positionnées sur Active Directory pour permettre à Azure AD Connect de synchroniser les objets AD dans Azure AD ont été réalisés lors de l’installation d’Azure AD Connect. Si cela n’est pas le cas, il peut-être nécessaire d’octroyer les permissions au compte (ce qui n’est pas l’objet de ce post).
Depuis une console PowerShell sur le serveur ADFS, le module “AdSyncConfig” permet de configurer les ACL du compte connecteur AD DS. La commande “Set-ADSyncPasswordHashSyncPermissions” permet de configurer les ACL pour la synchronisation des mots de passe.
#Import du module PS :
Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1"
#Obtenir le compte de connexion entre AADC et AD :
Get-ADSyncADConnectorAccount
L’ensemble de la documentation sur le module PowerShell “AdSyncConfig” est disponible :
Pour cette maquette, les ACL sont les ACL par défaut réalisés lors de l’installation d’Azure AD Connect.
Depuis la console Azure AD –> Azure AD Connect. Nous pouvons constater que 2 domaines sont fédérés et que “Password Hash Sync” (PHS) n’est pas activé.
Se rendre sur votre serveur Azure AD Connect, lancer l’assistant de configuration Azure AD Connect
Maintenant, dans la console Azure AD –> Azure AD Connect. Nous pouvons constater que 2 domaines sont fédérés et que “Password Hash Sync” (PHS) est activé.
Depuis la console M365 Admin Center, il est possible de vérifier que la synchronisation des mots de passe est bien activée et sans erreur.
Le dépannage de la synchronisation de password peut être réalisé grace à l’outil de troubleshooting d’Azure AD Connect.
L’outil est un script PowerShell :
- Enter ‘2’ – Troubleshoot Password Hash Synchronization.
Puis
- Enter ‘1’ – Password Hash Synchronization does NOT work at all
Ou
- Enter ‘2’ – Password Hash Synchronization does NOT work for a specific user account
Bascule ADFS à PHS en DRP
Ce type de migration est à réaliser en dernier recours lorsque l’ensemble des utilisateurs ne peuvent plus travailler et que le retour de l’infrastructure On-Premise est compromis dans un futur proche. Bon nombre de points sont à prendre en considération, notamment la gestion du MFA qui ne sera plus opérationnel si celui-ci était porté par ADFS. De plus, les utilisateurs ne seront pas migrés comme utilisateurs cloud, la modification de leurs propriétés ne sera pas possible.
Etat des lieux
À ce stade si :
- Les utilisateurs AD sont synchronisés sur Azure AD.
- Le mot de passe des utilisateurs est lui aussi synchronisé.
- Le domaine des utilisateurs est fédéré à l’aide d’ADFS.
- L’authentification de l’utilisateur est réalisée par ADFS.
Lors de l’authentification d’un utilisateur fédéré (ici : test01@teddycorp.fr), l’authentification est redirigée auprès de l’infrastructure ADFS On-Premise.
Réaliser le DRP
Pour la réalisation du DRP, l’infrastructure On-Premise n’est plus accessible.
Lors d’une tentative d’authentification, nous pouvons constater que le service ADFS n’est pas accessible. Dans ce cas si, l’ensemble de l’infrastructure (AD et AADC) On-Premise n’est plus disponible.
L’objectif est de supprimer la fédération pour le domaine “teddycorp.fr” tout en conservant les objets répliqués depuis AD vers Azure AD. Seul le STS va changer, les utilisateurs synchronisés depuis AD vont rester des utilisateurs synchronisés.
Import-Module MSOnline
Connect-MsolServiceCi-dessous, la liste des domaines du tenant Azure AD. Le domaine concerné est “Teddycorp.fr”.
Get-MsolDomain
Get-MsolDomainFederationSettings -DomainName "teddycorp.fr"
Le passage du domaine de fédéré à manager est réalisé à l’aide de la commande “Set-MsolDomainAuthentication”.
Set-MsolDomainAuthentication -DomainName "teddycorp.fr" -Authentication Managed
Désormais, l’authentification des utilisateurs de ce domaine est gérée à l’aide d’Azure AD. Comme vous pouvez le constater, la mire d’authentification n’est plus sur ADFS.
L’utilisateur peut se loger avec le mot de passe qu’il utilisait sur AD.
Du côté d’Azure AD, le domaine n’est plus vu comme un domaine fédéré.
Microsoft recommande l’utilisation de “Convert-MsolDomainToStandard”, cette commande reset le mot de passe des utilisateurs. L’utilisation de cette commande est à utiliser dans le cas où PHS n’a pas été activé.
Retour à la normale
Maintenant que nos utilisateurs peuvent s’authentifier directement sur Azure AD, nous allons imaginer que notre infrastructure On-Premise a été restaurée et est accessible.
À partir de ce moment, nous allons recréer la fédération du domaine “teddycorp.fr” pour que celui-ci soit de nouveau authentifié par ADFS.
Depuis le serveur Azure AD Connect, nous allons commander par lancer une vérification de la connectivité d’ADFS. Pour se faire, se rendre dans :
- AADC –> Manage federation –> Verify federation connectivity.
L’infrastructure ADFS est accessible. Si ce n’est pas le cas, il va falloir commencer par une petite séance de troubleshooting.
Toujours depuis le serveur Azure AD Connect, lancer les commandes suivantes où :
- adfs01.teddycorp.lan –> serveur ADFS primaire
Import-Module MSOnline
Connect-MsolService
Set-MsolADFSContext -Computer adfs01.teddycorp.lan
Convert-MsolDomainToFederated -DomainName teddycorp.fr -SupportMultipleDomain
Le domaine “teddycorp.fr” est de nouveau fédéré.
Get-MsolDomain
Get-MsolDomainFederationSettings -DomainName "teddycorp.fr"
Du côté de l’authentification utilisateur, celle-ci est de nouveau gérée par ADFS.
Bascule ADFS à PHS avec AADC
Dans le scénario précédent, nous avons vu une bascule d’ADFS vers PHS dans le cas de perte totale de l’infrastructure On-Premise. Il existe une autre possibilité en cas de dysfonctionnement d’ADFS uniquement. Ce qui arrive en cas de certificats expirés au lors de migration de l’infrastructure.
L’idée cette fois est de réaliser la migration depuis Azure AD Connect.
Etat des lieux
L’état des lieux est le même que lors de la précédente migration, à savoir :
- Les utilisateurs AD sont synchronisés sur Azure AD.
- Le mot de passe des utilisateurs est lui aussi synchronisé.
- Le domaine des utilisateurs est fédéré à l’aide d’ADFS.
- L’authentification de l’utilisateur est réalisée par ADFS.
Lors de l’authentification d’un utilisateur fédéré (ici : test01@teddycorp.fr), l’authentification est redirigée auprès de l’infrastructure ADFS On-Premise.
Réaliser la bascule vers PHS
Pour réaliser la migration vers PHS, se rendre sur le serveur Azure AD Connect et lancer la console AADC :
- AADC –> Change user sign-in
Se loguer à l’aide d’un compte Azure AD global admin.
Dans la console “User sign-in”, passer la méthode d’authentification de “Federation with ADFS” à “Password Hash Synchronization”. L’option “Enable single sign-on” est sélectionnée par défaut (optionnel).
Dans la fenêtre suivante, entrer les credentials d’un administrateur du domaine afin d’activer le SSO sur le domaine.
Après quelques secondes, la configuration est terminée.
Du côté d’Azure AD, nous pouvons constater que le domaine “teddycorp.fr” n’est plus fédéré avec ADFS. Notons que le domaine “bnugues.fr” qui lui aussi était fédéré ne l’est plus.
L’authentification de l’utilisateur est maintenant réalisée par Azure AD et plus par ADFS.
Rebasculer vers ADFS
Pour réaliser le retour vers ADFS, se rendre de nouveau sur le serveur Azure AD Connect et lancer la console AADC :
- AADC –> Change user sign-in
Sélectionner l’option “Federation with ADFS”.
Renseigner les credentials d’un administrateur du domaine.
Sélectionner l’option “Use an existing ADFS farm” et renseigner le serveur primaire de la ferme ADFS.
Il est possible de déterminer si le serveur est primaire au sein de la ferme ADFS à l’aide de la commande PowerShell “Get-AdfsSyncProperties”
Sélectionner le domaine à fédérer, ici “teddycorp.fr”. Le second domaine à fédérer sera à ajouter ultérieurement.
Cliquer sur “Next” afin de valider les informations concernant le trust Azure AD.
Continuer la configuration, après quelques secondes, la configuration est effective.
Afin de finaliser la configuration, il est possible de vérifier la connectivité de la ferme ADFS.
À la suite de cette configuration, l’authentification utilisateur est assurée par ADFS.
Afin de revenir à l’état initiale, il est nécessaire d’ajouter le domaine “bnugues.fr” à la fédération. Pour se faire se rendre dans Azure AD Connect puis :
- AADC –> Manage Federation –> Federate Azure AD domain.
Renseigner les informations d’authentification Azure AD et administrateur du domaine.
Sélectionner le domaine à fédérer.
Puis poursuivre la configuration en laissant les informations par défaut dans les blades suivants.
Désormais l’ensemble des domaines sont de nouveaux fédérés.
