Entra ID paramètres utilisateur par défaut du tenant restreignent l'enregistrement d'applications, la création de groupes et l'accès au centre d'administration

Entra ID paramètres utilisateur par défaut du tenant restreignent l'enregistrement d'applications, uniquement après une modification par un administrateur

Entra ID paramètres utilisateur par défaut du tenant restreignent l'enregistrement d'applications, la création de groupes et la navigation dans le centre d'administration — mais seulement une fois qu'un administrateur les a modifiés. Tant que personne ne l'a fait, la base documentée pour un utilisateur membre ordinaire est délibérément généreuse, et la plupart des tenants ne la revoient jamais.

Microsoft est explicite sur ce qu'un simple utilisateur membre peut faire. La référence des autorisations par défaut indique que « les utilisateurs membres peuvent enregistrer des applications, gérer leur propre photo de profil et leur numéro de téléphone mobile, changer leur propre mot de passe et inviter des invités B2B. Ces utilisateurs peuvent également lire toutes les informations d'annuaire (à quelques exceptions près) ». La même page indique, sous Groupes, que les utilisateurs membres peuvent « Créer des groupes de sécurité » et « Créer des groupes Microsoft 365 » ; sous Applications, qu'ils peuvent « Enregistrer (créer) de nouvelles applications » et « Énumérer la liste de toutes les applications » ; et sous Rôles et étendues, qu'ils peuvent « Lire tous les rôles d'administration et leurs appartenances » (Autorisations utilisateur par défaut).

C'est là que ça dérange. Les deux conditions préalables qui rendent possibles le phishing de consentement OAuth et la reconnaissance d'annuaire ne sont pas des capacités exotiques d'attaquant — ce sont des paramètres de tenant. Quatre interrupteurs ferment l'essentiel de la brèche, et aucun d'eux ne nécessite une montée en licence.

Comment ça marche : quatre interrupteurs, trois objets différents

Le centre d'administration Microsoft Entra présente cela comme une liste bien rangée sous Paramètres utilisateur et Paramètres de groupe. En dessous, ces valeurs sont stockées dans trois endroits sans rapport entre eux — c'est exactement pourquoi les audits partiels les manquent.

Les deux premiers vivent sur le singleton authorizationPolicy, valable pour tout le tenant. Microsoft Graph documente allowedToCreateApps comme correspondant au « paramètre Les utilisateurs peuvent enregistrer des applications dans le menu Paramètres utilisateur », et allowedToCreateSecurityGroups comme correspondant au « paramètre Les utilisateurs peuvent créer des groupes de sécurité dans les centres d'administration Microsoft Entra, l'API ou PowerShell » (defaultUserRolePermissions). Le même objet porte aussi allowedToCreateTenants, allowedToReadOtherUsers, allowedToReadBitlockerKeysForOwnedDevice et permissionGrantPoliciesAssigned.

La création de groupes Microsoft 365 se trouve tout à fait ailleurs : le paramètre EnableGroupCreation à l'intérieur du modèle Group.Unified, dont « le paramètre par défaut est true » (Vue d'ensemble des paramètres de groupe).

Le quatrième interrupteur est le plus délicat, et il est traité dans sa propre section ci-dessous.

La chaîne d'attaque

Étape 1 — Obtenir un compte ordinaire

Aucun rôle, aucun consentement admin, aucune élévation de privilège. Le password spraying, le vol de jeton par l'adversaire au milieu (adversary-in-the-middle) ou le device code phishing mènent tous au même endroit : une session en tant qu'utilisateur membre standard. Tout ce qui suit est ce à quoi cette session a droit par défaut.

Étape 2 — Cartographier l'annuaire de l'intérieur

Les utilisateurs membres peuvent énumérer tous les utilisateurs et contacts, tous les groupes, tous les appareils et toutes les applications, et lire tous les rôles d'administration et leurs appartenances. En pratique, cela signifie qu'un attaquant disposant d'une seule session ordinaire peut lister tous les administrateurs généraux du tenant, identifier quels comptes sont cloud-only, et choisir ses cibles — sans jamais toucher à une seule surface d'administration.

Étape 3 — Enregistrer une application et y ajouter une identification

Avec allowedToCreateApps laissé à sa valeur par défaut, le compte crée un enregistrement d'application. Microsoft documente la conséquence : « lorsqu'un utilisateur enregistre une application, il est automatiquement ajouté comme propriétaire de l'application ». Les propriétaires peuvent alors mettre à jour applications.credentials, entre autres propriétés.

C'est le point de pivot. Ajouter un secret ou un certificat contrôlé par l'attaquant à une application ou à un principal de service est catalogué par MITRE ATT&CK sous T1098.001 — Account Manipulation: Additional Cloud Credentials, qui note que « les adversaires peuvent ajouter des identifiants pour des principaux de service et des applications en plus des identifiants légitimes existants dans Azure / Entra ID. Ces identifiants incluent aussi bien des clés x509 que des mots de passe ». Un identifiant sur un objet application n'est pas lié au mot de passe de l'utilisateur compromis, donc réinitialiser ce mot de passe n'évince pas l'attaquant.

L'application a encore besoin de permissions pour être utile, et c'est là qu'intervient le volet consentement du tenant : « par défaut, tous les utilisateurs sont autorisés à consentir à des applications pour des permissions qui ne nécessitent pas de consentement administrateur » (Configurer la manière dont les utilisateurs consentent aux applications). Nous couvrons ce volet du problème en détail dans OAuth consent phishing : comment les applications malveillantes contournent le vol de mot de passe et dans Permissions Graph API dangereuses dans l'app registration Entra.

Étape 4 — Créer un groupe que personne ne gouverne

La création de groupes en libre-service n'est pas, en soi, une élévation de privilège — un nouveau groupe ne donne accès à rien. Le dommage est celui de la gouvernance. Un utilisateur membre qui crée un groupe en est normalement ajouté automatiquement comme propriétaire, avec des droits sur groups.members et groups.owners — avec une exception documentée : pour les groupes de sécurité créés dans le portail Azure, Microsoft note que le « propriétaire n'est pas assigné automatiquement à la création du groupe ». Microsoft note en outre que « les groupes de sécurité créés en libre-service via le portail Mes groupes sont disponibles pour tous les utilisateurs, qu'ils soient approuvés par le propriétaire ou auto-approuvés » (Configurer la gestion des groupes en libre-service).

Le résultat est un annuaire avec des milliers de groupes dont la propriété ne veut rien dire, dans lequel un groupe possédé par un attaquant est indiscernable des autres — jusqu'à ce qu'un administrateur accorde à ce groupe l'accès à une application, un site ou une exclusion d'Accès conditionnel.

Pourquoi le bascule du centre d'administration est une friction, pas un contrôle

C'est l'interrupteur le plus souvent signalé comme « durci » et le plus souvent mal compris. La propre documentation de Microsoft porte une mise en garde au-dessus du tableau : le paramètre Restreindre l'accès au portail d'administration Microsoft Entra « limite l'accès à un ensemble de pages du centre d'administration couramment visitées. Ce n'est pas une mesure de sécurité ».

Le détail mérite d'être lu attentivement. Le régler sur Oui « ajoute une couche de friction à la navigation occasionnelle » en empêchant les non-administrateurs de charger des pages fréquemment visitées comme l'accueil, la vue d'ensemble du tenant et la liste des utilisateurs. Mais Microsoft précise que ce paramètre « ne bloque pas l'accès programmatique aux données Microsoft Entra via PowerShell, l'API Microsoft Graph, ou d'autres outils comme Visual Studio », qu'il « ne s'applique pas aux utilisateurs disposant d'un rôle d'administration », et que « la plupart des pages du centre d'administration restent accessibles si l'utilisateur dispose d'un lien direct (profond) ».

Chaque étape de la chaîne d'attaque ci-dessus passe par Microsoft Graph. Aucune n'est affectée par ce bascule.

Il y a une seconde conséquence pour les auditeurs : contrairement aux trois autres paramètres, celui-ci n'a aucune propriété sur la ressource authorizationPolicy. Sa liste de propriétés documentée — en v1.0 comme en beta — contient defaultUserRolePermissions, guestUserRoleId, allowInvitesFrom, blockMsolPowerShell et consorts, et rien pour l'accès au portail d'administration. Si la baseline de votre tenant prétend lire ce paramètre depuis Graph, vérifiez ce qu'elle lit réellement.

🚨 Danger : ne comptez pas le bascule du portail comme un contrôle compensatoire pour un enregistrement d'application ouvert. La recommandation de Microsoft est d'utiliser une stratégie d'Accès conditionnel ciblant l'API Windows Azure Service Management pour bloquer l'accès non-admin aux points de terminaison de gestion Azure.

Détection

Lisez l'état réel plutôt que le rendu du centre d'administration. Trois des quatre paramètres sont récupérables avec des étendues en lecture seule ; le quatrième — le bascule du centre d'administration — n'a aucune propriété à lire, pour la raison indiquée ci-dessus.

Connect-MgGraph -Scopes "Policy.Read.All","Directory.Read.All"

$policy = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/policies/authorizationPolicy"
$policy.defaultUserRolePermissions

$settings = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/groupSettings"
$settings.value

Un tenant qui n'a jamais été durci renvoie quelque chose de proche de ceci, avec une collection groupSettings vide :

{
  "allowedToCreateApps": true,
  "allowedToCreateSecurityGroups": true,
  "allowedToCreateTenants": true,
  "allowedToReadOtherUsers": true,
  "permissionGrantPoliciesAssigned": ["managePermissionGrantsForSelf.microsoft-user-default-legacy"]
}

Associez la lecture de configuration au journal d'audit. Ces noms d'activités sont exacts, et tous sont accessibles dans le journal d'audit Microsoft Entra :

Source pour chaque nom d'activité : la référence des activités du journal d'audit Microsoft Entra.

Deux détections pratiques en découlent. Premièrement, alertez sur Add application ou Add service principal lorsque le principal à l'origine ne détient aucun rôle d'annuaire — dans un tenant avec une population de développeurs contrôlée, cela devrait être une courte liste. Deuxièmement, alertez sur Update authorization policy sans condition ; il y a très peu de raisons légitimes pour que cette stratégie change, et un attaquant qui atteint le rôle Administrateur de rôle privilégié l'utilisera pour rouvrir ce que vous avez fermé. Si votre tenant ne conserve pas ces journaux assez longtemps pour investiguer, corrigez cela en premier — voir Rétention des journaux Entra ID et paramètres de diagnostic.

Remédiation

1. Fermez les autorisations du rôle utilisateur par défaut. L'exemple PowerShell de Microsoft pour désactiver la création d'applications sert de base ; les deux propriétés supplémentaires sont documentées sur le même objet.

Import-Module Microsoft.Graph.Identity.SignIns
Connect-MgGraph -Scopes "Policy.ReadWrite.Authorization"

$params = @{
    defaultUserRolePermissions = @{
        allowedToCreateApps           = $false
        allowedToCreateSecurityGroups = $false
        allowedToCreateTenants        = $false
    }
}

Update-MgPolicyAuthorizationPolicy -BodyParameter $params

Régler allowedToCreateTenants sur $false restreint la création de tenant au rôle Tenant Creator. Cela compte plus qu'il n'y paraît : Microsoft note que « par défaut, l'utilisateur qui crée un tenant Microsoft Entra se voit automatiquement attribuer le rôle Administrateur général », et l'événement est journalisé sous Create Company.

2. Fermez la création de groupes Microsoft 365 et déléguez-la. Ceci nécessite un objet groupSettings créé à partir du modèle Group.Unified, car un tenant par défaut n'en a aucun. Récupérez d'abord l'id du modèle depuis votre propre tenant avec GET https://graph.microsoft.com/v1.0/groupSettingTemplates plutôt que de le coder en dur.

{
  "templateId": "62375ab9-6b52-47ed-826b-58e47e0e304b",
  "values": [
    { "name": "EnableGroupCreation", "value": "false" },
    { "name": "GroupCreationAllowedGroupId", "value": "<object-id-of-your-approved-creators-group>" }
  ]
}

GroupCreationAllowedGroupId est documenté comme « l'identifiant du groupe de sécurité dont les membres sont autorisés à créer des groupes Microsoft 365 même lorsqu'EnableGroupCreation est à false » — c'est votre porte de sortie, et elle ne nécessite aucune licence P1.

3. Resserrez la gestion des groupes en libre-service. Dans le centre d'administration, sous Groupes → Paramètres généraux, réglez Les utilisateurs peuvent créer des groupes de sécurité dans les portails Azure, l'API ou PowerShell et Les utilisateurs peuvent créer des groupes Microsoft 365 dans les portails Azure, l'API ou PowerShell sur Non. Microsoft est explicite sur la porte de sortie : « si vous voulez permettre à certains, mais pas à tous vos utilisateurs de créer des groupes, vous pouvez leur attribuer un rôle capable de créer des groupes, comme Administrateur de groupes ». Connaissez la limite de l'interrupteur voisin avant de vous y fier — Restreindre la capacité des utilisateurs à accéder aux fonctionnalités de groupe dans le Panneau d'accès « ne restreint que l'accès aux informations de groupe dans Mes groupes. Cela ne restreint pas l'accès aux informations de groupe via d'autres méthodes comme les appels à l'API Microsoft Graph ou le centre d'administration Microsoft Entra ».

4. Remplacez le bascule du centre d'administration par un vrai contrôle. Réglez-le sur Oui si vous voulez la friction, mais implémentez le contrôle que Microsoft recommande réellement : une stratégie d'Accès conditionnel ciblant l'API Windows Azure Service Management qui bloque l'accès non-admin aux points de terminaison de gestion Azure. Vérifiez-la d'abord en mode rapport seul — voir Accès conditionnel mode rapport seul, exclusions obsolètes.

5. Vérifiez, et méfiez-vous des deux pièges. Relancez le bloc de détection ci-dessus et confirmez que chaque valeur a bien changé. Deux comportements documentés pourraient sinon vous faire croire que le changement a échoué ou réussi alors que ce n'est pas le cas :

• Les paramètres de groupe « peuvent prendre jusqu'à 15 minutes pour prendre effet ».
• « Ces paramètres concernent les utilisateurs et n'affectent pas les principaux de service. Par exemple, si vous aviez un principal de service avec la permission de créer des groupes, même si vous réglez ces paramètres sur Non, le principal de service peut toujours créer des groupes ».

Ce second point est la raison pour laquelle ce passage de durcissement doit s'accompagner d'un inventaire des applications. Fermer la création côté utilisateur en laissant en place des principaux de service sur-permissionnés déplace le problème au lieu de le résoudre — voir Applications Azure sur-privilégiées dans votre tenant et la baseline de durcissement du tenant Azure plus large.

Comment EtcSec détecte cela

EtcSec découpe cette surface en quatre constats distincts sur chaque audit Azure plutôt que de tout regrouper dans un vague score de « durcissement du tenant ». Les quatre sont rapportés en sévérité moyenne.

• AZ_APP_REGISTRATION_OPEN — Enregistrement d'applications ouvert à tous les utilisateurs : levé quand authorizationPolicy → defaultUserRolePermissions.allowedToCreateApps revient à true. Ce constat est lu directement depuis Microsoft Graph.
• AZ_SELF_SERVICE_GROUPS_OPEN — Création de groupes en libre-service ouverte : levé quand le tenant ne porte aucune restriction de création de groupes — ce qui correspond à un tenant par défaut, puisque EnableGroupCreation reste à true tant qu'aucun objet Group.Unified n'existe.
• AZ_GROUP_SELF_SERVICE — Gestion des groupes en libre-service non restreinte : le même état non restreint évalué côté groupes — des groupes non gouvernés, et une propriété qui ne signifie rien.
• AZ_ADMIN_PORTAL_ACCESS_OPEN — Accès au portail d'administration non restreint : levé sauf si le tenant est enregistré comme restreignant l'accès au centre d'administration aux seuls administrateurs. Rapporté comme une question d'hygiène de configuration, pas comme une limite de sécurité, conformément à la propre mise en garde de Microsoft.

Les garder séparés compte parce que le correctif diffère selon le constat : l'un est une mise à jour d'authorizationPolicy, deux nécessitent de créer d'abord un objet groupSettings, et le quatrième est une stratégie d'Accès conditionnel. Pour la séquence complète, voir Comment auditer la sécurité Microsoft Entra ID.