02/05/2022
Cybersecurity Insights
Fédération des identités, vers la fin de la brique AD FS ?
La brique AD FS, pour Active Directory Federation Services, est aujourd’hui mise en place et fonctionnelle au sein de nombreuses organisations. Elle permet de faire le lien entre des applications du périmètre du SI de l’entreprise et la base de comptes de l’Active Directory, avec pour objectif principal de jouer les authentifications, et vise généralement à fournir du Single Sign-On (SSO). Ce sont ce qu’on appelle les mécanismes de « fédération des identités ».
La fédération des identités, un sujet complexe
L’intérêt de la fédération est double, il permet d’une part d’éviter de gérer une multitude de comptes locaux aux applications, potentiellement faibles, et d’autre part d’augmenter le niveau de sécurité des mécanismes d’authentification tout en centralisant les données d’identités.
Cependant l’architecture des services AD FS reste complexe à mettre en œuvre, composée de plusieurs rôles qu’il est nécessaire de segmenter au sein du SI interne (« fermes » AD FS sur des serveurs différents des AD DC), d’exposer de manière sécurisée aux applications externes au SI dit « local » (serveurs WAP, pour Web Application Proxy), d’interconnecter l’ensemble au travers du SI via des règles Firewall spécifiques, de penser la redondance de l’ensemble de l’architecture en doublant les services et en prévoyant des interconnexions croisées pour éviter les cas de panne, etc.
Au-delà de l’architecture elle-même, le système des serveurs a bien sûr besoin d’être durci et mis à jour, mais l’applicatif lui-même de l’AD FS doit faire l’objet d’une configuration sécurisée pour ne pas être trop permissif tout en restant fonctionnel. Et comme tout applicatif, il fait aussi l’objet de failles, comme pour l’année 2021 avec une faille de type « Golden SAML » exploitée par Solorigate, qui a permis aux attaquants de générer des tokens SAML valides afin d’accéder à Exchange Online. Dans ce cas, la réponse de Microsoft a été de dire que la faute revenait principalement aux entreprises qui ne configurent pas leurs serveurs AD FS correctement, en ajoutant que la recommandation était de surcroit de complexifier encore l’architecture en mettant en place des coffres forts spécifiques pour générer et gérer les secrets sur lesquels devraient s’appuyer les AD FS : des solutions HSM (Hardware Security Module).
Bref, la fédération d’identité reste encore aujourd’hui une fonction complexe et coûteuse.
Une nouvelle brique de fédération ?
En février 2022, Microsoft publie un nouvel applicatif Cloud qui se présente comme un module Azure AD, intégré nativement à l’Azure AD et donc gratuit. Ce module est nommé CBA pour Certificate Based Authentification. Un des usages présentés par Microsoft pour ce module est de permettre aux scripts PowerShell de s’affranchir des mécanismes d’authentification dits « legacy », ou « basic », c’est-à-dire basés sur des protocoles anciens et considérés comme trop faibles, ou des mécanismes qui impliquent d’écrire directement les identifiants et mots de passe au sein des scripts. Comme l’indique le nom du module, l’objectif est donc d’appuyer l’authentification de ces scripts sur le mécanisme des certificats.
Cet usage n’est cependant pas le seul, et vise aussi à pouvoir réaliser la fédération d’identité auprès des applications tierces du périmètre de l’entreprise, avec des certificats. Le module pourrait donc s’imaginer comme le principal remplaçant de la brique locale AD FS.
Le module CBA est actuellement en « public preview » et impliquerait mécaniquement plusieurs choses à l’usage :
- Le mode d’authentification CBA de l’Azure AD implique nécessairement de mettre en place une infrastructure de gestion des clés/certificats (IGC en français, PKI en anglais) incluant des certificats personnels à déployer sur l’ensemble des postes/tablettes/téléphones des utilisateurs. Nous parlons bien de certificat utilisateur et pas de certificat machine, car de notre compréhension actuelle du module, il sera nécessaire de d’associer le certificat avec le nom d’utilisateur dans le champ SAN du certificat, ce qui n’est pas une bonne pratique pour les certificats affectés uniquement à des machines ;
- Dans le cas d’un déploiement de plusieurs certificats sur les postes, les utilisateurs pourront choisir le certificat qui réalise l’authentification à chaque fois qu’une application fédérée sera consommée par l’utilisateur
- Le module CBA se greffant sur l’Azure AD, il sera bien sûr possible d’enrichir les possibilités d’authentification et d’être plus granulaire suivant les applications, les contextes, les utilisateurs, etc. Par exemple en imposant le MFA sur certaines applications pour certains groupes utilisateurs, en mettant en place des règles d’Accès Conditionnel spécifiques suivant la localisation de l’utilisateur, en vérifiant spécifiquement des champs du certificat comme le Subject ou le Policy OIDs.
La sortie du module CBA étant très récente, « la peinture n’est pas sèche » comme on dit et il existe encore des limitations importantes à l’heure actuelle :
- La fenêtre Windows d’authentification par défaut est utilisée lors d’une authentification fédérée, celle qui propose de saisir un identifiant et un mot de passe. Microsoft a simplement ajouté un bouton en dessous des champs pour choisir de s’authentifier par certificat. Impossible pour l’instant de supprimer la proposition visuelle par défaut, impliquant un clic supplémentaire de l’utilisateur ;
- Toujours en lien avec l’interface utilisateur, lors du choix de certificat à utiliser pour jouer l’authentification, l’interface n’est pas explicite et ne possède pas de fonction de « conseil » pour sélectionner le bon certificat. Si les noms des certificats ne sont pas facilement identifiables, il est très probable qu’un utilisateur du SI ne sache pas choisir. A terme il est possible d’imaginer que l’interface présente automatiquement le certificat utilisateur qui possède le même certificat racine (certificat Root-CA ou Sub-CA) que le certificat du site accédé ;
- Pour vérifier la validité des certificats lors des authentifications, le module CBA n’est aujourd’hui compatible qu’avec les mécanismes de CRL (Certificate Révocation List). Les mécanismes plus récents basés sur des répondeurs OCSP (Online Certificate Status Protocol) ne sont pas utilisables pour le moment, Microsoft évoque uniquement des problèmes de performance ;
- Par ailleurs il n’est possible de pointer qu’une seule adresse URL de service CRL par certificat racine (certificat CA), sans possibilité d’indiquer une URL de backup pour la redondance. Cette redondance nécessaire pour assurer la disponibilité du service de validité des certificats, sera donc à prendre en charge autrement, soit via l’architecture DNS, soit via une infrastructure de reverse proxy capable de faire de la répartition de charge ;
- Enfin, il y a pour l’instant d’autres limitations liées à ces mécanismes CRL :
- Par défaut si l’administrateur n’entre pas d’adresse URL pour la CRL, le module CBA ne vérifie jamais la validité des certificats (la chaine de confiance et la signature oui, mais pas la révocation/expiration) ;
- Si la taille de la CRL dépasse 20 Mo ou si son téléchargement met plus de 10 secondes, le module CBA l’ignore et ne vérifie pas la validité des certificats, d’où l’importance de l’architecture de redondance du service CRL ;
- Le module CBA vérifie la validité des certificats de l’authentification et uniquement sur le certificat qui a signé les certificats de l’authentification en jeu (certificat Sub-CA), mais pas l’ensemble de la chaine de certification (certificats Sub-CA supérieurs et certificat Root-CA).
- Pour tous ces mécanismes de révocation de certificats liés à la CRL, pour l’instant Microsoft conseille de révoquer manuellement les sessions des utilisateurs concernés… Aucune organisation n’aura la capacité d’inclure ce genre de chose dans ses processus opérationnels, depuis l’alerte de certificats expirés jusqu’à l’action manuelle de lister les sessions utilisateurs concernées pour les supprimer suffisamment rapidement et ne pas entrainer de risque sécurité.
Que faut-il en conclure ?
Donc certes, un nouveau mode est bien proposé par Microsoft pour permettre d’accélérer la voie du décommissionnement des architectures ADFS et donc aussi des authentifications « basic », mais attention aux impacts importants dans les entreprises à l’heure actuelle. Nous ne conseillons pas d’aller au-delà du POC ou du test pour ce module CBA.
Lorsqu’il aura évolué, nous publierons un article dans la continuité de celui-ci pour montrer les améliorations du module CBA, et reposer la question initiale de savoir si oui ou non il se présente comme le successeur des architectures AD FS. Stay tuned.
Références
- Un article haut niveau qui parle du sujet : https://redmondmag.com/articles/2022/02/14/azure-active-directory-certificate-based-authentication-preview.aspx?m=1
- L’article Overview du module CBA sur le site de Microsoft (les articles DeepDive sont en lien sur la page) : https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-certificate-based-authentication-limitations
- Le mail de Microsoft annonçant la sortie du module CBA fin janvier, propre à chaque entreprise ayant souscrit à Azure AD
Adrien GAILLARD
Consultant Senior cybersécurité et réseau
