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

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. Supporte password writeback, Exchange Hybrid attributes, group writeback / provisioning to AD (v1) et les disconnected forests (scénario fusion / M&A). Limites : ~150k objets/domaine, groupes ≤ 50k membres, PAS de device sync (Hybrid Azure AD Join), pas d'advanced sync rules, pas de cross-forest references. 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.

🏢 Scénarios d'entreprise (CAF/WAF)

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

Contexte business : gros turnover (saisonniers, étudiants). Les RH veulent que chaque vendeur ait ses accès dès son 1er jour, sans ticket IT. Choix architectural : on synchronise les comptes depuis l'AD du SIRH avec Entra Cloud Sync, on classe les gens automatiquement par dynamic groups (pays/métier), et on attache la licence M365 au groupe. Architecture / pattern :

• L'AD on-prem alimente Entra via Cloud Sync (agents légers redondants, ~5 min de délai).
• Dynamic group Vendeurs-FR : règle (user.jobTitle -eq "Vendeur") -and (user.country -eq "FR").
• Licence M365 F3 posée sur le groupe → l'attribution se fait toute seule, 0 clic.
• Une Administrative Unit par pays → le helpdesk régional gère ses users sans être Global Admin. Trade-offs assumés :
• Gain : onboarding 100% automatique, délégation propre par pays.
• Perte : dépendance à la qualité des données RH (un mauvais jobTitle = pas d'accès). Pièges à éviter :
• Oublier usageLocation sur les comptes hybrides → erreur licenseAssignmentNotAllowed (à mettre côté Entra, pas AD).
• Prendre Entra Connect Sync plutôt que Cloud Sync : son agent unique est un point de panne, et MS pousse Cloud Sync.
• Une seule AU pour tous les pays → un admin France peut toucher un compte espagnol.

📐 Réf. CAF — Landing zone identity & access management : la délégation par Administrative Unit régionale correspond à la reco officielle « delegate the administration of a service desk to a single business unit » (les AU évitent de multiplier les tenants comme frontière de sécurité). Lien

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

Contexte business : fintech sans AD on-prem, en pleine levée, doit passer un audit SOC 2. Laptops neufs envoyés à distance. Choix architectural : tout en cloud-only, postes en Entra Joined (setup auto à l'allumage), workloads Azure en Managed Identity (zéro secret), et app registrations pour leurs propres APIs. Architecture / pattern :

• Onboarding : RH crée le compte Entra → le user allume le laptop, se connecte avec son compte pro → Entra Joined + SSO M365 immédiats.
• L'API sur App Service lit Key Vault via une Managed Identity System-Assigned → aucun mot de passe dans le code.
• App Registration multi-tenant pour le produit SaaS : quand un client consent, un Service Principal est créé chez lui.
• Pipeline CI/CD GitHub : auth par certificat plutôt que client secret. Trade-offs assumés :
• Gain : zéro infra on-prem, zéro secret à gérer, prêt pour l'audit.
• Perte : tout repose sur Entra (pas de repli AD), et le SSO macOS demande de la config en plus. Pièges à éviter :
• Confondre App Registration (le modèle, chez toi) et Enterprise Application (l'instance, chez le client) : les permissions consenties sont côté client.
• Un client secret de 24 mois jamais tourné → il expire en silence, prod à terre un vendredi soir.
• Croire qu'Entra Joined sur Mac = comme Windows : le SSO macOS exige la Company Portal + Platform SSO.

📐 Réf. CAF — Identity & access management design area (greenfield) : un démarrage cloud-native avec un petit jeu d'users/rôles puis itération est le pattern CAF recommandé. La Managed Identity pour les workloads (zéro secret) et le certificat plutôt que client secret suivent les Azure identity management best practices. Lien

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

Contexte business : BankA rachète BankB (15-25k employés chacune, 1 tenant chacune). Pendant 18 mois, les équipes doivent collaborer sans tout fusionner d'un coup. Choix architectural : on garde les 2 tenants séparés, on relie les équipes mixtes via invitations B2B en masse, on partage les ressources Azure via des groupes Security, et on conserve les marques avec des custom domains. Architecture / pattern :

• Tenant BankA reste le principal pour les ressources Azure communes.
• Invitation CSV en masse des ~2000 collaborateurs BankB → ils deviennent guests chez BankA.
• Custom domain @bankb-legacy.com ajouté chez BankA pour garder l'identité email de BankB.
• Groupe Security Project-Integration côté A → sert de cible RBAC sur les RG du projet de fusion. Trade-offs assumés :
• Gain : collaboration immédiate sans projet de fusion long et risqué.
• Perte : 2 tenants à administrer en parallèle, gestion des guests à surveiller. Pièges à éviter :
• Vouloir tout fusionner dès J+1 : domaines, licences M365 et contrats EA sont par tenant → impossible sans projet 12+ mois.
• Inviter sans préparer usageLocation ni licences côté A → les guests existent mais ne peuvent rien faire.
• Mettre les guests Global Admin "pour aller vite" → viole le moindre privilège et pollue l'audit.

📐 Réf. CAF — Azure landing zones and multiple Microsoft Entra tenants : conserver 2 tenants distincts pendant la transition est un scénario CAF documenté ; Cloud Sync gère justement les disconnected forests typiques d'une fusion. Lien

DEMO

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.