Contrôles de session accès conditionnel, fréquence de connexion, emplacements nommés : ce qui révoque vraiment un jeton actif

Contrôles de session d'accès conditionnel, fréquence de connexion, emplacements nommés : ce que fait vraiment chaque paramètre

Si vous avez cherché contrôles de session accès conditionnel fréquence de connexion emplacements nommés, vous poursuivez presque certainement une seule question : durcir un contrôle de session éjecte-t-il réellement un utilisateur déjà connecté ? La réponse courte est non. Un contrôle de session décrit ce qui se passe la prochaine fois que Microsoft Entra ID évalue la session — il ne va pas chercher un jeton d'accès déjà émis pour le révoquer rétroactivement.

La référence des contrôles de session de Microsoft en liste huit : les restrictions imposées par l'application, le contrôle d'application d'accès conditionnel, la fréquence de connexion, la session de navigateur persistante, la personnalisation de l'évaluation continue de l'accès, la désactivation des valeurs par défaut de résilience, l'exigence de protection de jeton pour les sessions de connexion, et l'utilisation du profil de sécurité Global Secure Access. Deux d'entre eux — la fréquence de connexion et la session de navigateur persistante — se comportent dans le temps de façons documentées sur une page séparée, les stratégies de durée de vie de session adaptatives, où Microsoft précise également que « l'accès conditionnel est une fonctionnalité Microsoft Entra ID P1 ou P2 qui nécessite une licence premium ».

Si vous auditez ces paramètres via Microsoft Graph plutôt que via le portail, la vue est encore plus étroite. La ressource v1.0 conditionalAccessSessionControls n'expose que cinq propriétés — applicationEnforcedRestrictions, cloudAppSecurity, disableResilienceDefaults, persistentBrowser, signInFrequency — si bien qu'un script qui énumère les contrôles de session v1.0 ne verra ni la protection de jeton ni le bascule CAE.

Le paramètre par défaut est plus permissif que ce que la plupart des administrateurs supposent. Microsoft l'indique clairement : « La configuration par défaut de Microsoft Entra ID pour la fréquence de connexion utilisateur est une fenêtre glissante de 90 jours. » La justification est explicite — « ne pas demander aux utilisateurs de fournir leurs identifiants si la posture de sécurité de leurs sessions n'a pas changé ».

Comment ça marche : quand une stratégie est réellement évaluée

C'est la phrase qui gouverne tout le reste. Extrait de la documentation sur les signaux réseau de Microsoft :

Les stratégies d'accès conditionnel sont évaluées lorsque : un utilisateur se connecte initialement à une application web, mobile ou de bureau. Une application mobile ou de bureau qui utilise l'authentification moderne utilise un jeton d'actualisation pour obtenir un nouveau jeton d'accès. Par défaut, cette vérification se produit une fois par heure.

Et, pour les navigateurs : « pour les applications web, les stratégies s'appliquent à la connexion initiale et restent valables pendant toute la durée de vie de la session au niveau de l'application web ». Microsoft ajoute la conséquence pratique : « Par défaut, Microsoft Entra ID émet des jetons toutes les heures. Une fois que les utilisateurs quittent le réseau de l'entreprise, la stratégie est appliquée dans l'heure pour les applications utilisant l'authentification moderne. »

Une stratégie basée sur l'emplacement est donc une vérification au moment du renouvellement, pas un déclencheur en temps réel — sauf si l'évaluation continue de l'accès entre en jeu.

Fréquence de connexion, y compris « À chaque fois »

La fréquence de connexion « spécifie combien de temps un utilisateur peut accéder à une ressource avant de devoir se reconnecter ». Choisir À chaque fois ne signifie pas en continu. Microsoft : « Lorsque vous sélectionnez À chaque fois, la stratégie exige une réauthentification complète au moment où la session est évaluée. Cette exigence signifie que si l'utilisateur ferme puis rouvre son navigateur pendant la durée de vie de la session, il se peut qu'il ne soit pas invité à se réauthentifier. » Le contrôle « tient également compte de cinq minutes de décalage d'horloge lorsque l'option à chaque fois est sélectionnée, afin de ne pas solliciter les utilisateurs plus d'une fois toutes les cinq minutes ».

L'application est également différée pour tout ce qui est non interactif : « Si l'application cliente (dans les détails d'activité) est un navigateur, le système diffère l'application de la fréquence de connexion des événements et stratégies sur les services en arrière-plan jusqu'à la prochaine interaction utilisateur. Sur les clients confidentiels, le système diffère l'application de la fréquence de connexion sur les connexions non interactives jusqu'à la prochaine connexion interactive. »

Sur les appareils joints, il existe une seconde horloge : « déverrouiller l'appareil ou se connecter de façon interactive actualise le jeton d'actualisation principal (PRT) toutes les quatre heures ». L'exemple concret de Microsoft montre une stratégie SIF d'une heure qui invite l'utilisateur à 05:45 — cinq heures et 45 minutes après la connexion initiale à 00:00 — parce que le PRT a été actualisé à 04:45.

L'évaluation continue de l'accès est ce qui révoque réellement

L'évaluation continue de l'accès (CAE) est ce qui transforme une stratégie en révocation quasi temps réel, et elle le fait pour une liste fermée d'événements critiques : un compte utilisateur est supprimé ou désactivé ; un mot de passe est changé ou réinitialisé ; le MFA est activé pour l'utilisateur ; un administrateur révoque explicitement tous les jetons d'actualisation ; un risque utilisateur élevé est détecté par ID Protection. La latence annoncée par Microsoft : « l'objectif pour l'évaluation des événements critiques est une réponse quasi instantanée, mais une latence pouvant atteindre 15 minutes peut être observée en raison du temps de propagation des événements ; en revanche, l'application de la stratégie sur les emplacements IP est instantanée ».

La contrepartie, ce sont des jetons plus longs : « la durée de vie du jeton passe à une durée longue, jusqu'à 28 heures, dans les sessions CAE ». Sans client compatible CAE, « la durée de vie par défaut du jeton d'accès reste de 1 heure ». Et, point essentiel pour cet article : « la fréquence de connexion est respectée, avec ou sans CAE ».

L'écart : où un jeton actif survit à votre stratégie

1. Les emplacements nommés basés sur le pays sont invisibles pour CAE

C'est la ligne la plus précieuse de toute la documentation CAE :

CAE n'a de visibilité que sur les emplacements nommés basés sur IP. CAE n'a pas de visibilité sur les autres conditions d'emplacement telles que les IP de confiance MFA ou les emplacements basés sur le pays/la région. Lorsqu'un utilisateur provient d'une IP de confiance MFA, d'un emplacement de confiance incluant des IP de confiance MFA, ou d'un emplacement pays/région, CAE ne sera pas appliqué après que cet utilisateur se déplace vers un autre emplacement. Dans ces cas, Microsoft Entra émet un jeton d'accès d'une heure sans vérification d'application IP instantanée.

Une stratégie « bloquer l'accès depuis en dehors de ces pays » ramène donc le tenant au modèle horaire pré-CAE. La recommandation de Microsoft est sans ambiguïté : « N'utilisez pas les conditions d'emplacement pays/région ni la fonctionnalité d'IP de confiance disponible sur la page des paramètres de service de l'authentification multifacteur Microsoft Entra. »

2. Trop de plages IP désactive silencieusement l'application en temps réel de l'emplacement

« Lorsque la somme de toutes les plages IP spécifiées dans les stratégies d'emplacement dépasse 5 000, CAE ne peut pas appliquer en temps réel le flux de changement d'emplacement utilisateur. Dans ce cas, Microsoft Entra émet un jeton CAE d'une heure. » Le seuil est global au tenant — la somme sur l'ensemble des stratégies d'emplacement, pas un plafond par stratégie — il est donc franchi par accumulation plutôt que par une seule modification. Seule l'application de l'emplacement se dégrade : « CAE continue d'appliquer tous les autres événements et stratégies à l'exception des événements de changement d'emplacement du client. » Les limites structurelles sont elles aussi finies : pas plus de 195 emplacements nommés, pas plus de 2 000 plages IP par emplacement nommé, et uniquement des masques CIDR supérieurs à /8.

3. Les chemins de sortie scindés déclenchent l'exception de variation d'IP

Lorsque l'IP vue par Entra et l'IP vue par le fournisseur de ressource diffèrent — proxys, VPN en tunnel scindé, SD-WAN, SNAT, IPv6 — « Microsoft Entra considère que le client se trouve toujours dans un emplacement autorisé et que l'accès doit être accordé. Par conséquent, Microsoft Entra émet un jeton d'une heure qui suspend les vérifications d'adresse IP au niveau de la ressource jusqu'à l'expiration du jeton. » C'est le mode standard, activé par défaut. L'alternative plus stricte de Microsoft, encore étiquetée Public Preview sur sa page CAE, est l'application stricte de l'emplacement : « arrêter immédiatement l'accès si l'adresse IP détectée par le fournisseur de ressource n'est pas autorisée par la stratégie d'accès conditionnel ».

4. Les cookies de navigateur persistants survivent à la stratégie

L'avertissement de Microsoft sur la persistance est sans détour : « Dans les navigateurs persistants, les cookies restent stockés sur l'appareil de l'utilisateur même après la fermeture du navigateur. Ces cookies peuvent accéder aux artefacts Microsoft Entra, qui restent utilisables jusqu'à l'expiration du jeton, indépendamment des stratégies d'accès conditionnel appliquées à l'environnement de la ressource. » Un proxy adversary-in-the-middle qui récolte ce cookie hérite exactement de cette propriété — voir rejeu de jeton AiTM et détection de déplacements impossibles pour Entra ID et phishing par device code pour comprendre comment le vol se produit en premier lieu.

5. La condition de plateforme de l'appareil est une donnée non vérifiée

« Conditional Access identifie la plateforme de l'appareil à partir d'informations fournies par l'appareil, comme les chaînes user-agent. Comme les chaînes user-agent peuvent être modifiées, cette information n'est pas vérifiée. » Une condition de plateforme est un mécanisme de ciblage, pas un contrôle d'authentification. La recommandation de Microsoft est de l'utiliser « avec les stratégies de conformité des appareils Microsoft Intune ou dans le cadre d'une instruction de blocage ».

6. Les modifications de stratégie ne s'appliquent pas rétroactivement

« Les modifications apportées aux stratégies d'accès conditionnel et à l'appartenance aux groupes par les administrateurs peuvent prendre jusqu'à un jour pour devenir effectives… Une optimisation est faite pour les mises à jour de stratégie, ce qui réduit le délai à deux heures. » Durcir une stratégie après un incident n'évince pas les sessions déjà existantes. Deux autres angles morts méritent d'être cités : « CAE ne prend pas en charge les comptes utilisateurs invités », et « Teams est composé de plusieurs services ; les services d'appels et de chat n'obéissent pas aux stratégies d'accès conditionnel basées sur l'IP ».

Détection

Commencez par la configuration, puis passez à la télémétrie.

Import-Module Microsoft.Graph.Identity.SignIns
Connect-MgGraph -Scopes 'Policy.Read.All'

# Policies with no session controls at all, and those relying on country locations
Get-MgIdentityConditionalAccessPolicy |
    Select-Object DisplayName, State,
        @{n='SessionControls';e={ $_.SessionControls | ConvertTo-Json -Depth 4 -Compress }},
        @{n='Locations';e={ $_.Conditions.Locations | ConvertTo-Json -Depth 3 -Compress }}

# Named locations: which are IP-based (CAE-visible) and which are trusted
Get-MgIdentityConditionalAccessNamedLocation |
    Select-Object Id, DisplayName, AdditionalProperties

Ces deux cmdlets ne nécessitent que Policy.Read.All ; Microsoft cite Global Reader, Security Reader, Security Administrator et Conditional Access Administrator parmi les rôles à moindre privilège permettant ces lectures. Les appels REST équivalents sont GET /identity/conditionalAccess/policies et GET /identity/conditionalAccess/namedLocations.

Dans la réponse Graph, un emplacement basé sur IP est de type #microsoft.graph.ipNamedLocation avec isTrusted et ipRanges[].cidrAddress ; un emplacement pays est de type #microsoft.graph.countryNamedLocation avec countriesAndRegions et includeUnknownCountriesAndRegions. Seul le premier type est appliqué en temps réel par CAE. Un contrôle de navigateur persistant apparaît comme persistentBrowser avec un mode valant always ou never, et la fréquence de connexion comme signInFrequency avec un frequencyInterval valant timeBased ou everyTime.

La table SigninLogs d'Azure Monitor contient toutes ces informations. Une requête de départ pour le problème de chemin scindé :

SigninLogs
| where TimeGenerated > ago(7d)
| where isnotempty(IPAddressFromResourceProvider)
| where IPAddressFromResourceProvider != IPAddress
| summarize Sessions = count(),
            Users = dcount(UserPrincipalName)
        by AppDisplayName, IPAddress, IPAddressFromResourceProvider, ConditionalAccessStatus
| order by Sessions desc

La référence de la table SigninLogs de Microsoft décrit IPAddressFromResourceProvider comme « l'adresse IP utilisée par un utilisateur pour atteindre un fournisseur de ressource, utilisée pour déterminer la conformité à l'accès conditionnel pour certaines stratégies… Cette valeur est souvent nulle » — null est le cas sain, signifiant que les deux vues concordent. Son équivalent dans le portail est la colonne Adresse IP (vue par la ressource) des journaux de connexion, et Microsoft fournit un modèle de classeur public, Continuous Access Evaluation Insights, pour faire apparaître les mêmes incohérences.

Remédiation

1. Convertissez les emplacements critiques pour l'application en emplacements nommés basés sur IP. Microsoft : « Si vous voulez que vos stratégies d'emplacement soient appliquées en temps réel par l'évaluation continue de l'accès, utilisez uniquement la condition d'emplacement d'accès conditionnel basée sur IP et configurez toutes les adresses IP, y compris IPv4 et IPv6, visibles par votre fournisseur d'identité et votre fournisseur de ressources. » Réservez les emplacements pays au blocage grossier uniquement, et rappelez-vous qu'un emplacement marqué comme fiable « ne peut pas être supprimé sans d'abord retirer la désignation de confiance ».

2. Recensez chaque IP de sortie — les deux points de vue. Incluez les adresses vues par Entra lors de l'authentification et les adresses vues par Exchange Online, SharePoint Online, Teams et Microsoft Graph. Ne surchargez pas la liste : « N'ajoutez pas d'IP de sortie non dédiées ou non énumérables dans les règles d'accès conditionnel des emplacements nommés de confiance, car cela peut affaiblir la sécurité. » Gardez le total à l'échelle du tenant sous 5 000 plages.

3. Corrigez proprement l'angle mort du proxy. Avec un proxy cloud ou un VPN, « l'adresse IP que Microsoft Entra ID utilise lors de l'évaluation d'une stratégie est l'adresse IP du proxy. L'en-tête X-Forwarded-For (XFF)… n'est pas utilisé car il n'existe aucune validation garantissant qu'il provient d'une source fiable. » Microsoft recommande la restauration de l'IP source via Global Secure Access, ou un contrôle basé sur l'appareil plutôt qu'une liste d'IP.

4. Alors seulement, envisagez l'application stricte de l'emplacement. Validez d'abord avec le classeur CAE et le filtre Adresse IP (vue par la ressource). La mise en garde de Microsoft : « Si le trafic vers Microsoft Entra ID ou une ressource compatible CAE passe par une IP de sortie partagée ou non identifiable, n'activez pas l'application stricte de l'emplacement dans vos stratégies d'accès conditionnel. » Déployez groupe par groupe.

5. Réglez le navigateur persistant sur never — et ciblez-le correctement. Graph documente la contrainte directement sur la propriété : « Toutes les applications doivent être sélectionnées pour que ce contrôle de session fonctionne correctement. » Une stratégie de navigateur persistant ciblant un sous-ensemble d'applications ne fait pas ce que son nom implique.

6. Ne vous reposez pas uniquement sur la condition de plateforme. Associez Device platforms à la conformité Intune ou à la condition Filter for devices. Notez que l'ancienne condition Device state est dépréciée, et que « l'état de l'appareil et les filtres pour les appareils ne peuvent pas être utilisés ensemble dans une stratégie d'accès conditionnel ».

7. Éliminez deux conflits connus avant d'activer la fréquence de connexion. Désactivez d'abord « Se souvenir du MFA sur les appareils de confiance » — « utiliser ces deux paramètres ensemble peut inviter les utilisateurs à se réauthentifier de façon inattendue » — et ne mélangez pas les contrôles de session avec l'ancienne fonctionnalité de durée de vie de jeton configurable, que « Microsoft a retirée… pour les durées de vie des jetons d'actualisation et de session le 30 janvier 2021 ».

8. Révoquez explicitement pendant un incident. Comme les modifications de stratégie mettent jusqu'à un jour (deux heures avec optimisation) pour atteindre les fournisseurs de ressources, utilisez l'action directe :

Import-Module Microsoft.Graph.Users.Actions

# A UPN can also be used as -UserId.
Revoke-MgUserSignInSession -UserId $userId

Revoke-MgUserSignInSession « invalide tous les jetons d'actualisation émis aux applications pour un utilisateur (ainsi que les cookies de session dans le navigateur de l'utilisateur), en réinitialisant la propriété utilisateur signInSessionsValidFromDateTime à la date-heure actuelle ». Elle nécessite au minimum User.RevokeSessions.All. L'équivalent dans le portail est Revoke Session sur la page de profil de l'utilisateur. Confirmez que vos comptes break-glass sont exclus de toute stratégie d'emplacement avant de la durcir.

9. Ajoutez la protection de jeton là où le client la prend en charge. La protection de jeton « vise à réduire les attaques par vol de jeton en garantissant qu'un jeton n'est utilisable que depuis l'appareil prévu », et la colonne TokenProtectionStatusDetails de SigninLogs indique si un jeton de connexion était lié à son appareil.

Comment EtcSec détecte cela

Un audit Azure EtcSec lit vos stratégies d'accès conditionnel et vos emplacements nommés via Microsoft Graph et signale les lacunes de configuration derrière chacun des scénarios ci-dessus : CA_NO_SESSION_CONTROLS quand aucune stratégie activée ne définit de fréquence de connexion ni de mode de navigateur persistant, CA_PERSISTENT_BROWSER_ENABLED quand les cookies de navigateur sont autorisés à persister, CA_NO_NAMED_LOCATIONS et CA_NO_TRUSTED_LOCATIONS quand le tenant n'a aucun vocabulaire d'emplacement pour que CAE puisse l'appliquer, CA_NO_LOCATION_BLOCK quand aucune stratégie ne bloque sur l'emplacement, et CA_NO_PLATFORM_FILTER quand aucune stratégie ne cible par plateforme d'appareil. Ces éléments s'articulent naturellement avec l'analyse plus large dans failles de l'accès conditionnel Entra ID, lacunes de couverture des stratégies de base, et le guide complet d'audit de sécurité Entra ID.