MS Teams und die lokale Windows Firewall

Teams Windows Firewall

Die Digitalisierung schreitet immer weiter voran und Ton- und Videokonferenz mit Screen Sharing sind inzwischen nicht mehr wegzudenken.

Dies stellt den Admin vor die eine oder andere Hürde. So ging es mir diesmal auch in Zusammenhang mit der Windows Firewall und der Art und Weise der Standard Bereitstellung von MS Teams.

Wenn ein User versucht den ersten Call in Teams zu tätigen ploppt erstmal die Windows Firewall Meldung hoch und möchte eingehende Regeln erstellen.
Bei uns haben die Nutzer im Normfall aber keine lokalen Adminrechte. Nun gibt es mehrere Möglichkeiten
1. Der User ruft im Support an und jemand schaltet sich auf und trägt in die UAC Abfrage Admin Credentials ein und die Regel wird erstellt. Der Support wird sich herzlich bedanken, da gerade momentan mit Sicherheit genügend andere Anfragen da sind.
2. Der User klickt auf Abbrechen und es werden deaktivierte Regeln erstellt und der User stellt später fest, dass manches nicht funktioniert in Teams. Landet also wieder im Support
3. Der Admin überlegt sich wie er das Ganze ohne Impact für den Support lösen kann.

Bei einer Software die feste Ports nutzt oder in Program Files liegt liese sich ja einfach eine Firewallregel per Gruppenrichtlinie verteilen.
Aber Microsoft kam ja auf die glorreiche Idee Teams ins Userprofil zu packen. Davon kann man halten was man will.
Je nachdem mit wem man spricht bekommt man eine andere Antwort. Entwickler finden das Verhalten ganz toll. Admins die den Betrieb sicherstellen wollen finden es meist eher zum kotzen.

So um das Ganze nicht unnötig in die Länge zu ziehen zeige ich euch, wie ich das Ganze gelöst habe ohne dass mir der Support den Kragen umdreht.

Es kommt eine Kombination aus Gruppenrichtlinie, PowerShell und Aufgabenplanung zum Einsatz.

Schritt 1: Das PowerShell Skript

Microsoft hat wohl auch mitbekommen, dass die Firewall eine Hürde für Teams darstellen könnte und hat in den Docs auch ein Sample Skript veröffentlicht. Schon mal eine gute Grundlage. Allerdings haben wir momentan viele User im Homeoffice. Somit bleibt der Teams Traffic nicht im VPN und läuft auch über ein Interface das nicht als Domain Authenticated gilt. Daher eine kleine Anpassung am Skript um es auf alle „Profile“ zu binden.

<#
.SYNOPSIS
   Creates firewall rules for Teams.
.DESCRIPTION
   (c) Microsoft Corporation 2018. All rights reserved. Script provided as-is without any warranty of any kind. Use it freely at your own risks.
   Must be run with elevated permissions. Can be run as a GPO Computer Startup script, or as a Scheduled Task with elevated permissions. 
   The script will create a new inbound firewall rule for each user folder found in c:\users. 
   Requires PowerShell 3.0.
#>

#Requires -Version 3

$users = Get-ChildItem (Join-Path -Path $env:SystemDrive -ChildPath 'Users') -Exclude 'Public', 'ADMINI~*'
if ($null -ne $users) {
    foreach ($user in $users) {
        $progPath = Join-Path -Path $user.FullName -ChildPath "AppData\Local\Microsoft\Teams\Current\Teams.exe"
        if (Test-Path $progPath) {
            if (-not (Get-NetFirewallApplicationFilter -Program $progPath -ErrorAction SilentlyContinue)) {
                $ruleName = "Teams.exe for user $($user.Name)"
                "UDP", "TCP" | ForEach-Object { New-NetFirewallRule -DisplayName $ruleName -Direction Inbound -Profile Any -Program $progPath -Action Allow -Protocol $_ }
                Clear-Variable ruleName
            }
        }
        Clear-Variable progPath
    }
}

Die einzige Änderung gegenüber dem Sample Script ist im CMDlet New-NetFirewallRule von „-Profile Domain“ auf „-Profile Any“. Da wir Teams als vertrauenswürde Applikation sehen, sehe ich jetzt auch kein Sicherheitsproblem in als öffentlich getaggten Netzen. Vor allem wenn der Enduser bei der ersten Verbindung die Abfrage was das für ein Netz ist ignoriert hat spielt uns das in die Karten. Sonst würden wir ja evtl. wieder etwas nicht abdecken. Und Zack wieder ein Call im Support.

Schritt 2: Skript per GPO verteilen und Aufgabe erstellen

Um das Skript auf die Clients zu bekommen verwende ich eine Gruppenrichtlinie auf Computerbasis.

Computerkonfiguration –> Einstellungen –> Windows-Einstellungen –> Dateien

Kopieroptionen für das Script

Als Quelldatei muss natürlich ein Pfad genommen werden auf den das Computerobjekt lesend zugreifen kann. Ich hab es einfach in den Pfad der Richtlinie mit rein gepackt. Alternativ wäre NETLOGON auch machbar oder ein Fileshare auf das eben die Computer lesend zugreifen können. Das ist denke ich Geschmackssache.

Als Ziel nehme ich das Windows Verzeichnis, da der User selbst ja sowieso nie damit interagieren muss und dieser Pfad definitiv existiert.

Schritt 3: Geplante Aufgabe per GPO erstellen

So nun muss das Skript natürlich auch noch auf den Clients ausgeführt werden. Das mache ich über die Aufgabenplanung. Die dazu nötige Aufgabe erstelle ich ebenfalls per GPO. Auch das läuft über den Computeranteil.

Computerkonfiguration –> Einstellungen –> Systemsteuerungseinstellungen –> Geplante Aufgaben –> Neu –> Geplante Aufgabe (mindestens Windows 7)

Unter Allgemein vergebe ich einen sprechenden Namen für die Aufgabe. Ausführen lasse ich die Aufgabe unter dem Kontext von SYSTEM und sage „Unabhängig von Benutzeranmeldung ausführen“ und mit maximalen Privilegien ausführen

Allgemeine Konfiguration der Aufgabe

Als Trigger lege ich folgendes fest:

Trigger für die Aufgabe

Als Aktion wähle ich Programm starten.
Als Programm hinterlege ich folgendes:
%WINDIR%\System32\WindowsPowerShell\v1.0\powershell.exe
Als Argumente übergebe ich folgendes:
-ExecutionPolicy Bypass -File %WINDIR%\teams_firewall.ps1

Aktion für die Aufgabe

Die restlichen Optionen der Aufgabe habe ich auf Standard gelassen.

Diese GPO hängen wir jetzt an die OU in der die AD-Konten der Computer liegen.

Auf den Clients heißt es nun entweder warten oder „gpupdate /force“
Dann sollte man in der Aufgabenplanung entsprechend die Aufgabe finden (Achtung wenn ein User kein lokaler Admin ist sieht er die Aufgabe nicht, nur Admins sehen die Aufgabe) und in %WINDIR% das dazugehörige Skript.

Wenn nun einer der definierten Trigger ausgelöst wird werden vom Skript die entsprechenden Regeln erstellt. Achtung es werden 2 Regeln pro User mit gefundener Teams.exe erstellt. Eine für TCP und eine für UDP. Das ist so beabsichtigt.

Nun könnte man sich Fragen warum so umständlich und nicht einfach in den Pfad zur EXE in der Regel %LOCALAPPDATA% statt dem User Pfad verwenden.
Die Firewall läuft in einem anderen Kontext und würde die Umgebungsvariable somit auch auf einen anderen Pfad auflösen.

Nun könnte man noch sagen „warum hampelst du so mit Aufgabenplanung rum und machst nicht einfach ein Logonskript“.
Viele unserer User sind momentan im Homeoffice. Zum Zeitpunkt der Anmeldung am Client ist in diesem Fall noch keine Verbindung zum DC verfügbar und können somit keine Logonskripte ausführen, da sie den DC einfach nicht erreichen. Daher habe ich nach einer Lösung im laufenden Betrieb gesucht.

Ich hoffe der Beitrag gefällt euch und erspart euch die Suche nach einer für euch passenden Lösung.

Ähnliche Artikel
↑
Die mobile Version verlassen