Ce que vous saurez faire
- Comparer Entra Connect Sync (agent lourd) et Cloud Sync (agent léger) et choisir selon le contexte.
- Expliquer les trois méthodes d'authentification hybride : PHS, PTA, Federation (ADFS), avec leurs dépendances.
- Décrire le Seamless SSO et ses prérequis.
- Identifier la source de vérité d'un objet (on-prem vs cloud) et les conséquences sur sa gestion.
- Trancher hybride vs cloud-only à l'aide d'un arbre de décision.
Compétences transférées depuis l'AD classique
| L'admin AD réutilise | L'admin AD doit désapprendre |
|---|---|
| Maîtrise de l'AD source (users, attributs, UPN) | « Tout se gère sur le DC » — une partie bascule dans le cloud |
| Compréhension de Kerberos / NTLM | « L'auth se fait toujours en interne » — PHS valide dans le cloud |
| Notion de fédération / ADFS si déjà déployé | « ADFS est obligatoire » — PHS suffit dans la majorité des cas |
Fondamentaux hybride / cloud
1. Pourquoi l'hybride existe
La plupart des organisations ne basculent pas d'un coup. Elles gardent leur AD DS on-prem (qui authentifie encore les postes joints au domaine, les partages, les apps legacy) et utilisent Entra ID pour M365 et le SaaS. L'hybride fait coexister les deux en synchronisant les identités de l'AD vers Entra.
Votre AD reste la source pour les objets internes.
Reçoit une copie synchronisée des utilisateurs et groupes pour les services cloud.
2. Entra Connect Sync vs Cloud Sync
Deux moteurs pour synchroniser AD DS → Entra. Le choix impacte la topologie que vous pourrez couvrir.
| Entra Connect Sync (agent lourd) | Entra Cloud Sync (agent léger) | |
|---|---|---|
| Où tourne le moteur | Serveur Windows dédié on-prem (+ SQL/LocalDB) | Léger agent(s) on-prem, logique dans le cloud |
| Topologies complexes | ✅ (filtrage avancé, attributs étendus, writeback) | Limité (mais s'améliore) |
| Multi-forêts | ✅ | ✅ (plusieurs agents) |
| Résilience | 1 serveur actif (+ staging) | Plusieurs agents = tolérance native |
| Écriture inverse | Password, device, group writeback | Password writeback (selon évolutions) |
| Maintenance | À votre charge (mises à jour du serveur) | Allégée (logique côté Microsoft) |
| Recommandation Microsoft | Scénarios avancés / existants | Nouveaux déploiements simples |
Il n'y a pas de « sync annuaire → cloud » dans un AD isolé. Le plus proche conceptuellement : un connecteur MIM/FIM sur mesure.
3. Méthodes d'authentification
Password Hash Sync (PHS) — le défaut recommandé
- Un hash du hash du mot de passe AD est synchronisé vers Entra.
- L'authentification est validée dans le cloud (Entra), sans contacter l'AD.
- Avantages : simple, résilient (fonctionne même si l'on-prem est down), prérequis d'Identity Protection.
Pass-through Authentication (PTA)
- Le mot de passe est validé en temps réel par l'AD on-prem via des agents PTA.
- Aucun hash stocké dans le cloud.
- Dépendance : les agents PTA (et donc l'on-prem) doivent être disponibles pour se connecter.
Federation (ADFS)
- L'authentification est déléguée à une infrastructure ADFS on-prem (ou tierce).
- La plus lourde à opérer (serveurs ADFS, WAP, certificats, haute dispo).
- Justifiée seulement par des exigences spécifiques (carte à puce complexe, règles de claim très fines).
| Critère | PHS | PTA | Federation (ADFS) |
|---|---|---|---|
| Validation du mot de passe | Cloud | On-prem (agents) | On-prem (ADFS) |
| Résiste à une panne on-prem | ✅ | ❌ | ❌ |
| Complexité | Faible | Moyenne | Élevée |
| Prérequis Identity Protection | ✅ | Partiel | Partiel |
| Recommandation | Par défaut | Si hash cloud interdit | Cas spécifiques |
Votre PME n'a aucune contrainte réglementaire sur le stockage de hash de mots de passe. Quelle méthode d'authentification choisir en priorité ?
C'est le défaut recommandé par Microsoft : simple à opérer, résilient à une panne on-prem, et prérequis d'Identity Protection pour la détection de fuite de mots de passe. PTA ne se justifie que si une politique interne interdit le stockage du hash dans le cloud ; ADFS uniquement pour des cas très spécifiques.
Associer chaque concept AD DS à son pendant hybride/cloud
4. Seamless SSO
Seamless Single Sign-On (SSSO) permet aux utilisateurs sur un poste joint au domaine AD, sur le réseau d'entreprise, de s'authentifier à Entra sans ressaisir leur mot de passe (ticket Kerberos en coulisse). Il complète PHS ou PTA (inutile avec Federation, qui gère le SSO autrement).
Le SSO intranet via Kerberos vous est familier.
SSSO réutilise ce principe pour les apps cloud, tant que le poste est joint AD.
Attendre du SSSO qu'il fonctionne pour des postes joints Entra ou hors réseau. Il s'adresse aux postes joints AD DS sur le réseau interne. Pour les postes joints Entra, le SSO est natif via PRT.
5. Arbre de décision : hybride ou cloud-only ?
Un critère est décisif : la présence d'une dépendance persistante à l'AD DS (poste, serveur, application). Tant qu'elle existe, l'hybride est incontournable.
Règles de lecture :
- Postes/apps encore liés à l'AD DS → hybride obligatoire (pour l'instant).
- Rien ne dépend plus de l'AD DS → viser cloud-only (cible du projet, à terme).
- PHS par défaut ; PTA seulement si une politique interdit le hash dans le cloud ; ADFS en dernier recours.
Sources Microsoft Learn
- Choisir une méthode d'authentification
- Entra Cloud Sync — vue d'ensemble
- Password Hash Sync
- Pass-through Authentication
- Seamless SSO
Rappel : en cas d'écart entre ce support et le portail, le portail fait foi.
Lire l'état de synchronisation et décider
Partie A — Lire l'état de synchronisation (30 min)
1. Vérifier si la sync est activée
Portail : Entra admin center > Identity > Hybrid management > Microsoft Entra Connect
Sur un tenant dev neuf, la sync est désactivée (pas d'AD source). Constatez le statut et repérez l'emplacement.
2. Distinguer un objet cloud d'un objet synchronisé
Portail : Entra admin center > Users > [un user] > Propriétés > On-premises
Les users seedés au module 01/02 sont cloud-only. En prod hybride, certains seraient marqués « synchronisés depuis on-premises ».
3. En PowerShell
Connect-MgGraph -Scopes "Directory.Read.All","User.Read.All"
./scripts/03-sync-status.ps1Le script affiche l'état global de la synchronisation d'annuaire et répartit les utilisateurs cloud-only vs synchronisés.
Partie B — Appliquer l'arbre de décision (40 min)
Pour chacun des deux scénarios, décidez : hybride ou cloud-only ?, quel moteur de sync ?, quelle méthode d'auth ? Justifiez avec l'arbre du cours.
Scénario 1 — L'éditeur de logiciels (votre PME)
- 30 postes récents, aucun serveur de fichiers legacy indispensable (partages migrables).
- Une app interne encore authentifiée en LDAP contre l'AD.
- Pas de contrainte réglementaire sur le stockage de hash.
Scénario 2 — Filiale avec contrainte réglementaire
- Politique interne : interdiction de stocker tout hash de mot de passe hors du SI on-prem.
- Postes joints au domaine, présence forte sur le réseau interne.
Partie C — Restitution (20 min)
Comparez vos décisions avec le corrigé de l'évaluation. Identifiez ce qui, dans votre SI réel, empêche aujourd'hui le cloud-only (liste des dépendances AD DS restantes).
5 réflexes AD à corriger
Testez vos acquis
Une évaluation interactive qui vous donne le badge Acquis (≥60%) ou Maîtrisé (≥80%).
Cas pratique — Migration de votre PME
Contexte : votre PME (éditeur de logiciels) a 30 postes récents, une application interne encore authentifiée en LDAP contre l'AD, des partages réseau migrables vers SharePoint, et aucune contrainte réglementaire sur le stockage de hash.
Questions :
- Faut-il partir en hybride ou cloud-only aujourd'hui ? Justifiez avec l'arbre de décision.
- Quel moteur de synchronisation et quelle méthode d'authentification recommandez-vous ?
- Quelle condition permettrait de passer en cloud-only plus tard ?
Démarche attendue
- Hybride aujourd'hui. L'application interne en LDAP dépend de l'AD DS : tant qu'elle n'est pas remplacée ou réauthentifiée, l'AD doit rester, donc synchronisation vers Entra. L'arbre tranche « hybride » dès qu'une app ou un poste doit rester joint à l'AD.
- Sync : Cloud Sync (besoin simple, PME, pas de topologie exotique) ; auth : PHS (pas de contrainte de hash, résilience à une panne on-prem, prérequis d'Identity Protection) ; ajouter Seamless SSO pour les postes encore joints AD.
- Condition du cloud-only : avoir éliminé la dernière dépendance AD DS — ici, migrer ou réécrire l'app LDAP (ou la basculer sur OIDC/SAML) et finir la migration des partages vers SharePoint/OneDrive. Une fois ces dépendances levées, décommissionner l'AD (module 08).