Ce que vous saurez faire
- Créer et gérer des utilisateurs (membres / invités B2B, cloud-only / synchronisés).
- Choisir le bon type de groupe (sécurité vs M365, assigné vs dynamique) et écrire une règle d'appartenance.
- Distinguer rôles d'annuaire Entra et rôles Azure RBAC (deux plans de contrôle).
- Expliquer app registration, enterprise application, service principal, managed identity — et savoir lequel remplace un « compte de service ».
- Décrire le provisioning SCIM et son rôle dans l'automatisation du cycle de vie des comptes.
Objets d'annuaire et applications
1. Utilisateurs
Un objet utilisateur Entra ressemble à un objet utilisateur AD, mais avec des dimensions nouvelles :
- Type de compte : Membre (personnel interne) ou Invité (guest B2B, identité externe invitée).
- Source : cloud-only (créé dans Entra) ou synchronisé (répliqué depuis AD DS — module 03).
Get-ADUser, création dans une OU, mot de passe géré par le DC.
Get-MgUser, création à plat, UPN aligné sur un domaine vérifié.
Pour un utilisateur synchronisé, les modifications se font dans l'AD on-prem. Une modification dans Entra sera écrasée au cycle suivant.
Le B2B (invités) n'a pas vraiment d'équivalent AD simple. Le plus proche serait une approbation de forêt, mais le modèle est très différent — ici, on invite une identité externe par email.
2. Groupes — deux axes indépendants
Axe 1 — Type : Sécurité vs Microsoft 365
| Groupe de sécurité | Microsoft 365 Group | |
|---|---|---|
| Sert à | Donner des accès (apps, CA, licences) | Collaboration : Teams, SharePoint, boîte partagée |
| Membres | Users, appareils, groupes, SP | Users (et invités) |
| Crée quoi | Rien d'autre que le groupe | Site SharePoint, boîte mail, plan… |
| Équivalent AD | Groupe de sécurité AD | Pas d'équivalent AD direct |
Règle simple : accès → groupe de sécurité ; collaboration → M365 Group.
Axe 2 — Appartenance : Assigné vs Dynamique
- Assigné : on ajoute/retire les membres à la main (comme en AD).
- Dynamique : l'appartenance est calculée par une règle sur les attributs.
Exemple : utilisateurs du service Comptabilité :
(user.department -eq "Comptabilite")Exemple sur les appareils Windows :
(device.deviceOSType -eq "Windows")3. Rôles Entra vs Azure RBAC — la distinction critique
| Rôles d'annuaire Entra | Rôles Azure RBAC | |
|---|---|---|
| Contrôlent | L'administration d'Entra / M365 | L'accès aux ressources Azure |
| Exemples | Global Admin, User Admin, Groups Admin, Helpdesk Admin | Owner, Contributor, Reader |
| Où on les gère | entra.microsoft.com > Roles & admins | portal.azure.com > (ressource) > IAM |
| Portée (scope) | Tenant, ou unité administrative | Mgmt group / souscription / RG / ressource |
| Équivalent AD | Groupes « Domain Admins », délégation | Pas d'équivalent AD (Azure = plan distinct) |
À retenir : être Global Administrator ne donne aucun droit sur les ressources Azure par défaut, et être Owner d'une souscription ne donne aucun pouvoir d'administration sur Entra.
Un dev doit déployer des VM dans un resource group Azure. Vous lui donnez quel rôle et où ?
Le geste juste est un rôle du bon système (RBAC Azure, pas Entra) attribué au bon scope (le resource group, pas le tenant). Global Admin serait à la fois excessif et sans effet sur les VM.
4. Applications d'entreprise & Service Principals
| Objet | C'est quoi | Analogie |
|---|---|---|
| App registration | La définition d'une app (identifiants, redirect URI, permissions) | Le « modèle » / blueprint |
| Enterprise application | L'instance d'une app dans votre tenant | L'app telle que vous la consommez |
| Service principal | L'identité de l'app dans votre tenant | Le « compte » de l'app |
| Managed identity | Un SP géré automatiquement par Azure (pas de secret) | Compte de service sans mot de passe |
Un « compte de service » = un utilisateur AD avec mot de passe, souvent partagé et jamais renouvelé.
Équivalent moderne : service principal (avec secret/certificat) ou, mieux, managed identity (aucun secret exposé).
Créer un vrai utilisateur pour un script ou une app. Un utilisateur « robot » contourne la MFA, complique le CA et traîne un mot de passe partagé.
5. Provisioning SCIM
SCIM (System for Cross-domain Identity Management) est le standard qui permet à Entra de créer / mettre à jour / désactiver automatiquement les comptes dans une application SaaS tierce, en fonction de l'appartenance à un groupe.
Cas typique : un utilisateur rejoint grp-commerciaux → Entra provisionne automatiquement son compte dans l'app CRM SaaS ; il quitte le groupe → le compte est désactivé.
Sources Microsoft Learn
Créer les objets d'annuaire
Partie A — Groupe dynamique (30 min)
1. Créer un groupe dynamique par service
entra.microsoft.com > Groups > New group. Type : Security, Membership type : Dynamic User, règle : (user.department -eq "Comptabilite").
2. Vérifier l'application de la règle
Modifiez le department d'un utilisateur test. La membership se met à jour en quelques minutes.
Partie B — Rôle Entra à portée limitée (25 min)
3. Attribuer un rôle d'annuaire
Roles & admins > Helpdesk Administrator > Add assignments. Cible : un user test. Portée : tenant (ou AU si créée).
4. Comprendre la séparation avec Azure RBAC
Ouvrez portal.azure.com > Subscriptions > (sub) > Access control (IAM). Constatez que les Helpdesk Admin n'y apparaissent PAS.
Partie C — Application & Service Principal (35 min)
5. Enregistrer une application
App registrations > New registration. Récupérez l'Application (client) ID.
6. Observer l'enterprise application et le service principal
Enterprise applications → l'app apparaît avec un service principal généré automatiquement.
Partie D — Provisioning SCIM (démo, 15 min)
7. Explorer l'onglet Provisioning
Enterprise apps > (une app) > Provisioning. Repérez le mode Automatic et le mapping d'attributs.
5 réflexes AD à corriger
Testez vos acquis
Feedback riche par question et badge Acquis (≥60%) ou Maîtrisé (≥80%).
Cas pratique — La PME et ses 3 besoins
Contexte : la PME veut :
- Que tous les membres du service Commercial obtiennent automatiquement l'accès à l'app CRM (SaaS) et une licence M365.
- Qu'un prestataire externe puisse collaborer sur un espace d'équipe temporaire.
- Qu'un script de reporting tourne chaque nuit contre Microsoft Graph.
Pour chaque besoin, indiquez le(s) type(s) d'objet(s) Entra à utiliser, et pourquoi. Précisez la licence minimale pour le point 1.
Démarche attendue
- Commercial → CRM + licence : groupe de sécurité dynamique avec règle
(user.department -eq "Commercial"). Utilisation : (a) attribution de licence basée sur le groupe, (b) provisioning SCIM vers l'app CRM (Enterprise applications > Provisioning). Licence minimale : Entra ID P1 pour groupes dynamiques et licences par groupe — couvert par E3+P2. - Prestataire externe : invitation B2B (guest) ajouté au Microsoft 365 Group de l'équipe (site SharePoint). Retirer à la fin de la collaboration (ou piloter via Access Review — module 05).
- Script nocturne : service principal (app registration + certificat) ou managed identity si le script tourne sur une ressource Azure. Jamais un utilisateur avec mot de passe. Scopes Graph au moindre privilège.