Dans un environnement Microsoft 365 multi‑locataires (MTO), un locataire Teams peut apparaître « rouge » et refuser la connexion. Voici un guide concret, pas à pas, pour diagnostiquer et corriger la situation sans dégrader vos contrôles de sécurité.
Contexte et symptômes
Une organisation a créé une Multi‑Tenant Organization Microsoft Entra ID rassemblant quatre locataires. Environ 35 000 comptes existent, 12 ont été synchronisés pour la preuve de concept. Les fonctionnalités Outlook, annuaire, calendriers et partage SharePoint fonctionnent correctement entre les quatre locataires. En revanche, dans Teams, un locataire devient inaccessible : il apparaît en rouge dans le sélecteur de profil et les utilisateurs provenant des trois autres locataires ne peuvent pas s’y connecter, malgré des équipes créées et des invitations valides.
Ce symptôme indique généralement un blocage d’authentification inter‑locataires, une divergence de configuration entre Entra (B2B/B2B Direct), des politiques d’accès conditionnel trop restrictives, ou des jetons/paramètres clients obsolètes.
Pourquoi Teams échoue alors que les autres services fonctionnent ?
Teams s’appuie à la fois sur l’identité Entra ID, des stratégies spécifiques (accès invité, accès externe, cross‑tenant access), et des flux de jetons (WAM/SSO) côté client. Il suffit qu’un seul de ces éléments diverge sur un locataire pour déclencher l’état « rouge », même si Outlook/SharePoint continuent de fonctionner via d’autres chemins ou cache d’identités.
- Couche identité : objets synchronisés (Cross‑Tenant Synchronization), relations MTO, claims corrects dans les jetons.
- Couche contrôle d’accès : stratégies d’accès conditionnel et paramètres de confiance inter‑locataires (MFA, conformité appareil).
- Couche Teams : habilitations invité/externes, paramétrage des équipes et canaux, rosters/permissions.
- Couche client : cache de l’application, comptes SSO Windows/macOS, jetons périmés ou corrompus.
Plan de diagnostic : l’arbre de décision express
- Valider la MTO et la synchronisation inter‑locataires (source ↔ cible, journaux de provisioning, présence des 12 comptes de test).
- Tester l’accès conditionnel : passer les politiques en « Report‑only » pour un utilisateur test et vérifier si la connexion redevient possible.
- Contrôler les Cross‑Tenant Access Settings (Inbound/Outbound) : autorisations, trust settings (MFA, appareil conforme).
- Vérifier l’accès invité dans Teams : paramètres org‑wide et au niveau des équipes/canaux.
- Assainir le poste client : purge du cache Teams, test via le client Web, réinitialisation des comptes SSO.
- Collecter et lire les journaux : Teams Activity Logs, AADSTS dans les journaux d’activité et de connexion.
- Escalader au support avec IDs de corrélation et captures des journaux si l’incident persiste.
Vérifications détaillées et actions
Synchronisation inter‑locataires (Cross‑Tenant Synchronization) et MTO
Commencez par confirmer que la relation MTO et la synchronisation inter‑locataires sont complètes :
- Dans Microsoft Entra ID > External Identities > Multitenant Organization, les quatre locataires figurent‑ils comme membres ? Les relations source/cible et les invitations MTO sont‑elles en statut « Accepter/Actif » ?
- Les journaux de provisioning ne présentent‑ils pas d’erreurs pour les 12 comptes POC ? Vérifier les collisions d’attributs (
userPrincipalName,proxyAddresses), l’existence des objets « invités » (userType=Guest) dans le locataire cible, et la cohérence des identifiants. - Confirmer que les objets synchronisés portent les bons immutable IDs et que le mapping d’attributs n’a pas été modifié entre‑temps.
Astuce PowerShell (Microsoft Graph) :
# Connexion Microsoft Graph (admin)
Connect-MgGraph -Scopes "Policy.Read.All","Policy.ReadWrite.CrossTenantAccess","User.Read.All","Directory.Read.All","AuditLog.Read.All"
# Lister les partenaires Cross‑Tenant
(Get-MgPolicyCrossTenantAccessPolicy).Partners | Select-Object TenantId, DisplayName, InboundTrust, OutboundTrust
# Détails d'un partenaire spécifique
Get-MgPolicyCrossTenantAccessPolicyPartner -CrossTenantAccessPolicyConfigurationPartnerTenantId \
# Journal de provisioning (échantillon)
Get-MgAuditLogProvisioning -Top 50 | Select-Object ActivityDateTime, TargetId, Action, Status, InitiatedBy Stratégies d’accès conditionnel (Conditional Access)
Un locataire « rouge » dans Teams est souvent la conséquence d’une politique qui bloque la délivrance du jeton ou l’accès à l’application Microsoft Teams uniquement pour des utilisateurs provenant d’un tenant donné.
- Identifier les politiques ciblant des locations nommées, un Device state spécifique, ou une condition Guest/External avec exclusion/admission sélective par Tenant ID.
- Tester en Report‑only pour un compte de test afin d’observer l’impact sans bloquer la prod.
- Vérifier les applications cloud ciblées : si Teams (ou Office 365) est sous politique stricte, assurer l’exception pour les utilisateurs externes autorisés.
Astuce PowerShell (lecture des politiques) :
# Lecture des CA policies (rapport)
Get-MgIdentityConditionalAccessPolicy |
Select-Object DisplayName, State, Conditions, GrantControls, SessionControls
Paramètres d’accès B2B / B2B Direct (Cross‑Tenant Access Settings)
Les paramètres Inbound et Outbound doivent explicitement autoriser l’authentification, l’émission de jetons et l’accès à Teams pour chacun des locataires partenaires. Contrôlez également les Trust settings (MFA, appareil conforme, Hybrid Azure AD joined) : trop de sévérité côté tenant cible équivaut à un refus silencieux pour les externes.
- Au minimum, autoriser l’Inbound pour les types d’utilisateur attendus (B2B Collaboration, B2B Direct Connect) ainsi que les applications concernées (Teams/Exchange/SharePoint).
- Si vous exigez MFA ou appareil conforme depuis le tenant source, activez le trust correspondant côté cible, ou fournissez le mécanisme MFA dans le tenant cible.
- Aligner la configuration bidirectionnelle : un partenaire Outbound « fermé » côté A peut se manifester comme « Inbound refusé » côté B.
Astuce PowerShell (vérifier la confiance) :
$p = Get-MgPolicyCrossTenantAccessPolicyPartner -CrossTenantAccessPolicyConfigurationPartnerTenantId <TenantId_partenaire>
$p.InboundTrust
$p.OutboundTrust
$p.InboundAllowedServices
$p.OutboundAllowedServices
Droits invités dans Teams
Côté locataire « problématique », inspectez les réglages Org‑wide dans le Teams Admin Center :
- Guest access : autorisation d’appel/réunion, messagerie, création/édition de canaux selon le besoin. Les invités doivent être membres des équipes et, le cas échéant, autorisés au niveau des canaux privés/partagés.
- External access / Teams Connect : si vous utilisez des shared channels, assurez la compatibilité B2B Direct et les Cross‑Tenant Access Settings associés.
Attention : l’accès invité à Teams ne requiert pas de licence dans le locataire cible pour l’utilisateur externe, mais des paramètres de conformité ou de DLP peuvent imposer des restrictions sur certaines actions.
Cache et jetons côté client
Avant de conclure à un problème back‑end, éliminez les corruptions locales :
- Client de bureau (Windows) : fermer Teams, purger
%AppData%\Microsoft\Teams(ou du nouveau client new Teams), puis relancer. - Client macOS : quitter Teams, supprimer
~/Library/Application Support/Microsoft/Teams, tenter une reconnexion. - Client Web : ouvrir teams.microsoft.com en navigation privée, pour neutraliser le cache et les cookies.
- SSO Windows : dans Paramètres > Comptes > Accès professionnel ou scolaire, déconnecter/reconnecter le compte si les jetons WAM semblent bloqués.
Journaux et codes d’erreur utiles
Collectez les journaux Teams Activity Logs depuis le poste utilisateur (Ctrl+Alt+Shift+1) ou via F12 (outils développeur) pour obtenir les traces réseau et les erreurs d’authentification.
| Code | Symptôme | Piste de résolution |
|---|---|---|
| AADSTS50020 | Compte externe non accepté par le tenant cible | Vérifier l’invitation B2B et la présence de l’objet invité ; contrôler Cross‑Tenant Access (Inbound) |
| AADSTS50105 | Utilisateur non autorisé à l’appli | Vérifier l’assignation de l’application/du groupe, ou exceptions CA pour Teams |
| AADSTS53000/53003 | Accès conditionnel (MFA/Device/Location) | Tester en Report‑only, ajuster les conditions, activer le trust inter‑tenant |
| AADSTS700016 | Application non trouvée | Vérifier l’enregistrement et l’accès à l’appli cloud ciblée |
| AADSTS50107 | Session/jeton expiré | Révoquer la session, purger cache, reconnecter le compte |
Tableau récapitulatif des axes de vérification
| Axe de vérification | Détails et actions recommandées |
|---|---|
| Synchronisation inter‑locataires | Contrôler la MTO et les partenaires Cross‑Tenant ; vérifier les journaux de provisioning et la réplication des 12 comptes de test |
| Accès conditionnel | Détecter les règles bloquantes (Guest/TenantID, MFA, emplacement) ; tester en Report‑only |
| Cross‑Tenant Access | Valider Inbound/Outbound pour les trois locataires partenaires ; vérifier les trust settings (MFA, appareil conforme) |
| Droits invités Teams | Autoriser Guest access au niveau org et confirmer l’appartenance aux équipes/canaux requis |
| Cache & tokens | Purger le cache Teams, tester en Web privé, réinitialiser les comptes SSO côté OS |
| Journaux diagnostics | Collecter Activity Logs, lire les AADSTS, corréler avec les Sign‑in logs Entra |
| Support Microsoft/Partner | Transmettre IDs de corrélation, captures des journaux, contexte de sécurité (CA/Cross‑Tenant) |
Scénarios d’échec typiques et correctifs rapides
1) Trust inter‑tenant trop strict (MFA/Appareil conforme)
Le tenant cible exige une preuve MFA ou un appareil conforme provenant du tenant source, mais le trust n’est pas activé. Résultat : Teams refuse silencieusement l’accès.
Correctif : activer la confiance pour la MFA/le statut de conformité Inbound, ou fournir l’expérience MFA côté cible pour les externes. Ajuster en parallèle les politiques CA pour éviter les doublons de contraintes.
2) Cross‑Tenant Synchronization incomplète
Les objets invités n’existent pas ou sont en collision d’attributs ; l’utilisateur ne peut pas rejoindre les équipes bien que l’invitation ait été envoyée.
Correctif : corriger le mapping d’attributs, relancer la synchronisation, nettoyer les objets en doublon, puis vérifier la présence des 12 comptes POC dans chaque tenant cible.
3) Règle d’accès conditionnel ciblant un seul tenant partenaire
Une politique ajoute une contrainte (MFA, pays, application) pour un Tenant ID précis.
Correctif : faire un test en Report‑only, confirmer la levée du blocage, documenter l’exception propre au tenant partenaire.
4) Paramètre Teams « Guest access » restreint
Le paramètre Guest access est désactivé ou insuffisant au niveau org, alors que les équipes ont été créées et partagées.
Correctif : activer Guest access, paramétrer les capacités nécessaires (messagerie, réunion, canaux), et valider les autorisations au niveau des canaux privés/partagés.
5) Jetons clients obsolètes
Après des changements de politiques, les clients continuent d’utiliser des jetons en cache.
Correctif : purge du cache, test en Web privé, réconnexion SSO, éventuellement révocation de sessions pour forcer la régénération des jetons.
Méthode d’essai contrôlé (POC & production)
- Sélectionner 3 utilisateurs de test par tenant (dont 1 sur poste neuf/VM) et 1 équipe/mode d’accès (invité classique et canal partagé si utilisé).
- Basculer les politiques CA en Report‑only pour ces comptes, capturer les événements pendant 30 à 60 minutes.
- Activer un journalage avancé (Microsoft Purview) pour corréler les refus d’accès inter‑tenant avec les actions utilisateur.
- Appliquer les corrections par incréments : Cross‑Tenant → CA → Teams → Client. Après chaque correction, attendre la propagation (voir ci‑dessous) et rejouer les tests.
Délais de propagation et stabilisation
Limites MTO (septembre 2025) : attendez généralement 1 à 2 heures après une modification d’objet ou de stratégie pour sa pleine visibilité dans Teams. Planifiez vos tests en conséquence et évitez d’enchaîner trop de changements en rafale, au risque de masquer la cause première.
Commandes et vérifications avancées
Lister les utilisateurs invités d’un tenant cible
# Tous les invités (userType=Guest)
Get-MgUser -Filter "userType eq 'Guest'" -All |
Select-Object Id, DisplayName, Mail, UserPrincipalName, CreatedDateTime
Exporter les connexions Entra pour un utilisateur test
# Sign‑in logs (échantillon)
Get-MgAuditLogSignIn -Filter "userDisplayName eq 'Prénom Nom'" -Top 25 |
Select-Object CreatedDateTime, AppDisplayName, Status, IPAddress, ConditionalAccessStatus
Vérifier l’accès invité au niveau organisation (Teams)
# Module MicrosoftTeams requis
Connect-MicrosoftTeams
Get-CsTenantFederationConfiguration | Select-Object AllowTeamsConsumer, AllowPublicUsers
Get-CsTenant | Select-Object -ExpandProperty AllowGuestUser
Bonnes pratiques de gouvernance et de sécurité
- Documenter chaque modification (CA, Cross‑Tenant, Teams) dans un tableau de bord de conformité, incluant auteur, date, justification, population touchée.
- Activer l’audit avancé (Microsoft Purview) pour tracer finement les refus d’accès inter‑tenant et les changements de configuration.
- Modèle Hub‑and‑Spoke : si l’alternance de locataires dégrade l’UX, envisager un tenant « Hub » commun et l’utilisation de Teams Connect (canaux partagés) pour réduire les bascules de contexte.
- Principe du moindre privilège pour les partenaires : ouvrir uniquement ce qui est nécessaire, préférer des groupes dynamiques et des politiques pilotées par attributs.
- Observabilité : surveiller en continu les taux de succès de connexion, les AADSTS par catégorie, et mettre en place des alertes sur hausse anormale des refus.
Checklist opérationnelle (prête à l’emploi)
| Étape | Action | Critère de succès |
|---|---|---|
| MTO & sync | Vérifier partenaires MTO, relire journaux de provisioning, corriger collisions d’attributs | Les 12 comptes POC visibles en tant qu’invités dans le tenant cible |
| Cross‑Tenant | Valider Inbound/Outbound, trust MFA/appareil, services autorisés (Teams) | Jeton émis pour Teams sans refus de confiance |
| CA Policies | Basculer en Report‑only, ajuster exceptions par Tenant ID, tester | État CA= ReportOnly dans les logs, aucun blocage pour l’utilisateur test |
| Teams (org & équipe) | Activer Guest access, confirmer appartenance aux équipes/canaux requis | L’utilisateur invité accède à l’équipe et aux canaux attendus |
| Client | Purger cache, test Web privé, réinitialiser SSO si besoin | Le locataire n’apparaît plus « rouge », connexion réussie |
| Journaux | Collecter Activity Logs, AADSTS, capturer ID de corrélation | Traçabilité complète prête pour l’escalade |
FAQ rapide
Faut‑il une licence Teams pour les invités dans le tenant cible ?
Non pour l’accès invité standard. En revanche, certaines fonctionnalités de conformité ou de sécurité peuvent nécessiter des droits/licences côté organisation hôte.
Pourquoi un seul tenant devient‑il rouge alors que les autres fonctionnent ?
La cause la plus fréquente est un écart de Cross‑Tenant Access (Inbound/Outbound), une politique CA unique à ce tenant, ou une divergence de paramétrage Teams (Guest/External) spécifique.
Combien de temps attendre après une modification avant de retester ?
Prévoyez 1 à 2 heures pour la propagation complète côté Teams. Évitez les changements multiples sans fenêtre d’observation, au risque de masquer la cause première.
Que fournir au support Microsoft en cas d’escalade ?
- Horodatage précis, UPN/tenant IDs, corrélation AADSTS, captures Activity Logs.
- Résumé des tests : ce qui fonctionne (Outlook/SharePoint) et ce qui échoue (Teams), périmètre affecté.
- Liste des politiques CA impliquées et export des paramètres Cross‑Tenant.
Conclusion
Dans un scénario MTO Microsoft 365, l’état « locataire rouge » de Teams provient presque toujours d’un trépied identité ↔ accès ↔ client désaligné. En suivant l’ordre de vérification proposé — synchronisation et MTO, accès conditionnel, Cross‑Tenant Access, droits invités Teams, hygiène client, journaux — vous éliminez rapidement les causes majeures. Si le problème persiste, une escalade structurée auprès du support, munie des journaux et identifiants de corrélation, permet quasi systématiquement d’isoler la règle ou l’objet bloquant.
Annexe : script d’audit de base (exemple)
Exemple de squelette pour centraliser vos vérifications (à adapter selon vos contraintes de sécurité et vos scopes autorisés) :
# Connexion Graph avec scopes de lecture
Connect-MgGraph -Scopes "User.Read.All","Directory.Read.All","Policy.Read.All","AuditLog.Read.All"
# 1) Partenaires Cross‑Tenant (Inbound/Outbound)
\$partners = (Get-MgPolicyCrossTenantAccessPolicy).Partners
\$partners | ForEach-Object {
\$p = Get-MgPolicyCrossTenantAccessPolicyPartner -CrossTenantAccessPolicyConfigurationPartnerTenantId \$*.TenantId
\[PSCustomObject]@{
TenantId = \$*.TenantId
Display = $\_.DisplayName
InboundMFA = \$p.InboundTrust.IsMfaAccepted
InboundDev = \$p.InboundTrust.IsCompliantDeviceAccepted
OutbMFA = \$p.OutboundTrust.IsMfaAccepted
}
}
# 2) Comptes invités récents
Get-MgUser -Filter "userType eq 'Guest'" -Top 50 |
Select-Object DisplayName, UserPrincipalName, Mail, CreatedDateTime
# 3) Connexions récentes Teams (échantillon)
Get-MgAuditLogSignIn -Filter "AppDisplayName eq 'Microsoft Teams'" -Top 50 |
Select-Object CreatedDateTime, UserDisplayName, Status, ConditionalAccessStatus Notes complémentaires
- Propagation : 1–2 h entre modification d’objets et visibilité Teams.
- Alternative temporaire : tenant « Hub » + Teams Connect (canaux partagés) pour limiter les bascules de tenant.
- Traçabilité : consigner chaque changement dans un registre de conformité et activer l’audit avancé pour les refus d’accès inter‑tenant.