[English]Ich stelle mal ein Problem hier ein, mit dem ein Administrator aus der Blog-Leserschaft kämpft. Man setzt Windows Server 2019 mit konfiguriertem Proxy per PAC-URL ein. Dort funktionieren Updates problemlos. Bei Windows Server 2022 stellte sich heraus, dass Updates per Internet nur mit systemweitem Proxy funktionieren. Ist das bekannt und dokumentiert? Ich ziehe das Thema mal heraus und gebe auch an, was so bekannt zu sein scheint.
Was sind PAC und PAC-URL?
Zuerst ein kurzer Schlenker in die Begrifflichkeiten und die Theorie, denn ich musste schnell nachschauen, was sich hinter den Begriffen versteckt (hoffe, ich habe es richtig verstanden). Das Kürzel PAC steht für Proxy auto-config. Eine Konfigurationsdatei definiert, wie Webbrowser und andere Benutzeragenten automatisch den geeigneten Proxyserver (Zugriffsmethode) für den Abruf einer bestimmten URL wählen können. Forcepoint lässt sich in diesem Artikel über das Thema aus. PAC-URLs in der betreffenden Konfigurationsdatei sind nicht nur durch Webbrowser nutzbar.
PAC bei Windows Server
Administratoren können auch in Windows Server festlegen, wie Windows Update per Proxy seine Informationen aus dem Internet von Microsoft-Servern beziehen darf. Microsoft hat einen Support-Beitrag veröffentlicht, der beschreibt wie der Windows Update-Client bestimmt, welcher Proxyserver für die Verbindung mit der Windows Update-Website verwendet werden soll.
Die Kurzfassung: Die PAC-Datei, eine JavaScript-Datei, enthält die Logik zur Bestimmung des Proxyservers, der für bestimmte URLs verwendet werden soll. Die PAC-Datei bestimmt, ob eine URL über einen Proxyserver geleitet werden soll und wenn ja, welcher Proxyserver zu verwenden ist. Die PAC-Datei kann auf einem Webserver gespeichert und über eine HTTP- oder HTTPS-URL aufgerufen werden.
PAC-Konfigurierung unter Windows Server
Um einen Proxy-Server auf einem Windows Server mit einer PAC-Datei (Proxy Auto-Configuration) zu verwenden, müssen Administratoren die Netzwerkeinstellungen des Servers so konfigurieren, dass die URL der PAC-Datei verwendet wird. Dies kann über Gruppenrichtlinien oder manuell in den Netzwerkeinstellungen der einzelnen Rechner erfolgen.
Kollege Thomas Joos hat im Januar 2025 auf Windows Pro den Artikel Proxy-Einstellungen in Windows automatisch mit PAC-Datei zuweisen mit einigen praktischen Hinweisen veröffentlicht. Das Deployment per GPO wird in diesem Beitrag beschrieben. Und von Microsoft gibt es den Support-Artikel Configure proxy server settings in Windows aus dem Januar 2025.
Windows Server 2022 Update-Problem mit PAC-URL
Blog-Leser Julian S. arbeitet im kommunalen Umfeld, wo er als Administrator überwiegend Windows Server 2019 mit konfiguriertem Proxy per PAC-URL im Einsatz hat. Bei diesen funktioniert Windows Update über das Internet ohne Probleme, schrieb mir der Leser die Tage.
Problem ist nun Windows Server 2022, der langsam die Windows Server 2019 ablösen dürfte. Bei Windows Server 2022 muss zusätzlich der systemweite Proxy fest eingetragen werden, damit Windows Update funktioniert. Oder in Kurz: Was unter Windows Server 2019 nicht erforderlich war und einfach funktionierte, ist bei Windows Server 2022 nicht mehr möglich.
Durch das manuelle Eintragen des systemweiten (festen) Proxys macht das PAC-Skript, mit dem man ja den zu verwendenden Proxy bzw. die PAC-URL dynamisch ermittelt, unter Windows Server 2022 keinen Sinn mehr. Die Frage des Lesers, die ich damit an das Schwarmwissen weitergebe, lautet: Gab es zwischen den Windows Server Versionen in diesem Bereich Änderungen? Ist da was bekannt? Wie löst ihr das im betreffenden Umfeld?
Was grob bekannt ist
Auf meine Nachfrage hat Julian S. mir noch einige Informationen nachgereicht. Laut ihm finden sich bei Microsoft selbst keine genauen Informationen, welche Änderungen es in diesem Bereich seit Windows Server 2019 gab. Über ChatGPT seien ihm noch einige (nachfolgend zusammen getragene) Informationen ausgeworfen worden.
So gebe es dokumentierte Unterschiede im Umgang mit Proxy-Konfigurationen, insbesondere mit PAC-Dateien und WPAD, zwischen Windows Server 2019 und Windows Server 2022. Diese Unterschiede betreffen vor allem die Art und Weise, wie systemnahe Dienste wie Windows Update Proxy-Einstellungen interpretieren und anwenden.
WPAD und PAC: Unterschiede zwischen Windows Server 2019 und 2022
- Windows Server 2019 WPAD-Unterstützung: Das (Web Proxy Auto-Discovery Protocol) wird in Windows Server 2019 von einigen Diensten unterstützt. Dies ermöglicht es, Proxy-Einstellungen automatisch über DHCP oder DNS zu beziehen.
- Windows Server 2019 PAC-Dateien: PAC-Dateien können in bestimmten Szenarien funktionieren, insbesondere wenn sie über die Internetoptionen oder Gruppenrichtlinien konfiguriert sind.
- Windows Server 2022 WPAD-Unterstützung: Eingeschränkte WPAD-Unterstützung; In Windows Server 2022 ist die Unterstützung für WPAD in systemnahen Diensten wie Windows Update eingeschränkt oder nicht vorhanden. Dies bedeutet, dass automatische Proxy-Erkennung über WPAD für diese Dienste nicht zuverlässig funktioniert
- Windows Server 2022 PAC-Dateien: PAC-Dateien werden von systemnahen Diensten wie Windows Update nicht mehr automatisch berücksichtigt, selbst wenn sie über die Internetoptionen oder Gruppenrichtlinien konfiguriert sind. Stattdessen wird empfohlen, feste Proxy-Einstellungen zu verwenden.
Gruppenrichtlinien u. Registry-Unterschiede: Windows Server 2019 / 2022
- Windows Server 2019 Gruppenrichtlinien: Proxy-Einstellungen, einschließlich PAC-Dateien, die über Gruppenrichtlinien konfiguriert sind, werden von vielen Diensten übernommen.
- Windows Server 2019 Registry-Einstellungen: Manuelle Konfigurationen in der Registry können Proxy-Einstellungen für verschiedene Dienste beeinflussen.
- Windows Server 2022 Gruppenrichtlinien: In Windows Server 2022 werden Proxy-Einstellungen über Gruppenrichtlinien, insbesondere PAC-Dateien, von systemnahen Diensten wie Windows Update nicht mehr berücksichtigt.
- Windows Server 2022 Registry-Einstellungen: Die manuelle Konfiguration von Proxy-Einstellungen in der Registry hat möglicherweise keinen Einfluss auf systemnahe Dienste. Es wird empfohlen, den Proxy explizit über `netsh winhttp` zu konfigurieren.
Empfehlungen für Windows Server 2022
- Vermeiden Sie die Verwendung von PAC-Dateien und WPAD für systemnahe Dienste wie Windows Update.
- Konfigurieren Sie feste Proxy-Einstellungen über die Eingabeaufforderung mit dem folgenden Befehl:
netsh winhttp set proxy proxy-server="http=PROXY_SERVER:PORT;https=PROXY_SERVER:PORT"
Ersetzen Sie `PROXY_SERVER` und `PORT` durch die entsprechenden Werte für Ihren Proxy-Server.
- Überprüfen Sie die aktuellen Proxy-Einstellungen mit:
netsh winhttp show proxy
- Stellen Sie sicher, dass Gruppenrichtlinien und Registry-Einstellungen keine widersprüchlichen Proxy-Konfigurationen enthalten, die die Funktion von systemnahen Diensten beeinträchtigen könnten.
Für weitere Informationen und detaillierte Anleitungen sind die folgenden Quellen zu konsultieren:
How the Windows Update client determines which proxy server to use
How to disable HTTP proxy features – Windows Server
Using WPAD (Web Proxy Auto-Discovery Protocol on Windows
Diese Ressourcen bieten umfassende Informationen zur Konfiguration von Proxy-Einstellungen und zur Fehlerbehebung bei Problemen mit Windows Update und anderen systemnahen Diensten.
MVP: 2013 – 2016
WPAD und PAC sind irgenwie aus der Mode gekommen. Transparente Proxies funktionieren unbemerkt im Hintergrund, erst Sophos SG, nun zwangsweise XGS.
Das kann sicherlich nicht nur Sophos.
Es läuft. Vielleicht mal drüber nachdenken, das ganze WPAD/PAC Zeugs in Rente zu schicken. Hat mir damals nix als Ärger eingebracht. Damals war noch Cisco ASA 55xx Stand der Technik und eine Linux VM mit Squid mit einem riesen Regelwerk machte das, was heute meine Shophos XGS mit Webprotection deutlich besser kann.
Wieso steht da "bash"?
KI-Quatsch
ChatGPT-Admins… Die Frage ist doch eher, warum soll sich jeder Windows-Server separat seine Updates selbst direkt aus dem Internet holen? Warum wird hier kein WSUS oder MECM eingesetzt, welches die Updates zentral verwaltet und verteilt? So dass man auch mal sehen kann, welche Server noch welche Updates brauchen, und dass man auch mal von einer zentralen Stelle ein Update blockieren oder zurückziehen kann? So weiß man ja auch garnicht, ob abzusehen ist, dass bald die nächste Kommune gehackt wird, weil Sicherheitsupdates auf den Servern fehlen.
Zur eigentlichen Frage: Unter welchem Account läuft denn der Update-Dienst? Die Proxy-Pac wird ja im USER Zweig der Gruppenrichtlinien bzw. Registry verteilt, der Windows-Update-Dienst ist aber normalerweise kein AD-User, sondern das lokale SYSTEM Konto. Bekommt SYSTEM überhaupt die Proxy-Pac aus einer Benutzerrichtlinie mit?
> Bekommt SYSTEM überhaupt die Proxy-Pac aus einer Benutzerrichtlinie mit?
Nein, flasches Objekt. Computer übernehmen keine Benutzerrichtlinien. Davon abgesehen benötigt es eine Interaktive Anmeldung zur Übernahme von Richtlinien.
Das mit dem manuellen Eintragen des Proxy Server am Server ist Bullshit. Das gilt nur für den angemeldeten User.
Das Setzen mit netsh hingegen ist nicht neu und galt auch schon für ältere Windows Versionen (ich erinnere mich, dass ich das für 2008R2 mal musste). Das Systemkonto bekommt und bekam schon vor 2022 von einem Proxy nichts mit.
Das Verteilen der .pac und wpad.dat sollte zudem defensiv erfolgen, da unterschiedliche Browser/Plattformen diese unterschiedlich einlesen/suchen.
Zum Beispiel sollte man A/CNAME auf http://wpad.example.local/wpad.dat anbieten UND auch ein http://example.local/wpad.dat
Meistens scheitert es am Content-Type, der application/x-ns-proxy-autoconfig sein sollte.
Manche Windows-Versionen/Browser (in meiner dunklen Erinnerung der IE) hatten sogar Probleme mit Groß- und /oder Kleinbuchstaben.
> …funktioniert Windows Update über das Internet…
Lieber Julian S. You had one job! Ein frei am Netz hängender Windows-Server (auch wenn hinter einem Proxy) bedeutet der Verlust von allen Schutzzielen (CIA-Triad).
"Manche Windows-Versionen/Browser (in meiner dunklen Erinnerung der IE) hatten sogar Probleme mit Groß- und /oder Kleinbuchstaben."
Nur zu wahr.
Eines der ersten Dinge die ich damals (vor gut 20y) in unser pac file eingebaut hatte war
host=host.toLowerCase();
Ist immer noch drin; schadet ja nicht und die zussäztliche 0.1ms die das pac file länger braucht stört keinen. Soweit ich mich erinnere hatte sogar der non-Chrome Edge noch dieses Problem.
> Zum Beispiel sollte man A/CNAME auf http://wpad.example.local/wpad.dat anbieten UND auch ein http://example.local/wpad.dat
Auf der Suche nach einem WPAD ist DHCP vor der DNS Anfrage.. Über die Option 252 kann dann die URL zur wpad.dat/proxy.pac/giveit.aname verteilt werden.
Der DNS Eintrag ist nach dem DHCP praktisch ein Fallback oder für Rechner mit Fesnter IP Adresse. Die Verteilung der URL ist eigentlich unnötig, wenn das Autodiscover nicht funktioniert, vorher würde ich diese nicht "statisch" an die Clients/Benutzer verteilen. Die URL muss ja immer existieren und definiert sein, denn schliessliche benötigen DHCP und DNS eine Antwort, die sie geben können
Alles richtig, defensiv eben.
Wer sagt dass der Windows Server frei am Netz hängt, nur weil ein Proxy für den Internetzugriff genutzt wird? Kennst du die Infrastruktur? Überleg doch einfach mal, bevor du schreibst.
es ist alles gesagt… Du nutzt offensichtlich keinen WSUS und beziehst Updates direkt aus dem Netz… und selbstverständlich wenn Dein Proxy dem System bekannt ist, bist Du mit dem Rechner am Netz.
Das mit dem Überlegen liegt auf Deiner Seite….
Manche Dienste/Applikationen in Windows benutzen 'winhttp', andere 'wininet'
Je nachdem greifen entweder die via pac verteilten proxy settings oder auch nicht.
Dann kommt es auch darauf an ob man das pac auf wpad hostet (http://wpad.company.com/proxy.pac) oder sonstwo (http://pacserver.company.com).
Manche Unternehmen blocken auch auf DNS-Level den wpad-Eintrag; d.h. selbst wenn der Eintrag im DNS steht (und die Zone auf einem MS-DNS liegt) bekommt man schlicht keine Antwort auf nslookup.
Zumindest in der Vergangenheit konnte es sogar einen Unterschied machen ob man es als '/proxy.pac' oder als '/wpad.dat' aufruft. Minimal unterschiedliches Verhalten…
Richtig lustig kann es werden wenn sowohl 'autodetect' und gleichzeitig 'pac file von url' aktiv sind.
Das ganze ist oft ein ziemlicher K(r)ampf (und 'autodetect proxy settings' ist enabled by default, zumindest bei uns waren die Windowsadmins auch schlicht zu faul das zu deaktivieren.
"Manche Unternehmen blocken auch auf DNS-Level den wpad-Eintrag"
Das ist eine bekannte Härtungsmaßnahme, die z.B. Akamai letztes Jahr im Rahmen einer Empfehlung zur Härtung von DHCP/DNS auf Windows-Maschinen empfohlen hat.
https://www.akamai.com/blog/security-research/abusing-dhcp-administrators-group-for-privilege-escalation-in-windows-domains
Auch z.B. PingCastle prüft, ob wpad entsprechend blockiert ist.
Komplett OT:
Hostpoint hat heute grössere DNS Probleme, was viele Webseiten betrifft…
https://hostpoint-status.com/
Seitdem der IE quasi entfernt wurde .. fehlt ja der Nachfolger in der GUI für die Internetseiten aber auch Proxy Einstellungen.
Ich bin mir nicht sicher ob Microsoft das Konzept weiterführen wird.
Proxy Server passen nicht zum Zerotrust Prinzip .
Bullshit! Schau in der klassichen Systemsteuerung nach oder gib in der Shell ein:
Rundll32.exe shell32.dll,Control_RunDLL inetcpl.cpl
Der Rest ist noch größerer Bullshit!
>>> Proxy Server passen nicht zum Zerotrust Prinzip
Man hat halt nicht immer die Wahl wenn man von kommunalen Dienstleistern abhängig ist…
Proxyserver sind eines der wichtigsten Dinge, die man in sein Netzwerk stellen sollte, um sich vor dem ganzen Dreck da draußen zu schützen. Das ist "Zero Trust" – vertraue niemandem da draußen, den du nicht kennst.
Und den Proxyserver soll ich dann MitM machen lassen oder wie soll der schützen?
ja.
besser du, dein System/Scanner liest mit, als ein anderer.
zudem nutzt du den proxy um Internetzugang mit Benutzer Authentifizierung zu realisieren und zb Admins den Weg ins Web zu verweigern (Ausnahmen kann es geben)
@squat0001
tippe Mal Windows Taste und"Proxy" … in den pc Einstellungen setzt du identische Registry Einträge zur alten cpl
Letztere war immer schon der Systemproxy, den auch andere Browser und Produkte nutzen konnten, nicht nur der IE