Ce que vous saurez faire
- Distinguer AD DS et Entra ID sans les confondre : protocoles, structure, périmètre, ce que fait chacun.
- Expliquer le modèle de tenant Entra et le rôle des domaines vérifiés (
onmicrosoft.com+ domaine custom). - Situer les briques de l'écosystème M365 et leur lien avec l'identité.
- Identifier ce que débloquent les licences (E3 vs E5, Entra ID Free/P1/P2) et vérifier les licences d'un tenant.
- Naviguer dans les 4 portails (entra / admin / intune / azure) et savoir lequel utiliser pour quelle tâche.
Compétences transférées depuis l'AD classique
| L'admin AD réutilise | L'admin AD doit désapprendre |
|---|---|
| Notion d'annuaire, d'utilisateurs et de groupes | « OU = conteneur de stratégie » (pas d'OU ni de GPO dans Entra) |
| Rigueur sur les comptes à privilèges | « J'administre depuis un DC / RSAT » — ici portails web + Graph |
| Logique DNS (les domaines vérifiés en dépendent) | « Kerberos/NTLM partout » — ici OAuth 2.0 / OIDC / SAML |
AD DS vs Entra ID · Tenant · Licences · Portails
1. AD DS vs Entra ID : ce n'est PAS la même chose
Le tableau comparatif (à connaître par cœur)
| Critère | AD DS (on-premise) | Entra ID (cloud) |
|---|---|---|
| Nature | Service d'annuaire sur DC | Fournisseur d'identité SaaS multi-tenant |
| Protocoles | LDAP, Kerberos, NTLM | OAuth 2.0, OpenID Connect, SAML 2.0, WS-Fed, SCIM |
| Structure | Forêt → domaines → OU (hiérarchie) | Tenant plat : pas d'OU, pas de hiérarchie |
| Regroupement | OU + GPO liées | Groupes + politiques ciblées (CA, Intune) |
| Gestion des postes | GPO (push au login) | Intune / MDM (pull au check-in) |
| Authentification | Ticket Kerberos / NTLM sur le réseau | Jeton OAuth/OIDC sur HTTPS, depuis partout |
| Administration | RSAT, dsa.msc, GPMC | Portails web + Microsoft Graph (API/PowerShell) |
| Requêtes | Get-ADUser (ActiveDirectory) | Get-MgUser (Microsoft.Graph) |
| Périmètre réseau | LAN / VPN (ligne vers un DC) | Internet (identité = nouveau périmètre) |
| Contrôle d'accès conditionnel | Inexistant nativement | Conditional Access (cœur du modèle) |
Les 3 idées à retenir
- Structure plate. Il n'y a pas d'OU dans Entra. On cible avec des groupes (assignés ou dynamiques), pas avec une arborescence.
- L'identité est le périmètre. En AD, le réseau protège. En Entra, la protection se fait par Conditional Access (module 04), pas par un pare-feu.
- On administre par API. Le portail est pratique, mais l'outil de fond est Microsoft Graph — l'équivalent conceptuel de
Get-ADUser/ ADSI en REST.
Vous liez une GPO à l'OU Comptabilité.
Vous ciblez un groupe grp-comptabilite avec une politique CA et/ou un profil Intune.
Créer une « OU » dans Entra. Ça n'existe pas. Les unités administratives servent à déléguer l'admin, pas à appliquer de la configuration.
Microsoft Entra Domain Services (anciennement Azure AD DS) est un service séparé qui fournit un vrai domaine géré (LDAP/Kerberos/GPO) dans Azure, pour des applications legacy. Ce n'est pas Entra ID. On ne le traite pas ici : la cible est cloud-first. À retenir seulement pour ne pas confondre : AD DS ≠ Entra ID ≠ Entra Domain Services.
2. Le modèle de tenant
Un tenant est une instance dédiée d'Entra ID pour une organisation. C'est la frontière d'identité : un annuaire, ses utilisateurs, ses groupes, ses apps, ses politiques.
- Créé automatiquement avec le premier abonnement M365/Azure.
- Identifié par un Tenant ID (GUID) et un domaine initial
xxxxx.onmicrosoft.com. - 1 organisation = 1 tenant en règle générale.
Domaines vérifiés
Au départ le tenant n'a que contoso.onmicrosoft.com. Pour utiliser @contoso.fr, il faut ajouter puis vérifier le domaine :
- Ajouter le domaine dans le portail.
- Microsoft fournit un enregistrement DNS TXT (ou MX).
- Vous le publiez dans votre zone DNS publique.
- Microsoft vérifie que vous contrôlez le domaine → utilisable pour les UPN et adresses mail.
3. Licences M365 / Entra
Ce que débloque chaque plan Entra ID
| Fonctionnalité | Free | P1 | P2 |
|---|---|---|---|
| Utilisateurs, groupes, SSO apps SaaS | ✅ | ✅ | ✅ |
| MFA de base (security defaults) | ✅ | ✅ | ✅ |
| Conditional Access | ❌ | ✅ | ✅ |
| Groupes dynamiques, SSPR cloud | ❌ | ✅ | ✅ |
| Identity Protection (risk-based) | ❌ | ❌ | ✅ |
| PIM (Privileged Identity Management) | ❌ | ❌ | ✅ |
| Access Reviews, Entitlement Management | ❌ | ❌ | ✅ |
D'après ce que nous venons de voir, la fonctionnalité PIM nécessite-t-elle Entra ID P1 ou P2 ?
PIM, Identity Protection et Access Reviews sont trois fonctionnalités P2. Conditional Access, lui, est disponible dès P1. La cible E3 + Entra ID P2 débloque tout ce dont la formation a besoin en prod.
4. L'écosystème Microsoft 365
Entra ID est le socle d'identité. Les autres briques s'appuient dessus :
| Brique | Rôle | Lien avec Entra |
|---|---|---|
| Entra ID | Identité : users, groupes, auth, CA, PIM | Le socle |
| Intune | Gestion des postes/mobiles (MDM/MAM) | Conformité d'appareil consommée par CA |
| Defender (XDR) | Sécurité : endpoint, identité, mail, cloud apps | Signaux de risque remontés à IP |
| Purview | Conformité, DLP, rétention | Étiquettes de sensibilité liées aux identités |
| Exchange Online | Messagerie | Boîtes liées aux comptes Entra |
| SharePoint / OneDrive | Fichiers, intranet | Cible de migration des partages (module 08) |
| Teams | Collaboration | S'appuie sur M365 Groups + SharePoint |
Idée clé : tout tourne autour de l'identité Entra. Un utilisateur, ses licences, ses groupes déterminent ses accès à Exchange, SharePoint, Teams, et les politiques de sécurité qui s'appliquent à lui.
5. Les 4 portails
| Portail | URL | On y fait quoi |
|---|---|---|
| Entra admin center | entra.microsoft.com | Users, groupes, rôles, CA, PIM, Identity Protection, apps |
| Microsoft 365 admin | admin.microsoft.com | Licences, users métier, domaines, Exchange/SharePoint/Teams |
| Intune admin center | intune.microsoft.com | Enrôlement, conformité, profils de config (ex-GPO), apps, Autopilot |
| Azure portal | portal.azure.com | Abonnements Azure, RBAC Azure, Log Analytics / Sentinel, ressources |
- Beaucoup de tâches d'identité existent à la fois dans
admin.microsoft.cometentra.microsoft.com. Pour tout ce qui est sécurité/identité avancée (CA, PIM, IP), utilisez entra.microsoft.com. - Rôles Entra (annuaire) se gèrent dans Entra ; rôles RBAC Azure (ressources) se gèrent dans le portail Azure. Deux systèmes différents — détaillé au module 02.
Sources Microsoft Learn
Rappel : en cas d'écart entre ce support et le portail, le portail fait foi.
Explorer un tenant et ses licences
Partie A — Exploration au portail (30 min)
1. Identifier le tenant
Portail : entra.microsoft.com > Overview
Notez le Tenant ID, le nom d'organisation et le domaine initial xxxxx.onmicrosoft.com.
2. Explorer les utilisateurs et groupes
entra.microsoft.com > Users puis > Groups. Repérez l'origine (cloud vs synchronisé).
3. Repérer les rôles
entra.microsoft.com > Roles & admins. Repérez le rôle Global Administrator.
Partie B — Domaines et licences (50 min)
4. Ajouter un domaine personnalisé
admin.microsoft.com > Settings > Domains. Microsoft affichera un TXT à publier dans votre zone DNS publique.
5. Voir les licences disponibles
admin.microsoft.com > Billing > Licenses. Notez les SKU présents (SPE_E3, SPE_E5, AAD_PREMIUM_P2…).
6. Attribuer une licence
Ciblez un utilisateur de test et attribuez lui une licence M365 E3 (ou équivalent tenant dev).
Partie C — En PowerShell / Graph (40 min)
7. Connexion et contexte
Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "Organization.Read.All","Directory.Read.All","User.Read.All","Group.Read.All"
Get-MgContext8. Exploration automatisée
./scripts/01-explore-tenant.ps1Le script affiche organisation, domaines, SKU, volumétrie utilisateurs/groupes.
9. Attribution de licence par script
./scripts/01-assign-license.ps1 -UserPrincipalName "test.user@contoso.onmicrosoft.com" -SkuPartNumber "SPE_E5"5 réflexes AD à corriger
Testez vos acquis
Feedback riche par question et badge Acquis (≥60%) ou Maîtrisé (≥80%).
Cas pratique — Test E5 vs prod E3+P2
Contexte : votre PME migre vers M365 E3 + Entra ID P2. Un administrateur a monté un tenant de test via le Microsoft 365 Developer Program (E5). Il vous dit :
« J'ai testé PIM et Defender for Identity sur le tenant de dev, ça marche nickel. Je documente la procédure pour la prod. Et j'ai créé une OU Admins pour y ranger nos comptes à privilèges. »
Questions :
- Parmi PIM et Defender for Identity, lequel sera réellement déployable en E3+P2 et lequel ne le sera pas ? Justifiez.
- Pour la feature non déployable, quelle alternative proposez-vous sous E3+P2 ?
- Que répondez-vous sur l'« OU
Admins» ? Quel est le bon mécanisme dans Entra ?
Démarche attendue
- PIM est déployable en E3+P2 (fonctionnalité Entra ID P2). Defender for Identity ne l'est pas : il exige E5/add-on. Ne pas documenter une procédure prod qui en dépend.
- Alternative E3+P2 à Defender for Identity : s'appuyer sur Identity Protection (P2, détections basées sur le risque) et sur les sign-in / audit logs d'Entra pour la détection et l'investigation (voir module 07).
- L'OU
Adminsn'existe pas dans Entra (annuaire plat). Bon mécanisme : un groupe de sécurité pour regrouper les comptes à privilèges + PIM (rôles éligibles, activation JIT avec MFA + justification) + politiques Conditional Access. Les AU peuvent servir à déléguer, pas à appliquer une stratégie.