AZURE AD / Office 365: Password Hash Sync et Seamless SSO en profondeur

Posted On 23 novembre 2019

L’objectif de cet article n’est absolument pas d’expliquer comment installer et mettre en service ces 2 fonctionnalités d’Azure AD. Philippe Beraud, Daniel Pasquier, Jean-Yves Grasset et Philippe Maurent de Microsoft l’ont très bien fait dans ce document à télécharger ici ou alors en suivant un autre lien ici.

Nous verrons donc plutôt en détail comment ces technologies fonctionnent et quelles sont les considérations à prendre en compte en termes de sécurité si vous souhaitez déployer ces fonctionnalités.

Password Hash Sync (PHS)

Microsoft recommande systématiquement d’activer Password Hash Sync dans n’importe quel scénario d’authentification Azure AD / O365 (fédéré ou managé).
Ce mécanisme consiste à synchroniser, toujours via l’outil Azure AD Connect, les hashs des mots de passe (hashs de hashs exactement, on le verra plus tard) de l’Active Directory local vers Azure AD. Au-delà de permettre une authentification directe aux services Azure pour un utilisateur dans le cadre d’une authentification managée, ceci permet de bénéficier de fonctionnalités avancées en termes de sécurité : Par exemple la possibilité pour un administrateur de recevoir par mail une alerte quand un compte et un mot de passe de son organisation ont été compromis et sont présents sur le Dark Net. Également en cas d’un problème bien plus grave de cyber attaque sur le réseau ou les services O365 pourraient toujours etre accessible alors que le système d’information est dégradé.

A l’installation d’Azure AD Connect PHS est maintenant systématiquement activé par défaut. Lors de IGNITE 2019, (Nov 2019) Microsoft a annoncé que 91% des tenants AZURE AD ont la fonctionnalité PHS activée !
Pour vérifier si c’est le cas sur votre tenant, vous pouvez controler l’activation sur le portail Azure AD:


Il est pourtant légitime de se poser la question en termes de sécurité, de l’implémentation dans notre Système d’information de la synchronisation des secrets d’Active Directory vers Azure Active Directory :

Comment Azure AD Connect récupère les mots de passe de AD ?

Dans son fonctionnement habituel, Active Directory ne stocke pas directement le mot de passe de l’utilisateur en clair mais le hash MD4 correspondant au mot de passe d’un compte. Cette valeur est stockée de manière sécurisée dans l’attributs unicodePwd sur 16 octets et est appelée empreinte NTLM (NTLM Hash).

Toutes les deux minutes, l’agent password hash synchronization présent sur le serveur Azure AD Connect demande à un contrôleur de domaine les hashs nouvellement stockés (dans l’attribut unicodePwd). Cette action est effectuée grâce à compte de service dont le nom par défaut commence par MSOL_ (Ce compte est créé automatiquement au cours du processus d’installation d’Azure AD Connect mais un autre compte de service dédié peut etre utilisé) Ce dernier doit disposer des autorisations ci-dessous (à positionner sur la racine du domaine):

• Replicate Directory Changes
• Replicate Directory Changes All

Description détaillée du fonctionnement de la synchronisation de hachage de mot de passe

La section suivante explique en détail comment fonctionne la synchronisation du hachage de mot de passe entre Active Directory et Azure AD :

Nous prendrons en exemple le mot de passe bien connu Azerty123 dont le hash stocké dans l’attribut unicodePwd de l’Active Directory est toujours
9A-B1-47-88-AF-C1-3C-83-57-6D-FB-13-AC-61-91-52

1. L’agent de synchronisation qui se trouve sur le serveur Azure AD Connect demande les hachages de mots de passe stockés (dans l’attribut unicodePwd) à un contrôleur de domaine.
   
   
2. Avant l’envoi, le contrôleur de domaine chiffre le hash du mot de passe MD4 à l’aide d’une clé qui est un hash MD5 de la clé de session RPC et un salt. Le hash du mot de passe est donc encapsulé dans une enveloppe de chiffrement MD5.
   
3. Le contrôleur de domaine envoie ensuite le résultat à l’agent de synchronisation via RPC. Le contrôleur de domaine passe également le sel à l’agent de synchronisation à l’aide du protocole de réplication du contrôleur de domaine (MS-DRSR), pour que l’agent puisse déchiffrer l’enveloppe.
   
   
4. Une fois que l’agent de synchronisation de hachage de mot de passe dispose de l’enveloppe chiffrée, il utilise MD5CryptoServiceProvider et le sel pour générer une clé afin de déchiffrer les données reçues dans leur format MD4 d’origine. L’agent de synchronisation n’a jamais accès au mot de passe en clair.
   -> L’utilisation de MD5 par l’agent de synchronisation est strictement destinée à assurer la compatibilité du protocole de réplication avec le contrôleur de domaine.
   
5. L’agent de synchronisation étend le hash de mot de passe binaire de 16 octets à 64 octets en convertissant d’abord le hash en chaîne hexadécimale de 32 octets, puis en reconvertissant cette chaîne au format binaire avec l’encodage UTF-16.
   
6. L’agent de synchronisation ajoute pour chaque utilisateur un sel de 10 octets de long au fichier binaire de 64 octets pour renforcer la protection du hachage d’origine.
   Sel généré aléatoirement: 3830918974b34b5011a4
   
7. L’agent de synchronisation combine alors le hash MD4 et le sel par utilisateur, puis place le tout dans la fonction de dérivation de clé PBKDF2. 1 000 itérations de l’algorithme de hachage à clé HMAC-SHA256 sont utilisées.
   Hash MD4: 9ab14788afc13c83576dfb13ac619152
   Sel généré aléatoirement: 3830918974b34b5011a4
   
   v1;PPH1_MD4,3830918974b34b5011a4,1000,820a2e32db5ce3b46c2b
   75f770fc17e454ade9f436e328ca8ce96998f09ce888;
   
8. L’agent de synchronisation prend le hash de 32 octets généré au point 7, concatène le sel par utilisateur et le nombre d’itérations SHA256, puis transmet la chaîne d’Azure AD Connect à Azure AD via TLS.
   
   -> Le hash est concaténé avec le sel et le nombre d’itérations dans cette chaîne finale qui est envoyée à Azure AD sous cette forme exacte.
   Est présent aussi dans cet extrait de trame la valeur SourceAnchor. Cette dernière est définie en tant qu’attribut immuable pendant la durée de vie d’un objet. Elle identifie de façon unique un objet comme étant le même objet local et dans Azure AD. L’attribut est également appelé immutableId et les deux noms sont interchangeables.
   
9. Lorsqu’un utilisateur tente de se connecter à Azure AD et entre son mot de passe, le mot de passe est traité par le même processus MD4+sel+PBKDF2+HMAC-SHA256. Si le hachage résultant correspond au hachage stocké dans Azure AD, l’utilisateur a entré le bon mot de passe et est authentifié.

Considérations en matière de sécurité

On l’a vu plus haut, les autorisations données au compte de service sont extrêmement critiques. Dès que la fonction PHS est activée et que ces droits sont donnés, vous devez prendre en compte les points ci dessous :

• Le compte de service doit etre considéré avec le même niveau de criticité qu’un compte administrateur de domaine.
• Le serveur Azure AD Connect sur lequel le compte de service s’exécute doit etre considéré au même niveau de sécurité que les contrôleurs de domaines (Tier 0)…
• Le mot de passe du compte de service est également stocké en « clair » dans la base de données SQL Server ou Windows Internal Database utilisée par l’agent de synchronisation. Il est donc crucial de s’assurer que seuls les administrateurs de domaine ont accès à cette base de données.

Dois-je donc utiliser PHS?

Je pense qu’en effet il est trés bénéfique d’utiliser cette fonctionnalité si les considérations en matière de sécurité ont été respecté.
Techniquement, les mécanismes et protocoles sont robustes. PBKDF2 est largement utilisé, la fonction de dérivation de clé est déjà éprouvée. Aupravant le nombre d’itération etait à 100, aujourdhui Microsoft l’a augmenté à 1000 et il pourra etre à nouveau augmenté dans le futur si besoin. Le sel est sur 10 octets, la RFC2898 recommande au minimum 8 octets. Ainsi ajouté il permet d’éviter l’utilisation de rainbow tables et donc limite les attaques sur plusieurs mots de passe en simultané.
Bien sur impossible d’utiliser ce hash pour effectuer des attaques Password Hash Sync sur le domaine local. Le NT Hash ne peut etre calculé à partir du hash présent dans AZURE AD.

Seamless Single Sign-On (SSSO)

Seamless SSO (SSSO) permet aux utilisateurs finaux connectés à l’Active Directory de ne pas avoir à saisir leur mot de passe pour se connecter aux services Azure AD / Office 365 ou à d’autres applications AZURE.
Cette fonctionnalité s’active facilement dans AZURE AD Connect à partir de la version 1.1.644.0 et ne fonctionne que lorsque PHS (ou PTA) est aussi activé. Nous le verrons, Kerberos est le protocole d’authentification utilisé. C’est pour cette raison que cela ne fonctionne qu’avec les utilisateurs connectés au réseau local et leurs ordinateurs intégrés au domaine Active Directory. SSSO est prise en charge via par les principaux navigateur Web et les clients lourds Office ou Teams qui prennent en charge l’authentification moderne.

Vous pouvez controler l’état d’activation de Seamless SSO sur le portail Azure AD:

Seamless SSO peut avantageusement remplacer ADFS pour l’authentification aux services AZURE / Office 365. Seamless SSO est une fonctionnalité native d’Active Directory adaptée pour un service cloud. Elle ne nécessite pas d’infrastructure complexe comme ce qu’il faut mettre en place pour les services de fédération ADFS.

Attention: Il y a souvent des incompréhentions sur l’utilité de SSSO pour un ordinateur Windows 10 enregistré à Azure AD et donc bénéfiçiant de l’expérience optimale du primary refresh tokens (PRT).
Il est bien évidement possible d’utiliser à la fois Azure AD Join et Seamless SSO. Ces deux fonctions sont complémentaires. Si les deux fonctionnalités sont activées, la jonction Azure AD a priorité sur SSSO, mais l’utilisation de SSSO garantie que l’utilisateur ne verra presque jamais un formulaire d’authentification, même en cas de changement de mot de passe.
Pour les ordinateurs connectés au domaine, antérieurs à Windows 10 ou non-joint/inscrit sur AZURE AD, SSSO sera utilisé systématiquement. Idem, sans l’extention Windows 10 Account, Chrome, n’ayant pas accès au composant WAM de Windows 10, utilisera uniquement Seamless SSO et pas le mécanisme basé sur PRT. Pour les autres cas, le formulaire d’authentification HTML AZURE s’affichera.

Description détaillée du fonctionnement de Seamless SSO

Vous en conviendrez, à première vue, il est étrange techniquement d’utiliser Kerberos pour s’authentifier sur un service cloud!?

Le protocole a été pensé pour les scénarios d’authentification locaux, et fonctionne classiquement avec 3 acteurs: Un utilisateur identifié par un UPN (User Principal Name), un service / serveur identifié par un SPN (Service Principal Name), un tiers de confiance, le KDC (Key Distribution Center). Chaque acteur dispose d’un secret (on parle de clé Kerberos) connu de lui et du Kdc : Kc (client) et Ks (service). Le KDC dispose de sa propre clé : Kkdc.

Pour que ce type de scénario fonctionne, il faut donc obligatoirement que le service/serveur cloud AZURE partage un secret commun avec le contrôleur de domaine. C’est quelque chose de classique dans un domaine Active Directory local, mais dans le cas d’un service cloud, il faut que le compte machine sur lequel le Service Principal Name a été enregistré, puisse partager sa clé Ks avec AZURE AD. C’est un module powershell intégré à AZURE AD Connect qui va effectuer cette opération lors de la première configuration de SSSO.

Voici ce qu’il se passe pendant l’activation de la fonctionnalité SSSO dans Azure AD Connect :

• L’administrateur qui procède à l’activation de SSSO doit fournir un compte Domain Admin de l’Active Directory et un compte Global Admin Azure AD.
• Un compte d’ordinateur nommé AZUREADSSOACC$ est créé dans l’Active Directory local. Par ailleurs, deux noms de principal du service (SPN) Kerberos sont créés pour représenter les deux URL utilisées pendant la connexion à Azure AD.
  
• La clé de déchiffrement Kerberos du compte d’ordinateur (Ks) est alors transmise à Azure AD de manière chiffrée (S’il existe plusieurs forêts AD, chacun a sa propre clé de déchiffrement Kerberos) :
  

A cet instant, et puisque Azure AD connait la Clé Ks, il pourra déchiffer le TGS (obtenu du KDC) qui sera transmis par le client au service AZURE AD.

Par défaut, les navigateurs n’envoient pas les informations d’identification aux serveurs Web en réponse à un code HTTP 401 à moins que l’URL ne soit définie dans la zone Intranet d’Internet Explorer.


Microsoft impose donc de déclarer les 2 URLs publiques suivantes dans la zone Intranet:

• https://autologon.microsoftazuread-sso.com
• https://aadg.windows.net.nsatc.net

Une fois effectué, Seamless SSO fonctionne de la même façon que n’importe quelle autre connexion utilisant l’authentification Windows intégrée (IWA): Le navigateur répond positivement au code HTTP 401 (Unauthorized) envoyé par AZURE AD et fournit automatiquement les informations d’identification de l’utilisateur actuellement connecté sous forme de ticket Kerberos (TGS encapsulé dans les entêtes WWW-Authorization) pour Azure AD.

-> Pour un peu plus de détails sur ces mécanismes HTTP vous pouvez consulter l’article sur ce site en suivant le lien.

Je vous propose de voir à présent de manière plus précise le mécanisme d’un utilisateur se connectant avec un navigateur WEB (l’authentification pour un client natif varie légèrement et fera l’objet d’un article à part):

1. L’utilisateur tente d’accéder à une application web ou ressource qui approuve les jetons de sécurité issus d’Azure AD, telle que SharePoint Online pour Office 365 ou Outlook Web App à partir d’un appareil d’entreprise joint au domaine.
   
2. Dans le cas ou l’utilisateur ne s’est pas déjà connecté, SharePoint Online ou OWA le redirige pour s’authentifier auprès d’Azure AD.
   
3. L’utilisateur est ensuite invité à fournir son nom d’utilisateur afin qu’Azure AD puisse déterminer si la fonctionnalité SSSO est activée pour le tenant. En supposant que SSSO est activée sur le tenant, les événements suivants se produisent:
   
4. Azure AD met le client au défi, via une réponse HTTP 401 (Unauthorized), de fournir un ticket Kerberos.
   
5. Le client demande alors un TGS à Active Directory pour le SPN HTTP/autologon.microsoftazuread-sso.com.
   
6. Active Directory localise le compte d’ordinateur créé par Azure AD Connect (AZUREADSSOACC$) grace au SPN, et retourne un TGS au client, chiffré avec le secret du compte d’ordinateur Ks. Le ticket comprend l’identité de l’utilisateur actuellement connecté à l’ordinateur.
   
   
7. Le client envoie dans l’entête Autorization le ticket TGS obtenu auprès d’Active Directory à Azure AD.
   
   
8. Azure AD déchiffre le ticket Kerberos à l’aide de la clé Ks précédemment partagée, récupère l’UserSid du domaine local et ainsi identifie l’utilisateur connecté de manière unique.
   
   
9. Azure AD termine le processus d’authentification et informe l’utilisateur s’il est bien authentifié.
   Dans certains cas, il peut demander à l’utilisateur de fournir des preuves supplémentaires, telles qu’une authentification multifacteur.
   Le client obtient alors un token d’accès JWT de la part d’Azure AD.
   
10. Pour finir, l’utilisateur est redirigé vers l’application et fournit le token JWT d’accès à l’application.
    
    
    -> En complément d’information, si l’authentification au travers Seamless SSO aboutit, l’utilisateur n’a pas la possibilité de choisir l’option Keep me signed in.
    

Considérations en matière de sécurité

Emplacement du compte ordinateur AZUREADSSOACC$
Le compte machine est créé dans l’OU par défaut /Computers/. Il est pourtant extrèmement critique:
– Supprimer ce compte désactive complètement SSSO.
– Changer le mot de passe du compte ordinateur sans exécuter les commandes powershell adéquates revient à « casser » le mécansime (Hash de AZUREADSSOACC$ dans AD ≠ Hash dans Azure AD = SSSO KO).
– Découvrir le hash du compte machine reviendrait à pouvoir disposer de l’équivalent du compte KRBTGT pour AZURE AD.

Pour pallier à tous ces problèmes il est donc conseillé de déplacer le compte ordinateur AZUREADSSOACC$ dans une OU dédiée sur laquelle l’héritage des droits aura été supprimé. Les ACL positionnées sur cette nouvelle OU doivent être très restreintes. Seuls des administrateurs de domaine doivent être en mesure de gérer le compte d’ordinateur. Vérifiez aussi que la délégation Kerberos sur le compte d’ordinateur est désactivée et qu’aucun autre compte dans Active Directory ne dispose d’autorisations de délégation sur le compte d’ordinateur AZUREADSSOACC$.
Concernant le dernier point sur la délégation, des améliorations ont été effectuées dans la version d’Azure AD Connect v1.4.18.0. Cela n’empèche pas un controle 🙂

Renouvellement de la clé Kerberos
La clé de chiffrement Kerberos du compte d’ordinateur (Ks) doit également être traitée comme sensible. Pour des raisons de sécurité ce mécanisme n’est pas automatique: en l’état cela reviendrait à stocker quelque part un compte « à privilège » du domaine local dans un script ou une tache planifiée. C’est pourtant un point important pour lequel Microsoft devrait proposer quelque chose. En effet, tout comme le celèbre compte KRBTGT sur un Active Directory, il est fortement recommandé de renouveller la clé de chiffrement Kerberos du compte d’ordinateur AZUREADSSOACC$ au moins tous les 30 jours via le process ci dessous:

• Exécutez $creds = Get-Credential. Quand vous y êtes invité, entrez les informations d’identification d’administrateur de domaine pour la forêt AD souhaitée. Microsoft précise que le compte ne doit pas être membre du groupe Utilisateurs protégés.
• Exécutez Update-AzureADSSOForest -OnPremCredentials $creds. Cette commande met à jour la clé de déchiffrement de Kerberos pour le compte de l’ordinateur AZUREADSSOACC$ et la forêt AD spécifique et dans Azure AD.
• Répétez les étapes précédentes pour chaque forêt AD dans laquelle vous avez configuré la fonctionnalité.

Depuis quelque temps, le portail Azure indique s’il est recommandé de renouveller les clés de chiffrement Kerberos du compte AZUREADSSOACC$:

Algorithme de chiffrement
Vous l’avez certainement remarqué dans la capture klist plus haut, la clé Ks du compte ordinateur AZUREADSSOACC$ qui a permis de chiffrer les informations dans notre TGS est issue d’une méthode très ancienne: RSADSI RC4-HMAC.

D’autres types d’empreintes, liées à Kerberos sont également calculées et ne demandent qu’à être utilisées. Seamless SSO prend aussi en charge les types de chiffrement AES256_HMAC_SHA1 et AES128_HMAC_SHA1. Il est donc recommandé de ne plus utiliser RC4_HMAC_MD5 mais plutot AES256_HMAC_SHA1. Le type d’algorithme de chiffrement est stocké dans l’attribut msDS-SupportedEncryptionTypes du compte dans l’Active Directory. Il suffira d’indiquer au compte de service que nous supportons le chiffrement basé sur AES-256 via la console ADUC:

-> Si le type de chiffrement est défini sur RC4_HMAC_MD5 et que vous souhaitez le remplacer par l’un des types de cryptage AES, veillez à bien exécuter à nouveau les commandes powershell de substitution de la clé de déchiffrement Kerberos pour qu’Azure AD puisse aussi les utiliser. Dans le cas contraire, à la suite du code code 401 (Unauthorized), Azure AD répondra 403 (Forbidden):