Authentification par certificat dans Entra ID : liaisons, affinité et révocation
Pendant longtemps, utiliser une carte à puce pour se connecter à Microsoft 365 imposait une fédération AD FS. L'authentification par certificat native d'Entra ID supprime cette dépendance. Mais sa sécurité repose sur quelques réglages précis, souvent laissés à leur valeur par défaut.
Les cas d'usage
L'authentification par certificat d'Entra ID (CBA) valide un certificat X.509 présenté par l'utilisateur, sur carte à puce, clé matérielle compatible PIV ou dans un magasin de certificats, directement auprès d'Entra ID. Nous la voyons surtout dans les situations suivantes :
- organisations disposant déjà d'une infrastructure de cartes à puce, notamment dans le secteur public et la défense ;
- sortie d'AD FS, lorsque la carte à puce était l'une des dernières raisons de conserver la fédération ;
- besoin d'une méthode résistante au hameçonnage pour des populations où les clés FIDO2 ne conviennent pas ;
- postes partagés ou environnements contraints où le certificat est déjà l'outil d'identification.
Déclarer les autorités de certification
Entra ID doit connaître les autorités de certification qui émettent les certificats des utilisateurs : racines et intermédiaires sont chargées dans le locataire, avec pour chacune l'adresse de sa liste de révocation (CRL). Microsoft fait évoluer la manière dont ce magasin est géré ; vérifiez l'interface en vigueur dans votre locataire. Chaque autorité déclarée devient une source de confiance pour l'authentification : la liste doit être réduite au strict nécessaire et revue régulièrement.
Les règles de liaison du nom d'utilisateur
Une fois le certificat validé, Entra ID doit déterminer à quel utilisateur il appartient. C'est le rôle des règles de liaison, qui associent un champ du certificat à un attribut de l'utilisateur :
- côté certificat : le nom principal (UPN) de l'extension SAN, l'adresse RFC822, le couple émetteur et sujet, l'identifiant de clé du sujet (SKI), le hachage SHA1 de la clé publique, le couple émetteur et numéro de série ;
- côté utilisateur :
userPrincipalName,onPremisesUserPrincipalNameoucertificateUserIds, un attribut multivalué prévu pour ces liaisons.
Affinité faible et affinité forte
C'est le réglage le plus important. Les liaisons fondées sur le nom principal, l'adresse RFC822 ou l'émetteur et le sujet sont dites à affinité faible : elles reposent sur des valeurs qu'une autorité de certification peut inscrire dans n'importe quel certificat. Les liaisons fondées sur le SKI, le hachage de la clé publique ou le couple émetteur et numéro de série sont à affinité forte : elles désignent un certificat précis.
Le risque concret. Avec une liaison à affinité faible sur l'UPN, toute personne capable d'obtenir d'une autorité de confiance un certificat portant l'UPN d'un administrateur peut s'authentifier en tant que lui. Les faiblesses classiques des modèles de certificats AD CS deviennent alors un chemin direct vers le cloud.
La stratégie permet de définir l'affinité exigée par défaut et des règles spécifiques par autorité ou par identifiant de stratégie (OID). Viser l'affinité forte, au moins pour les comptes privilégiés, en alimentant certificateUserIds, est la cible que nous recommandons.
Révocation et niveau de protection
Entra ID télécharge les CRL des autorités déclarées pour vérifier qu'un certificat n'a pas été révoqué. Points à contrôler :
- les adresses de CRL doivent être joignables depuis Internet et les listes rester d'une taille raisonnable ;
- l'option qui exige la validation de la CRL doit être activée, faute de quoi un certificat révoqué peut continuer à être accepté si la liste est indisponible ;
- la révocation d'un certificat n'invalide pas les sessions déjà ouvertes : en cas de perte de carte, il faut aussi révoquer les sessions de l'utilisateur.
Enfin, chaque règle de protection détermine si le certificat compte comme un facteur unique ou comme une authentification multifacteur. Configuré comme multifacteur, par exemple pour une carte à puce protégée par un code PIN, le CBA est reconnu comme résistant au hameçonnage et peut satisfaire la force d'authentification correspondante dans l'accès conditionnel.
Ce qu'un audit vérifie
- La liste des autorités de certification de confiance et leur justification.
- Les règles de liaison du nom d'utilisateur et le niveau d'affinité exigé, en particulier pour les administrateurs.
- L'alimentation de l'attribut
certificateUserIds. - L'accessibilité des CRL et l'exigence de leur validation.
- Les règles de protection (facteur unique ou multifacteur) par autorité ou OID.
- La sécurité des modèles de certificats de l'AD CS émettrice.