$course$/Formation Entra ID - Atoo Next Formation De l'admin AD a l'admin Microsoft 365 / Entra ID $course$/Formation Entra ID - Atoo Next/Module 01 - Évaluation — Fondamentaux Module 01 - q1 Un collègue affirme : « Entra ID, c'est juste notre AD hébergé chez Microsoft. » Que répondez-vous ?

]]> Entra ID est un IdP (fournisseur d'identité) qui parle des protocoles web modernes. Il n'a ni LDAP, ni Kerberos, ni OU, ni GPO. Le modèle mental doit changer, pas seulement les outils.

Ref: Section 1 — AD DS vs Entra ID

]]> 1 0.3333333 0 true true abc Module 01 - q2 Dans Entra ID, comment applique-t-on une configuration à un sous-ensemble d'utilisateurs ?

]]> On cible par groupes (assignés ou dynamiques). Les politiques CA, les profils Intune, les attributions de licences, tout se pilote par groupe.

Ref: Section 1 — Structure plate

]]> 1 0.3333333 0 true true abc Module 01 - q3 À quoi sert un enregistrement DNS TXT lors de l'ajout d'un domaine personnalisé ?

]]> Le TXT prouve la possession du domaine public. Microsoft vérifie qu'il est là (donc que vous contrôlez la zone DNS), et vous pouvez alors utiliser ce domaine pour vos UPN et adresses mail.

Ref: Section 2 — Domaines vérifiés

]]> 1 0.3333333 0 true true abc Module 01 - q4 Quelles fonctionnalités nécessitent Entra ID P2 (et pas seulement P1) ? (plusieurs)

]]> PIM, Identity Protection et Access Reviews sont les trois piliers P2. Le CA de base est P1 (mais son intégration avec le risque nécessite P2 pour les risk-based policies).

Ref: Section 3 — Licences

]]> 1 0.3333333 0 false true abc Module 01 - q5 Un domaine interne AD nommé contoso.local peut-il être vérifié comme domaine personnalisé dans Entra ?

]]> Un domaine non routable publiquement (comme .local) ne peut pas être prouvé. Entra exige un domaine public dont vous contrôlez la zone DNS. Anticiper le décalage UPN interne ↔ adresse mail dans les scénarios hybrides.

Ref: Section 2 + Piège 3

]]> 1 0.3333333 0 true true abc Module 01 - q6 Où configure-t-on le Conditional Access et le PIM ?

]]> CA, PIM et Identity Protection sont toutes dans entra.microsoft.com. Règle de mémoire : sécurité / identité avancée = entra.microsoft.com.

Ref: Section 5 — Les 4 portails

]]> 1 0.3333333 0 true true abc Module 01 - q7 Qu'est-ce qu'une unité administrative (AU) dans Entra ?

]]> Les AU servent à déléguer l'administration à un scope réduit (un service, une filiale). Elles ne portent aucune configuration comme le ferait une OU liée à une GPO.

Ref: Section 1 + Piège 2

]]> 1 0.3333333 0 true true abc Module 01 - q8 « Entra Domain Services » et « Entra ID », c'est :

]]> Entra Domain Services (ex-Azure AD DS) est un domaine géré dans Azure pour les apps legacy nécessitant LDAP/Kerberos/GPO. Entra ID est l'IdP cloud. Piège de nommage classique.

Ref: Section 1 — Encadré Entra Domain Services

]]> 1 0.3333333 0 true true abc Module 01 - q9 Dans l'écosystème M365, quel élément fournit la conformité d'appareil consommée par le Conditional Access ?

]]> Intune évalue la conformité d'appareil (chiffrement, version OS, etc.). Le CA la consomme comme signal via la condition « require compliant device ».

Ref: Section 4 — Écosystème

]]> 1 0.3333333 0 true true abc Module 01 - q10 Vous voulez inventorier par script les licences d'un tenant. Quel module PowerShell utilisez-vous ?

]]> Microsoft.Graph est le SDK moderne. Get-MgSubscribedSku liste les SKU (licences) du tenant. C'est le successeur unifié de MSOnline et AzureAD, tous deux dépréciés.

Ref: Section 5 — Portails et Graph

]]> 1 0.3333333 0 true true abc $course$/Formation Entra ID - Atoo Next/Module 02 - Évaluation — Identités Entra Module 02 - q1 Vous devez donner à un prestataire externe l'accès à un site SharePoint, sans lui créer de compte interne. Quel mécanisme ?

]]> Le B2B invite une identité externe existante par email. Le prestataire reste géré par son organisation d'origine ; on peut le retirer facilement en fin de collaboration.

Ref: Section 1 — Utilisateurs / B2B

]]> 1 0.3333333 0 true true abc Module 02 - q2 Un groupe doit contenir automatiquement tous les utilisateurs du service Commercial. Quel type de groupe ?

]]> Un groupe dynamique avec règle (user.department -eq "Commercial") maintient automatiquement l'appartenance à jour. Nécessite Entra ID P1 (inclus dans E3+P2).

Ref: Section 2 — Groupes dynamiques

]]> 1 0.3333333 0 true true abc Module 02 - q3 Vrai ou faux : être Global Administrator (rôle Entra) donne automatiquement les droits Owner sur les souscriptions Azure.

]]> C'est l'erreur n°1. Les deux plans sont isolés : Global Admin (Entra) ne donne aucun droit sur les VM ; Owner d'une souscription (RBAC Azure) ne donne aucun pouvoir Entra.

Ref: Section 3 — Rôles Entra vs RBAC

]]> 1 0.3333333 0 true true abc Module 02 - q4 Pour donner à une équipe un espace collaboratif avec site SharePoint et boîte partagée, quel objet créez-vous ?

]]> Un M365 Group crée automatiquement site SharePoint, boîte partagée, et peut être teamifié. Règle : collaboration = M365 Group ; accès = groupe de sécurité.

Ref: Section 2 — M365 Group

]]> 1 0.3333333 0 true true abc Module 02 - q5 Un script non interactif doit lire l'annuaire toutes les nuits. Quelle identité ?

]]> Service principal (avec certificat de préférence, pas secret) ou managed identity si le script tourne sur Azure. Aucun secret exposé côté managed identity.

Ref: Section 4 — Service principals

]]> 1 0.3333333 0 true true abc Module 02 - q6 Quelle affirmation sur les groupes dynamiques est correcte ?

]]> Le type (assigné/dynamique) et la portée (user/device) sont figés à la création. Pour un ajout manuel ponctuel, prévoir un groupe assigné.

Ref: Section 2 — Contraintes

]]> 1 0.3333333 0 true true abc Module 02 - q7 Où attribue-t-on le rôle Contributor sur un resource group Azure ?

]]> RBAC Azure se configure dans le portail Azure, section IAM (Identity and Access Management) de la ressource ciblée. Le scope peut être management group, souscription, resource group ou ressource.

Ref: Section 3 — RBAC

]]> 1 0.3333333 0 true true abc Roles & admins]]> (ressource) > Access control (IAM)]]> Roles]]> Module 02 - q8 Quelle est la différence entre app registration et enterprise application ?

]]> App registration = le « modèle » ; enterprise application = l'instance (avec son service principal) dans votre tenant. Une app tierce peut n'avoir qu'une enterprise application (venue de la galerie), sans app registration locale.

Ref: Section 4 — Apps

]]> 1 0.3333333 0 true true abc Module 02 - q9 SCIM sert principalement à :

]]> SCIM automatise le cycle de vie : quand l'utilisateur rejoint un groupe, son compte est créé côté app. Quand il quitte, le compte est désactivé.

Ref: Section 5 — Provisioning

]]> 1 0.3333333 0 true true abc Module 02 - q10 Un compte est synchronisé depuis l'AD on-prem. Où corrigez-vous son department ?

]]> Règle de la source de vérité : pour un objet synchronisé, l'AD DS est maître. Vérifier onPremisesSyncEnabled avant toute modification.

Ref: Section 1 + Piège 5

]]> 1 0.3333333 0 true true abc $course$/Formation Entra ID - Atoo Next/Module 03 - Évaluation — Hybride vs Cloud-only Module 03 - q1 Quelle méthode d'authentification hybride valide le mot de passe **dans le cloud** ?

]]> PHS synchronise un hash du hash du mot de passe vers Entra ID. C'est donc Entra qui valide la connexion, dans le cloud — méthode recommandée par Microsoft pour la majorité des cas.

Ref: Section 3 — Méthodes d'authentification

]]> 1 0.3333333 0 true true abc Module 03 - q2 Un incident coupe l'accès à l'AD on-prem. Avec quelle méthode les utilisateurs peuvent **encore** se connecter à M365 ?

]]> Seul PHS valide dans le cloud : le hash est stocké côté Entra, la connexion aboutit même si l'AD on-prem est indisponible. C'est un argument fort de résilience.

Ref: Section 3 — PHS

]]> 1 0.3333333 0 true true abc Module 03 - q3 Pour un nouveau déploiement simple, quel moteur de synchronisation Microsoft recommande-t-il en premier examen ?

]]> Cloud Sync : agent léger, logique dans le cloud, tolérance de panne native (plusieurs agents), maintenance réduite. Microsoft le positionne comme le choix par défaut pour les nouveaux déploiements simples.

Ref: Section 2 — Connect vs Cloud Sync

]]> 1 0.3333333 0 true true abc Module 03 - q4 Le Seamless SSO s'adresse en priorité à :

]]> SSSO cible les postes joints AD DS sur le réseau interne. Il réutilise le ticket Kerberos pour éviter la re-saisie de mot de passe côté Entra.

Ref: Section 4 — Seamless SSO

]]> 1 0.3333333 0 true true abc Module 03 - q5 Vrai/Faux : ADFS est obligatoire pour synchroniser un AD vers Entra.

]]> ADFS n'est pas obligatoire. PHS ou PTA suffisent dans l'immense majorité des cas. ADFS n'est justifié que par des exigences spécifiques : claims complexes, carte à puce avancée, dépendance existante.

Ref: Section 3 — Federation

]]> 1 0.3333333 0 true true abc Module 03 - q6 Un objet utilisateur est **synchronisé** depuis l'AD. Où modifiez-vous son nom d'affichage ?

]]> Règle de la source de vérité : pour un objet synchronisé, l'AD DS est maître. La modification cloud est écrasée. Vérifier onPremisesSyncEnabled avant toute action.

Ref: Section 1 + Piège 3

]]> 1 0.3333333 0 true true abc Module 03 - q7 Quel est un prérequis fonctionnel de la détection « identifiants divulgués » d'Identity Protection en contexte hybride ?

]]> Identity Protection compare les hashs stockés côté Entra avec les bases publiques de credentials fuités. PHS est donc requis pour que la fonctionnalité soit pleinement opérationnelle.

Ref: Section 3 — PHS

]]> 1 0.3333333 0 true true abc Module 03 - q8 Quel avantage majeur du Cloud Sync par rapport au Connect Sync ?

]]> Cloud Sync : plusieurs agents actifs simultanément (résilience native, pas de mode staging à basculer manuellement), logique côté Microsoft (maintenance allégée).

Ref: Section 2

]]> 1 0.3333333 0 true true abc Module 03 - q9 Une organisation n'a plus aucune dépendance à l'AD DS (partages migrés, pas d'app LDAP). Vers quoi doit-elle tendre ?

]]> Cloud-only : moins de surface d'administration, alignement Zero Trust, plus de dépendance à l'infrastructure on-prem. Voir module 08 pour le plan de décommission de l'AD.

Ref: Section 5 — Arbre de décision

]]> 1 0.3333333 0 true true abc Module 03 - q10 PTA implique quelle dépendance de disponibilité ?

]]> PTA valide en temps réel via les agents PTA connectés à l'AD on-prem : si l'on-prem est indisponible, l'auth échoue. C'est la contrepartie du fait de ne pas stocker le hash dans le cloud.

Ref: Section 3 — PTA

]]> 1 0.3333333 0 true true abc $course$/Formation Entra ID - Atoo Next/Module 04 - Évaluation — Conditional Access Module 04 - q1 Dans quel état crée-t-on **toujours** une nouvelle politique CA en premier ?

]]> Report-only permet d'évaluer la politique sans l'appliquer. Les sign-in logs indiquent ce qu'elle aurait fait — de quoi valider avant de passer en On. C'est le premier des 3 garde-fous obligatoires.

Ref: Section 5 — Déploiement sûr

]]> 1 0.3333333 0 true true abc Module 04 - q2 À quoi servent les comptes break-glass ?

]]> Break-glass = 2 comptes Global Admin cloud-only, mot de passe long, exclus de toutes les politiques CA, documentés hors ligne et surveillés par alerte. Filet de sécurité en cas de panne MFA / CA.

Ref: Section 5 + Piège 2

]]> 1 0.3333333 0 true true abc Module 04 - q3 Quel contrôle bloque les protocoles qui ne supportent pas la MFA (POP, IMAP, SMTP AUTH) ?

]]> Politique CA « Block legacy authentication » (client apps = Exchange ActiveSync + Other clients). Ces protocoles ne portent pas la MFA — les laisser ouverts contourne toute votre stratégie MFA.

Ref: Section 6 + Piège 5

]]> 1 0.3333333 0 true true abc Module 04 - q4 L'exigence « appareil conforme » dans une politique CA s'appuie sur :

]]> La conformité est évaluée par Intune (module 06) selon des politiques de conformité que vous définissez (chiffrement disque, code PIN, OS à jour...). Le CA consomme ce signal via « Require device to be marked as compliant ».

Ref: Section 3

]]> 1 0.3333333 0 true true abc Module 04 - q5 À quoi sert l'outil **What If** ?

]]> What If simule à froid : pour un utilisateur donné, sur une app donnée, dans un contexte donné (plateforme, emplacement, client app, risque), il liste les politiques qui s'appliqueraient et le résultat attendu.

Ref: Section 5

]]> 1 0.3333333 0 true true abc Module 04 - q6 Une politique « MFA pour tous » passée directement en **On** sans exclusion, alors que la MFA n'est pas encore enrôlée partout, produit quel risque ?

]]> Si un admin n'est pas enrôlé MFA et qu'aucun break-glass n'est exclu de la politique, personne ne peut plus entrer pour corriger. C'est pour ça que les 3 garde-fous (report-only, What If, break-glass) sont non négociables.

Ref: Piège 1 + Piège 2

]]> 1 0.3333333 0 true true abc Module 04 - q7 Le geo-blocking seul est-il une protection suffisante ?

]]> La géolocalisation est un signal parmi d'autres, pas une barrière. Elle ajoute de la friction pour un attaquant occasionnel, mais ne bloque pas un attaquant motivé. La défense repose sur la combinaison MFA + appareil conforme + blocage legacy + geo.

Ref: Section 3 + Piège 3

]]> 1 0.3333333 0 true true abc Module 04 - q8 Quels éléments composent les **affectations** d'une politique CA ? (plusieurs)

]]> Les affectations = users/groups/roles + cloud apps ou actions + conditions (plateforme, emplacement, client app, état de l'appareil, risque). Ce sont les 3 volets du SI de la politique.

Ref: Section 2

]]> 1 0.3333333 0 false true abc Module 04 - q9 Les conditions **basées sur le risque** (risque de connexion / utilisateur) exigent quelle licence ?

]]> Les conditions basées sur le risque (Identity Protection) exigent Entra ID P2. Elles sont couvertes en détail au module 07.

Ref: Section 2 + Lab licences

]]> 1 0.3333333 0 true true abc Module 04 - q10 En E3+P2, que fait-on généralement des **Security Defaults** ?

]]> Security Defaults = mode simplifié destiné aux petits tenants sans P1. Dès qu'on a P1/P2, on les désactive pour piloter finement via CA (granularité utilisateur/app/condition, report-only, exclusions).

Ref: Section 6

]]> 1 0.3333333 0 true true abc $course$/Formation Entra ID - Atoo Next/Module 05 - Évaluation — PIM & Gouvernance Module 05 - q1 Un rôle **éligible** dans PIM signifie :

]]> Éligible = capacité d'activer le rôle temporairement. Au repos, aucun privilège n'est porté. C'est le coeur du Just-In-Time.

Ref: Section 2 — Éligibles vs actifs

]]> 1 0.3333333 0 true true abc Module 05 - q2 Quel est l'intérêt de sécurité de rendre un admin **éligible** plutôt qu'**actif permanent** ?

]]> Le compte éligible n'a aucun droit au repos. L'attaquant qui le compromet ne récupère rien tant qu'il n'active pas le rôle — activation qui exige MFA, justification, approbation, et n'est valable qu'un temps limité.

Ref: Section 1 + Section 2

]]> 1 0.3333333 0 true true abc Module 05 - q3 Quels contrôles PIM peut-il imposer à l'activation ? (plusieurs)

]]> PIM combine ces 4 contrôles au moment de l'activation, plus éventuellement un numéro de ticket. Tout est tracé — audit natif.

Ref: Section 3

]]> 1 0.3333333 0 false true abc Module 05 - q4 À quoi sert une **Access Review** ?

]]> Access Review = revue périodique planifiée d'un rôle, groupe, app ou des invités. Peut auto-appliquer la révocation. C'est l'antidote au privilege creep.

Ref: Section 4

]]> 1 0.3333333 0 true true abc Module 05 - q5 Quelle licence est nécessaire pour PIM et les Access Reviews ?

]]> PIM, Access Reviews et Entitlement Management sont tous inclus dans Entra ID P2 (dans la cible E3 + P2).

Ref: Section 1 + Positionnement

]]> 1 0.3333333 0 true true abc Module 05 - q6 Un **access package** (Entitlement Management) permet :

]]> Un access package regroupe groupes, apps, sites SharePoint. Publié dans un catalogue, il peut être demandé en self-service, avec workflow d'approbation, durée et revue. Idéal pour l'onboarding et le B2B.

Ref: Section 5

]]> 1 0.3333333 0 true true abc Module 05 - q7 Après activation d'un rôle avec une durée max de 4h, que se passe-t-il ?

]]> L'expiration est automatique : la fenêtre d'exposition est bornée dans le temps. Si l'admin a encore besoin du rôle, il refait une activation (nouvelle MFA + justification + approbation).

Ref: Section 3

]]> 1 0.3333333 0 true true abc Module 05 - q8 Le principal ennemi que la gouvernance des identités combat est :

]]> Privilege creep : accumulation silencieuse d'accès qui ne sont jamais retirés (changement de poste, projet fini, congés prolongés). Les Access Reviews avec auto-apply sont l'antidote.

Ref: Section 4 + Piège 3

]]> 1 0.3333333 0 true true abc Module 05 - q9 Vrai / Faux : avec PIM, on devrait viser un maximum d'assignations **actives permanentes** sur Global Admin pour la commodité.

]]> Cible : 0 (ou 1-2 max) actifs permanents sur Global Admin. Tout le reste bascule en éligible. C'est le sens même du Just-In-Time.

Ref: Section 2 + Piège 1

]]> 1 0.3333333 0 true true abc Module 05 - q10 Un access package peut inclure :

]]> Un access package regroupe des ressources hétérogènes (groupes + apps + sites SharePoint) publiées dans un catalogue, gouvernées par un workflow commun.

Ref: Section 5

]]> 1 0.3333333 0 true true abc $course$/Formation Entra ID - Atoo Next/Module 06 - Évaluation — Intune / MDM Module 06 - q1 Quelle différence fondamentale entre GPO et Intune ?

]]> GPO = push, LAN, ciblage OU. Intune = pull, HTTPS Internet, ciblage par groupe. Deux mécaniques radicalement différentes — d'où les principaux pièges de migration.

Ref: Section 1

]]> 1 0.3333333 0 true true abc Module 06 - q2 L'équivalent de `gpupdate /force` en MDM est :

]]> La sync est initiée côté client (Paramètres > Accès professionnel > Sync) ou côté portail (action Sync sur l'appareil). L'application n'est jamais instantanée : compter jusqu'à quelques minutes.

Ref: Section 1 + Piège 1

]]> 1 0.3333333 0 true true abc Module 06 - q3 Windows Autopilot sert à :

]]> Autopilot : le poste part du Windows OEM. Au premier démarrage, il joint Entra, s'enrôle Intune, télécharge apps + politiques. Zéro image, zéro touche IT sur place.

Ref: Section 2

]]> 1 0.3333333 0 true true abc Module 06 - q4 Une politique de conformité Intune, seule, fait quoi ?

]]> Séparation étanche : Intune étiquette (compliant / non-compliant), CA décide (require compliant device). L'un sans l'autre ne protège pas.

Ref: Section 3 + Piège 4

]]> 1 0.3333333 0 true true abc Module 06 - q5 Quel type de profil Intune est le plus direct pour rejouer des réglages type GPO ?

]]> Settings Catalog : catalogue exhaustif de milliers de paramètres OS, présentation par domaine (Device Lock, Firewall, Update...). Le plus proche des ADMX et le plus riche.

Ref: Section 4

]]> 1 0.3333333 0 true true abc Module 06 - q6 Pour importer les paramètres ADMX d'un navigateur tiers dans Intune, on utilise :

]]> Import ADMX (Ingested ADMX) permet d'apporter les fichiers .admx d'un navigateur tiers ou d'une app métier dans Intune, puis d'assigner ces réglages via un profil.

Ref: Section 4

]]> 1 0.3333333 0 true true abc Module 06 - q7 Le ciblage d'un profil Intune se fait par :

]]> Ciblage par groupe (souvent dynamique par OS / service). Les groupes remplacent l'arborescence OU comme unité d'assignation.

Ref: Section 1 + Piège 2

]]> 1 0.3333333 0 true true abc Module 06 - q8 Une application « classique » (ex : un MSI packagé) se déploie dans Intune comme :

]]> Le format Win32 (.intunewin) empaquète un .msi ou .exe avec le Content Prep Tool. Il est le format le plus polyvalent pour les apps classiques.

Ref: Section 5

]]> 1 0.3333333 0 true true abc Module 06 - q9 Que remplace, côté migration, une GPO BitLocker ?

]]> Profil Endpoint protection / Disk encryption dans Intune (avec ses options TPM, PIN, méthodes d'escrow des clés). Souvent combiné à une exigence BitLocker dans la politique de conformité.

Ref: Section 6

]]> 1 0.3333333 0 true true abc Module 06 - q10 Faut-il migrer toutes les GPO 1:1 vers Intune ?

]]> La migration Intune est l'occasion d'un audit : Group Policy Analytics mesure la couverture, on trie l'obsolète, on priorise sécurité / conformité. Un projet de migration n'est pas un copier-coller.

Ref: Section 6 + Piège 3

]]> 1 0.3333333 0 true true abc $course$/Formation Entra ID - Atoo Next/Module 07 - Évaluation — Zero Trust & Sécurité Module 07 - q1 Quel présupposé du modèle AD classique le Zero Trust rejette-t-il ?

]]> Zero Trust renverse la confiance implicite au périmètre réseau : dès qu'on est sur le LAN, on n'est plus « à l'intérieur ». Chaque accès doit être vérifié explicitement, indépendamment de la localisation réseau.

Ref: Section 1

]]> 1 0.3333333 0 true true abc Module 07 - q2 Les trois principes Zero Trust sont :

]]> Verify explicitly (tous les signaux, à chaque accès) + Least privilege (JIT / JEA, PIM) + Assume breach (limiter le rayon d'explosion). Ces principes structurent le mapping vers les briques Entra.

Ref: Section 1

]]> 1 0.3333333 0 true true abc Module 07 - q3 Le **risque de connexion** (sign-in risk) évalue :

]]> Sign-in risk = « cette connexion, ici, maintenant, est-elle suspecte ? ». User risk = « ce compte est-il probablement compromis dans la durée ? ». Deux signaux distincts, deux politiques distinctes.

Ref: Section 2

]]> 1 0.3333333 0 true true abc Module 07 - q4 Avant d'activer une **user risk policy** qui exige un changement de mot de passe, quel prérequis ?

]]> SSPR permet à l'utilisateur à risque de changer lui-même son mot de passe (self-remediation) sans passer par le helpdesk. Sans SSPR, il est bloqué et génère un ticket.

Ref: Section 2 + Piège 2

]]> 1 0.3333333 0 true true abc Module 07 - q5 Quelle méthode d'authentification est la plus faible et à retirer en priorité ?

]]> Le SMS est vulnérable au SIM swapping et à l'interception. Il reste utile en secours très encadré, mais c'est la méthode à retirer en priorité pour aller vers le passwordless.

Ref: Section 3 + Piège 3

]]> 1 0.3333333 0 true true abc Module 07 - q6 Le **number matching** dans Authenticator sert à :

]]> MFA fatigue : l'attaquant qui a le mot de passe spamme des notifications push jusqu'à ce que la victime approuve par lassitude. Le number matching force à saisir un chiffre affiché à l'écran de connexion — impossible sans voir cet écran.

Ref: Section 3

]]> 1 0.3333333 0 true true abc Module 07 - q7 Defender for Identity (MDI) en E3+P2 :

]]> MDI est à connaître (vocabulaire, attaques on-prem) mais hors périmètre déployable en E3+P2. L'alternative repose sur Identity Protection (côté cloud) et les logs Entra (module 09). Réduire l'AD DS réduit d'autant le besoin de MDI.

Ref: Section 4 + Piège 4

]]> 1 0.3333333 0 true true abc Module 07 - q8 La détection « identifiants divulgués » en contexte hybride suppose :

]]> Identity Protection compare le hash stocké côté Entra avec des bases publiques de credentials fuités. En hybride, cela suppose PHS (module 03). Sans PHS, la détection « leaked credentials » n'est pas pleinement opérationnelle.

Ref: Section 2 + Module 03

]]> 1 0.3333333 0 true true abc Module 07 - q9 « Zero Trust » est :

]]> Zero Trust s'assemble : Conditional Access + PIM + Intune (conformité poste) + Identity Protection + supervision (logs, alertes, module 09). Aucun SKU ne le remplace ; aucune brique seule ne le fournit.

Ref: Section 1 + Piège 1

]]> 1 0.3333333 0 true true abc Module 07 - q10 Empiler plusieurs méthodes MFA faibles « pour la disponibilité » :

]]> L'attaquant vise le maillon le plus faible : si le SMS est actif, c'est ce qui sera attaqué, indépendamment des méthodes fortes disponibles. Retirer les méthodes faibles est aussi important qu'ajouter les fortes.

Ref: Section 3 + Piège 3

]]> 1 0.3333333 0 true true abc $course$/Formation Entra ID - Atoo Next/Module 08 - Évaluation — Migration AD → Entra Module 08 - q1 Quelle stratégie convient le mieux à une PME encore dépendante de quelques apps legacy, qui veut avancer sans big bang ?

]]> Hybride progressif : synchronisation en place, bascule service par service, réduction progressive de l'AD. Réversible, maîtrisé — la trajectoire adaptée à la majorité des PME.

Ref: Section 1

]]> 1 0.3333333 0 true true abc Module 08 - q2 Le frein n°1 au cloud-only est le plus souvent :

]]> Une app LDAP qui refuse d'être réécrite = un DC qui reste. Le chemin critique du cloud-only, c'est le traitement des dépendances applicatives.

Ref: Section 5 + Piège 3

]]> 1 0.3333333 0 true true abc Module 08 - q3 Pendant la migration des groupes, quelle bonne pratique ?

]]> La migration est l'occasion de nettoyer. Passer à des groupes dynamiques (attributs) élimine la maintenance manuelle. Le tri des groupes morts se fait avant ou pendant la sync, pas plus tard.

Ref: Section 2 + Piège 2

]]> 1 0.3333333 0 true true abc Module 08 - q4 Le lecteur personnel `H:` migre vers :

]]> Données personnelles -> OneDrive ; partages d'équipe -> SharePoint / Teams. Le mappage de lecteur SMB disparaît au profit du client OneDrive et des sites collaboratifs.

Ref: Section 4

]]> 1 0.3333333 0 true true abc Module 08 - q5 Avant de décommissionner un DC, quelle condition est **indispensable** ?

]]> La condition sine qua non : zéro dépendance restante. Tant qu'un poste ou une app s'authentifie contre l'AD, éteindre le DC casse la prod.

Ref: Section 5 + Piège 5

]]> 1 0.3333333 0 true true abc Module 08 - q6 Migrer les partages « 1:1 » dans SharePoint est :

]]> SharePoint fonctionne par sites, bibliothèques et métadonnées, avec un modèle de permissions différent des ACL NTFS. Repenser l'organisation évite de recréer 20 niveaux de dossiers imbriqués.

Ref: Section 4 + Piège 4

]]> 1 0.3333333 0 true true abc Module 08 - q7 Quel outil aide à mesurer la couverture Intune des GPO existantes ?

]]> Group Policy Analytics : outil Intune qui importe vos GPO existantes et mesure quels paramètres sont couverts par les profils Intune modernes. Support majeur pour prioriser la migration.

Ref: Section 3

]]> 1 0.3333333 0 true true abc Module 08 - q8 Dans le plan 6 mois proposé, à quel moment déploie-t-on la baseline Conditional Access et PIM ?

]]> M3 « Sécurité identité » : la sync est faite (M2), les identités sont là, on peut protéger. Attendre M4-M6 exposerait les identités pendant plusieurs mois.

Ref: Section 6

]]> 1 0.3333333 0 true true abc Module 08 - q9 Quelle propriété du plan de bascule proposé le rend prudent ?

]]> Réversibilité à chaque étape : si un obstacle apparaît (app LDAP qui ne se laisse pas migrer, résistance métier), on s'arrête à hybride sans casse. C'est la garantie majeure du plan.

Ref: Section 6 + Piège 1

]]> 1 0.3333333 0 true true abc Module 08 - q10 Pendant la transition, comment compenser l'absence de Defender for Identity (E3+P2) ?

]]> Identity Protection (P2) apporte la détection basée risque côté cloud. Combiné aux sign-in / audit logs Entra (module 09), il couvre l'essentiel sans exiger E5 / MDI. La réduction progressive de l'AD DS réduit d'autant le besoin de MDI.

Ref: Section 5 + Module 07

]]> 1 0.3333333 0 true true abc $course$/Formation Entra ID - Atoo Next/Module 09 - Évaluation — Supervision & Logs Module 09 - q1 Quel journal répond à « qui s'est connecté, d'où, avec quel résultat » ?

]]> Sign-in logs = connexions : qui, quand, d'où (IP, pays), quelle app, quel résultat (succès, échec MFA, blocage CA). Le premier réflexe d'investigation.

Ref: Section 1

]]> 1 0.3333333 0 true true abc Module 09 - q2 Quel journal répond à « qui a modifié une politique CA » ?

]]> Audit logs = modifications d'annuaire : création d'utilisateur, ajout à un groupe, changement de rôle, modif de politique CA. À croiser avec Sign-in logs pour tracer la chaîne complète.

Ref: Section 1

]]> 1 0.3333333 0 true true abc Module 09 - q3 La rétention native des logs Entra est :

]]> 7 j en Free, 30 j en P1 / P2. Passé ce délai, l'historique disparaît si aucun diagnostic setting n'a été configuré. À anticiper avant d'en avoir besoin.

Ref: Section 1 + Piège 1

]]> 1 0.3333333 0 true true abc Module 09 - q4 Pour conserver et corréler les logs au-delà de la rétention native, on exporte vers :

]]> Log Analytics workspace : destination privilégiée. KQL + rétention configurable + base pour alertes Azure Monitor et workbooks. Coût Azure à budgeter (ingestion + rétention).

Ref: Section 2

]]> 1 0.3333333 0 true true abc Module 09 - q5 Microsoft Sentinel en E3+P2 :

]]> Sentinel = SIEM / SOAR cloud, bâti sur Log Analytics. Puissant mais coûteux et hors périmètre E3+P2. Alternative valable : Log Analytics seul + KQL + alertes Azure Monitor + rapports Entra natifs.

Ref: Section 2 + Piège 4

]]> 1 0.3333333 0 true true abc Module 09 - q6 En KQL, quel opérateur agrège (count, dcount) ?

]]> `summarize` est l'équivalent de GROUP BY en SQL. Accepte count(), dcount() (distinct), sum(), avg(), max(), min()... avec la syntaxe `summarize agrégats by colonnes`.

Ref: Section 3

]]> 1 0.3333333 0 true true abc Module 09 - q7 Pourquoi toujours mettre un filtre temporel (`ago`) ?

]]> Chaque requête sans `ago()` scanne toute la table, jusqu'à des mois de logs. Coût de traitement facturé + latence élevée. Toujours borner en premier filtre.

Ref: Section 3 + Piège 3

]]> 1 0.3333333 0 true true abc Module 09 - q8 Quelle alerte à forte valeur mettre en priorité ?

]]> Alerte rare, à haute valeur : les break-glass ne doivent jamais servir en routine. Leur usage = quelqu'un s'est verrouillé dehors (incident CA / MFA) ou compromission. À investiguer immédiatement.

Ref: Section 4 + Piège 5

]]> 1 0.3333333 0 true true abc incident)]]> Module 09 - q9 `ResultType == 50126` dans SigninLogs correspond à :

]]> 50126 = « mauvais nom d'utilisateur ou mot de passe ». C'est le code le plus utile pour détecter le password spraying : beaucoup de 50126 depuis une IP, sur peu de comptes distincts, en peu de temps.

Ref: Section 3

]]> 1 0.3333333 0 true true abc Module 09 - q10 Exporter des logs sans définir d'alertes, c'est :

]]> Mieux vaut 3 alertes exploitées que 1000 dashboards ignorés. Définir en priorité : break-glass, password spraying, modifications de rôles à privilèges ou de politiques CA.

Ref: Section 4 + Piège 5

]]> 1 0.3333333 0 true true abc $course$/Formation Entra ID - Atoo Next/Module 10 - Évaluation — Collaboration B2B Module 10 - q1 Dans la collaboration B2B, où l'invité prouve-t-il son identité ?

]]> L'invité s'authentifie chez lui (home realm) ; l'OTP e-mail n'est qu'un repli pour un externe sans identité fédérable. Vous ne gérez ni son mot de passe ni sa MFA.

Ref: Section 2

]]> 1 0.3333333 0 true true abc Module 10 - q2 Quel attribut caractérise un utilisateur invité et sert de filtre partout ?

]]> userType = Guest pilote les restrictions et sert de filtre dans CA, les revues d'accès, l'entitlement management. C'est l'attribut discriminant du B2B.

Ref: Section 2

]]> 1 0.3333333 0 true true abc Module 10 - q3 Un invité vient d'être créé mais n'a pas cliqué le lien d'invitation. Son état est :

]]> Avant rédemption : PendingAcceptance. L'objet Guest existe déjà dans votre tenant mais n'a pas d'accès effectif. Après consentement de l'invité : Accepted.

Ref: Section 2

]]> 1 0.3333333 0 true true abc Module 10 - q4 Les **cross-tenant access settings** permettent, entre autres, de :

]]> Les trust settings dans les CTAS acceptent MFA / appareil conforme prouvés dans le tenant d'origine, évitant le double challenge. À activer par organisation, pas dans les défauts globaux.

Ref: Section 3

]]> 1 0.3333333 0 true true abc Module 10 - q5 Quelle affirmation distingue correctement B2B et CIAM (External ID for customers) ?

]]> B2B = mes partenaires (workforce, inclus) ; CIAM = les clients de mon app (tenant external, facturé MAU, hors E3+P2). Deux mécanismes différents pour des publics différents.

Ref: Section 1 + Section 5

]]> 1 0.3333333 0 true true abc Module 10 - q6 Sur quel modèle l'External ID pour les clients (CIAM) est-il facturé ?

]]> MAU = utilisateur actif au moins une fois dans le mois. Modèle Azure classique pour les services grand public, adapté à la volumétrie variable d'une base clients.

Ref: Section 5

]]> 1 0.3333333 0 true true abc Module 10 - q7 Quelles fonctionnalités de gouvernance des invités relèvent d'**Entra ID P2** ? (plusieurs)

]]> Revues d'accès + Entitlement management = Entra ID Governance = Entra ID P2. Ces briques transforment la simple invitation en gouvernance industrialisée (approbation, expiration, retrait auto).

Ref: Section 4

]]> 1 0.3333333 0 false true abc Module 10 - q8 Un invité doit refaire une MFA chez vous alors qu'il en a déjà fait une chez lui. Que règle-t-on ?

]]> Trust MFA dans les trust settings inbound de l'organisation partenaire : votre CA considère l'exigence MFA satisfaite si l'invité a déjà fait sa MFA chez lui. À activer par partenaire, jamais dans les défauts globaux.

Ref: Section 3

]]> 1 0.3333333 0 true true abc Module 10 - q9 Pourquoi éviter de créer un compte **membre** « maison » pour un prestataire externe ?

]]> Compte « maison » = duplication d'identité + mot de passe à gérer + rotation à assurer + coupure manuelle à ne pas oublier quand le prestataire part. Le B2B élimine tout ça.

Ref: Section 1 + Piège 1

]]> 1 0.3333333 0 true true abc Module 10 - q10 Pour éviter le **guest sprawl** (invités qui s'accumulent), la meilleure approche est :

]]> Revues récurrentes + packages à expiration = P2 : le sprawl est traité à la racine, sans dépendre d'un geste manuel oublié. Le lifecycle est industrialisé.

Ref: Section 4 + Piège 4

]]> 1 0.3333333 0 true true abc