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 :

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.

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

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).

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).

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.

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).

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).

⚠️ Exception piège : les Security questions ne sont PAS encore migrables vers la nouvelle Authentication methods policy → elles restent gérables uniquement dans la legacy SSPR policy (Password reset > Authentication methods). Si tu les utilises, garde-les activées là-bas tant qu'un contrôle de migration n'est pas dispo.

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.

D. Entra ID Security

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

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.

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

Scenario 1 : Hôpital régional — réseau de cliniques, conformité HIPAA/HDS

Contexte business : cliniques en croissance, certains sites avec AD legacy, d'autres sans. Les médecins itinérants ouvrent le dossier patient (PHI) sur tablette 4G. Audit HDS imminent. Choix architectural : on verrouille les accès avec du Conditional Access fin, on détecte les comptes à risque avec Identity Protection (P2), on met les admins en PIM (accès temporaire), et on active le SSPR avec writeback vers l'AD. Architecture / pattern :

• CAP 1 : apps cliniques + rôle Médecin + appareil non conforme → Block.
• CAP 2 : risque de connexion élevé → exiger MFA + changement de mot de passe (signal Identity Protection).
• CAP 3 : connexion hors France/UE → Block sur les apps PHI.
• PIM sur Global Admin, Privileged Role Admin, Security Admin : activation 4h max, MFA + justification.
• SSPR pour tous, writeback activé (les médecins ont des comptes hybrides venus de l'AD).
• 2 comptes break-glass exclus de toutes les CAPs, en AU Restricted. Trade-offs assumés :
• Gain : accès aux données patient strictement contrôlé, conforme à l'audit.
• Perte : règles nombreuses à tester et maintenir, risque de blocage si mal réglées. Pièges à éviter :
• Passer une CAP en On sans phase Report-only → médecins de garde bloqués un samedi soir.
• Oublier d'exclure les break-glass d'une CAP "MFA always" → panne globale d'Authenticator = tenant inaccessible.
• Tarder à migrer les anciennes policies Identity Protection (User/Sign-in risk legacy) : coupées le 01/10/2026, à recréer en CAP avec conditions de risque.

📐 Réf. WAF — Security pillar (Identity & access management) : le risk-based Conditional Access, l'exclusion des emergency access accounts et le démarrage en report-only sont les recommandations Well-Architected pour la sécurité de l'identité. Lien

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

Contexte business : ~300 employés, 800+ freelances ponctuels et 50 clients qui valident des assets dans Teams. Le turnover externe est énorme et les accès jamais fermés = problème RGPD. Choix architectural : on invite les externes en B2B, on package leurs accès avec Entitlement Management (avec expiration auto), on fait le ménage via des Access Reviews trimestriels, et pour les gros clients déjà sur Entra on utilise B2B Direct Connect (sans créer de guest). Architecture / pattern :

• Catalogue External-Creatives géré par le Head of Production (pas l'IT).
• Access Package Freelance-Projet-X = groupe Security + site SharePoint + app Adobe, expiration 90 jours auto, approbation par le chef de projet.
• Le freelance va sur myaccess.microsoft.com, demande l'accès avec justif → onboarding en self-service.
• Access Reviews trimestriels sur les inactifs (pas de connexion depuis 30 jours) → suppression auto.
• Pour les 3 plus gros annonceurs (eux-mêmes sur Entra) : B2B Direct Connect → Teams Shared Channels sans guest créé. Trade-offs assumés :
• Gain : les accès externes s'ouvrent et se ferment seuls, fini les comptes fantômes.
• Perte : il faut concevoir et gouverner les catalogues/packages en amont. Pièges à éviter :
• Inviter les freelances un par un sans Entitlement → 6 mois plus tard, 600 guests fantômes avec accès Salesforce.
• Mettre un RG Azure dans un Access Package : non supporté → passer par un Security Group avec RBAC dessus.
• Attendre de B2B Direct Connect un accès SharePoint/Outlook : aujourd'hui il ne couvre que les Teams Shared Channels.

📐 Réf. — Microsoft Entra ID Governance : l'usage d'Entitlement Management (access packages, expiration auto) + Access Reviews récurrents pour gouverner les externes suit le pattern officiel de gouvernance du cycle de vie des accès. Lien

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

Contexte business : équipementier aéro (25k employés). Le portail RH SAP http://hr.acme.local n'est joignable qu'en VPN, qui a saturé pendant le COVID. Objectif : Zero Trust et fin du VPN pour les apps non critiques. Choix architectural : on publie l'app via Application Proxy avec pré-authentification Entra ID, on la protège par Conditional Access, et MIM synchronise les certs/SSPR vers l'AD legacy. Architecture / pattern :

• 2 connectors sur 2 serveurs Windows dans 2 datacenters → Connector Group EU-DC (HA + routage géo).
• Seul l'outbound 443 vers Azure est utilisé (déjà ouvert) ; aucun port entrant n'est ouvert sur le firewall.
• Publication : URL interne http://hr.acme.local → URL externe https://hr-acme.msappproxy.net, pré-auth = Entra ID.
• CAP sur l'Enterprise App SAP-HR-OnPrem : exiger MFA + appareil conforme.
• MIM en fond pour synchroniser les certs SAP et faire le SSPR vers l'AD legacy. Trade-offs assumés :
• Gain : app legacy exposée en sécurité, sans VPN ni port entrant ouvert.
• Perte : connectors à héberger et patcher, dépendance à leur disponibilité. Pièges à éviter :
• Installer le connector sur le serveur SAP lui-même → un patch SAP tue le connector = app injoignable.
• Choisir Passthrough au lieu de Microsoft Entra ID en pré-auth → on perd CAP/MFA, l'app reste exposée sans Zero Trust.
• Oublier de synchroniser les users avant publication : Entra ne peut pas pré-authentifier des comptes inexistants (Connect Sync ou Cloud Sync requis en amont).

📐 Réf. — Application Proxy & Zero Trust (remote access) : publier une app on-prem sans VPN avec pre-auth Entra + CAP est le pattern recommandé pour appliquer Zero Trust aux apps legacy (secure remote access). Lien