1 — Microsoft Entra ID (ex Azure AD)

Solution d'identité cloud de Microsoft. Sert à Azure mais aussi à M365, apps SaaS, apps custom. Pas un AD DS (pas de GPO, pas de LDAP, pas de Kerberos natif → c'est de l'identité cloud, basée sur OAuth2 / OpenID Connect / SAML - on se connecte via HTTP au lieu de protocole LDAP vers annuaire).

Licences

Note AZ-104 : retenir surtout ce qui passe en P1 (groupes dynamiques, AU, Conditional Access, SSPR). C'est le piège le plus fréquent.

Tenant

• Instance dédiée d'Entra ID pour une organisation = annuaire d'objets d'identité (users, groupes, devices, apps).
• Domaine par défaut : <nomtenant>.onmicrosoft.com (modifiable via custom domain à vérifier par TXT/MX).
• Relation avec Subscriptions :
  • 1 tenant ↔ plusieurs subscriptions
  • 1 subscription ↔ un seul tenant à la fois (mais on peut la transférer vers un autre tenant)
• Un user peut avoir accès à plusieurs tenants (guest ou via switch).

Types d'identité

User

• Cloud only : créé directement dans Entra ID.
• Hybride : créé dans l'AD on-prem puis synchronisé vers Entra via :
  • Entra Connect Sync : agent lourd installé sur un serveur on-prem, il faut une base SQL locale, supporte writebacks (cloud → on-prem) : password writeback (mdp reset SSPR redescend), device writeback (Hybrid Joined écrit dans AD), Exchange Hybrid (mailbox mixed). Agent non HA (le second agent doit être activé manuellement et seulement un a la fois qui sync onprem vers le cloud)
  • Entra Cloud Sync : agents légers, plusieurs actifs simultanément = HA natif. Config dans le cloud, plus simple. Limites : ~150k objets/domaine, pas de writebacks device/Exchange mais password OUI. Direction stratégique de MS.
• Guest (B2B) : user externe invité dans le tenant.

Bulk operations : Users > Bulk operations permet bulk create / bulk invite (B2B) / bulk delete / bulk restore via upload CSV (template fourni). Limite ~50k lignes par opération. Les jobs s'exécutent en async — voir résultats dans Bulk operations results.

Application

• Enregistrée via App Registration → crée 2 objets :
  • Application object (le "template", dans le tenant home)
  • Service Principal (l'instance dans chaque tenant qui consomme l'app) → visible dans Enterprise Applications
• Auth via :
  • Client secret (string, expire)
  • Certificat (recommandé, plus sécurisé)
• ⚠️ Piège AZ-104 :
  • App Registration = je définis l'app (TU développes l'app)
  • Enterprise Application = j'utilise l'app (instance + permissions consenties dans mon tenant)
  • Une app SaaS tierce (Salesforce, Zoom…) ajoutée à ton tenant n'a qu'une Enterprise App, pas d'App Reg.
  • Comment ajouter une app SaaS : Enterprise applications > New > Browse Microsoft Entra Gallery > [chercher Salesforce/etc.] > Create > configurer SSO (SAML/OIDC) > assigner users. L'App Registration globale appartient à l'éditeur dans LEUR tenant (c'est l'équivalent de partager son App Reg entre tenants)

Managed Identity

• Identité gérée pour ressources Azure → pas de credentials à gérer (rotation auto).
• Auth via le endpoint local IMDS, fonctionne avec RBAC pour donner accès à d'autres ressources.

Groupes

💡 M365 group membership ≠ licence M365 : être membre d'un M365 group ne nécessite aucune licence (n'importe quel user Entra peut être ajouté). Mais pour utiliser les services associés (Exchange mailbox, SharePoint, Teams) → l'user doit avoir la licence M365 individuelle correspondante sur son compte. Distinction : membership (gratuit) vs feature access (licencié).

Membership types

• Assigned : ajout/retrait manuel.
• Dynamic User : règle sur attributs user (ex: user.department -eq "IT").
• Dynamic Device : règle sur attributs device (ex: device.deviceOSType -eq "Windows").

Règles importantes

• Dynamic groups → P1 requis
• Pas de membership manuel possible si le groupe est dynamique (tout est piloté par la règle)
• Marche pour Security ET M365 (mais un groupe dynamique ne peut pas mixer users + devices)

Devices

Les devices sont des objets d'identité dans Entra → permettent d'appliquer des policies (Conditional Access, Intune compliance) et SSO sur des machines de confiance.

Comment join : Registered/Joined via Settings > Accounts > Access work or school > Connect. Hybrid Joined via Entra Connect Device options > Configure Hybrid Azure AD join (auto-process pour tous les PC déjà domain-joined). Détails

À retenir :

• Settings : Entra > Devices > Device settings → qui peut joindre, max devices/user, MFA pour join, local admins.

Administrative Units (AU)

Équivalent des OU de l'AD on-prem → segmentation du tenant pour déléguer l'admin sans donner Global Admin.

• P1 requis
• Membres possibles : users, groupes, devices
• Un objet peut appartenir à plusieurs AU simultanément
• ❌ Pas de nesting (une AU ne peut pas en contenir une autre)
• Rôles assignés au scope d'une AU (ex: User Admin sur AU "France" uniquement)

Restricted Management AU

• Variante "verrouillée" : même un Global Admin ne peut pas modifier les objets de l'AU s'il n'a pas un rôle explicite dessus.
• Use case : protéger des comptes sensibles (break-glass, VIPs).

License management

3 façons d'assigner une licence à un user :

Pièges fréquents :

• Pas de licence sans Usage Location définie sur le user (FR / US / etc.) → erreur licenseAssignmentNotAllowed.
• License conflicts : 2 licences donnant le même service plan → un seul prend effet. Désactiver les service plans en double.
• Reprocess : si un user reste en erreur → Licenses > [licence] > Reprocess.
• Reports : Entra > Billing > Licenses > All products → vue conso par licence.

DEMO — chemins portail & pièges

Portail principal : entra.microsoft.com (admin center Entra ID). Alternative : portal.azure.com (recherche "Microsoft Entra ID").

Tenant

• Création : Entra > Overview > Manage tenants > Create
• Le compte qui crée devient Global Admin automatiquement.

Subscription

• Créer / changer de tenant : Subscription > Change directory (déplace la sub vers un autre tenant — attention : les RBAC sont perdus, à réassigner).

Custom domain

• Entra > Custom domain names > Add → ajoute un enregistrement TXT ou MX chez le registrar → Verify.
• Le domaine peut être défini comme primary.

Création users

• Single : Entra > Users > New user > Create new user (cloud) ou Invite external user (B2B).
• Bulk : Users > Bulk operations > Bulk create → upload CSV (template fourni).

App Registration (piège classique)

• Entra > App registrations > New registration
• Options à connaître :
  • Supported account types : single tenant (juste ta boîte) / multi-tenant (toute boîte Entra) / multi-tenant + perso (élargit aux comptes hotmail/outlook.com perso)
  • Redirect URI : URL où Entra renvoie le user après login OAuth (avec le token). Doit matcher EXACTEMENT. Ex web app : https://myapp.com/auth/callback
  • Client secrets : string avec date d'expiration (~2 ans max), à rotater. Visible une seule fois à la création
  • Certificates : alternative + sécurisée (recommandé prod) ; tu uploades la clé publique, l'app garde la privée
  • API permissions — Delegated : app agit au nom du user connecté (ex User.Read = lire MES infos quand JE suis loggé)
  • API permissions — Application : app agit toute seule sans user (ex User.Read.All = lire tous les users du tenant). Exige souvent Grant admin consent par un Global Admin
  • App roles : rôles métier exposés par l'app (ex Manager, Employee). Tu assignes ces rôles à des users → l'app les voit dans le token et adapte son UI
• Vérifier dans Enterprise applications que le service principal est bien créé.

Managed Identity

• System-Assigned : sur la ressource (ex VM) → Identity > System assigned > On. Disparaît avec la VM.
• User-Assigned : créer la ressource indépendante Create > Managed Identity puis l'attacher à la VM via Identity > User assigned > Add.
• Test rapide depuis la VM :

  az login --identity                      # SA
  az login --identity --username <client-id-UA>   # UA
  

Security group

• Entra > Groups > New group > Type: Security → membership Assigned ou Dynamic.

M365 group — options à retenir

• Type: Microsoft 365
• Expiration policy : tenant-wide, force le renouvellement (ex 180j) sinon suppression (récup possible 30j).
• Naming policy : tenant-wide. Préfixe/suffixe + blocked words. Exemple : préfixe GRP_, suffixe _[Department], blocked = test,admin. Marie (Dept=Finance) crée "Projet Q3" → nom imposé GRP_Projet Q3_Finance. "test team" → bloqué. En gros on force un nommage aux groupes crées.
• Attention : ces deux policies sont tenant-level, pas par groupe.

Dynamic group

• Au create : Membership type → Dynamic User (ou Device).
• Builder de règle ou syntaxe directe : (user.department -eq "Finance") -and (user.country -eq "FR")
• Validation possible avec "Validate Rules" (tester sur un user existant).

Licences

• Entra > Billing > Licenses > All products > [licence] > Assign
• Group-based licensing : assigner une licence à un groupe → tous les membres l'obtiennent (P1 requis).

Administrative Unit

• Entra > Roles & admins > Administrative units > Add
• Add members (users / groupes / devices) → puis Roles and administrators au scope de l'AU pour déléguer.
• Restricted Management AU : option à cocher à la création. Effet : même un Global Admin ne peut PAS modifier les objets de l'AU sans rôle assigné explicitement dessus → protège comptes break-glass / VIP. Irréversible = une fois la case cochée à la création, on ne peut plus la décocher. Pour annuler, supprimer l'AU et la recréer non-restricted (perte de config). Bien réfléchir avant.

🏢 Scenarios d'entreprise réels — pensée d'architecte

Comment ces services s'utilisent dans la vraie vie. Pour chaque scenario : contexte business → choix techniques (uniquement les services traités dans la fiche) → pièges typiques.

Scenario 1 : Retail multi-pays — 12 000 vendeurs, 800 magasins

Contexte business : enseigne grande distribution avec turnover élevé (saisonniers Noël, étudiants été). Les RH veulent que les vendeurs obtiennent automatiquement leurs accès le jour de leur embauche, sans ticket IT. Choix techniques : users hybrides (Entra Cloud Sync) depuis l'AD on-prem du SIRH + dynamic groups par department et country + group-based licensing (M365 F3 frontline). Architecture / pattern :

• SIRH écrit dans AD on-prem → Cloud Sync pousse vers Entra (agents légers HA, ~5 min latence)
• Dynamic group Vendeurs-FR avec règle (user.jobTitle -eq "Vendeur") -and (user.country -eq "FR")
• Licence M365 F3 assignée au groupe → onboarding licence = 0 clic
• AU France / Espagne / Italie → délégation Helpdesk régional sans Global Admin Pièges à éviter :
• Oublier usageLocation sur les users hybrides → erreur licenseAssignmentNotAllowed (à set côté Entra, pas AD)
• Choisir Entra Connect Sync au lieu de Cloud Sync : agent unique = SPOF, et MS est en mode maintenance dessus
• Mettre toutes les régions dans une seule AU non-restricted → un User Admin France peut bidouiller un compte espagnol

Scenario 2 : Startup SaaS B2B fintech — 100% cloud, 80 employés

Contexte business : jeune fintech sans AD on-prem, lève une Série B, doit passer des audits SOC 2. Tous les laptops sont des MacBooks et Surface neufs distribués en remote. Choix techniques : users cloud-only + Entra Joined (zero-touch OOBE) + Managed Identity pour les workloads Azure + app registrations pour leurs propres APIs. Architecture / pattern :

• Onboarding : RH crée le user Entra → laptop livré scellé → user fait OOBE avec son compte corp → Entra Joined automatique, SSO immédiat M365
• L'API Node.js sur App Service utilise une System-Assigned MI pour lire Key Vault → zéro secret dans le code
• App Reg multi-tenant pour leur produit SaaS (les clients consentent → Service Principal créé dans leur tenant)
• Auth via certificat (pas client secret) pour la pipeline CI/CD GitHub Actions Pièges à éviter :
• Confondre App Registration (le template chez toi) et Enterprise Application (l'instance chez le client) lors du support — les permissions consenties sont côté Enterprise App du client
• Laisser un client secret de 24 mois sans rotation → expiration silencieuse, prod KO un vendredi soir
• Activer Entra Joined sur des Mac en pensant que c'est pareil que Windows : le SSO macOS exige la Company Portal app + config Platform SSO

Scenario 3 : Banque retail européenne — fusion de 2 entités

Contexte business : BankA rachète BankB. Chacune a son tenant Entra avec 15-25k employés. Pendant 18 mois de migration, les équipes doivent collaborer (Teams, projets communs) sans tout merger d'un coup. Choix techniques : 2 tenants distincts conservés + bulk invite B2B pour les équipes mixtes + groupes Security côté ressources Azure communes + custom domains pour préserver les marques. Architecture / pattern :

• Tenant BankA reste primaire pour les ressources Azure partagées (sub holding)
• Bulk invite CSV des ~2000 collaborateurs BankB côté BankA → guests dans tenant A
• Custom domain @bankb-legacy.com ajouté au tenant A pour préserver l'identité visuelle email
• Groupe Security Project-Integration côté A → RBAC sur les RG du programme de fusion Pièges à éviter :
• Vouloir tout fusionner en un seul tenant dès J+1 : les domaines, licences M365, contrats EA sont par tenant → impossible sans projet 12+ mois
• Bulk invite sans préparer usageLocation ni licences côté tenant A → les guests sont là mais ne peuvent rien faire
• Inviter les guests directement en Global Admin du tenant A pour "aller vite" — viole le principe least privilege et trace audit catastrophique

Scenario 4 : Industriel manufacturing IoT — 200 usines, apps legacy SAP

Contexte business : groupe industriel, 60k employés, AD on-prem ancien (forêt 2008), apps métier (SAP, MES) qui ne parlent que LDAP/Kerberos. Modernise progressivement vers M365 et Azure. Choix techniques : Entra Connect Sync (writebacks needed) + users hybrides + Managed Identity User-Assigned partagée par un pool de Function Apps de télémétrie + devices Hybrid Joined pour les postes opérateurs. Architecture / pattern :

• Entra Connect Sync sur 2 serveurs (1 actif + 1 staging) avec password writeback (SSPR doit redescendre dans AD pour MES)
• Postes opérateurs déjà domain-joined → activation Hybrid Join via Entra Connect → GPO conservées + SSO M365
• UA Managed Identity mi-telemetry-prod partagée par 50 Function Apps régionales → RBAC Storage Blob Data Contributor sur 1 seul Storage central Pièges à éviter :
• Choisir Cloud Sync alors qu'on a besoin du device writeback (Hybrid Join) → non supporté, repartir sur Connect Sync
• Donner une System-Assigned MI par Function App : 50 identités à gérer en RBAC = ingérable, préférer UA partagée
• Oublier d'activer le staging mode du 2e Connect Sync → en cas de crash, les 200 usines ne syncent plus pendant le weekend