Un message Teams venu d'un tenant externe, un interlocuteur qui se présente comme le helpdesk, une demande d'ouverture de Quick Assist : le scénario analysé par Microsoft Threat Intelligence le 2 septembre 2026 repose sur un réglage que Teams laisse ouvert par défaut. Cet article montre comment passer à une liste d'autorisation de domaines, l'amorcer depuis vos invités Microsoft Entra ID et valider le comportement dans un tenant de test avant la production.
Pourquoi l'accès externe ouvert par défaut profite aux faux support IT
Par défaut, Teams autorise tous les domaines externes, comme le précise la documentation Microsoft Learn. Un attaquant n'a donc qu'à créer un tenant, contacter vos utilisateurs et se faire passer pour l'IT ou le helpdesk. Dans les intrusions décrites par Microsoft Threat Intelligence, il pousse ensuite la victime à ouvrir Quick Assist ou à accepter une demande de contrôle à distance.
Teams affiche pourtant des garde-fous : étiquette de tenant externe, invite Accepter/Bloquer, aperçu du message. Mais ils n'agissent que si l'utilisateur ne les contourne pas. Tony Redmond, MVP, tire la même conclusion : les avertissements ne suffisent pas, puisque l'utilisateur peut quand même accepter la connexion. Il recommande une liste d'autorisation plutôt qu'un accès ouvert, au prix de sa maintenance.
Décembre 2024
Avis d'un MVP sur le chat fédéré
Tony Redmond plaide pour une liste d'autorisation contre l'usurpation d'identité de marque dans le chat fédéré.
Novembre 2025
Campagne de vishing Teams découverte
L'équipe DART de Microsoft découvre une campagne où l'attaquant usurpe le support IT.
16 mars 2026
Rapport DART
Microsoft recommande un modèle de liste d'autorisation limitée aux domaines externes de confiance et la restriction des comptes Teams non gérés entrants.
2 septembre 2026
Analyse Microsoft Threat Intelligence
Chaîne d'attaque détaillée, de la fausse demande de support à l'accès étendu à l'entreprise.
Ce réglage s'inscrit dans un ensemble plus large de contrôles : notre guide Teams Security Baseline 2026 le replace parmi les autres vecteurs d'attaque modernes.
Comment Teams filtre les domaines externes
L'accès externe se règle par domaine, selon trois modes. Le choix du mode conditionne aussi ce que votre équipe sécurité peut faire dans Microsoft Defender.
| Mode | Comportement | Gestion via Defender (Tenant Allow/Block List) | Charge de maintenance |
|---|---|---|---|
| Allow all external domains | Tous les domaines sont autorisés (valeur par défaut) | Compatible | Aucune, mais aucune barrière |
| Block only specific domains | Seuls les domaines listés sont bloqués | Compatible | Liste de blocage à alimenter au fil des incidents |
| Allow only specific external domains | Tous les domaines sont bloqués sauf ceux de la liste | Non compatible | Liste d'autorisation à tenir à jour |
Trois mécanismes méritent d'être compris avant de basculer.
- L'accès externe est bilatéral. Le partenaire doit aussi autoriser votre domaine et activer l'accès externe pour ses utilisateurs, sinon le chat échoue. Un domaine ajouté chez vous ne suffit pas.
- Des politiques granulaires existent. Elles permettent des listes différentes par utilisateur ou groupe (finance, direction, support IT). Une politique personnalisée assignée à un utilisateur prime sur les paramètres de l'organisation, et le réglage « Manage external domains for this organization » doit être activé au niveau de l'organisation.
- La gestion Defender a un prérequis de licence. La Tenant Allow/Block List exige Defender for Office 365 Plan 1 ou 2, et ne fonctionne qu'avec « Block only specific domains » ou « Allow all ». Pour la vue d'ensemble de l'offre, consultez notre article sur la plateforme Microsoft Defender.
Configurer la liste d'autorisation : portail ou PowerShell
Prérequis avant de modifier le réglage
- Un compte disposant d'un rôle d'administration Teams sur le tenant (vérifiez dans votre tenant que le rôle choisi suffit, en appliquant le moindre privilège)
- Le module PowerShell MicrosoftTeams installé (Install-Module MicrosoftTeams -Scope CurrentUser)
- L'inventaire des domaines partenaires, fournisseurs et clients avec lesquels vos équipes échangent réellement
- Un tenant de test configuré pour valider la procédure (voir plus bas)
Dans le centre d'administration Teams, ouvrez Utilisateurs (ou Collaboration externe selon le tenant) puis Accès externe. Le libellé du menu varie d'un tenant à l'autre. Choisissez « Allow only specific external domains », puis ajoutez chaque domaine autorisé et enregistrez.
Impact sur tout le tenant
Une fois la liste d'autorisation active, tous les domaines absents de la liste sont bloqués, partenaires légitimes compris. Peuplez la liste avant la bascule et validez d'abord dans un tenant de test. Les pages Microsoft Learn consultées ne donnent pas de délai de propagation : ne concluez pas à un échec dans la minute qui suit la modification.
Mise en œuvre : amorcer la liste depuis vos invités Microsoft Entra ID
Repartir de zéro est le meilleur moyen de couper des échanges légitimes. Tony Redmond propose d'amorcer la liste avec les domaines des comptes invités du tenant ou ceux des chats fédérés existants, puis de la compléter à la main. Le script ci-dessous automatise la première piste.
- Modules : Microsoft.Graph.Users et MicrosoftTeams (Install-Module Microsoft.Graph.Users -Scope CurrentUser, puis Install-Module MicrosoftTeams -Scope CurrentUser)
- Permission Graph minimale : User.Read.All en délégué, lecture seule
- Sortie : un fichier CSV des domaines candidats ; avec l'option de simulation, rien n'est modifié
- Filtre : les domaines de messagerie grand public sont exclus par défaut, à adapter à votre contexte
1#Requires -Version 5.12[CmdletBinding()]3param(4 [switch]$DryRun,5 [string[]]$DomainesExclus = @('gmail.com','outlook.com','hotmail.com','yahoo.com'),6 [string]$CheminCsv = '.\domaines-invites.csv'7)8 9# 1. Connexion à Microsoft Graph en lecture seule10Connect-MgGraph -Scopes 'User.Read.All' -NoWelcome11 12# 2. Récupération des invités et extraction du domaine de leur adresse e-mail13$invites = Get-MgUser -Filter "userType eq 'Guest'" -All -Property Id,Mail14$domaines = $invites |15 Where-Object { $_.Mail } |16 ForEach-Object { ($_.Mail -split '@')[-1].ToLower() } |17 Where-Object { $_ -notin $DomainesExclus } |18 Sort-Object -Unique19 20# 3. Export pour revue manuelle avant toute écriture21$domaines | ForEach-Object { [pscustomobject]@{ Domaine = $_ } } |22 Export-Csv -Path $CheminCsv -NoTypeInformation -Encoding UTF823Write-Host "$($domaines.Count) domaine(s) candidat(s) exporté(s) vers $CheminCsv"24 25# 4. Mode simulation : on s'arrête avant de toucher à Teams26if ($DryRun) {27 Write-Host 'Simulation : aucune modification effectuée.'28 return29}30 31# 5. Ajout des domaines à la liste d'autorisation Teams32Connect-MicrosoftTeams33foreach ($domaine in $domaines) {34 Set-CsTenantFederationConfiguration -AllowedDomainsAsAList @{Add=$domaine}35 Write-Host "Ajouté : $domaine"36}37 38# 6. Vérification du résultat39Get-CsTenantFederationConfiguration | Format-List AllowedDomains, BlockedDomains, BlockAllSubdomainsLancez d'abord le script avec -DryRun, relisez le CSV, retirez les domaines douteux, puis exécutez-le sans l'option. Complétez ensuite à la main avec les partenaires qui n'ont jamais été invités dans le tenant.
Tester un message externe dans un tenant de test
Le test doit prouver deux choses : un domaine autorisé passe, un domaine inconnu est bloqué. Comme l'accès est bilatéral, le tenant de test doit autoriser le domaine du tenant de production, et inversement.
Autoriser les deux domaines de part et d'autre
Dans le tenant de test, ajoutez le domaine de production à la liste d'autorisation. Dans le tenant de production (ou son environnement de pré-production), ajoutez le domaine de test. Activez l'accès externe des deux côtés.
Vérifier la configuration appliquée
Controlez que la liste contient bien les domaines attendus.
1Connect-MicrosoftTeams2Get-CsTenantFederationConfiguration | Format-List AllowedDomains, BlockedDomains, BlockAllSubdomainsEnvoyer un message depuis un domaine autorisé
Depuis un compte du tenant de test, écrivez à un utilisateur de production. Observez ce que voit le destinataire : étiquette de tenant externe, invite Accepter/Bloquer, aperçu du message. La page Microsoft Learn sur les indicateurs de confiance détaille ces représentations.
Retirer le domaine et recommencer
Supprimez le domaine de test de la liste de production, patientez, puis renvoyez un message. Le chat doit échouer. Pour nettoyer les conversations de test, voir notre article sur la suppression d'un chat externe pour un utilisateur.
Tester les cas limites
Essayez un sous-domaine d'un domaine autorisé, puis la jonction anonyme à une réunion depuis un domaine non autorisé. Ces deux cas sont les pièges détaillés ci-dessous.
Pièges documentés et dépannage
Bloquer contoso.com ne bloque pas ses sous-domaines, sauf si vous activez BlockAllSubdomains :
1Set-CsTenantFederationConfiguration -BlockAllSubdomains $TrueAutre limite : les personnes d'un domaine bloqué peuvent encore rejoindre vos réunions en anonyme si l'accès anonyme est autorisé. La liste d'autorisation ne remplace donc pas la revue de vos paramètres de réunion.
| Symptôme | Cause probable | Résolution |
|---|---|---|
| Le chat avec un partenaire de confiance échoue | Le partenaire n'autorise pas votre domaine ou n'a pas activé l'accès externe | Demander au partenaire d'ajouter votre domaine et d'activer l'accès externe de son côté |
| Un sous-domaine d'un domaine bloqué passe encore | Le blocage ne couvre pas les sous-domaines par défaut | Activer BlockAllSubdomains avec Set-CsTenantFederationConfiguration -BlockAllSubdomains $True |
| Un utilisateur d'un domaine bloqué rejoint une réunion | L'accès anonyme aux réunions est autorisé | Revoir les paramètres d'accès anonyme des réunions |
| La Tenant Allow/Block List de Defender n'a aucun effet | Le mode « Allow only specific external domains » est actif, ou la licence Defender for Office 365 Plan 1 ou 2 est absente | Gérer la liste dans Teams, ou revenir à « Block only specific domains » ou « Allow all » avec la licence requise |
| Une règle différente doit s'appliquer à une équipe | Réglage organisationnel unique | Créer une politique d'accès externe personnalisée et activer « Manage external domains for this organization » |
| Le menu Accès externe est introuvable | Le libellé varie selon les tenants | Chercher sous Utilisateurs ou Collaboration externe dans le centre d'administration Teams |
La liste réduit la surface, elle ne vérifie rien
Un domaine autorisé peut lui-même être compromis. Microsoft recommande aussi de vérifier toute demande de support par un canal interne connu et de mettre en place une phrase d'authentification. Sans ces réflexes, un attaquant qui contrôle un domaine de confiance reste crédible.
Questions fréquentes
Une liste d'autorisation suffit-elle à bloquer les faux appels du support IT ?
Non, elle réduit fortement la surface d'attaque en coupant les tenants inconnus, mais elle ne suffit pas seule. Microsoft recommande de la combiner avec la vérification de toute demande de support par un canal interne et avec une phrase d'authentification. L'équipe DART recommande aussi de restreindre les comptes Teams non gérés entrants.
Dois-je prévenir mes partenaires avant d'activer la liste ?
Oui. Le chat externe est bilatéral : le partenaire doit autoriser votre domaine et activer l'accès externe pour ses utilisateurs, sinon la conversation échoue. Ce point vaut aussi pour votre tenant de test.
Puis-je appliquer des listes différentes selon les services ?
Oui, via des politiques d'accès externe granulaires, par exemple pour la finance, la direction ou le support IT. Une politique personnalisée assignée à un utilisateur prime sur le paramètre de l'organisation. Le réglage « Manage external domains for this organization » doit être activé au niveau de l'organisation.
Puis-je gérer ma liste depuis la Tenant Allow/Block List de Defender ?
Seulement avec « Block only specific domains » ou « Allow all », et avec Defender for Office 365 Plan 1 ou 2. Avec une liste d'autorisation, la gestion se fait dans Teams.
Par où commencer
Prochaines actions
- Exécuter le script avec -DryRun et relire le CSV des domaines candidats
- Compléter la liste avec les partenaires absents des invités Entra et les domaines des chats fédérés existants
- Valider la procédure dans le tenant de test, sous-domaines et réunions anonymes compris
- Prévenir les partenaires critiques pour qu'ils autorisent votre domaine
- Basculer sur « Allow only specific external domains » et relancer Get-CsTenantFederationConfiguration pour contrôler le résultat
- Rappeler aux utilisateurs la procédure de vérification d'une demande de support par un canal interne
Si votre organisation compte beaucoup de partenaires qui changent souvent, commencez par « Block only specific domains » et une politique granulaire pour les populations sensibles (finance, direction, support IT), puis resserrez progressivement. Si vous disposez déjà de Defender for Office 365 Plan 1 ou 2 et privilégiez la gestion centralisée par l'équipe sécurité, gardez en tête que cette gestion est incompatible avec la liste d'autorisation.
Pour aller plus loin
- Gérer les réunions et chats externes (organisations de confiance) – Microsoft Learn : la référence sur les listes d'autorisation et de blocage, les politiques granulaires et les prérequis Defender.
- Impersonating IT support: how threat actors turn a remote session into enterprise-wide access : la chaîne d'attaque détaillée et les recommandations de Microsoft.
- Help on the line: How a Microsoft Teams support call led to compromise : le retour d'incident de Microsoft DART et le modèle de liste d'autorisation recommandé.
- Thwarting Social Engineering Attacks Against Teams Federated Chat : l'avis d'un MVP sur le coût de maintenance et les méthodes pour constituer la liste.
- Representation of users outside your organization (trust indicators) : ce que voit l'utilisateur pour un domaine autorisé ou inconnu, utile pour valider votre test.
