Comptes d'accès d'urgence Entra ID : les configurer sans créer de porte dérobée

Pourquoi ces comptes existent

Un tenant Entra ID peut se verrouiller lui-même. Une politique d'accès conditionnel mal ciblée, une panne du fournisseur MFA, une fédération indisponible, le départ de l'unique administrateur global : dans chacun de ces cas, plus personne ne peut ouvrir le portail pour corriger. Les comptes d'accès d'urgence — les « bris de glace » — sont la clé posée derrière la vitre pour ces situations.

Le problème, c'est qu'un compte administrateur global permanent, exclu des contrôles habituels et rarement utilisé, est aussi exactement ce que cherche un attaquant. Tout l'enjeu est de garder la clé utilisable sans la laisser sur la porte.

Les règles de base

• Deux comptes, pas un. Si l'un est inutilisable (clé perdue, erreur de configuration), l'autre prend le relais.
• Comptes cloud uniquement, sur le domaine *.onmicrosoft.com, jamais synchronisés depuis l'Active Directory : une compromission ou une panne on-premise ne doit pas pouvoir les atteindre.
• Rôle Administrateur global attribué de façon permanente, et non éligible via PIM : en pleine crise, l'activation PIM peut elle-même être bloquée.
• Aucun lien avec une personne : pas de nom d'employé, pas de boîte aux lettres utilisée, pas de licence nécessaire.

Une authentification forte, mais indépendante

La pratique historique consistait à protéger ces comptes par un long mot de passe coupé en deux moitiés confiées à deux personnes. Ce n'est plus suffisant : Microsoft impose désormais l'authentification multifacteur pour l'accès aux portails d'administration, et un simple mot de passe reste la cible idéale d'une pulvérisation.

La bonne pratique actuelle est une méthode résistante au phishing — clés FIDO2 ou authentification par certificat — qui ne dépend ni du téléphone d'un collaborateur ni d'un service susceptible d'être en panne au même moment. Chaque compte reçoit au moins deux clés, rangées dans des lieux physiques différents, avec une procédure écrite de retrait et de restitution.

Exclure de l'accès conditionnel avec discernement

Les comptes d'urgence doivent être exclus des politiques qui peuvent provoquer un verrouillage : exigence d'appareil conforme, restriction géographique, conditions de risque dépendant d'un service tiers. L'exclusion passe par un groupe dédié, et ce groupe doit lui-même être protégé : si n'importe quel gestionnaire de groupes peut y ajouter un membre, il vient de créer un contournement universel de l'accès conditionnel. Un groupe assignable à des rôles, dont l'appartenance ne peut être modifiée que par un rôle privilégié, ferme cette porte.

Surveiller chaque connexion

Un compte d'urgence ne se connecte presque jamais : toute connexion est donc un événement. Les journaux de connexion Entra ID, envoyés vers Log Analytics ou Microsoft Sentinel, permettent une règle d'alerte simple : toute tentative d'authentification — réussie ou échouée — sur l'un de ces comptes déclenche une notification immédiate vers plusieurs destinataires. Une série d'échecs est un signal aussi important qu'un succès.

Tester, sinon rien ne marchera le jour J

Une procédure jamais testée n'est qu'une hypothèse. Planifiez un test régulier — chaque trimestre, et après tout changement important de l'accès conditionnel : retrait des clés, connexion, vérification des droits, restitution des clés, contrôle que l'alerte s'est bien déclenchée. Le test valide à la fois l'accès et la surveillance.

Ce qu'un audit vérifie

• Le nombre d'administrateurs globaux permanents, et lesquels sont réellement des comptes d'urgence.
• Le type de compte (cloud ou synchronisé) et le domaine utilisé.
• Les méthodes d'authentification enregistrées sur ces comptes.
• Les politiques d'accès conditionnel qui les excluent, et qui peut modifier le groupe d'exclusion.
• L'existence d'une alerte sur leurs connexions.

Deux comptes bien configurés valent mieux que cinq comptes « au cas où » oubliés depuis trois ans. Un accès d'urgence doit être rare, visible et testé.