1. Modèle de tenant et licences

1.1 Ce qu'est un tenant

Un tenant Microsoft Entra ID est une instance dédiée de l'annuaire, identifiée par un Tenant ID (GUID immuable) et un domaine initial <nom>.onmicrosoft.com (non supprimable). C'est la frontière de sécurité et d'administration pour Microsoft 365, Azure, Intune et toutes les applications SaaS fédérées.

• Ce n'est pas un Active Directory dans le cloud : pas d'OU, pas de GPO, pas de Kerberos/LDAP natif (Entra Domain Services est un service séparé pour cela). Le modèle est plat, les délégations passent par les unités administratives.
• Protocoles : OAuth 2.0, OpenID Connect, SAML 2.0, WS-Fed ; API d'administration : Microsoft Graph.
• Objets : utilisateurs (membres / invités), groupes (sécurité, Microsoft 365, dynamiques, assignables à des rôles), appareils (enregistrés, joints, joints hybrides), applications et service principals.

1.2 Un ou plusieurs tenants ?

Modèle	Avantages	Inconvénients
Tenant unique	Collaboration native, une seule politique de sécurité, licences mutualisées	Isolation administrative limitée aux unités administratives
Multi-tenant (filiales, fusions)	Isolation forte, souveraineté	Collaboration via B2B / multitenant organization / cross-tenant sync, double administration
Tenant de test séparé	Tester CA, Connect, applications sans risque	Licences à prévoir, maintien de la parité

1.3 Licences et fonctionnalités

Fonctionnalité	Free	P1	P2
Security defaults	Oui	Oui	Oui
Conditional Access	-	Oui	Oui
Groupes dynamiques, writeback, journaux 30 jours	-	Oui	Oui
CA basé sur le risque, ID Protection complet	-	-	Oui
Privileged Identity Management	-	-	Oui
Access reviews, entitlement management	-	-	Oui (certaines fonctions avancées en Entra ID Governance)

P1 est inclus dans Microsoft 365 E3 / Business Premium, P2 dans E5. Les fonctions des workload identities (CA pour principals de service) relèvent d'une licence distincte. Vérifier le périmètre exact dans la doc de licences Microsoft, il évolue régulièrement.

1.4 Exigences imposées par Microsoft

• MFA obligatoire pour l'accès aux portails d'administration (Azure, Entra, Intune, Microsoft 365) puis aux outils en ligne de commande et IaC qui gèrent Azure. Aucune exclusion possible côté client : comptes de service « utilisateur » et break-glass doivent avoir une méthode MFA.
• Retrait des modules AzureAD / MSOnline : scripts à migrer vers Microsoft Graph PowerShell (§11).
• Retrait de l'authentification héritée dans Exchange Online (Basic Auth), y compris SMTP AUTH selon le calendrier annoncé : vérifier la date applicable.

# Domaines du tenant et type d'authentification
Connect-MgGraph -Scopes "Domain.Read.All","Organization.Read.All"
Get-MgDomain | Select-Object Id, AuthenticationType, IsVerified, IsDefault
(Get-MgOrganization).Id   # Tenant ID

2. Identité hybride et appareils

2.1 Comparatif

Critère	Microsoft Entra Connect Sync	Microsoft Entra Cloud Sync
Architecture	Serveur Windows avec moteur de synchro + base SQL (LocalDB ou SQL Server)	Agents de provisionnement légers, moteur et configuration dans le cloud
Haute disponibilité	Serveur actif + serveur en staging mode (bascule manuelle)	Plusieurs agents actifs (HA native)
Forêts déconnectées (fusion)	Possible mais complexe	Natif
Synchronisation des appareils (jointure hybride)	Oui	Non (vérifier l'état actuel)
Pass-through Authentication	Configurée par l'assistant	Agents PTA indépendants
Règles de synchro personnalisées	Éditeur de règles complet	Mappages d'attributs et expressions (plus limité)
Objets volumineux (groupes > 50 000 membres)	Oui	Limites à vérifier
Direction cloud vers AD	Writeback (mots de passe, groupes, appareils)	Provisioning de groupes Entra vers AD supporté

2.2 Ancre source et correspondance

• L'ancre source (ms-DS-ConsistencyGuid, valeur initialisée depuis objectGUID) relie l'objet AD à l'objet cloud via onPremisesImmutableId. Elle ne doit jamais changer.
• Hard match : correspondance par ImmutableId. Soft match : par proxyAddresses SMTP principal ou UPN.
• La reprise d'un compte cloud ayant un rôle d'administration par soft/hard match est bloquée par défaut (protection contre l'élévation depuis l'AD).

2.3 Exploitation de Connect Sync

Import-Module ADSync

# Etat du planificateur (cycle par defaut : 30 min)
Get-ADSyncScheduler

# Synchronisation delta immediate
Start-ADSyncSyncCycle -PolicyType Delta

# Suspendre pendant une maintenance
Set-ADSyncScheduler -SyncCycleEnabled $false

# Exporter la configuration (comparaison avant/apres mise a jour, revue)
Get-ADSyncServerConfiguration -Path "D:\ADSyncConfig\$(Get-Date -f yyyyMMdd)"

# Compte de connexion AD DS : verifier les permissions minimales
Get-ADSyncADConnectorAccount

• Seuil anti-suppression : par défaut, l'export est bloqué si plus de 500 suppressions sont détectées. Ne jamais le désactiver définitivement ; analyser la cause (OU sortie du périmètre, filtre modifié).
• Staging mode : le serveur secondaire importe et calcule, sans exporter. Avant une bascule, comparer les exports en attente (csexport.exe).
• Mises à jour : les anciennes versions 1.x ne sont plus supportées ; maintenir une version 2.x récente (auto-upgrade si configuration standard). TLS 1.2 obligatoire.
• Filtrage : par OU de préférence ; exclure comptes de service, comptes admin et objets techniques.

2.4 Cloud Sync en bref

1. Installer l'agent de provisionnement sur au moins deux serveurs membres (gMSA créé par l'assistant).
2. Dans le centre d'administration Entra : Hybrid management > Cloud sync, créer une configuration par domaine AD.
3. Définir le périmètre (OU ou groupes), les mappages d'attributs, activer PHS.
4. Tester avec Provision on demand sur un utilisateur avant d'activer.

2.5 Identité des appareils

L'état de l'appareil conditionne le SSO (Primary Refresh Token) et les contrôles Conditional Access « appareil conforme » ou « joint hybride ».

État	Pour qui	SSO / PRT	Remarques
Microsoft Entra registered	BYOD, mobiles personnels	Partiel (compte professionnel ajouté)	Combiné à MAM / app protection policies
Microsoft Entra joined	Postes d'entreprise cloud-first (Autopilot)	Oui, y compris vers les ressources AD via Kerberos cloud	Cible recommandée pour les nouveaux postes
Microsoft Entra hybrid joined	Postes existants joints AD	Oui	Dépend de la synchro des objets ordinateurs et du SCP ; transition, pas une fin

# Etat de l'appareil (poste Windows)
dsregcmd /status
#   AzureAdJoined : YES / DomainJoined : YES  => joint hybride
#   AzureAdPrt    : YES                        => SSO operationnel
#   TenantId      : doit etre le tenant attendu

# Appareils inactifs depuis 180 jours (nettoyage)
Connect-MgGraph -Scopes "Device.Read.All"
$limit = (Get-Date).AddDays(-180)
Get-MgDevice -All -Property DisplayName,OperatingSystem,TrustType,ApproximateLastSignInDateTime |
  Where-Object { $_.ApproximateLastSignInDateTime -lt $limit } |
  Select-Object DisplayName, OperatingSystem, TrustType, ApproximateLastSignInDateTime

3. PHS, PTA ou fédération

Critère	Password Hash Sync (PHS)	Pass-through Auth (PTA)	Fédération (AD FS / IdP tiers)
Où est validé le mot de passe	Dans Entra (hash dérivé du hash NT, salé, PBKDF2)	Sur un DC, via agents on-prem	Par l'IdP fédéré
Dépendance on-prem pour se connecter	Aucune	Agents PTA + DC joignables	Ferme AD FS + WAP + DC
Détection d'identifiants divulgués	Oui	Uniquement si PHS activé en parallèle	Uniquement si PHS activé en parallèle
Politiques AD (heures de connexion, compte expiré)	Partiel (désactivation synchronisée au cycle suivant)	Appliquées en temps réel	Appliquées
Surface d'attaque	Minimale	Agents Tier 0	Importante (vol de certificat de signature, Golden SAML)
Recommandation	Par défaut	Exigence de validation en temps réel	À migrer vers l'authentification managée

3.1 Migration AD FS vers l'authentification managée

1. Activer PHS et attendre la synchronisation complète des hash.
2. Inventorier les relying party trusts AD FS autres que Microsoft 365 et migrer ces applications vers Entra (rapport d'activité des applications AD FS dans le centre Entra).
3. Utiliser le staged rollout pour basculer des groupes pilotes sans convertir le domaine.
4. Recréer en Conditional Access les règles d'accès portées par les claims rules AD FS (MFA, emplacement réseau).
5. Convertir le domaine, puis décommissionner la ferme (et révoquer les certificats de signature).

# Etat d'authentification d'un domaine
Get-MgDomain -DomainId contoso.com | Select-Object Id, AuthenticationType

# Conversion federee -> managee (apres validation du staged rollout)
Update-MgDomain -DomainId contoso.com -AuthenticationType Managed

3.2 Seamless SSO

Seamless SSO crée un compte ordinateur AZUREADSSOACC dans l'AD dont la clé Kerberos déchiffre les tickets. Cette clé doit être renouvelée régulièrement (Microsoft recommande au moins tous les 30 jours) : un vol permet de forger des tickets pour n'importe quel utilisateur synchronisé. Sur des postes Windows 10/11 joints Entra ou joints hybrides, le Primary Refresh Token fournit déjà le SSO : Seamless SSO n'est alors utile que pour des postes uniquement joints au domaine. Évaluer sa suppression.

4. Méthodes d'authentification : MFA, passkeys, Windows Hello

4.1 Hiérarchie de robustesse

Niveau	Méthodes	Résiste au phishing (AiTM)
Résistant au phishing	Passkeys FIDO2 (clés physiques, passkeys dans Microsoft Authenticator), Windows Hello for Business, platform credential macOS, authentification par certificat (CBA) multifacteur	Oui : lié à l'origine / à l'appareil
Sans mot de passe	Authenticator en connexion par téléphone	Non (relayable)
MFA standard	Notification push avec number matching, code OATH (TOTP)	Non
Faible	SMS, appel vocal	Non, et SIM swapping

4.2 Authentication methods policy

Les méthodes se pilotent dans Protection > Authentication methods > Policies (les anciennes politiques MFA et SSPR ont été migrées vers ce modèle unique). Pour chaque méthode : activation, groupes cibles, options.

• Microsoft Authenticator : number matching et contexte géographique, passkey dans Authenticator.
• Passkey (FIDO2) : activer l'attestation et une liste d'AAGUID autorisés pour restreindre aux modèles de clés validés. Le support des passkeys synchronisées (gestionnaires de mots de passe) s'ajoute via des profils de passkeys : vérifier le statut (preview / GA) avant de l'ouvrir.
• Temporary Access Pass (TAP) : code à durée limitée pour l'amorçage (enrôlement d'une passkey, d'un nouveau téléphone, d'un poste Windows Hello). À délivrer après vérification d'identité par le support.
• SMS / voix : à désactiver ou à limiter à un groupe de transition.
• System-preferred MFA : propose la méthode la plus forte enregistrée par l'utilisateur.
• Registration campaign : incite les utilisateurs encore sur SMS à enregistrer Authenticator.

4.3 Windows Hello for Business

Modèle de confiance	Prérequis	Commentaire
Cloud Kerberos trust	Postes joints Entra ou joints hybrides, DC Windows Server 2016+, objet serveur Kerberos Entra créé dans l'AD	Modèle recommandé en hybride : pas de PKI, pas de délai de writeback des clés
Key trust	DC avec certificats, writeback de clé publique	Délai avant première connexion (synchro)
Certificate trust	PKI d'entreprise + NDES/Intune ou AD FS	Complexe ; pour RDP avec certificat ou exigences spécifiques

# Creer l'objet serveur Kerberos Entra dans le domaine (cloud Kerberos trust)
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
$domain = "corp.contoso.com"
$cloudCred = Get-Credential   # compte Hybrid Identity Administrator
$domainCred = Get-Credential  # Domain Admin
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred

# Rotation reguliere de la cle (comme krbtgt)
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred -RotateServerKey

Le déploiement de la stratégie WHfB se fait par Intune (voir Intune) ou GPO.

5. Conditional Access

5.1 Modèle d'évaluation

Conditional Access s'évalue après la première authentification, à chaque obtention de jeton. Toutes les politiques applicables sont combinées : un Block l'emporte toujours, et tous les contrôles Grant exigés par les différentes politiques doivent être satisfaits (logique ET entre politiques).

Composant	Contenu
Assignments	Utilisateurs / groupes / rôles / invités / workload identities ; inclusions et exclusions
Target resources	Applications cloud, actions utilisateur (enregistrement des infos de sécurité, joindre un appareil), authentication contexts
Conditions	Risque utilisateur / connexion, plateforme, emplacements nommés, applications clientes (dont legacy auth), filtre d'appareil, flux d'authentification (device code, transfert)
Grant	Block, MFA, authentication strength, appareil conforme, joint hybride, app approuvée, politique de protection d'app, changement de mot de passe, conditions d'utilisation
Session	Fréquence de connexion, session de navigateur persistante, CAE, Defender for Cloud Apps, restrictions appliquées par l'app, protection des jetons

5.2 Socle de politiques recommandé

#	Politique	Portée	Contrôle
CA001	Bloquer l'authentification héritée	Tous les utilisateurs, clients « Exchange ActiveSync » + « Other clients »	Block
CA002	MFA pour tous	Tous les utilisateurs, toutes ressources	Authentication strength « MFA »
CA003	MFA résistante au phishing pour les admins	Rôles d'annuaire privilégiés	Authentication strength « Phishing-resistant MFA »
CA004	Gestion Azure	Ressource « Windows Azure Service Management API »	MFA (ou plus fort)
CA005	Sécuriser l'enregistrement des infos de sécurité	Action utilisateur « Register security information »	Depuis emplacement de confiance ou appareil conforme, sinon MFA (TAP accepté)
CA006	Appareil conforme ou joint hybride	Employés, applications Office 365	Require compliant OR hybrid joined
CA007	Bloquer le flux device code	Tous sauf groupe d'exception (salles de réunion, appareils sans navigateur)	Block
CA008	Risque de connexion moyen et élevé	Tous (P2)	MFA + fréquence « Every time »
CA009	Risque utilisateur élevé	Tous (P2)	Changement de mot de passe sécurisé (ou révocation/blocage pour comptes sans mot de passe)
CA010	Invités	Guest or external users	MFA, fréquence de connexion, applications limitées
CA011	Pays bloqués	Tous, emplacement nommé « pays interdits »	Block

5.3 Exclusions et mode report-only

• Exclure systématiquement le groupe des comptes d'urgence (§6) de toutes les politiques, et le surveiller.
• Exclusions documentées et portées par des groupes dédiés (CA-Exclude-CA006) soumis à access review, jamais d'utilisateurs ajoutés directement dans la politique.
• Comptes de synchronisation (Sync_*, ADToAADSyncServiceAccount) : ils s'authentifient sans MFA ; les exclure des politiques MFA uniquement si nécessaire et compenser (restriction par emplacement). Préférer l'authentification par principal de service lorsque l'outil le propose (cas des versions récentes de Connect Sync : vérifier).
• Toute nouvelle politique en Report-only 1 à 2 semaines, puis analyse avec le classeur Conditional Access insights and reporting ou KQL (§12) : on voit qui aurait été bloqué.
• Utiliser l'outil What If pour simuler une connexion précise.

5.4 Emplacements nommés

• Plages IP : IP publiques de sortie des sites (NAT, proxy). Les marquer « trusted » abaisse le risque de connexion calculé ; ne pas y mettre des plages partagées (hébergeur, VPN grand public).
• Pays : déterminés par géolocalisation IP (option GPS via Authenticator possible). Utile pour bloquer, peu fiable pour autoriser (un VPN suffit).
• Global Secure Access : la condition « compliant network » remplace avantageusement les listes d'IP pour les utilisateurs nomades (licence Entra Internet/Private Access).
• Ne jamais exclure « emplacements de confiance » d'une politique MFA pour les administrateurs : un attaquant présent sur le réseau interne contournerait la MFA.

# Creer un emplacement IP nomme (plages RFC 5737 d'exemple)
New-MgIdentityConditionalAccessNamedLocation -BodyParameter @{
    "@odata.type" = "#microsoft.graph.ipNamedLocation"
    displayName   = "Sites Contoso - sorties Internet"
    isTrusted     = $true
    ipRanges      = @(
        @{ "@odata.type" = "#microsoft.graph.iPv4CidrRange"; cidrAddress = "198.51.100.0/28" }
        @{ "@odata.type" = "#microsoft.graph.iPv4CidrRange"; cidrAddress = "203.0.113.32/29" }
    )
}

5.5 Authentication strengths

Trois forces intégrées : Multifactor authentication, Passwordless MFA, Phishing-resistant MFA. On peut créer des forces personnalisées (ex. « FIDO2 restreint à certains AAGUID » ou « CBA multifacteur »). Pour les invités, la force est évaluée en tenant compte des paramètres de confiance inter-tenants (§8).

5.6 Contextes d'authentification et session

• Authentication context : exiger un niveau supérieur pour une action précise (ouvrir un site SharePoint « Confidentiel », activer un rôle PIM).
• Sign-in frequency : la valeur « Every time » est réservée aux scénarios risque/PIM ; ailleurs elle dégrade l'expérience sans gain.
• Continuous Access Evaluation (CAE) : les services compatibles (Exchange, SharePoint, Teams, Graph) révoquent quasi immédiatement un jeton en cas de désactivation du compte, changement de mot de passe, risque élevé ou changement d'IP hors emplacement autorisé (mode strict).
• Token protection : lie le jeton de session à l'appareil (réduit le rejeu de jetons volés) ; périmètre d'applications et de plateformes limité, à vérifier.

5.7 Politique CA en Graph PowerShell

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess","Policy.Read.All"

$params = @{
    displayName = "CA001 - Block legacy authentication"
    state       = "enabledForReportingButNotEnforced"
    conditions  = @{
        users = @{
            includeUsers  = @("All")
            excludeGroups = @("<BREAKGLASS_GROUP_ID>")
        }
        applications   = @{ includeApplications = @("All") }
        clientAppTypes = @("exchangeActiveSync","other")
    }
    grantControls = @{
        operator        = "OR"
        builtInControls = @("block")
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

# Sauvegarder toutes les politiques en JSON (versionner dans Git)
Get-MgIdentityConditionalAccessPolicy -All | ForEach-Object {
    $_ | ConvertTo-Json -Depth 10 | Out-File -Encoding utf8 ".\ca\$($_.Id).json"
}

6. Comptes d'accès d'urgence

Les comptes break-glass permettent de reprendre la main si les administrateurs sont bloqués : CA mal configurée, panne de fédération ou de MFA, compte admin compromis.

• Deux comptes minimum, cloud-only, sur le domaine *.onmicrosoft.com (indépendants de la fédération et de la synchronisation).
• Rôle Global Administrator permanent (actif, pas éligible PIM : PIM pourrait être la cause de la panne).
• Exclus de toutes les politiques CA mais soumis à une méthode résistante au phishing : la MFA obligatoire imposée par Microsoft sur les portails d'administration s'applique aussi à eux. Recommandation : passkeys FIDO2 (deux clés par compte, stockées dans des coffres physiques distincts) ou CBA.
• Mot de passe long généré aléatoirement, scindé ou scellé, pas d'expiration, non enregistré dans le gestionnaire de mots de passe d'entreprise si celui-ci dépend d'Entra.
• Aucune boîte aux lettres, aucune licence inutile, non synchronisés, nom non évident.
• Alerte immédiate sur toute connexion (§12.4) et test trimestriel documenté (connexion, vérification du rôle, déconnexion).

7. Rôles d'administration et PIM

7.1 Rôles sensibles

Rôle	Pourquoi il est critique
Global Administrator	Tout ; peut s'élever sur Azure. Viser moins de 5 titulaires (hors break-glass)
Privileged Role Administrator	Peut s'attribuer n'importe quel rôle : équivalent Global Admin
Privileged Authentication Administrator	Réinitialise les méthodes de n'importe qui, y compris des Global Admins
Application Administrator / Cloud Application Administrator	Peut ajouter des identifiants à un service principal ayant des permissions Graph élevées : chemin d'élévation classique
Hybrid Identity Administrator	Configure la synchro/fédération (peut ajouter un domaine fédéré)
Conditional Access Administrator	Peut désactiver toute la protection
Exchange / SharePoint Administrator	Accès à toutes les données métier

• Comptes d'administration séparés des comptes bureautiques, cloud-only, sans boîte mail, utilisés depuis un poste d'administration dédié (PAW).
• Utiliser les rôles les moins privilégiés (Helpdesk Administrator, User Administrator...) et les unités administratives pour restreindre la portée (ex. support d'une filiale).
• Restricted management administrative units : protègent des objets sensibles même contre les administrateurs de niveau tenant (sauf ceux affectés à l'AU).
• Groupes assignables à des rôles (isAssignableToRole) : seuls les Privileged Role Administrators peuvent en modifier les membres.

7.2 Privileged Identity Management

Paramètre	Valeur recommandée (Global Admin)	Valeur (rôle courant)
Type d'affectation	Éligible	Éligible
Durée max d'activation	1 à 2 h	4 à 8 h
Exiger à l'activation	Authentication context lié à une CA phishing-resistant, justification, ticket	MFA + justification
Approbation	Oui (2 approbateurs)	Non
Expiration de l'éligibilité	6 à 12 mois + access review	12 mois
Notifications	À l'équipe sécurité à chaque activation	Par défaut

PIM couvre aussi les rôles Azure RBAC (voir Azure) et les groupes (PIM for Groups : appartenance juste-à-temps à un groupe qui donne des droits applicatifs).

# Activer un role eligible (self-activation)
Connect-MgGraph -Scopes "RoleAssignmentSchedule.ReadWrite.Directory"
$me = (Get-MgContext).Account
$userId = (Get-MgUser -UserId $me).Id
$roleId = (Get-MgRoleManagementDirectoryRoleDefinition -Filter "displayName eq 'User Administrator'").Id

New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest -BodyParameter @{
    action           = "selfActivate"
    principalId      = $userId
    roleDefinitionId = $roleId
    directoryScopeId = "/"
    justification    = "Ticket 12345 - creation comptes"
    scheduleInfo     = @{
        startDateTime = (Get-Date).ToUniversalTime().ToString("o")
        expiration    = @{ type = "AfterDuration"; duration = "PT2H" }
    }
}

# Inventaire des affectations ACTIVES permanentes (a reduire)
Get-MgRoleManagementDirectoryRoleAssignment -All -ExpandProperty Principal |
    Select-Object @{n='Role';e={(Get-MgRoleManagementDirectoryRoleDefinition -UnifiedRoleDefinitionId $_.RoleDefinitionId).DisplayName}},
                  @{n='Principal';e={$_.Principal.AdditionalProperties.userPrincipalName}}

8. Accès invités B2B et paramètres inter-tenants

8.1 Les briques

Fonction	Rôle
B2B collaboration	L'externe devient un objet userType=Guest dans votre tenant, authentifié par son propre IdP
B2B direct connect	Pas d'objet invité ; utilisé par les canaux partagés Teams
Cross-tenant access settings	Par organisation partenaire : entrant/sortant, applications autorisées, confiance MFA et appareil
Cross-tenant synchronization	Provisionne automatiquement les utilisateurs d'un tenant vers un autre (groupes multi-tenants)
External collaboration settings	Qui peut inviter, restrictions de domaines, droits des invités dans l'annuaire
Entitlement management	Packages d'accès avec demande, approbation, expiration (P2 / Governance)

8.2 Paramétrage recommandé

• Guest user access : « Guest user access is restricted to properties and memberships of their own directory objects » (niveau le plus restrictif).
• Guest invite settings : invitation limitée aux rôles Guest Inviter ou via entitlement management, pas « tout le monde, y compris les invités ».
• Collaboration restrictions : liste d'autorisation de domaines si l'activité le permet, sinon liste de refus des domaines grand public.
• Inbound trust : faire confiance à la MFA (et éventuellement à la conformité des appareils) des tenants partenaires connus, pour éviter la double MFA. Ne pas l'activer par défaut pour tous.
• Outbound : restreindre les tenants dans lesquels vos utilisateurs peuvent être invités ; combiner avec tenant restrictions v2 pour empêcher l'usage de comptes d'autres tenants depuis vos appareils (prévention d'exfiltration).
• Access reviews trimestrielles sur les invités et suppression automatique des invités inactifs.
• Activer l'email one-time passcode pour les externes sans compte Microsoft/Entra (plutôt que la création de comptes viraux « unmanaged »).

# Invites jamais connectes ou inactifs depuis 90 jours
Connect-MgGraph -Scopes "User.Read.All","AuditLog.Read.All"
$limit = (Get-Date).AddDays(-90)
Get-MgUser -All -Filter "userType eq 'Guest'" `
    -Property DisplayName,Mail,CreatedDateTime,SignInActivity,ExternalUserState |
  Where-Object {
      -not $_.SignInActivity.LastSignInDateTime -or $_.SignInActivity.LastSignInDateTime -lt $limit
  } |
  Select-Object DisplayName, Mail, CreatedDateTime, ExternalUserState,
      @{n='LastSignIn';e={$_.SignInActivity.LastSignInDateTime}} |
  Sort-Object LastSignIn

9. Applications d'entreprise : SSO SAML et OIDC

9.1 Choisir le protocole

Critère	SAML 2.0	OpenID Connect / OAuth 2.0
Applications cibles	SaaS et applications web d'entreprise historiques	Applications modernes, mobiles, SPA, API
Format	Assertion XML signée	Jetons JWT (ID token, access token)
Appel d'API au nom de l'utilisateur	Non	Oui (access token, on-behalf-of)
Configuration côté Entra	Enterprise application (non-gallery ou galerie)	App registration
Rotation des clés	Certificat par application, à renouveler et à recharger chez le SP	Clés Entra tournantes publiées dans le JWKS, automatiques

9.2 Configuration SAML : les points qui cassent

• Identifier (Entity ID) et Reply URL (ACS) doivent correspondre exactement (casse, slash final) à ce que le SP envoie.
• NameID : choisir un identifiant stable. Le UPN change (mariage, renommage) ; préférer user.objectid ou user.employeeid si le SP le permet, sinon gérer le renommage chez le SP.
• Claims de groupes : au-delà de 150 groupes (SAML), le claim est omis et remplacé par un lien d'overage ; filtrer sur les groupes assignés à l'application ou utiliser des app roles.
• User assignment required = Yes : sinon tout utilisateur du tenant (y compris les invités) peut obtenir une assertion pour l'application.
• Signature : SHA-256, signer la réponse et/ou l'assertion selon ce qu'attend le SP.

<!-- Extrait d'assertion attendue : verifier avec l'extension navigateur SAML-tracer -->
<saml:Subject>
  <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">jdupont@contoso.com</saml:NameID>
</saml:Subject>
<saml:AttributeStatement>
  <saml:Attribute Name="http://schemas.microsoft.com/ws/2008/06/identity/claims/role">
    <saml:AttributeValue>App.Admin</saml:AttributeValue>
  </saml:Attribute>
</saml:AttributeStatement>

9.3 Certificats de signature SAML et rotation

Entra génère un certificat auto-signé par application (validité par défaut 3 ans). À l'expiration, le SSO tombe pour tous les utilisateurs de l'application.

1. Renseigner des adresses de notification (liste de diffusion, pas une personne) : Entra envoie des rappels avant expiration.
2. Environ 60 jours avant : créer un nouveau certificat (inactif) dans la section SAML Signing Certificate.
3. Charger le nouveau certificat (ou l'URL de métadonnées) chez le SP. Si le SP accepte plusieurs certificats ou consomme l'URL de métadonnées fédération, la bascule est transparente.
4. Activer le nouveau certificat dans Entra (fenêtre de maintenance si le SP n'accepte qu'un certificat).
5. Tester, puis supprimer l'ancien certificat.

# Certificats SAML (keyCredentials des service principals) expirant sous 60 jours
Connect-MgGraph -Scopes "Application.Read.All"
$limit = (Get-Date).AddDays(60)
Get-MgServicePrincipal -All -Property DisplayName,AppId,KeyCredentials,PreferredSingleSignOnMode |
  Where-Object PreferredSingleSignOnMode -eq 'saml' |
  ForEach-Object {
      $sp = $_
      $sp.KeyCredentials | Where-Object { $_.Usage -eq 'Verify' -and $_.EndDateTime -lt $limit } |
        Select-Object @{n='App';e={$sp.DisplayName}}, EndDateTime
  }

Pour le détail des formats et des chaînes de certificats, voir PKI et certificats et OpenSSL.

9.4 OIDC : jetons et claims

• ID token : pour l'application cliente (qui est l'utilisateur). Access token : pour l'API cible, à valider uniquement par l'API (audience aud), jamais à inspecter côté client.
• Identifier l'utilisateur par oid + tid (stables), pas par email ou preferred_username (modifiables, parfois non vérifiés).
• Valider : signature (JWKS de https://login.microsoftonline.com/<TENANT_ID>/discovery/v2.0/keys), iss, aud, exp/nbf, et tid si l'application est multi-tenant.
• Optional claims et claims mapping policies pour ajouter des attributs ; limite de groupes dans le JWT (200) au-delà de laquelle un claim d'overage oblige à interroger Graph.
• Flux : authorization code + PKCE pour toutes les applications interactives ; jamais l'implicit flow pour un nouveau développement.

9.5 Consentement

10. App registrations, service principals et identifiants

10.1 Application vs service principal

Objet	Où	Rôle
Application (app registration)	Tenant d'origine uniquement	Définition globale : URI de redirection, permissions demandées, app roles, identifiants
Service principal (enterprise application)	Chaque tenant où l'application est utilisée	Instance locale : affectations d'utilisateurs, permissions accordées, SSO, CA
Managed identity	Service principal spécial lié à une ressource Azure	Identifiants gérés par Azure, aucune rotation à faire

Permissions déléguées (agit au nom d'un utilisateur, limitée à ses droits) vs permissions application (app-only, sans utilisateur, sur tout le tenant). Une permission application Mail.Read lit toutes les boîtes : restreindre avec RBAC for Applications dans Exchange Online (voir Exchange Online).

10.2 Secrets, certificats ou fédération

Identifiant	Sécurité	Rotation	Usage
Client secret	Faible : chaîne copiable, finit dans des fichiers de config et des dépôts	Manuelle, durée max 24 mois via portail (à restreindre par policy)	À éviter ; développement uniquement
Certificat	Bonne si la clé privée est non exportable (Key Vault, TPM, HSM)	Manuelle ou automatisée via Key Vault	Serveurs on-prem, scripts planifiés
Workload identity federation	Excellente : aucun secret, jeton OIDC de courte durée émis par la plateforme externe	Aucune	GitHub Actions, Azure DevOps, GitLab, Kubernetes, autre cloud
Managed identity	Excellente	Aucune	Tout ce qui tourne dans Azure (ou Arc)

10.3 Workload identity federation : exemple GitHub Actions

# Credential federe sur une app registration (ou une user-assigned managed identity)
az ad app federated-credential create --id <APP_OBJECT_ID> --parameters '{
  "name": "github-main",
  "issuer": "https://token.actions.githubusercontent.com",
  "subject": "repo:contoso/infra:ref:refs/heads/main",
  "audiences": ["api://AzureADTokenExchange"]
}'

# Variante pour un environnement GitHub protege (approbation manuelle)
#   "subject": "repo:contoso/infra:environment:production"

# .github/workflows/deploy.yml (extrait)
permissions:
  id-token: write
  contents: read
jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: azure/login@v2
        with:
          client-id: ${{ vars.AZURE_CLIENT_ID }}
          tenant-id: ${{ vars.AZURE_TENANT_ID }}
          subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}

10.4 Hygiène des applications

• Propriétaires d'application : un propriétaire peut ajouter des identifiants à l'app et donc agir avec ses permissions. Limiter, revoir, ne jamais laisser un utilisateur standard propriétaire d'une app ayant des permissions application sensibles.
• App instance property lock pour empêcher l'ajout d'identifiants sur le service principal dans les tenants clients.
• App management policies : interdire les secrets, limiter la durée de vie des certificats (licence workload ID selon les fonctions).
• Revue régulière des permissions application à haut risque : RoleManagement.ReadWrite.Directory, AppRoleAssignment.ReadWrite.All, Application.ReadWrite.All, Directory.ReadWrite.All, Mail.ReadWrite, Sites.FullControl.All.

# Secrets et certificats d'app registrations expirant sous 30 jours
$limit = (Get-Date).AddDays(30)
Get-MgApplication -All -Property DisplayName,AppId,PasswordCredentials,KeyCredentials | ForEach-Object {
    $app = $_
    @($app.PasswordCredentials | ForEach-Object { [pscustomobject]@{App=$app.DisplayName; Type='Secret'; End=$_.EndDateTime} }) +
    @($app.KeyCredentials      | ForEach-Object { [pscustomobject]@{App=$app.DisplayName; Type='Cert';   End=$_.EndDateTime} })
} | Where-Object End -lt $limit | Sort-Object End

# Service principals disposant de permissions APPLICATION sur Microsoft Graph
$graph = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'"
Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $graph.Id -All |
  Select-Object PrincipalDisplayName,
    @{n='Permission';e={ $id = $_.AppRoleId; ($graph.AppRoles | Where-Object Id -eq $id).Value }} |
  Sort-Object PrincipalDisplayName

11. Microsoft Graph PowerShell

11.1 Installation et connexion

Les modules AzureAD et MSOnline sont retirés : tout script qui les utilise doit être migré vers Microsoft.Graph (ou Microsoft.Entra, module de compatibilité basé sur Graph).

Install-Module Microsoft.Graph -Scope CurrentUser
# Ou seulement les sous-modules utiles (chargement plus rapide)
Install-Module Microsoft.Graph.Authentication, Microsoft.Graph.Users, Microsoft.Graph.Identity.SignIns -Scope CurrentUser

# Interactif delegue : demander le strict necessaire
Connect-MgGraph -TenantId <TENANT_ID> -Scopes "User.Read.All","Group.Read.All" -NoWelcome
Get-MgContext | Select-Object Account, Scopes, AuthType

# App-only par certificat (tache planifiee)
Connect-MgGraph -TenantId <TENANT_ID> -ClientId <APP_ID> `
  -CertificateThumbprint <THUMBPRINT> -NoWelcome

# Identite managee (Azure Automation, VM Azure)
Connect-MgGraph -Identity -NoWelcome

11.2 Requêtes courantes

# Filtre cote serveur (OData) plutot que Where-Object : beaucoup plus rapide
Get-MgUser -Filter "accountEnabled eq true and userType eq 'Member'" -All `
  -Property DisplayName,UserPrincipalName,OnPremisesSyncEnabled,CreatedDateTime

# Requetes avancees (endsWith, count) : ConsistencyLevel eventual
Get-MgUser -Filter "endsWith(mail,'@contoso.com')" -ConsistencyLevel eventual -CountVariable n -All
"$n utilisateurs"

# Methodes d'authentification enregistrees par utilisateur (rapport global)
Connect-MgGraph -Scopes "AuditLog.Read.All","UserAuthenticationMethod.Read.All"
Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
  Select-Object UserPrincipalName, IsMfaRegistered, IsPasswordlessCapable, MethodsRegistered |
  Where-Object { -not $_.IsMfaRegistered }

# Membres effectifs (transitifs) d'un groupe
Get-MgGroupTransitiveMember -GroupId <GROUP_ID> -All |
  ForEach-Object { $_.AdditionalProperties.userPrincipalName }

# Revoquer toutes les sessions d'un utilisateur compromis
Revoke-MgUserSignInSession -UserId jdupont@contoso.com
Update-MgUser -UserId jdupont@contoso.com -AccountEnabled:$false

# Delivrer un Temporary Access Pass (usage unique, 1 heure)
New-MgUserAuthenticationTemporaryAccessPassMethod -UserId jdupont@contoso.com `
  -BodyParameter @{ lifetimeInMinutes = 60; isUsableOnce = $true }

11.3 Appels bruts et pagination

# Endpoint non couvert par une cmdlet, ou version beta
$uri = "https://graph.microsoft.com/v1.0/identity/conditionalAccess/namedLocations"
$res = Invoke-MgGraphRequest -Method GET -Uri $uri
$all = @($res.value)
while ($res.'@odata.nextLink') {
    $res = Invoke-MgGraphRequest -Method GET -Uri $res.'@odata.nextLink'
    $all += $res.value
}
$all | ForEach-Object { $_.displayName }

12. Journaux de connexion, audit et KQL

12.1 Sources et rétention

Journal	Contenu	Table Log Analytics
Interactive sign-ins	Connexions avec saisie utilisateur	SigninLogs
Non-interactive sign-ins	Renouvellements de jetons par les clients	AADNonInteractiveUserSignInLogs
Service principal sign-ins	App-only	AADServicePrincipalSignInLogs
Managed identity sign-ins	Identités managées	AADManagedIdentitySignInLogs
Audit	Modifications de l'annuaire (utilisateurs, groupes, rôles, apps, politiques)	AuditLogs
Provisioning	Synchro sortante vers des SaaS	AADProvisioningLogs
Risques	Détections ID Protection	AADRiskyUsers, AADUserRiskEvents
Graph activity	Requêtes HTTP faites à Graph	MicrosoftGraphActivityLogs

Rétention native limitée (7 jours en Free, 30 jours en P1/P2). Configurer un diagnostic setting Entra vers Log Analytics (ou Sentinel) dès le premier jour : une investigation d'incident remonte souvent à plusieurs mois.

12.2 Lire un événement de connexion

• ResultType : 0 = succès, sinon code AADSTS (§14). Champ texte dans SigninLogs.
• ConditionalAccessStatus : success, failure, notApplied. Le détail par politique est dans ConditionalAccessPolicies (y compris les résultats report-only : reportOnlyFailure, reportOnlySuccess...).
• AuthenticationRequirement : singleFactorAuthentication ou multiFactorAuthentication.
• AuthenticationDetails : méthodes effectivement utilisées ; « MFA requirement satisfied by claim in the token » indique une MFA antérieure réutilisée.
• CorrelationId : à communiquer au support Microsoft ou à l'éditeur SaaS.

12.3 Requêtes KQL

// Connexions reussies en authentification simple facteur (hors comptes attendus)
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == "0" and AuthenticationRequirement == "singleFactorAuthentication"
| summarize Count = count(), Apps = make_set(AppDisplayName, 10) by UserPrincipalName
| order by Count desc

// Impact d'une politique en report-only : qui aurait ete bloque
SigninLogs
| where TimeGenerated > ago(14d)
| mv-expand cap = ConditionalAccessPolicies
| where tostring(cap.displayName) == "CA006 - Require compliant device"
| where tostring(cap.result) == "reportOnlyFailure"
| summarize Attempts = count() by UserPrincipalName, AppDisplayName,
            OS = tostring(DeviceDetail.operatingSystem)
| order by Attempts desc

// Authentification heritee encore utilisee (avant de la bloquer)
SigninLogs
| where TimeGenerated > ago(30d)
| where ClientAppUsed !in ("Browser", "Mobile Apps and Desktop clients")
| summarize count() by UserPrincipalName, ClientAppUsed, AppDisplayName

// Password spray : nombreux comptes differents, echec mot de passe, meme IP
SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType in ("50126", "50053")
| summarize Users = dcount(UserPrincipalName), Attempts = count() by IPAddress
| where Users > 10
| order by Users desc

// Ajouts a des roles d'annuaire
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName in ("Add member to role", "Add eligible member to role in PIM completed (permanent)",
                          "Add member to role completed (PIM activation)")
| extend Actor = tostring(InitiatedBy.user.userPrincipalName),
         Target = tostring(TargetResources[0].userPrincipalName),
         Role = tostring(TargetResources[0].modifiedProperties[1].newValue)
| project TimeGenerated, OperationName, Actor, Target, Role

// Identifiants ajoutes a une application ou un service principal (persistance classique)
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName has_any ("Add service principal credentials", "Update application - Certificates and secrets management")
| project TimeGenerated, OperationName,
          Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName)),
          App = tostring(TargetResources[0].displayName)

// Consentements accordes a des applications
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName == "Consent to application"
| project TimeGenerated, Actor = tostring(InitiatedBy.user.userPrincipalName),
          App = tostring(TargetResources[0].displayName), TargetResources

Les noms exacts des opérations d'audit peuvent varier : valider sur vos propres journaux avant d'en faire des règles d'alerte.

12.4 Alerte sur les comptes d'urgence

// Regle d'alerte (log search alert ou regle analytique Sentinel) - frequence 5 min
union SigninLogs, AADNonInteractiveUserSignInLogs
| where UserPrincipalName in~ ("bg-01@contoso.onmicrosoft.com", "bg-02@contoso.onmicrosoft.com")
| project TimeGenerated, UserPrincipalName, ResultType, IPAddress, AppDisplayName, Location

13. ID Protection et détection des risques

13.1 Deux notions de risque

Type	Signification	Exemples de détections	Remédiation
Sign-in risk	Probabilité que cette connexion ne soit pas légitime	IP anonyme (Tor), voyage atypique, propriétés inhabituelles, jeton anormal, AiTM suspecté	MFA réussie
User risk	Probabilité que le compte soit compromis	Identifiants divulgués (nécessite PHS), renseignement Microsoft, activité anormale	Changement de mot de passe sécurisé, ou réinitialisation par l'admin, ou « Dismiss / Confirm compromised »

13.2 Mise en œuvre

• Configurer les politiques de risque dans Conditional Access (CA008, CA009) et non dans les anciennes politiques ID Protection, dont Microsoft a annoncé le retrait (vérifier la date dans la doc éditeur et migrer).
• Prérequis : utilisateurs enregistrés en MFA avant d'activer, sinon un risque de connexion devient un blocage. Politique d'enregistrement MFA ou campagne préalable.
• Pour l'auto-remédiation du risque utilisateur : SSPR activé avec password writeback pour les comptes synchronisés.
• Comptes sans mot de passe (passkey uniquement) : la remédiation « changer le mot de passe » n'a pas de sens ; prévoir un contrôle adapté (révocation de session, blocage et intervention du support). Vérifier les options de remédiation proposées par Microsoft, en évolution.
• Workload identities : ID Protection détecte aussi les comportements anormaux de service principals (licence dédiée).

# Utilisateurs a risque eleve non remedies
Connect-MgGraph -Scopes "IdentityRiskyUser.Read.All"
Get-MgRiskyUser -Filter "riskLevel eq 'high' and riskState eq 'atRisk'" -All |
  Select-Object UserPrincipalName, RiskLevel, RiskState, RiskLastUpdatedDateTime

# Confirmer une compromission (positionne le risque utilisateur a eleve)
Invoke-MgConfirmRiskyUserCompromised -UserIds @("<USER_OBJECT_ID>")

13.3 Réponse à une compromission de compte

1. Désactiver le compte et révoquer les sessions (Revoke-MgUserSignInSession) ; côté AD si synchronisé (sinon la synchro réactive).
2. Réinitialiser le mot de passe (deux fois si la compromission est ancienne), supprimer les méthodes MFA ajoutées par l'attaquant.
3. Vérifier les persistances : règles de boîte mail (transfert, suppression), consentements OAuth, appareils enregistrés, identifiants ajoutés à des apps, délégations.
4. Analyser les journaux (connexions depuis l'IP de l'attaquant, opérations d'audit initiées par le compte, MicrosoftGraphActivityLogs).
5. Rétablir avec TAP + enrôlement d'une méthode résistante au phishing.

Pour la démarche globale d'audit, voir Audit de sécurité.

14. Dépannage et codes AADSTS

14.1 Méthode

1. Récupérer le code AADSTS, le Correlation ID et l'horodatage (affichés sur la page d'erreur ou dans l'application).
2. Chercher la connexion dans Sign-in logs (penser aux onglets non interactif et service principal) : onglets Basic info, Authentication details, Conditional Access.
3. Rejouer le scénario avec What If (CA) et, pour SAML, avec un traceur SAML ; pour OIDC, décoder le jeton (outil local, jamais un site tiers pour un jeton de production).
4. Sur le poste Windows : dsregcmd /status (état de jointure, AzureAdPrt : YES), journaux Microsoft-Windows-AAD/Operational.

14.2 Codes courants

Code	Signification	Cause fréquente / correction
50126	Identifiant ou mot de passe invalide	Erreur de saisie, mot de passe pas encore synchronisé (PHS : jusqu'à 2 min), password spray si massif
50053	Compte verrouillé (Smart Lockout) ou IP bloquée	Attaque en cours ou client avec ancien mot de passe en boucle ; Smart Lockout cloud à aligner sous le seuil AD (PTA)
50057	Compte désactivé	Désactivé dans AD (synchro) ou Entra
50055	Mot de passe expiré	Politique d'expiration ; changer le mot de passe
50076	MFA requise	Interruption normale (l'utilisateur doit faire la MFA) ; dans les journaux, pas une erreur en soi
50079	Enregistrement MFA requis	Utilisateur non enregistré ; fournir un TAP
50074	Authentification forte requise	Idem 50076, contexte d'interruption
500121	Échec de l'authentification forte	Notification refusée/expirée ; MFA fatigue si répété : réinitialiser le mot de passe
53003	Bloqué par Conditional Access	Onglet CA du journal : quelle politique, quelle condition
53000	Appareil non conforme / non géré requis	Appareil absent d'Intune, non conforme, ou navigateur ne transmettant pas l'état (extension/compte non connecté)
53001	Appareil joint au domaine (hybride) requis	Jointure hybride incomplète : dsregcmd /status, synchro de l'objet ordinateur
530032	Bloqué par une politique de sécurité (security defaults ou paramètre de tenant)	Vérifier les security defaults et les paramètres inter-tenants
50105	Utilisateur non affecté à l'application	Assignment required = Yes : affecter l'utilisateur ou son groupe
50011	Reply URL non concordante	URI de redirection exacte (schéma, port, slash final) dans l'app registration
700016	Application introuvable dans le tenant	Mauvais client ID ou tenant, ou application multi-tenant pas encore consentie
65001	Consentement non accordé	Admin consent requis (permissions sensibles ou consentement utilisateur désactivé)
7000215	Secret client invalide	Valeur du secret confondue avec son ID
7000222	Secret client expiré	Renouveler, puis migrer vers certificat/fédération
700027	Échec de validation de la signature de l'assertion client	Certificat absent de l'application ou mauvais certificat utilisé
700213 / 70021	Aucun credential fédéré correspondant	Issuer, subject ou audience différent du jeton OIDC réel (branche, environnement)
50020	Compte d'un autre IdP inexistant dans le tenant	Invité non invité ou point de terminaison /common pour une app mono-tenant
90072	Compte externe absent du tenant de ressource	Inviter l'utilisateur ou se connecter avec le bon compte
75011	Méthode d'authentification non concordante (SAML)	Le SP exige un RequestedAuthnContext particulier ; ajuster côté SP
70043	Refresh token expiré (fréquence de connexion CA)	Comportement attendu ; reconnexion
50173	Jeton révoqué (changement de mot de passe ou révocation)	Se reconnecter
50158	Défi de sécurité externe non satisfait	Fournisseur MFA externe / fédération
81016 et voisins	Seamless SSO : ticket Kerberos invalide	Clé AZUREADSSOACC, horloge, zone intranet du navigateur

14.3 Autres symptômes

Symptôme	Cause	Correction
Utilisateur synchronisé en double (un objet cloud + un objet synchro)	Soft match impossible (UPN/SMTP différents)	Aligner les attributs ou hard match par ImmutableId, puis resynchroniser
Erreurs d'export « AttributeValueMustBeUnique »	proxyAddresses/UPN en conflit avec un objet existant	Rapport Connect Health > Sync errors, corriger la source AD
Modification d'attribut cloud refusée	Objet synchronisé : la source d'autorité est l'AD	Modifier dans l'AD
AzureAdPrt : NO sur un poste joint hybride	Objet ordinateur non synchronisé, SCP absent, proxy bloquant	Vérifier le SCP, l'OU synchronisée, dsregcmd /debug
MFA demandée en boucle	Cookies tiers bloqués, fréquence « Every time » sur une app, horloge	Revoir la session CA et les paramètres du navigateur
Invité ne peut pas accepter l'invitation	Domaine bloqué par les collaboration restrictions ou paramètres sortants du tenant partenaire	Vérifier les deux côtés (entrant chez vous, sortant chez lui)

15. Checklist de mise en production

15.1 Tenant et comptes privilégiés

• ☐ Deux comptes break-glass cloud-only, FIDO2, exclus de CA, alerte sur connexion, test trimestriel.
• ☐ Moins de 5 Global Administrators ; comptes admin dédiés, cloud-only, non synchronisés.
• ☐ PIM sur tous les rôles privilégiés (annuaire et Azure), approbation pour Global Admin / Privileged Role Admin.
• ☐ Inscription self-service et création de tenants par les utilisateurs désactivées.

15.2 Identité hybride

• ☐ Serveur Connect / agents Cloud Sync traités en Tier 0, version supportée, staging mode ou agents multiples.
• ☐ PHS activé (même avec PTA/fédération) ; fédération migrée ou plan de migration.
• ☐ Seuil anti-suppression actif ; filtrage par OU sans comptes admin.
• ☐ Seamless SSO : clé renouvelée ou fonction retirée si inutile.

15.3 Authentification et Conditional Access

• ☐ Authentification héritée bloquée (vérifiée dans les journaux : zéro succès).
• ☐ MFA pour tous ; MFA résistante au phishing pour les admins.
• ☐ SMS/voix désactivés ou résiduels ; TAP disponible pour le support ; procédure de vérification d'identité écrite.
• ☐ Enregistrement des informations de sécurité protégé par CA.
• ☐ Device code flow bloqué sauf exceptions documentées.
• ☐ Politiques de risque (P2) en CA ; SSPR + writeback.
• ☐ Toutes les politiques passées par report-only, export JSON versionné.

15.4 Applications et externes

• ☐ Consentement utilisateur restreint + admin consent workflow.
• ☐ Applications SSO : assignment required, notifications de certificat sur une liste de diffusion, inventaire des dates d'expiration.
• ☐ Aucun client secret en production (certificat, fédération ou identité managée).
• ☐ Revue des permissions application à haut risque et des propriétaires d'applications.
• ☐ Paramètres invités restrictifs, inbound trust limité aux partenaires connus, access reviews.

15.5 Supervision

• ☐ Diagnostic settings Entra vers Log Analytics / Sentinel (toutes catégories utiles), rétention ≥ 1 an.
• ☐ Alertes : connexion break-glass, ajout à un rôle privilégié, ajout d'identifiants à une application, modification/suppression de politique CA, consentement admin, nouveau domaine fédéré.
• ☐ Suivi du Secure Score identité et des recommandations Entra.
• ☐ Plan de réponse à compromission de compte documenté et testé.

Pour aller plus loin : Intune, Exchange Online, Azure, Durcissement AD, Windows Server.