Teams und Copilot erfordern Firewall-Updates

Microsoft zieht um. Nicht das Büro in Redmond, sondern die Adressen, unter denen deine Leute jeden Tag Teams und Copilot im Browser aufrufen. Wer seine Firewall nicht mitnimmt, erlebt das, was Admins am meisten lieben: einen weißen Bildschirm und eine Ticket-Lawine um 8:01 Uhr.

Executive Summary

Kurz und schmerzlos, wie eine gute Kündigung: Microsoft leitet die Web-Version von Teams von teams.microsoft.com auf teams.cloud.microsoft um. Parallel landet, wer Microsoft 365 Copilot Chat unter m365.cloud.microsoft öffnet, künftig auf copilot.cloud.microsoft. Beides passiert automatisch. Niemand fragt dich. Und beides funktioniert nur, wenn deine Firewalls, Proxys, Secure Web Gateways und SSE-Plattformen die komplette Domäne *.cloud.microsoft durchlassen.

Der Teams-Umzug sollte bis 30. September 2026 für alle Unternehmens-Tenants durch sein. Für Copilot lief die erste Welle Anfang September, die zweite folgt im Oktober beziehungsweise Anfang November. Für Teams gibt es noch eine Notbremse bis 31. Dezember 2026, danach ist Schluss. Ab 1. Januar 2027 kannst du den Redirect nicht mehr abschalten. Wer heute noch nicht getestet hat, sollte das in den nächsten zwei Wochen mit einer Pilotgruppe nachholen, statt im Januar mit dem Vorstand.

Worum geht es im Detail?

Ein bisschen Hintergrund, damit du verstehst, warum Microsoft das überhaupt macht. Über die Jahre hat sich ein Zoo aus Domänen angesammelt: office.com, microsoft.com, live.com, sharepoint.com, office365.com, dazu Hunderte Subdomänen. Für jede Firewall-Regel ein eigenes Haustier, das gefüttert werden will. Seit 2023 baut Microsoft deshalb die eigene Top-Level-Domain .microsoft als zentrales Zuhause für authentifizierte Microsoft-365-Oberflächen auf. cloud.microsoft steht seit April 2023 in der offiziellen Netzwerk-Dokumentation. Wer die damals sauber übernommen hat, darf sich jetzt zurücklehnen. Alle anderen haben drei Jahre Vorwarnzeit verschlafen, was im Konzernalltag allerdings eher als normale Reaktionsgeschwindigkeit gilt.

Der Vorteil für Microsoft liegt auf der Hand: Eine eigene TLD gehört niemandem sonst. Kein Phishing-Kollege kann sich irgendwas.cloud.microsoft registrieren, was bei .com leider ein Volkssport ist. Für dich bedeutet das langfristig weniger Ausnahmen in der Firewall und eine klarere Antwort auf die Helpdesk-Frage, ob eine Adresse echt ist. Kurzfristig bedeutet es: Regeln anpassen, sonst brennt die Hütte.

Abbildung 1: Der Zeitplan für Teams und Copilot. Heute ist der 12. Oktober, die Uhr läuft.

Technisch ist das Ganze ein simpler HTTP-Redirect. Deine Nutzer klicken auf ein altes Lesezeichen, der Browser bekommt eine Umleitung und landet auf der neuen Adresse. Die Features bleiben gleich, die Oberfläche bleibt gleich, nur die Adresszeile endet plötzlich auf .microsoft. Klingt harmlos. Ist es auch, solange zwischen Browser und Microsoft niemand sitzt, der sich querstellt. Und genau da sitzen in jedem Unternehmen mindestens vier Kandidaten: Endgerät, Proxy, Firewall und die schicke SASE-Plattform, die letztes Jahr für viel Geld eingekauft wurde.

Abbildung 2: Vier Kontrollpunkte, vier Gelegenheiten, den Redirect sterben zu lassen.

Zur Teams-Seite gehört noch ein Detail, das gern übersehen wird: eigene Web-Apps. Wenn deine Entwickler eine Teams-App gebaut haben, die mit einem alten Teams-JavaScript-SDK arbeitet oder in Content-Security-Policy, X-Frame-Options oder Authentifizierungs-Redirects fest teams.microsoft.com hinterlegt hat, rendert die nach dem Umzug möglicherweise nicht mehr. Das ist dann kein Firewall-Problem, sondern ein Code-Problem, und landet trotzdem beim Netzwerk-Team, weil die Nutzer "Teams geht nicht" ins Ticket schreiben.

Was sind Chancen? Was sind Risiken?

Fangen wir mit dem Positiven an, das ist schneller erledigt. Die Konsolidierung auf eine einzige, Microsoft-exklusive Domäne ist aus Sicherheitssicht eigentlich ein Geschenk. Du kannst Regeln aufräumen, die seit 2017 niemand mehr verstanden hat, und deinen Nutzern endlich eine einfache Regel beibringen: Was auf .microsoft endet, gehört Microsoft. Gleichzeitig ist der Umzug ein hervorragender Vorwand, mal nachzusehen, ob die TLS-Inspection auf dem Proxy für Microsoft-365-Verkehr wirklich abgeschaltet ist, wie es Microsoft seit Jahren empfiehlt.

Jetzt zu den Risiken, und da wird es schwarz-humorig. Das größte Risiko ist nicht technischer, sondern organisatorischer Natur. Die Firewall gehört dem Netzwerk-Team, der Proxy der Security, die SASE-Plattform einem externen Dienstleister, der Teams-Tenant dem Modern-Workplace-Team und die Teams-App einer Agentur, die es seit 2024 nicht mehr gibt. Jeder dieser Beteiligten wird dir im Ernstfall glaubhaft versichern, dass es an ihm nicht liegt. Meistens stimmt das sogar, und trotzdem geht nichts.

Ein Praxisbeispiel, wie es in den letzten Wochen tatsächlich gelaufen ist: Ein Mittelständler aus dem Maschinenbau, rund 1.200 Arbeitsplätze, hatte auf seinem Proxy eine Kategorie-Sperre für "neu registrierte Domains und unbekannte TLDs". Klingt vernünftig, hat jahrelang Malware ferngehalten. Dummerweise stufte der Hersteller des Proxys .microsoft intern als exotisch ein. Ergebnis: Am Morgen nach der Umleitung saß der komplette Vertrieb vor einem leeren Teams-Fenster im Browser. Der Desktop-Client lief, also schob die IT das zwei Tage lang auf die Browser. Gefunden hat den Fehler am Ende ein Werkstudent, der in der Browser-Konsole nachgesehen hat. Die Moral: Lies die Konsole, bevor du die Geschäftsführung informierst.

Zweites Beispiel, diesmal aus dem Finanzsektor: Dort hatte das Netzwerk-Team Wildcards per Policy verboten und stattdessen über 300 einzelne FQDNs für Microsoft 365 gepflegt, inklusive Excel-Liste mit Änderungshistorie. Respekt für die Disziplin. Nur: Copilot in Edge rief Backend-Hosts unter *.cloud.microsoft auf, die in keiner Liste standen. Die Copilot-Seitenleiste blieb leer, das Board-Mitglied, das gerade seine erste Copilot-Demo zeigen wollte, nicht. Die Wildcard-Policy hat jetzt eine dokumentierte Ausnahme.

Und warum trifft es ausgerechnet die vorsichtigen Unternehmen am härtesten? Weil gute Sicherheitsarchitektur oft aus Misstrauen gegenüber allem Neuen besteht. Eine neue Top-Level-Domain, die plötzlich geschäftskritisch wird, passt in kein Raster, das 2019 jemand in einem Workshop entworfen hat. Viele Secure Web Gateways bewerten Domänen nach Alter, Reputation und Kategorie. Eine Microsoft-TLD ist zwar weder jung noch verdächtig, landet aber je nach Hersteller und Update-Stand in einer Schublade wie "Sonstiges" oder "Unkategorisiert". Und Unkategorisiertes wird in vielen Häusern traditionell erschossen und erst danach befragt.

Dazu kommt TLS-Inspection. Microsoft rät seit Jahren davon ab, Microsoft-365-Verkehr aufzubrechen, weil das Latenz kostet, Zertifikatsprüfungen stört und bei Echtzeit-Medien wie Teams-Anrufen schlicht zu Aussetzern führt. Wer bisher eine sauber gepflegte Ausnahmeliste für Microsoft-Domänen hatte, muss *.cloud.microsoft und *.static.microsoft dort ebenfalls eintragen. Sonst funktioniert zwar die Verbindung, aber du baust dir einen hausgemachten Flaschenhals, über den sich hinterher alle beschweren, ohne zu wissen, woran es liegt.

Was müssen wir jetzt schon vorbereiten?

Die gute Nachricht: Für Teams hast du noch bis Silvester Zeit, die Notbremse zu ziehen und sauber nachzuarbeiten. Die schlechte: Für Copilot gibt es keinen Schalter, nur das Gespräch mit deinem Microsoft-Ansprechpartner, und die Frist dafür war eigentlich schon am 10. September. Also los, und zwar strukturiert statt hektisch.

Abbildung 3: Der Pilotfahrplan. Langweilig, aber genau deshalb funktioniert er.

Inventur: Durchsuche Firewall-Regeln, PAC-Dateien, Proxy-Kategorien, SSE-Policies, Conditional-Access-Regeln und App-Control-Richtlinien nach teams.microsoft.com, m365.cloud.microsoft und alten IP-Listen.

Freigabe: Erlaube *.cloud.microsoft vollständig, plus *.static.microsoft, jeweils TCP und UDP 443. Gleiche alles mit der aktuellen Microsoft-365-Endpoint-Liste ab, nicht mit dem PDF von 2021 aus dem Teams-Kanal.

Pilotgruppe: Nimm IT, Helpdesk, einen Außenstandort mit eigenem Internet-Breakout und ein Assistenzteam der Geschäftsführung. Wer bei denen nichts kaputt macht, hat den Härtetest bestanden.

Messen: Nutze den Connectivity-Test unter connectivity.m365.cloud.microsoft/copilot, schau in die Browser-Konsole und zähle die Tickets der Pilotgruppe.

Helpdesk briefen: teams.cloud.microsoft ist echt, teams.cloud.microsoft.com ist ein Tippfehler. Das muss jeder im First Level aufsagen können.

Dokumentation anpassen: Intranet-Links, Onboarding-Unterlagen und Schulungsvideos aktualisieren. Alte Links funktionieren zwar weiter, aber die Screenshots lügen dann.

Häufig gestellte Fragen

Welche Domänen muss ich für Teams und Copilot in der Firewall freigeben?

Du brauchst die komplette Domäne *.cloud.microsoft, ergänzt um *.static.microsoft für statische Inhalte, jeweils auf TCP und UDP 443. Microsoft unterstützt ausdrücklich keine teilweise Freigabe einzelner Hosts wie nur teams.cloud.microsoft oder copilot.cloud.microsoft.

Kann ich die Umleitung von Teams auf teams.cloud.microsoft verhindern?

Nur vorübergehend: Mit Set-CsTeamsClientConfiguration und dem Wert UseUnifiedDomain Disabled bleibt der Teams-Webclient bis 31. Dezember 2026 auf teams.microsoft.com. Ab 1. Januar 2027 ist die Umleitung verpflichtend und lässt sich nicht mehr abschalten.

Funktionieren alte Lesezeichen auf teams.microsoft.com weiterhin?

Ja, bestehende Links und Lesezeichen werden automatisch auf die neue Adresse weitergeleitet. Voraussetzung ist, dass das Ziel teams.cloud.microsoft im Netzwerk erreichbar ist, sonst endet die Weiterleitung im Fehler.

Wie verhindere ich private Microsoft-Konten in Copilot, ohne die Copilot-Domäne zu sperren?

Nutze Tenant Restrictions v2 in Microsoft Entra ID, um Anmeldungen mit privaten Microsoft-Konten zu blockieren. So bleibt copilot.cloud.microsoft für die lizenzierten Firmenkonten erreichbar.

Ist der Teams-Desktop-Client von der Domänenumstellung betroffen?

Die Umleitung betrifft den Teams-Webclient im Browser, der Desktop-Client gilt laut Microsoft sogar als Ausweichlösung bei Web-Problemen. Backend-Dienste nutzen aber ebenfalls *.cloud.microsoft, deshalb solltest du die Freigabe trotzdem vollständig umsetzen.