M365 Teams | Föderationskontrollen für Gruppenchats einrichten

Federierte Gruppenchats in Teams prüfen bisher nur die Föderationsbeziehung zwischen der einladenden Person und der Person, die neu hinzukommt. Wer schon im Chat sitzt, wird nicht erneut gegen die eigene externe Zugriffsrichtlinie geprüft.

Microsoft schließt beide Lücken mit zwei neuen, unabhängig voneinander schaltbaren Parametern am Cmdlet Set-CsTenantFederationConfiguration (Message Center MC1423114).

Föderation bezeichnet in Teams die Fähigkeit, mit Nutzern eines anderen, unabhängigen Microsoft 365 Tenants direkt zu chatten, den Präsenzstatus zu sehen oder Anrufe zu führen, ohne dass eine der beiden Seiten dafür einen Gastzugang im eigenen Verzeichnis anlegen muss. Das unterscheidet Föderation von Azure AD B2B Gastzugängen. Ein Gastkonto legt ein eigenes, wenn auch eingeschränktes Objekt im gastgebenden Tenant an, Föderation dagegen läuft rein über domänenbasierte Erkennung und die Föderationskonfiguration der beteiligten Tenants, ohne dass ein Verzeichnis das andere kennt. Nicht gemeint ist hier die Föderation mit privaten Teams- oder Skype-Konten, sogenannten Teams Consumer Konten, die über eigene Parameter wie AllowTeamsConsumer gesteuert wird.

Eine Föderationsbeziehung entsteht auf zwei Ebenen gleichzeitig. Auf Tenant-Ebene muss AllowFederatedUsers in der eigenen Set-CsTenantFederationConfiguration auf True stehen, und die Domäne der Gegenseite muss in AllowedDomains enthalten sein oder pauschal erlaubt werden, das gilt spiegelbildlich auch für den anderen Tenant. Auf Nutzerebene muss zusätzlich die zugewiesene External Access Policy des einzelnen Nutzers EnableFederationAccess auf True setzen, denn ein Tenant kann Föderation grundsätzlich erlauben und trotzdem einzelne Nutzer oder Gruppen davon ausnehmen. Erst wenn beide Ebenen zusammenpassen, können zwei konkrete Personen aus zwei verschiedenen Organisationen tatsächlich miteinander chatten.

Ein federierter Gruppenchat ist ein Teams Chat mit mehr als zwei Teilnehmenden, bei dem mindestens eine Person einem anderen Tenant angehört als die übrigen. Das unterscheidet ihn vom federierten 1:1-Chat, für den andere Regeln gelten, und vom internen Gruppenchat ohne externe Beteiligung.

Genau an dieser Stelle setzt MC1423114 an: Die Föderationsbeziehung wird bisher nur beim Initiieren oder Beitreten geprüft, nicht laufend für alle bereits anwesenden Teilnehmenden.

EnableExternalAccessRestrictionsForChatParticipants schließt die erste Lücke. Aktivierst Du den Parameter, greift die individuelle Sperre eines Nutzers unabhängig davon, wer den Chat angelegt hat: Betroffene Nutzer werden weder zu externen Gruppenchats hinzugefügt, noch bleiben sie in aktiven externen Gruppenchats. Das bestehende Flag CommunicationWithExternalOrgs in den External Access Policies bleibt davon unberührt, die beiden Einstellungen wirken parallel. Verfügbar ab dem 31. Juli 2026.

EnableMutualFederationForChatParticipants schließt die zweite Lücke, das Bridging-Problem. Bisher genügt eine gültige Föderationsbeziehung zwischen der beitretenden Person und der Chat-Initiatorin oder dem Chat-Initiator, andere anwesende externe Teilnehmer werden nicht gegengeprüft. Aktivierst Du den Parameter, braucht jeder Teilnehmer eine gültige gegenseitige Föderationsbeziehung zu jedem einzelnen anderen Teilnehmer im Chat, die Beziehung zur Initiatorin allein reicht dann nicht mehr. Verfügbar ab dem 30. September 2026.

Beide Schalter sind standardmäßig deaktiviert und wirken nur auf Gruppenchats, nicht auf 1:1-Chats, Besprechungen, Besprechungschats oder Shared Channels. Die automatische Entfernung betroffener Teilnehmer greift nur in aktiven Chats mit einer Nachricht innerhalb der letzten zwei Stunden, inaktive Chats werden erst bei neuer Aktivität neu bewertet, und die initiierende Person wird nie entfernt.

Für die folgenden Schritte brauchst Du das aktuelle Microsoft Teams PowerShell Module und eine Verbindung per Connect-MicrosoftTeams.

Administrativ reicht die Rolle Teams-Administrator, eine zusätzliche Lizenz ist nicht nötig, da beide Parameter Teil der Tenant-weiten Federation-Konfiguration sind. Wichtig für die Zeitplanung: Beide Parameter tauchen zwar schon heute in der Syntax von Set-CsTenantFederationConfiguration auf, sind in der aktuellen Cmdlet-Referenz auf Microsoft Learn aber ausdrücklich als für die zukünftige Verwendung reserviert markiert. Ein Aufruf vor dem jeweiligen Rolloutdatum wird also weder angewendet noch gespeichert. Die Schritte 1 und 2 unten kannst Du dagegen schon heute durchführen.

Bevor Du einen der beiden Schalter aktivierst, solltest Du wissen, wie viele Nutzer heute schon mit EnableFederationAccess auf False laufen, denn genau die sieht der erste Parameter vor. Das folgende Skript ermittelt alle External Access Policies mit deaktivierter Föderation und listet die zugewiesenen Nutzer:

Das Skript verbindet sich, sammelt alle Richtlinien mit EnableFederationAccess gleich False, löst je Richtlinie den Namen ohne das Präfix tag: auf und filtert damit Get-CsOnlineUser nach betroffenen Nutzern. Das Ergebnis landet als CSV im aktuellen Verzeichnis und lässt sich direkt an Fachbereiche oder den Helpdesk weiterreichen. Für gruppenbasierte Zuweisungen ergänzt Get-CsGroupPolicyAssignment -PolicyType ExternalAccessPolicy die Sicht, einzelne Nutzer erben ihre Richtlinie sonst über eine Gruppenmitgliedschaft, die im obigen Skript nicht auftaucht.

Parallel lohnt sich ein Blick auf die tenant-weite Föderationskonfiguration, insbesondere auf Vollständigkeit der Allowed Domains und auf AllowFederatedUsers:

Sobald das jeweilige Datum erreicht ist, aktivierst Du die Parameter einzeln, unabhängig voneinander:

Willst Du erst Erfahrung mit der ersten Kontrolle sammeln, bevor die zweite dazukommt, ist das durch den gestaffelten Rollout ohnehin vorgegeben.

Nach der Aktivierung bestätigt derselbe Cmdlet den aktuellen Stand:

Beide Werte sollten True zeigen, wenn die jeweilige Kontrolle aktiv ist. Rechne in den ersten Stunden nach der Aktivierung mit Rückfragen von Nutzern, die aus bestehenden Gruppenchats entfernt wurden, das ist bei aktiven Chats mit erfüllten Bedingungen erwartetes Verhalten.

Beide Parameter lassen sich jederzeit einzeln zurücksetzen:

Ein Rollback hebt keine bereits erfolgten Entfernungen aus Gruppenchats auf, betroffene Nutzer müssen dem Chat danach erneut hinzugefügt werden.

Die Teams Admin Center Oberfläche zeigt beide neuen Parameter aktuell nicht als Schalter an, laut Message Center läuft die Konfiguration ausschließlich über Set-CsTenantFederationConfiguration. Wer die Einstellung im Blick behalten will, muss also regelmäßig per PowerShell nachsehen oder sich ein eigenes Reporting bauen.

Praktisch relevant wird EnableMutualFederationForChatParticipants vor allem im Zusammenspiel mit Partnerorganisationen. Aktiviert eine Partnerfirma den Parameter auf ihrer Seite, können Deine Nutzer aus gemeinsamen Gruppenchats fallen, ohne dass Du an Deiner eigenen Konfiguration etwas geändert hast. Das lässt sich vorab nicht vollständig testen, weil das Verhalten von der Konfiguration der jeweils anderen Tenants abhängt.

Und schließlich: Die Kontrollen reihen sich in eine Serie von Verschärfungen bei der externen Zusammenarbeit in Teams ein, zu der bereits im November 2025 domänenbasierte Zugriffsrichtlinien pro Nutzer und Gruppe kamen. Wer seine External Access Policies bisher nur grob gepflegt hat, sollte das Audit aus Schritt 1 nicht als einmalige Übung behandeln.

Handlungsbedarf besteht laut Microsoft aktuell nicht, beide Schalter starten deaktiviert, und keiner der beiden Parameter verändert heute bestehendes Verhalten. Das Sicherheitsproblem, das sie adressieren, ist trotzdem real: Externe Zugriffsrichtlinien greifen bislang lückenhaft in Gruppenchats, und gerade das Bridging-Szenario über eine gemeinsame dritte Organisation lässt sich ohne diese Kontrollen weder erkennen noch verhindern.

Für Organisationen mit vielen aktiven Gruppenchats über mehrere externe Partner hinweg ist das kein theoretisches Risiko, sondern ein Compliance-relevanter blinder Fleck, den Prüfer bei ISO-27001 oder NIS2 Audits zunehmend hinterfragen dürften. Die Abhängigkeit von der Konfiguration fremder Tenants bei EnableMutualFederationForChatParticipants bleibt der unbequemste Teil der Änderung, denn sie bedeutet, dass Deine Umgebung sich ändern kann, ohne dass Du selbst etwas angefasst hast.

Wer heute schon die External Access Policies bereinigt und die Allowed Domains aktuell hält, geht mit deutlich weniger Überraschungen in den 31. Juli und den 30. September. Wer beides erst zum jeweiligen Rolloutdatum angeht, riskiert kurzfristige Verwirrung beim Helpdesk, wenn Nutzer ohne Vorwarnung aus Gruppenchats verschwinden.