MENU
  1. Accueil
  2. Microsoft 365
  3. Whitelist Microsoft : FQDN/URL/IP à autoriser pour Windows Update, Microsoft 365 et Teams (guide SWG/SASE)

Whitelist Microsoft : FQDN/URL/IP à autoriser pour Windows Update, Microsoft 365 et Teams (guide SWG/SASE)

Microsoft 365

Vous devez laisser passer Windows Update, Office/Teams, Intune et Defender via votre Secure Web Gateway / SASE ? Voici un guide opérationnel pour bâtir une whitelist fiable à partir des flux officiels (JSON Microsoft 365, Service Tags Azure) et l’automatiser en PowerShell.

Sommaire

Vue d’ensemble de la question

Les mises à jour Microsoft (Windows, Microsoft 365 Apps, Teams nouvelle application, Defender, Store, Intune/Endpoint Manager, Azure DevOps, etc.) s’appuient sur un ensemble dynamique de FQDN, d’URL, d’adresses IP et de ports. Une liste figée vieillit très vite et conduit à des blocages, des « timeouts », des retards de déploiement et des régressions fonctionnelles (ex. Teams 2.x qui ne charge pas, Windows Update qui reste en « Téléchargement en attente », etc.).

La réponse robuste consiste à consommer automatiquement les sources officielles Microsoft (flux JSON Microsoft 365, Service Tags Azure, pages produits dédiées) et à pousser quotidiennement les entrées dans votre passerelle/SASE. Vous trouverez ci‑dessous : la cartographie par service, des modèles de règles, du code PowerShell prêt à l’emploi, des tableaux de ports et FQDN « cœurs », ainsi qu’un playbook de validation et de diagnostic.

Pourquoi une liste statique n’est jamais « exhaustive »

  • CDN et Anycast : les ressources (installateurs, médias, mises à jour delta) sont servies via des CDN Microsoft/Azure avec hostnames et edges qui évoluent.
  • Routage optimisé : Microsoft bascule régulièrement des charges vers de nouveaux POP/Front Door. Vos IPs autorisées d’hier ne couvrent pas forcément demain.
  • Éditions Cloud : Worldwide, Allemagne, Chine (opéré par 21Vianet), US Gov… Chaque instance publie ses propres endpoints.
  • Nouveaux produits : la « Nouvelle application Microsoft Teams » (client 2.x) ou de nouvelles fonctions Defender publient des dépendances supplémentaires.

D’où la stratégie recommandée : ingestion automatisée des flux + règles génériques par catégorie (Optimize/Allow/Default pour Microsoft 365) + surveillance continue.

Jeux de données officiels à consommer

Microsoft met à disposition des sources normalisées orientées réseau :

FamilleRessource de référenceFormatUsage recommandé dans la passerelle/SASE
Microsoft 365 (Exchange, SharePoint/OneDrive, Teams, Common)Service « endpoints » Microsoft 365 (instance : Worldwide, Germany, China, GCC, GCC High)JSON (catégories Optimize / Allow / Default, champs urls, ips, tcpPorts, udpPorts)Créer/mettre à jour chaque jour des URL categories, IP sets et règles « no SSL inspection » pour Optimize
Windows Update & Delivery OptimizationService Tags Azure (ex. WindowsUpdate, AzureFrontDoor.FirstParty)API Az PowerShell / Azure CLI ou JSON hebdoAutoriser IP ranges au niveau pare‑feu, permettre 80/443 et 7680 (Delivery Optimization P2P)
Microsoft StoreDocumentation produit + dépendances Delivery OptimizationFQDN + portsAjouter les hôtes Store aux catégories « Microsoft Updates » et DO
Intune / Autopilot (Endpoint Manager)Documentation Intune/Autopilot, dépendances AADFQDN + portsAutoriser MDM/MA, en particulier durant le pre‑logon (Autopilot)
Defender for Endpoint & Windows DefenderDocumentation Defender (services capteurs, remontées télémétriques)FQDN + portsAutoriser remontées vers les passerelles régionales, pas d’inspection pour la télémétrie sensible
Azure DevOpsDocumentation Azure DevOpsFQDN + portsAutoriser dev et pkgs, ainsi que le trafic agent si pipelines

Note : ce guide n’inclut pas de liens hypertexte. Les noms ci‑dessus désignent les flux/ressources officiels publiés par Microsoft et connus des équipes réseau.

Modèles de whitelist par grands produits

Les listes ci‑dessous servent de socle pour initialiser la passerelle avant d’automatiser l’ingestion. Elles s’appuient sur des patrons stablement utilisés par Microsoft. Ne les considérez pas comme exhaustives : l’automatisation reste la source de vérité.

Windows Update et Delivery Optimization

  • FQDN clés :
    • *.windowsupdate.com, *.update.microsoft.com, download.windowsupdate.com
    • *.delivery.mp.microsoft.com et hôtes dl/tlu utilisés par Delivery Optimization
    • Éléments de test de connectivité Windows (ex. *.msftconnecttest.com) utiles au diagnostic
  • Ports/Protocoles :
    • HTTP 80, HTTPS 443
    • Delivery Optimization P2P : TCP/UDP 7680 (intra‑LAN/intra‑site selon votre politique)
    • WSUS on‑prem : 8530 (HTTP), 8531 (HTTPS) vers vos serveurs WSUS
  • Service Tags conseillés (pare‑feu) : WindowsUpdate, AzureFrontDoor.FirstParty
  • Inspection TLS : à désactiver pour les contenus Optimize et Windows Update afin d’éviter les ruptures de signature.

Microsoft 365 Apps (Office) & Office Click‑to‑Run

  • FQDN clés :
    • officecdn.microsoft.com (CDN Office)
    • Familles *.office.com, *.office365.com, *.microsoftonline.com (authentification AAD, services communs)
  • Ports : HTTPS 443 (prioritaire), HTTP 80 (occasionnellement pour redirections/CDN).
  • Catégories JSON : privilégier Optimize, puis Allow, enfin Default.

Microsoft Teams (nouvelle application incluse)

  • FQDN clés : *.teams.microsoft.com (service principal Teams), dépendances Microsoft 365 et CDN Microsoft/Azure.
  • Médias temps réel :
    • UDP 3478–3481 (STUN/TURN) obligatoire pour la qualité audio/vidéo;
    • Fallback TCP 443 si UDP non disponible (dégradé).
  • QoS conseillé : DSCP Voix ≈ 46, Vidéo ≈ 34, Partage ≈ 18 (à adapter à votre plan de marquage).
  • Inspection TLS : éviter sur les flux médias et Optimize.

Intune / Autopilot

  • FQDN clés :
    • *.manage.microsoft.com, device.management.microsoft.com, enrollment.manage.microsoft.com
    • Service Autopilot (ex. ztd.dds.microsoft.com)
    • Azure AD : login.microsoftonline.com, enterpriseregistration.windows.net
  • Contexte pré‑connexion : configurer une allowlist fonctionnelle même sans session utilisateur (proxy explicite, authentification transparente, PAC/WPAD).

Defender (Microsoft Defender for Endpoint et signatures Windows Defender)

  • FQDN clés :
    • Passerelles Defender (ex. *.securitycenter.windows.com ou équivalents régionaux modernes)
    • Télémétrie et paramètres Windows : *.events.data.microsoft.com, *.settings-win.data.microsoft.com
  • Inspection TLS : déconseillée pour ne pas altérer l’intégrité des capteurs.

Microsoft Store

  • FQDN clés : hôtes store Microsoft et dépendances Delivery Optimization.
  • Cas pratique : autoriser les téléchargements d’images/manifestes (icônes, métadonnées) pour éviter des anomalies UX dans l’entreprise.

Azure DevOps

  • FQDN clés : dev.azure.com, *.visualstudio.com, pkgs.dev.azure.com, ressources de stockage d’artefacts.
  • Agents : prévoir les sorties nécessaires vers les services ADO si vous exécutez des pipelines on‑prem.

Mise en œuvre automatisée : scripts et pipelines

Les extraits ci‑dessous illustrent une automatisation de bout en bout : télécharger les endpoints, produire des fichiers de référence (CSV/TXT) et les exposer à votre passerelle (EDL/Threat Feed/Catégorie URL).

Récupérer le JSON Microsoft 365 et générer des listes

# Paramètres
param(
  [ValidateSet('Worldwide','Germany','USGov','USGovGCCHigh','China')]
  [string]$Instance = 'Worldwide',
  [string]$OutDir = 'C:\_m365_endpoints',
  [switch]$SplitByCategory,
  [switch]$SplitByServiceArea # Exchange/SharePoint/Teams/Common
)

# Création du répertoire de sortie

New-Item -Path $OutDir -ItemType Directory -Force | Out-Null

# Construction de l'URL du service endpoints M365 sans insérer de lien cliquable dans ce document

$base = ('https' + '://endpoints.office.com')
$clientId = [guid]::NewGuid().Guid
$uri = "$base/endpoints/$Instance?ClientRequestId=$clientId"

# Récupération du JSON

Write-Host "Téléchargement des endpoints Microsoft 365 ($Instance)..."
$data = Invoke-RestMethod -Method Get -Uri $uri

# Sélection des champs utiles

$records = foreach($item in $data){
[PSCustomObject]@{
id            = $item.id
category      = $item.category
serviceArea   = $item.serviceArea
serviceName   = $item.serviceAreaDisplayName
urls          = ($item.urls -join ';')
ips           = ($item.ips  -join ';')
tcpPorts      = $item.tcpPorts
udpPorts      = $item.udpPorts
expressRoute  = $item.expressRoute
notes         = $item.notes
}
}

# Exports globaux

$csvAll = Join-Path $OutDir 'm365_endpoints_all.csv'
$records | Sort-Object serviceArea, category, id | Export-Csv -Path $csvAll -NoTypeInformation -Encoding UTF8

# Listes URL et IP (dédupliquées)

$allUrls = $data.urls | Where-Object { $_ } | Sort-Object -Unique
$allIps  = $data.ips  | Where-Object { $_ } | Sort-Object -Unique
$allUrls | Set-Content -Path (Join-Path $OutDir 'm365_urls_all.txt') -Encoding UTF8
$allIps  | Set-Content -Path (Join-Path $OutDir 'm365_ips_all.txt')  -Encoding ASCII

# Découpes optionnelles

if($SplitByCategory){
$cats = $data | Group-Object category
foreach($c in $cats){
$u = $c.Group.urls | Where-Object { $_ } | Sort-Object -Unique
$i = $c.Group.ips  | Where-Object { $_ } | Sort-Object -Unique
$u | Set-Content -Path (Join-Path $OutDir ("urls_{0}.txt" -f $c.Name.ToLower())) -Encoding UTF8
$i | Set-Content -Path (Join-Path $OutDir ("ips_{0}.txt"  -f $c.Name.ToLower())) -Encoding ASCII
}
}

if($SplitByServiceArea){
$areas = $data | Group-Object serviceArea
foreach($a in $areas){
$u = $a.Group.urls | Where-Object { $_ } | Sort-Object -Unique
$i = $a.Group.ips  | Where-Object { $_ } | Sort-Object -Unique
$u | Set-Content -Path (Join-Path $OutDir ("urls_{0}.txt" -f $a.Name.ToLower())) -Encoding UTF8
$i | Set-Content -Path (Join-Path $OutDir ("ips_{0}.txt"  -f $a.Name.ToLower())) -Encoding ASCII
}
}

Write-Host "Fichiers générés dans $OutDir"

Utilisation recommandée : utilisez urls_optimize.txt pour créer une catégorie « M365 Optimize » avec bypass TLS inspection et priorité d’acheminement; ajoutez ensuite urls_allow.txt puis urls_default.txt à vos règles plus génériques. Les fichiers IP peuvent alimenter des IP Sets côté pare‑feu.

Extraire les Service Tags Azure (Windows Update, Front Door…)

Cette variante s’appuie sur le module Az PowerShell pour éviter la gestion d’un fichier JSON volumineux. Elle nécessite un compte Azure (lecture publique des tags).

# Prérequis: Install-Module Az -Scope AllUsers
Connect-AzAccount | Out-Null

# Récupération des Service Tags pour une région (peu importe pour les services "Global")

$location = 'westeurope'
$tags = Get-AzNetworkServiceTag -Location $location

# Extraction WindowsUpdate & AzureFrontDoor.FirstParty

$wu = $tags.Values | Where-Object { $*.Properties.SystemService -eq 'WindowsUpdate' }
$afd = $tags.Values | Where-Object { $*.Properties.SystemService -eq 'AzureFrontDoor.FirstParty' }

# Adresses IP agrégées

$wuIps  = $wu.Properties.AddressPrefixes  | Sort-Object -Unique
$afdIps = $afd.Properties.AddressPrefixes | Sort-Object -Unique

# Export

$out = 'C:_m365_endpoints'
New-Item -ItemType Directory -Path $out -Force | Out-Null
$wuIps  | Set-Content -Path (Join-Path $out 'ips_windowsupdate.txt') -Encoding ASCII
$afdIps | Set-Content -Path (Join-Path $out 'ips_azurefrontdoor_firstparty.txt') -Encoding ASCII

Publiez ces fichiers comme External Dynamic Lists (EDL) / Threat Feeds dans votre passerelle. Programmez le job quotidien via Scheduled Tasks.

Modèles de règles pour SWG / SASE

PrioritéDestinationPorts/ProtosActionInspection TLSNotes
1 (plus haut)Catégorie M365 Optimize (depuis JSON)TCP 443 (+ UDP 3478–3481 pour Teams)AllowBypassTrafic critique, sensibilité à la latence
2Service Tag WindowsUpdateTCP 80/443AllowBypassÉviter proxying/caching agressif
3Delivery Optimization P2P (intra)TCP/UDP 7680Allow (segmentation)N/ALimiter au LAN/site selon politique
4Catégorie M365 AllowTCP 443AllowBypass si recommandéServices importants mais moins sensibles
5Catégorie M365 DefaultTCP 443AllowInspect possibleSurveiller les effets
6Intune/Autopilot & AADTCP 443AllowBypassImpératif en pre‑logon
7Defender (portails/télémétrie)TCP 443AllowBypassSensibilité au MITM

DNS/SNI : si votre SWG s’appuie sur le SNI/TLS pour catégoriser, créez des règles hostname‑based (ex. patrons ^(.+\.)?windowsupdate\.com$, ^(.+\.)?office\.com$, ^(.+\.)?teams\.microsoft\.com$) en complément des listes JSON.

Cartographie synthétique des ports

ServicePorts requisCommentaires réseau
Windows UpdateTCP 80, 443Préférer sortie directe. Éviter proxy de contenu agressif.
WSUS (on‑prem)TCP 8530, 8531Vers vos hôtes WSUS uniquement.
Delivery OptimizationTCP/UDP 7680Intra‑LAN/site. Autoriser selon votre stratégie P2P.
Microsoft 365 Apps / Office CDNTCP 443 (80 optionnel)Bypass TLS inspection sur Optimize.
Teams (signalisation)TCP 443Hostname teams + dépendances Microsoft 365.
Teams (médias)UDP 3478–3481; fallback TCP 443UDP indispensable pour qualité. Prioriser (QoS).
Intune / AutopilotTCP 443Prévoir politiques applicables avant logon (proxy/WPAD).
Defender / TélémétrieTCP 443Pas d’inspection TLS pour éviter l’altération des capteurs.
Azure DevOpsTCP 443Autoriser agents et dépôts/artefacts (dev, pkgs).

Playbook d’industrialisation

Pipeline quotidien

  1. Collecte (05:00) : script PowerShell télécharge le JSON Microsoft 365 et extrait les Service Tags essentiels.
  2. Génération : création de fichiers TXT/CSV par catégorie et service.
  3. Publication : exposition des fichiers via un point HTTP interne (ou stockage objet) consommé par votre SWG/SASE (EDL/Threat Feed/URL Category API).
  4. Validation : comparaison des nouvelles listes avec la veille (diff) et remontée d’un change summary au NOC/SecOps.
  5. Application : déclenchement d’un commit poussé sur la passerelle, avec rollback automatique si l’API retourne une erreur.

Stratégie de décryptage TLS

  • Bypass systématique pour les catégories Optimize Microsoft 365, Windows Update, Defender et flux médias Teams.
  • Inspection tolérée pour certaines entrées Default après tests, en excluant authentification AAD et portails critiques.

Modèle de sécurité

  • Limiter l’autorisation des IPs au strict nécessaire via Service Tags (pare‑feu) et appliquer les FQDN/SNI via la passerelle HTTP/S.
  • Établir un processus d’exception documenté et réversible (expiration, propriétaire, justification).
  • Garder un inventaire centralisé des règles dérivées (qui/quoi/pourquoi/quand).

Procédures de test et de diagnostic

Avant déploiement global, mettez en place un pilote (poste Windows 11, profil utilisateur, réseau d’agence) et testez :

Windows Update

# Connectivité de base
Test-NetConnection download.windowsupdate.com -Port 443
# Journal Delivery Optimization
Get-DeliveryOptimizationStatus
Get-DeliveryOptimizationPerfSnap
# Déclencheur d’analyse (à lancer en tant qu'admin)
UsoClient StartScan

Microsoft 365 (Exchange/SharePoint/Teams)

# Exemple : contrôle des URLs Teams (extrait des fichiers générés)
$urls = Get-Content 'C:\_m365_endpoints\urls_optimize.txt' | Where-Object { $_ -match 'teams' }
$urls | ForEach-Object { Test-NetConnection $_ -Port 443 }

Intune/Autopilot

# Vérification inscription MDM
Test-NetConnection enrollment.manage.microsoft.com -Port 443
# Résolution AAD
Test-NetConnection login.microsoftonline.com -Port 443

Débogage proxy

# Vérifier la configuration WinHTTP (contexte système)
netsh winhttp show proxy
# Remise à zéro si besoin
netsh winhttp reset proxy

FAQ : points d’attention et erreurs courantes

  • « J’ai tout ouvert vers *.microsoft.com, ça devrait passer ! » : trop large et incomplet. Une partie du trafic passe par des domaines first‑party spécifiques et des CDN. Utilisez les flux officiels.
  • « On inspecte tout en TLS » : les signatures/manifestes peuvent échouer. Bypass sur Optimize, Windows Update, Defender, médias Teams.
  • « Nos règles UDP sont fermées » : Teams dégradera l’expérience en TCP. Ouvrez UDP 3478–3481 vers les destinations Teams publiées.
  • « On applique après approbation manuelle » : acceptable si vous appliquez au moins les nouvelles entrées en append‑only automatiquement, et retirez les obsolètes via un cycle de revue séparé.
  • « Autopilot échoue derrière proxy » : fournir une sortie directe/transparent proxy pour les FQDN critiques AAD/MDM pendant le device ESP (pre‑logon).

Exemple de politique d’entreprise

Voici une politique type à adapter :

  1. Source of Truth : le JSON Microsoft 365 et les Service Tags Azure sont les seules sources autorisées. Interdiction d’éditer des listes à la main.
  2. Fréquence : mise à jour quotidienne, validation automatique par smoke test, promotion en production si OK.
  3. Inspection : bypass sur Optimize/Windows Update/Defender/Teams médias. Évaluation trimestrielle.
  4. Surveillance : activer la journalisation SWG/SASE, corréler toute erreur 403/407/timeout avec les sources officielles, créer un ticket si l’URL est légitime.
  5. Changements : notifier réseau/sécurité en cas d’ajout massif (ex. nouveaux POP) et planifier des tests ciblés.

FQDN « noyau » pour amorcer la whitelist

À utiliser comme bootstrap minimal avant automatisation :

  • Windows Update : *.windowsupdate.com, download.windowsupdate.com, *.update.microsoft.com, hôtes delivery/dl/tlu mp.microsoft.com.
  • Office CDN : officecdn.microsoft.com.
  • Microsoft 365 commun : *.office.com, *.office365.com, *.microsoftonline.com.
  • Teams : *.teams.microsoft.com + UDP 3478–3481.
  • Intune/Autopilot : device.management.microsoft.com, enrollment.manage.microsoft.com, login.microsoftonline.com, enterpriseregistration.windows.net, ztd.dds.microsoft.com.
  • Defender : passerelles régionales (portails Defender) et *.events.data.microsoft.com, *.settings-win.data.microsoft.com.
  • Azure DevOps : dev.azure.com, pkgs.dev.azure.com, *.visualstudio.com.

Rappel : ces patrons ne dispensent pas d’importer régulièrement les listes officielles.

Intégration dans les solutions courantes

  • Passerelles on‑prem (ex. Palo Alto, FortiProxy) : utiliser les External Dynamic Lists. Publiez vos fichiers TXT/CSV depuis un serveur interne hautement disponible.
  • SASE / SWG cloud (ex. Zscaler, Netskope, Prisma Access) : créer des « URL Categories » et « IP Sets » alimentés par API/Threat Feeds. Ajoutez des règles no‑decrypt pour M365 Optimize/Windows Update/Defender/Teams médias.
  • DNS filtering : si vous appliquez aussi un filtrage DNS, importez les FQDN pour éviter les résolutions bloquées (NXDOMAIN policy).

Surveillance continue et audit

  • Alerting : alerte si le volume de trafic vers Windows Update chute anormalement ou si la latence moyenne vers teams > seuil.
  • Journaux : indexer les 403/407/5xx relatifs aux catégories Microsoft. Joindre le change number du JSON Microsoft 365 du jour.
  • Revue trimestrielle : rejouer les tests pilotes, purger les exceptions expirées, valider les versions client (Teams 2.x, Office LTSC, Windows 11 courant).

Checklist express

  • Importer quotidiennement le JSON Microsoft 365 et les Service Tags clés.
  • Créer des catégories/règles distinctes par Optimize, Allow, Default.
  • Bypass TLS inspection pour Optimize, Windows Update, Defender, médias Teams.
  • Ouvrir UDP 3478–3481 pour Teams.
  • Autoriser Delivery Optimization (TCP/UDP 7680) selon votre périmètre.
  • Prévoir le pré‑logon (Autopilot/AAD/Intune) derrière proxy/SASE.
  • Automatiser la publication (EDL/URL Category API) + validation/rollback.
  • Surveiller et corréler les blocages avec les listes officielles.

Conclusion

Construire une « liste exhaustive » à la main pour les mises à jour Microsoft est une impasse. La bonne approche consiste à brancher vos équipements à la source : flux JSON Microsoft 365 et Service Tags Azure, puis industrialiser la mise à jour des catégories/feeds côté passerelle. Ajoutez des règles de priorisation (Optimize en tête), bypass TLS sur les services sensibles et UDP ouvert pour Teams. Avec cette méthode, vous réduisez les incidents, accélérez les déploiements, et garantissez une expérience stable pour la « Nouvelle application Microsoft Teams », Windows Update et l’ensemble des services Microsoft.

Microsoft 365
Windows Update PowerShell Microsoft 365 Teams Intune SASE
Sommaire