3 — Entra ID Extended Services

Tout ce qui s'ajoute au coeur Entra ID : hybride, identités externes, gouvernance, sécurité, accès aux apps on-prem.

A. External Services

A.1 Entra Connect — synchronisation hybride

Synchronise un AD on-prem vers Entra ID. Deux outils distincts :

💡 HA : Connect Sync ne tolère qu'un seul agent actif à la fois. Le second est en staging mode (standby) — il observe mais ne pousse rien vers Entra. Si le principal tombe, il faut l'activer manuellement → SPOF. Cloud Sync, lui, fait tourner plusieurs agents légers en parallèle. Ils se partagent la sync et prennent le relais automatiquement si l'un tombe.

Méthodes d'authentification hybride (où est validé le mdp ?) :

• PHS (Password Hash Sync) : hash du hash du mdp synchronisé vers Entra → Entra valide en cloud. Si AD on-prem tombe, login M365 continue. ⭐ Le plus simple, recommandé.
• PTA (Pass-Through Auth) : mdp ne sort jamais d'on-prem. Agent on-prem valide le mdp en temps réel contre AD. RGPD-friendly. Si AD/agent tombe → login M365 KO.
• Federation (ADFS) : Entra délègue l'auth à un cluster ADFS on-prem. ADFS valide le mdp et délivre un token SAML. Complexe (cluster ADFS + WAP en DMZ + certs). MS pousse à dégager au profit PHS+CAP.
• SSO (Seamless SSO) : ⚠️ pas une méthode d'auth, c'est une option en plus activable avec PHS ou PTA → users sur PC AD-domain-joined sont logged-in automatiquement à M365 sans saisir leur mdp (Kerberos en arrière-plan).

Propriétés des objets synchronisés = modifiables uniquement on-prem (Entra est read-only sur ces attributs, sauf password writeback activé).

⚠️ Exceptions modifiables côté cloud même pour users hybrid synced :

• UsageLocation (attribut purement Entra, n'existe pas dans AD on-prem — requis pour assignation de licences).
• Assignations de licences et rôles Entra (gérés cloud-only).

Piège exam : "modifier Department de hybrid user" → on-prem AD (synced read-only côté Entra). "Modifier UsageLocation de hybrid user" → Entra portal directement OK.

A.1bis Microsoft Identity Manager (MIM)

Solution on-prem d'identity management de Microsoft (≠ Entra ID qui est cloud, ≠ Entra DS qui est AD DS managé). À retenir pour AZ-104 quand un scénario demande identity mgmt complet hybride :

Quand le choisir vs alternatives :

• MIM : tu as besoin de SSPR + cert mgmt + sync multi-systèmes dans un environnement on-prem ou hybride complexe.
• Entra ID seul : si tout est cloud (pas SSPR vers AD) ou hybride simple.
• Entra DS : seulement pour fournir LDAP/Kerberos aux apps legacy (≠ identity mgmt).
• Entra ID Protection : juste détection de risques (≠ identity mgmt).

Niche AZ-104 : si une question parle d'identity mgmt for large enterprise + on-prem AD + cert mgmt + SSPR + sync multi-systèmes = MIM.

A.2 Entra Domain Services (Entra DS)

AD DS managé par Azure (sans gérer de DC) → fournit LDAP, NTLM, Kerberos, GPO pour les apps legacy qui ne savent pas faire OAuth/SAML.

💡 Pourquoi les apps legacy ne savent pas OAuth/SAML : apps écrites avant ~2010, conçues pour AD on-prem. Elles parlent uniquement LDAP/Kerberos/NTLM (protocoles réseau, ports 389/88/445). OAuth/SAML = HTTPS web modernes. Une vieille app SAP ou .NET 2.0 ne peut donc PAS s'authentifier directement contre Entra ID (qui parle OAuth/SAML, pas LDAP). Solution : Entra DS = AD DS managé synchronisé depuis Entra → l'app legacy parle LDAP au managed domain, Entra DS sync depuis Entra ID.

Entra ID vs Entra DS : Entra ID = identité cloud (OAuth/SAML, M365, Azure). Entra DS = AD DS managé (LDAP/Kerberos, apps legacy, VM domain-joined). Sync one-way Entra ID → Entra DS.

Mise en place :

1. Créer un Managed Domain (forêt managée, nom DNS).
2. Synchro one-way : Entra ID → Managed Domain (jamais l'inverse).
3. Déployé dans un VNet → les ressources qui consomment doivent être dans ce VNet (ou peered).

Use case : VM Windows legacy à joindre à un domaine AD sans monter un DC.

DEMO — Entra Domain Services

1. Créer le Managed Domain : Entra Domain Services > Create → nom DNS (acme.onmicrosoft.com ou custom vérifié), région, SKU (Standard/Enterprise/Premium).
2. VNet + Subnet : choisir un VNet → créer un subnet dédié aadds-subnet (réservé Entra DS, pas d'autres ressources, pas de NSG bloquant). Azure y déploie 2 DCs managés (HA auto, intouchable).
3. DNS du VNet : VNet > DNS servers > Custom → pointer vers les 2 IPs des DCs managés (affichées dans Entra DS > Properties). Sinon les VMs ne trouvent pas le domaine.
4. Synchronisation : Sync settings → All (tous les users/groupes Entra) ou Scoped (groupes sélectionnés). Sync one-way Entra ID → Entra DS uniquement.
5. Activer hashes NTLM/Kerberos : Entra DS > Security settings → enable. ⚠️ Les users doivent changer leur mdp après activation pour que le hash soit généré (sinon Kerberos KO).
6. Joindre une VM Windows : VM dans le VNet (ou peered) → System > Domain or workgroup > Change > Domain: acme.onmicrosoft.com → login Entra. Pour les droits admin local, l'user doit être dans le groupe AAD DC Administrators.
7. GPO : depuis la VM joined → gpmc.msc → gérer les 2 OUs créées (AADDC Computers, AADDC Users).

⚠️ Pièges AZ-104 :

• Sync one-way : modifs dans Entra DS (GPO, OUs custom) ne remontent PAS dans Entra ID.
• Hashes Kerberos/NTLM : sync seulement après changement de mdp post-activation.
• Pas de schema extensions, pas de trust avec AD on-prem (sauf scénario resource forest).
• Subnet Entra DS = dédié, ne pas y mettre de VMs.

A.3 External Identities

B2B Direct Connect — limite à connaître :

• Supporte uniquement les Teams Shared Channels aujourd'hui (pas SharePoint, pas autres apps M365, donc pas d'accès aux ressources Azure).
• Configuré via Entra > External Identities > Cross-tenant access settings.

Entra External ID for Customers (hors scope AZ-104, culture)

Le principe : tu développes une app/site grand public (e-commerce, banque, app fitness…) et tu veux que tes clients puissent créer un compte et se logger. Au lieu de coder toi-même tout le système d'auth (signup, login, mdp oublié, 2FA, login Google/FB…), tu délègues à Microsoft via un tenant Entra séparé dédié aux clients. Pourquoi un tenant séparé ? Tu ne mélanges pas tes 1M de clients avec tes 500 employés (sécurité, scale, branding totalement différents). Ce que tu obtiens prêt à l'emploi : login social (Google/FB/Apple), MFA, reset mdp, gestion profil, scale millions d'users, compliance GDPR. Pages de login customisées aux couleurs de ton app (le client voit ta marque, pas "Microsoft"). Use cases typiques : app mobile e-commerce, paywall journal en ligne, programme fidélité retail, app banque clients, marketplace, forum communauté. Ancien nom : Azure AD B2C (legacy depuis ~2024, même produit modernisé). Pricing : facturé au MAU (Monthly Active User), pas par licence. ~50k users actifs/mois gratuits, ensuite payant.

💡 TL;DR : tenant workforce = employés + partenaires B2B. Tenant External ID for Customers = clients grand public de ton produit. Deux mondes, deux tenants.

DEMO — B2B Collaboration

Tenant ↔ Tenant

1. Entra > Users > New user > Invite external user → email du guest
2. Optionnel : assign roles/groupes via Assignments
3. Le guest reçoit un mail, clique → redeem → apparaît dans All users (User type = Guest)
4. Côté guest : il peut switcher entre tenants

Google → Tenant

1. Entra > External Identities > External collaboration settings → activer "Guest invite settings"
2. Entra > External Identities > All identity providers > Google → besoin de Client ID + Client Secret
3. Côté GCP : créer projet → APIs & Services → OAuth consent screen → Credentials → Authorized redirect URIs (avec ton Tenant ID)
4. Coller Client ID/Secret dans Entra → invitation gmail → login avec compte Google (pas OTP)

Sans config IdP Google : le guest gmail recevra un email one-time passcode par défaut.

DEMO — B2B Direct Connect

Connection entre deux organisations entières (Entra ↔ Entra). PAS d'invitation, PAS de guest user créé.

Côté Tenant A :

1. Entra > External Identities > Cross-tenant access settings
2. Organizational settings → Add organization → tape l'ID ou le domaine du Tenant B
3. Tenant B apparaît → onglet Inbound access → B2B direct connect → Customize settings → External users and groups : Allow access
4. Trust settings : cocher Trust multifactor authentication from Microsoft Entra tenants (sinon redemande MFA)
5. Outbound access : config miroir si tes users vont chez Tenant B

Côté Tenant B : faire le miroir (sinon trust unilatéral, ne marche pas).

Test : Tenant A user crée un Teams Shared Channel → ajoute des users de Tenant B (par email). Les users de Tenant B accèdent directement avec leur compte Tenant B (pas de login Tenant A).

⚠️ Aujourd'hui supporte UNIQUEMENT les Teams Shared Channels (pas SharePoint, Outlook, ni autres apps M365).

Différence rapide

B. Entra ID Governance

⚠️ Licensing récap (souvent piégé en exam) :

• P2 = PIM (de base), Access Reviews (groupes, apps, roles), Entitlement Management (de base)
• Entra ID Governance (add-on payant, exige P2) = Lifecycle Workflows, fonctionnalités avancées d'Entitlement Management & Access Reviews, ML recommendations
• SSPR = M365 minimum (cloud only) / P1 pour identités hybrides (writeback)

B.1 Entitlement Management — Access Packages

Le problème : sans EM, chaque demande d'accès = ticket helpdesk → admin clique manuellement → 6 mois plus tard l'user a changé de service mais ses accès restent → accumulation, faille de sécu.

EM = portail self-service où les users demandent leurs accès, avec workflow d'approbation + expiration auto.

Hiérarchie à comprendre (3 niveaux)

→ Le user (=client) ne demande pas une ressource individuelle, il demande un access package qui contient les bonnes ressources.

⚠️ Ressources supportées dans un access package : groupes (Security/M365), apps (Enterprise application), SharePoint sites. PAS de RG / sub / VM Azure directement → passer par un Security Group avec RBAC.

Pourquoi des Catalogs (pas tout en vrac) ?

1. Délégation : Sophie (manager Marketing) gère son catalog Marketing sans pouvoir toucher au catalog Finance.
2. Organisation : 50 access packages classés par catalog = clair. Tous en vrac = ingérable.
3. Sécurité : un Catalog Owner ne peut pas ajouter de ressources hors de son périmètre.

Rôles & scopes (qui peut faire quoi)

→ Délégation : l'admin global crée les catalogs + nomme des Catalog Owners métier (managers de département) → chacun gère son catalog en autonomie. → ⚠️ Catalog Owner ≠ ajouter n'importe quoi. Pour ajouter une ressource au catalog, il doit en être owner (ou avoir Groups Administrator / Application Administrator / SharePoint Administrator selon le type).

Walkthrough bout-en-bout

PHASE 1 — Bob (Governance Admin)
├── Crée catalog "Marketing Tools"
├── Ajoute ressources : Salesforce, groupe Marketing, SP Marketing
└── Nomme Sophie comme Catalog Owner

PHASE 2 — Sophie (Catalog Owner)
└── Crée access package "Onboarding Marketing"
    ├── Resources : les 3 du catalog
    └── Policy : All users can request / Approver = manager / Justif = oui / Durée = 1 an

PHASE 3 — Marie (nouvelle dans Marketing)
├── Va sur myaccess.microsoft.com
├── Request "Onboarding Marketing" + tape justif
├── Son manager reçoit notif → Approve
└── Auto-provisionnée : groupe Marketing + Salesforce + SP

PHASE 4 — 1 an plus tard
└── Accès expire automatiquement, Marie sort du groupe + perd les apps. Aucune intervention humaine.

Notes utiles

• Justification : juste un champ texte que le user remplit pour expliquer pourquoi il demande. Sert à l'audit / à éclairer l'approbateur. Indépendant de l'expiration (sans justif ≠ accès éternel).
• Approbation : 3 options → Aucune (auto-approved, accès direct) / Simple (1 approver : manager / specific user / sponsor) / Multi-stage (ex manager + DSI).
• Expiration : 3 options → durée fixe (X jours, date) / never expires (permanent) / access reviews (revalidation périodique, ex. tous les 3-6 mois — nécessite de configurer un reviewer).
• Portail user : myaccess.microsoft.com → faire une demande, voir ses accès actifs, approuver les demandes des autres.

B.2 PIM (Privileged Identity Management)

Activer des rôles à privilèges temporairement au lieu de les avoir en permanent. P2 requis.

Modèle :

• Eligible : tu peux activer le rôle quand tu en as besoin (sur justification, MFA, approbation ou sans etc.)
• Active : le rôle est appliqué immédiatement (permanent ou time-bound)

Couvre :

• Rôles Entra ID (Global Admin, etc.)
• Rôles Azure RBAC (Owner, Contributor, etc.)
• PIM for Groups (rôles assignables via groupe)

Options par rôle (Role settings) :

• Durée max d'activation (ex 8h)
• MFA / justification / ticket / approbation requis pour activer (pas forcément un Admin Cloud, peut être un Manager etc.)
• Notifications aux admins

B.3 Access Reviews

Audit périodique des accès → décide qui garde / qui perd ses droits. Évite l'accumulation de permissions.

Périmètres possibles :

• Teams & Groups
• Applications
• Rôles Entra et rôles Azure
• Access Packages
• Inactive users (review qui n'a pas signé in depuis X jours)

Configuration clé :

• Reviewer : self / managers / utilisateurs spécifiques
• Fréquence : one-time / récurrent
• Auto-apply des résultats (les "denied" sont retirés automatiquement à la fin)

B.4 SSPR (Self-Service Password Reset)

Les users reset leur mdp eux-mêmes (sans ticket support) après vérification.

Pré-requis :

• M365 minimum pour cloud users
• P1 + password writeback pour identités hybrides → supporté par Entra Connect Sync ET Cloud Sync (writeback ajouté à Cloud Sync depuis ~2023)
• Default administrator policy est toujours active sur les admins, non désactivable → admins doivent toujours utiliser méthodes fortes (pas que questions sécurité)

Scope (Password reset > Properties) : tenant-wide avec 3 options → None (désactivé) / Selected (1 groupe précis) / All (tous les users). ⚠️ Pas de scoping par AU.

⚠️ Pièges scoping & permissions (souvent en exam) :

• SSPR scopé à un groupe (Selected) → user hors du groupe ne peut PAS reset son mdp, même si méthode d'auth dispo.
• Modifier les méthodes MFA / security questions d'un user nécessite Global Administrator → un User Administrator ne peut PAS le faire.
• Number of methods required pour reset (1 ou 2) → si 2, le user doit valider 2 méthodes différentes (ex security questions + mobile phone), pas juste répondre à toutes les questions.

Mise en place :

• Entra > Password reset > Properties → None / Selected / All
• Registration : forcer les users à enregistrer au prochain sign-in
• Notifications : alerter les admins sur reset
• On-premises integration : activer password writeback (Entra Connect Sync OU Cloud Sync)

🚨 Changement 2025-2026 : la config des méthodes SSPR (SMS, email, Authenticator…) ne se fait plus dans Password reset > Authentication methods (legacy déprécié 30/09/2025) → tout est centralisé dans Entra > Protection > Authentication methods > Policies (UI moderne unifiée pour MFA + SSPR : tu actives une méthode 1x, ça vaut pour les 2).

DEMO — Governance

Access Package

1. Identity Governance > Catalogs → ajouter ressources (apps, groupes…)
2. Access packages > New → choisir catalog, ressources, qui peut request, approbation, lifecycle
3. Users vont sur myaccess.microsoft.com pour request

💡 Définir l'approver d'un Access Package : à l'onglet Requests de l'access package → cocher Require approval → choisir le type d'approver :

• Manager (du requester) → automatique selon l'attribut manager du user
• Specific users or groups → liste explicite (Sophie, ou groupe IAM-Approvers)
• Sponsors → internal/external sponsors définis sur le user
• Multi-stage : jusqu'à 2 niveaux (ex manager puis security team)
• Fallback possible si l'approver n'existe pas (ex pas de manager assigné)

PIM

1. Privileged Identity Management > Microsoft Entra roles > Roles > [role] > Add assignments
2. Choisir scope + members → Eligible (pas Active)
3. Role settings : durée d'activation, MFA, justification, approbation, notifications
4. Côté user : PIM > My roles > Activate → demande activation → admin approuve si requis

💡 Définir l'approver d'un rôle PIM : PIM > Microsoft Entra roles > Roles > [role] > Settings > Edit → onglet Activation → cocher Require approval to activate → Add approvers :

• Specific users (Sophie + Pierre individuellement)
• Groups (n'importe quel membre du groupe IAM-Approvers peut approuver) → recommandé pour gérer les vacances
• ⚠️ Pas de rôle Entra "Approver" prérequis : n'importe qui désigné peut être approver, peu importe son rôle existant
• L'approver reçoit un mail + notif portail → traite via PIM > Approve requests
• ⚠️ Si l'approver est lui-même Eligible sur son rôle d'admin → il doit l'activer d'abord pour pouvoir approuver. Préférer Active permanent pour les approvers.

Access Reviews

⚠️ Le chemin dépend de CE qu'on review :

• Groupes / Apps / Inactive users : Entra admin center > ID Governance > Access Reviews > New access review
• Rôles Entra (Global Admin…) : PIM > Microsoft Entra roles > Access reviews > New
• Rôles Azure RBAC : PIM > Azure resources > Access reviews > New
• Access Packages : configuré dans la lifecycle policy de l'access package
• PIM for Groups : PIM > Groups > [groupe] > Access reviews

Étapes (groupes/apps) :

1. ID Governance > Access Reviews > New access review
2. Select what to review : Teams + Groups / Applications / etc.
3. Scope : Everyone / Guest users only / Inactive users (X jours, jusqu'à 730j)
4. Reviewers :
   • Group owners (groupes uniquement)
   • Selected users or groups
   • Users review their own access (self-review)
   • Managers of users + fallback reviewer si pas de manager
5. Recurrence : One-time / Weekly / Monthly / Quarterly / Semi-annually / Annually
6. Duration : nb de jours pour répondre (ex 14j)
7. Settings :
   • Auto-apply : ✅ pour retirer auto les "Denied" à la fin
   • If reviewers don't respond : Keep / Remove / Take recommendations
   • Decision helpers : No sign-in within 30 days / User-to-Group Affiliation (suggestions auto)
   • Justification required : forcer le reviewer à motiver sa décision
8. Review + Create

💡 Délégation aux owners de groupe : par défaut seul un Identity Governance Admin peut créer des reviews → activer via ID Governance > Access Reviews > Settings > Group owners can create reviews for groups they own = Yes.

💡 Côté reviewer : reçoit un mail → myaccess.microsoft.com > Access reviews → décide Approve / Deny pour chaque user.

SSPR

1. Entra > Password reset > Properties → Selected / All / None
2. Méthodes d'auth : Entra > Protection > Authentication methods > Policies (UI moderne, plus dans Password reset > Authentication methods qui est legacy/déprécié)
3. Password reset > Registration → Yes pour forcer la conf au prochain sign-in
4. On-premises integration → activer password writeback (agent Entra Connect requis)

C. Authentication Methods (transverse)

Authentication Methods policy = endroit unifié où tu actives quelles méthodes les users peuvent utiliser pour MFA et SSPR. Remplace les vieilles UI séparées.

🚨 Migration obligatoire : les legacy MFA settings (Per-user MFA) et legacy SSPR Authentication methods sont dépréciées depuis le 30 septembre 2025. → Migrer vers Entra > Protection > Authentication methods > Policies. Wizard de migration disponible dans le portail.

Méthodes disponibles

Décider quelle approche MFA utiliser

Règle simple AZ-104 : Security Defaults activés ↔ CAP activé = mutuellement exclusifs. Activer une CAP désactive les Security Defaults.

💡 Pourquoi exclusifs : les deux essaient d'imposer du MFA avec des règles différentes → conflits. MS empêche techniquement la coexistence. Workflow : (1) petite boîte sans P1 → Security Defaults ON. (2) Boîte prend P1 et veut granularité → désactive Security Defaults manuellement → crée CAPs en mode Report-only → puis ON. Sinon fenêtre de quelques minutes où rien n'est appliqué = risque sécu.

Activer MFA + SSPR — flow :

• MFA : Security Defaults (gratuit, tout ou rien) OU CAP (P1+, granulaire).
• SSPR : (1) Entra > Password reset > Properties → enable. (2) Entra > Protection > Authentication methods > Policies → activer Authenticator/SMS/Email (UI moderne, pas le legacy Password reset > Authentication methods). (3) Password reset > Registration → forcer enrollment. (4) Si users hybrides : activer password writeback sur Entra Connect Sync.

D. Entra ID Security

💡 Vue d'ensemble : 2 composants qui bossent ensemble :

• Identity Protection = les yeux (détecte les risques avec ML)
• Conditional Access = le cerveau qui agit (décide quoi faire selon les risques + autres conditions)

D.1 Identity Protection — le détecteur

Moteur ML qui scanne chaque sign-in et chaque user pour détecter des anomalies. Génère un score de risque (Low/Med/High) consommable par Conditional Access.

Exemples de détections : leaked credentials (mdp dans un leak public), anonymous IP (Tor), atypical travel (Paris 14h → Moscou 14h15), malware-linked IP, password spray, unfamiliar sign-in properties.

Deux dimensions de risque :

Pré-requis : P2 pour utiliser les signaux de risque dans CAP.

🚨 Changement 01/10/2026 : les legacy policies d'Identity Protection (User risk policy, Sign-in risk policy, MFA registration policy) sont retirées. → Identity Protection reste comme moteur de détection, mais les actions se configurent désormais dans Conditional Access (avec User risk / Sign-in risk en conditions). Il faut migrer les policies legacy vers CAP avant cette date.

D.2 Conditional Access (CAP) — le décideur

Moteur de sécurité central. Logique : SI <conditions> ALORS <action>.

Pré-requis : P1 min (P2 pour les conditions de risque).

Construction d'une policy — 5 blocs :

Exemples de policies courantes :

• "Si user risk = High → forcer changement de mdp + MFA"
• "Si app = M365 + location = hors France → bloquer"
• "Si admins (rôles privilégiés) → require MFA toujours"
• "Si device non compliant → bloquer accès aux apps sensibles"

Best practices critiques :

• ✅ Toujours exclure 1-2 comptes break-glass (sinon risque de lockout total du tenant)
• ✅ Démarrer en Report-only (logge ce qu'aurait fait la CAP, sans appliquer)
• ✅ Tester avec What-if tool (simule une auth fictive : "que se passerait-il si Bob se loggait depuis la Russie ?")
• ⚠️ Désactiver les Security Defaults avant la 1ère CAP (sinon conflit, voir section C)

DEMO — Security

Identity Protection (consultation + legacy à migrer)

1. Reports : Entra > Protection > Identity Protection > Reports → Risky users / Risky sign-ins / Risk detections (toujours actifs, à consulter pour audit)
2. Legacy policies (à migrer avant 01/10/2026) :
   • Identity Protection > User risk policy → assignment + threshold (Low/Med/High) → control (Block / Allow + force password change)
   • Sign-in risk policy → idem + require MFA
   • MFA Registration Policy → force enrollment MFA
3. Migration : recréer ces policies dans Conditional Access avec User risk / Sign-in risk comme Conditions.

Conditional Access

1. Named locations (optionnel mais utile) : Entra > Protection > Conditional Access > Named locations → définir IPs trusted / pays autorisés
2. Créer la policy : Conditional Access > Policies > + New policy
3. Configurer les 5 blocs :
   • Users : qui est concerné + ⚠️ exclude break-glass
   • Target resources : sur quelles apps
   • Conditions : risk levels, locations, devices…
   • Grant : Block ou Grant + require (MFA, compliant device…)
   • Session : sign-in frequency, etc.
4. Enable policy : commencer en Report-only
5. Tester avec What-if tool (Conditional Access > What If)
6. Vérifier les sign-in logs (Entra > Sign-in logs) → onglet Conditional Access montre quelle policy a matché
7. Une fois validé → passer la policy en On

⚠️ Compte break-glass : 2 comptes Global Admin (cloud-only, mdp ultra-long stocké en coffre, exclus de TOUTES les CAPs et MFA). En cas de lockout total ou panne MFA → tu utilises ces comptes pour reprendre la main. Sans break-glass, tu peux te lock out toi-même de ton tenant.

E. Entra ID Connection

E.1 Application Proxy

Le besoin : exposer une app on-prem privée sur internet sans VPN ni ouverture de port entrant dans le firewall, avec auth Entra (SSO + CAP). Use case typique : portail RH http://hr.acme.local accessible aux télétravailleurs.

💡 Forward proxy vs Reverse proxy

• Forward proxy (classique) : ton PC bloqué d'internet → parle au proxy entreprise → le proxy va sur google.com pour toi. → "Le proxy fait les requêtes pour le client."
• Reverse proxy (= App Proxy) : l'inverse. Tu as une app interne privée → on la rend publique via un endpoint Azure → user tape l'URL publique → ça relaie vers ton app interne. → "Le proxy reçoit les requêtes du public et les relaie vers ton app."

Architecture

USER télétravail (internet)
   │ tape https://hr-acme.msappproxy.net
   ▼
┌──────────────────┐
│ Azure App Proxy  │  ← service managé MS (cloud public)
└────────┬─────────┘
         │
         │ ⬅ via connexion outbound déjà ouverte
         │
DATACENTER ON-PREM ─────────────────────
│        │                              │
│  Serveur Connector (Windows membre)   │
│   - Outbound HTTPS (443) vers Azure   │
│   - LAN privé vers app                │
│        │                              │
│        ▼                              │
│  Serveur App                          │
│  http://hr.acme.local                 │
└───────────────────────────────────────┘

Le connector :

• Installé sur un serveur Windows on-prem (member server, pas sur le serveur de l'app idéalement)
• Doit avoir : (1) outbound 443 vers Azure (déjà autorisé en général) + (2) accès LAN vers l'app interne
• Ouvre une connexion sortante permanente vers Azure → Azure pousse les requêtes via cette connexion, le connector forward à l'app, renvoie la réponse via la même connexion.
• ⚠️ Aucun port inbound à ouvrir dans le firewall. C'est le gros avantage.

Connector Groups : tu peux installer plusieurs connectors → les regrouper par région/datacenter → HA automatique + routing géographique.

📝 Le connector s'appelle officiellement "Microsoft Entra private network connector"

Pre-authentication (qui valide le user avant de toucher le backend) :

Comparé à un VPN : pas d'inbound firewall, pas d'accès au LAN entier, juste l'app exposée + SSO Entra natif.

DEMO — App Proxy

Pré-requis : 1 serveur Windows on-prem (ou VM Azure dans un VNet sans IP publique) qui a (1) accès LAN à ton app et (2) outbound HTTPS vers internet.

1. Préparer l'environnement : désactiver inbound 80/443 sur la VM/firewall (pour bien valider que rien n'est exposé directement). L'app reste accessible uniquement depuis le LAN privé.
2. Installer le connector :
   • Entra > Applications > Application proxy > Download connector service
   • Installer le .exe sur le serveur on-prem → login avec un compte admin du tenant
   • Vérifier dans Connector groups > Default que le connector apparaît avec status Active
3. Publier l'app (Enterprise applications > New application > On-premises application) :
   • Internal URL : URL vue du connector dans le LAN (ex http://hr.acme.local) - URL DE L'APP PRIVEE
   • External URL : URL publique auto-générée (https://hr-tenant.msappproxy.net) ou custom domain - NOUVELLE URL PUBLIC POUR ACCEDER A L'APP
   • Pre-authentication : Microsoft Entra ID (recommandé)
   • Connector Group : Default (ou un groupe spécifique si tu en as configuré)
4. Properties → enable User assignment required (pour limiter l'accès aux users assignés) + Visible to users (apparaît dans MyApps)
5. Users and groups → assigner les users/groupes autorisés (ex groupe Employees-Remote)
6. (Optionnel) Conditional Access : créer une CAP sur cette Enterprise App qui exige MFA / device compliant
7. Tester depuis internet : ouvre https://hr-tenant.msappproxy.net depuis ton mobile/PC perso → redirigé login Entra → MFA → arrives sur l'app on-prem ✅

💡 Sign-in logs : Entra > Sign-in logs → tu vois les connexions à l'app on-prem comme n'importe quelle app cloud. Magie d'Entra : ton app legacy se comporte maintenant comme une app moderne aux yeux d'Entra.

🏢 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 : Hôpital régional — réseau de cliniques, conformité HIPAA/HDS

Contexte business : réseau de cliniques en croissance, mix de sites avec AD on-prem legacy et sites neufs sans AD. Les médecins itinérants accèdent au dossier patient (PHI) depuis tablettes 4G. Audit HDS imminent. Choix techniques : Conditional Access (granular) + Identity Protection (P2, risk-based) + PIM pour les admins SI + SSPR avec password writeback. Architecture / pattern :

• CAP 1 : "Apps cliniques + role=Médecin + device non compliant → Block"
• CAP 2 : "Sign-in risk = High → require MFA + password change" (via Identity Protection signal)
• CAP 3 : "Location hors France/UE → Block" pour les apps PHI
• PIM Eligible sur Global Admin, Privileged Role Admin, Security Admin : activation 4h max + MFA + justification ticket
• SSPR scopé All, writeback activé (les médecins ont des comptes hybrides synced depuis l'AD historique)
• 2 comptes break-glass exclus de toutes les CAPs, en AU Restricted Pièges à éviter :
• Démarrer une CAP directement en On sans phase Report-only → lockout des médecins en garde un samedi soir
• Oublier exclude break-glass sur la CAP "require MFA always" → si Microsoft Authenticator a une panne globale, tenant inaccessible
• Migrer en retard les legacy Identity Protection policies (User risk / Sign-in risk legacy) → coupées le 01/10/2026, recréer en CAP avec conditions de risque

Scenario 2 : Agence média/pub — collaboration intense avec freelances et clients

Contexte business : agence créative ~300 employés, travaille avec 800+ freelances ponctuels (graphistes, monteurs) et 50 clients qui doivent valider des assets dans Teams. Turnover externe énorme, accès qui restent ouverts éternellement = nightmare RGPD. Choix techniques : B2B Collaboration (invitation par projet) + Entitlement Management Access Packages + Access Reviews trimestriels + B2B Direct Connect pour les gros clients Entra. Architecture / pattern :

• Catalog External-Creatives géré par un Catalog Owner = Head of Production (pas IT)
• Access Package Freelance-Projet-X : ressources = groupe Security + site SharePoint + Adobe Enterprise app + expiration 90 jours auto, approver = chef de projet
• Freelance va sur myaccess.microsoft.com → request avec justif → onboarding self-service
• Access Reviews trimestriels sur les inactive users (no sign-in 30 jours) → auto-apply remove
• Pour les 3 plus gros annonceurs (eux-mêmes en Entra) : B2B Direct Connect → Teams Shared Channels sans guest user créé Pièges à éviter :
• Inviter les freelances un par un en B2B sans Entitlement → 6 mois après, 600 guests fantômes avec accès Salesforce
• Mettre un RG Azure dans un Access Package — non supporté, il faut passer par un Security Group avec RBAC dessus
• Activer B2B Direct Connect en espérant accéder à SharePoint ou Outlook → aujourd'hui supporte uniquement les Teams Shared Channels

Scenario 3 : Industrie aéronautique — modernisation app legacy sans VPN

Contexte business : équipementier aéro, 25k employés, portail RH SAP on-prem http://hr.acme.local accessible uniquement en VPN. Pendant le COVID, le VPN a saturé. Direction veut "Zero Trust" + suppression VPN pour les apps non-critiques. Choix techniques : Application Proxy + pre-authentication Entra ID + Conditional Access sur l'Enterprise App publiée + MIM pour la sync cert mgmt vers AD legacy. Architecture / pattern :

• 2 connectors (Microsoft Entra private network connector) sur 2 serveurs Windows membres dans 2 datacenters → Connector Group EU-DC (HA + routing géo)
• Outbound 443 vers Azure (déjà ouvert), aucun inbound firewall ouvert
• Publication app : Internal URL http://hr.acme.local → External URL https://hr-acme.msappproxy.net → pre-auth = Entra ID
• CAP sur l'Enterprise App SAP-HR-OnPrem : require MFA + compliant device
• MIM en arrière-plan pour synchroniser les certs SAP et faire SSPR vers AD legacy Pièges à éviter :
• Installer le connector directement sur le serveur SAP → en cas de patching SAP, le connector meurt = app inaccessible
• Choisir Passthrough au lieu de Microsoft Entra ID pre-auth → tu perds le bénéfice CAP/MFA, ton app legacy reste exposée sans Zero Trust
• Oublier la sync des users avant publication : Entra ne peut pas pre-authentifier des comptes qui n'existent pas (Connect Sync ou Cloud Sync requis en amont)

Scenario 4 : Fintech scale-up — apps legacy .NET 4 et migration cloud

Contexte business : fintech B2B (paiement marchand) achète une petite boîte qui a des apps .NET 4 et un SQL Server 2014 nécessitant un domain join AD classique. Pas envie de déployer un DC dans Azure ni de gérer un AD on-prem. Choix techniques : Entra Domain Services (managed AD DS) + PHS (Password Hash Sync) + Conditional Access sur les workloads modernes. Architecture / pattern :

• Managed Domain fintech.onmicrosoft.com déployé dans un VNet dédié vnet-aadds, subnet aadds-subnet sans NSG bloquant
• VNet de prod peered avec vnet-aadds → les VMs SQL + .NET joinent le managed domain
• DNS du VNet pointe vers les 2 IPs des DCs managés (sinon les VMs ne trouvent pas le domaine)
• Hashes Kerberos/NTLM activés → users doivent reset leur mdp une fois pour générer le hash
• PHS configuré (pas PTA, pas Federation) : si on-prem crash, login Azure continue Pièges à éviter :
• Croire qu'on peut écrire dans Entra DS et que ça remonte vers Entra ID — sync one-way uniquement, les OUs custom et GPO restent local au managed domain
• Mettre d'autres VMs dans le aadds-subnet → réservé Entra DS, comportement non supporté
• Activer Kerberos sans communiquer aux users qu'ils doivent reset leur mdp → tickets helpdesk en masse, Kerberos KO tant que pas de nouveau hash

Scenario 5 : Gouvernement / défense — accès séparé contractors vs employés

Contexte business : agence publique avec 5000 fonctionnaires + 1500 prestataires (ESN, consultants). Les prestataires changent constamment, exigence de revue d'accès semestrielle, séparation stricte des droits sensibles. Choix techniques : PIM for Groups + Access Reviews récurrents (recommandations ML via Entra ID Governance add-on) + Authentication Methods Policies modernes (FIDO2 obligatoire pour admins) + Authentication Strengths dans CAP. Architecture / pattern :

• Tous les rôles admin Entra et RBAC en PIM Eligible uniquement, activation 8h max, approbation par groupe Security-Approvers (pas une seule personne → vacances OK)
• Access Reviews semestriels sur tous les groupes contenant des prestataires : reviewer = manager + fallback = security team, auto-apply remove
• Auth Methods Policy : FIDO2 + Windows Hello obligatoire pour les groupes admins, SMS désactivé pour tous (SIM swap)
• CAP "admins → require Authentication Strength = Phishing-resistant MFA" (FIDO2 ou Windows Hello uniquement, pas Authenticator push) Pièges à éviter :
• Laisser des admins en Active permanent "parce que c'est plus simple" — vide tout l'intérêt de PIM, audit ANSSI ne passera pas
• Configurer encore les méthodes MFA dans Per-user MFA legacy → déprécié 30/09/2025, migrer vers Authentication methods > Policies
• Choisir un seul approver PIM individuel → s'il part en congés, blocage activation de rôles critiques (préférer un groupe d'approvers)