Renforcer l’authentification contre le phishing : guide pas à pas de mise en œuvre de l’authentification par certificat dans Entra ID

L’authentification par certificat (CBA) améliore considérablement les connexions traditionnelles par mot de passe ou la MFA TOTP/OTP classique. Elle permet un accès sans mot de passe et résistant au phishing à Microsoft Entra ID (anciennement Azure AD), tout en protégeant les ressources et services critiques. Ce guide présente la mise en œuvre de CBA pour les utilisateurs finaux et les applications (service principals), en s’appuyant sur la documentation Microsoft officielle et les pratiques du secteur.

Remarque : l’exemple d’origine montre comment activer la CBA résistante au phishing pour le groupe d’administrateurs Intune face à la menace récente de l’acteur Handala, associée à « Stryker ».

Face à des cybermenaces de plus en plus sophistiquées, s’appuyer uniquement sur les mots de passe ou la MFA OTP/TOTP représente un risque important. La CBA de Microsoft Entra ID offre une autre méthode : les utilisateurs et applications vérifient leur identité à l’aide de certificats numériques X.509, ce qui réduit les risques de phishing et de vol d’identifiants. Ce guide couvre deux cas d’usage : l’authentification des utilisateurs (par exemple, l’accès des employés à Microsoft 365) et l’authentification des applications ou outils d’automatisation par service principals.

Partie 1 : configurer la CBA pour l’authentification des utilisateurs

Ce processus établit la confiance entre votre PKI et Microsoft Entra ID et définit la correspondance entre les certificats et les comptes utilisateur.

Prérequis

• PKI configurée : une PKI d’entreprise est nécessaire pour émettre des certificats utilisateur.
• Certificats utilisateur : ils doivent contenir le User Principal Name (UPN) dans le champ Subject Alternative Name (SAN), sous forme de RFC822Name (format e-mail) ou d’un autre identifiant pris en charge.
• Accès administrateur : connectez-vous au Microsoft Entra admin center avec au minimum le rôle Privileged Authentication Administrator.
• Certificate Revocation Lists (CRL) : les CA doivent publier des CRL à des URL accessibles depuis Internet afin que Microsoft Entra ID puisse vérifier la révocation.

Étape 1 : configurer les autorités de certification

Microsoft Entra ID doit faire confiance aux CA qui émettent les certificats utilisateur. Vous pouvez charger les certificats CA dans un magasin de confiance basé sur PKI.

1. Dans Entra admin center, accédez à Identity → Identity Secure Score → Public key infrastructure (PKI).
2. Cliquez sur + Create PKI, attribuez un nom d’affichage (par exemple « Contoso PKI »), puis créez-le.
3. Sélectionnez le conteneur PKI, cliquez sur + Add certificate authority et chargez le fichier de certificat CA racine ou intermédiaire (`.cer`).
4. Indiquez s’il s’agit d’une Root CA.
5. Saisissez les URL publiques de Certificate Revocation List (CRL) et, facultativement, de Delta CRL.
6. Vérifiez que l’option Issuer hints est activée (valeur par défaut) pour filtrer les certificats proposés à l’utilisateur.
7. Cliquez sur Save et répétez l’opération pour chaque CA de la chaîne.

Remarque : pour les grandes PKI, la fonction Upload PKI permet de charger en une fois un fichier `.p7b` contenant tous les certificats CA.

Étape 2 : activer et configurer la CBA dans le tenant

Une fois les CA approuvées, activez la méthode CBA et définissez le mappage des certificats aux comptes utilisateur.

1. Accédez à Protection → Authentication methods → Certificate-based authentication.
2. Dans l’onglet Enable and target, activez la stratégie et choisissez les utilisateurs ou groupes autorisés à utiliser la CBA (par exemple « Intune Admin Group » ou « All Users »).
3. Configurez Username binding (Mapping), qui associe un champ du certificat à un attribut utilisateur Entra ID. Microsoft recommande les liaisons à forte affinité fondées sur des propriétés uniques et non réutilisables.
4. Ouvrez l’onglet Configuration. Sous Username binding, cliquez sur Add rule.
5. Pour une liaison à forte affinité, sélectionnez IssuerAndSerialNumber ou SHA1PublicKey, puis associez-le à un attribut comme CertificateUserIds. Cet attribut doit être renseigné sur l’objet utilisateur Entra ID correspondant.
6. Pour une configuration à affinité plus faible, associez le champ PrincipalName ou RFC822Name (SAN) du certificat à l’attribut Entra ID userPrincipalName.
7. Sous Authentication binding, définissez si la CBA est considérée comme un facteur unique ou une authentification multifacteur. Par exemple, les certificats dont la clé dépasse un seuil donné (comme RSA 2048 bits) peuvent être considérés comme MFA.
8. Vérifiez la configuration et cliquez sur Save.

Étape 3 : appliquer la CBA avec Conditional Access (facultatif, recommandé)

Pour réduire la dépendance aux mots de passe, vous pouvez créer une stratégie Conditional Access exigeant la CBA pour certaines applications.

1. Accédez à Protection → Conditional Access → Policies, puis cliquez sur + New policy.
2. Dans Assignments, sélectionnez les utilisateurs ou groupes et les applications cloud à protéger, par exemple Office 365.
3. Dans Access controls → Grant, sélectionnez Require multi-factor authentication (la CBA peut satisfaire cette exigence) et/ou Require authentication strength. Vous pouvez créer une force d’authentification personnalisée exigeant spécifiquement la CBA.
4. Réglez Enable policy sur On, puis cliquez sur Create.

Après ces étapes, les utilisateurs disposant d’un certificat valide et approuvé installé sur leur appareil (par exemple dans le magasin de certificats Windows) peuvent se connecter à Microsoft 365 sans mot de passe ou satisfaire l’exigence MFA.

Partie 2 : CBA pour les applications (service principals)

Les scripts d’automatisation et les applications doivent souvent s’authentifier auprès d’Azure. Un certificat est une solution plus sûre que le stockage d’un mot de passe.

Étape 1 : préparer le certificat

Vous pouvez créer un certificat autosigné pour les tests ou utiliser un certificat existant émis par votre PKI. Il doit inclure la clé privée et être dans un format pris en charge (`.pem` ou `.cer` pour la clé publique).

• Pour créer un certificat autosigné de test, utilisez Azure CLI ou OpenSSL.
• Pour un certificat existant, préparez la clé publique (`.cer`).
• Pour convertir un fichier PKCS#12 (`.pfx`) au format PEM requis, utilisez OpenSSL :

openssl pkcs12 -in yourcert.pfx -clcerts -nodes -out cert.pem -passin pass:

Étape 2 : créer le service principal avec le certificat

Azure CLI permet de créer un service principal et d’y charger son certificat. Connectez-vous à Azure CLI et exécutez l’une des commandes suivantes.

Pour créer un certificat autosigné et un service principal :

az ad sp create-for-rbac --name MyAppWithCert --create-cert --years 2

La commande affiche `appId` et l’emplacement du fichier `.pem` contenant le certificat et la clé privée.

Pour utiliser un certificat public existant (`.cer` ou `.pem`) :

az ad sp create-for-rbac --name MyAppWithCert --cert @/path/to/publiccertificate.cer

Important : avec un certificat existant, ne chargez que la clé publique (fichier `.cer`) dans Azure AD. La clé privée doit rester sécurisée sur la machine locale ou dans un magasin sécurisé tel qu’Azure Key Vault.

Notez `appId` (client ID) et `tenantId` ; ils seront nécessaires pour l’authentification.

Étape 3 : utiliser le certificat pour l’authentification

Les applications peuvent utiliser la clé privée du certificat pour s’authentifier. Exemple de connexion Azure CLI avec le service principal :

az login --service-principal --username APP_ID --password /path/to/cert-with-privatekey.pem --tenant TENANT_ID

Vous pouvez aussi utiliser le certificat avec PowerShell ou des bibliothèques comme MSAL (Microsoft Authentication Library). L’application doit pouvoir accéder à la clé privée pour créer une assertion d’authentification signée.

Conclusion

La mise en œuvre de CBA dans Microsoft Entra ID peut renforcer considérablement la sécurité de l’organisation. En réduisant la dépendance aux mots de passe pour les utilisateurs et les applications, et en complétant ou remplaçant la MFA TOTP/OTP classique, vous avancez vers une authentification sans mot de passe et résistante au phishing. Que ce soit pour les employés accédant à Microsoft 365 ou pour les scripts DevOps automatisés, ces étapes permettent de mieux sécuriser et gérer les identités.