Nutzt man auf dem Server zur Absicherung von Verbindungen ein Zertifikat, dessen Herausgeber die Clients nicht trauen, dann werden die Benutzer mit einer Warnung konfrontiert. Um dies zu vermeiden, kann man das Zertifikat in den Store der PCs übertragen, bevorzugt über GPO oder auch via PowerShell.
Neben den gängigen GUI- und CLI-Tools ist unter den Bordmitteln von Windows auch PowerShell in der Lage, die Ausstellung eines Zertifikats anzufordern. Das dafür zuständige Cmdlet weist zwar einige Einschränkungen auf, eignet sich aber zum Beispiel dazu, ein SSL-Zertifikat von einer internen CA ausstellen zu lassen.
Windows 365 und Azure Virtual Desktop (AvD) sind Microsofts Angebote für virtuelle PCs aus der Cloud, wobei sich AvD auch auf Azure Stack HCI betreiben lässt. Der Service zeichnet sich durch Flexibilität und Skalierbarkeit aus. Damit die Kosten nicht aus dem Ruder laufen, sollte man sich mit den Abrechnungsmodellen beschäftigen.
Installiert man das Windows Admin Center (WAC) auf einem Server, dann sollte der Browser mit dem Gateway über eine sichere Verbindung kommunizieren. Das WAC bringt dafür zwar ein Zertifikat mit, aber dieses verursacht eine Sicherheitswarnung des Browsers. Daher sollte man es durch ein eigenes Zertifikat ersetzen.
Verbindungen, die man über Enter-PSSession und Invoke-Command aufbaut, kommunizieren standardmäßig über HTTP. Allerdings verschlüsselt dabei WinRM die übertragenen Daten. Zusätzliche Sicherheit erlangt man speziell in Workgroups durch HTTPS, wobei ein selbstsignierten SSL-Zertifikat in der Regel reicht.
Während man früher Tools wie makecert.exe benötigte, um selbstsignierte Zertifikate auszustellen, kann PowerShell diese Aufgabe seit Windows 8 und Server 2012 mit New-SelfSignedCertificate übernehmen. Sie lassen sich etwa für die Client- und Server-Authentifizierung oder die Code-Signierung verwenden.
Um die Authentizität von Scripts zu gewährleisten, kann PowerShell sie mit einer Signatur versehen. Eine solche benötigen sie, wenn man Richtlinien vorgeben möchte, die nur das Ausführen vertrauenswürdiger Scripts erlauben. Das erforderliche Zertifikat kann man bei intern entwickelten Scripts über eine AD-basierte CA ausstellen.
Die Ausführung von PowerShell-Scripts lässt sich über Richtlinien einschränken, standardmäßig wird sie blockiert. Während die vom Admin interaktiv gesetzte Execution Policy von jedem User aufgehoben werden kann, ist die Konfiguration per GPO nachhaltiger. Sicherheit gegen böswillige User bietet sie aber trotzdem nicht.
Für öffentlich zugängliche Websites sind SSL-Verbindungen mittlerweile Standard, und Ähnliches sollte auch für Exchange gelten. Let's Encrypt betreibt eine freie CA, die Zertifikate nicht nur kostenlos, sondern auch weitgehend automatisiert ausstellt. Diese Anleitung zeigt das Vorgehen für IIS und Exchange.
Zertifikate sind zweifellos eine kritische Komponente der IT-Infrastruktur. Laufen sie ab, dann kann dies zum Ausfall von Diensten führen. Wurden sie mit einem schwachen Hash-Algorithmus signiert, stellen sie ein Sicherheitsrisiko dar. Diese und andere Informationen lassen sich mit PowerShell effizient auslesen.
Microsoft empfiehlt, die Kommunikation der Windows Server Update Services (WSUS) mit Clients und abhängigen WSUS-Servern über SSL abzusichern. Dafür müssen ein Zertifikat installiert, die IIS angepasst, die Clients via GPO auf die korrekte URL verwiesen und die MMC-Konsole konfiguriert werden.