Fehler beim Anwenden der Internet Explorer Zonemapping GPO

Ein häufig auftretendes Problem bei der Verarbeitung der GPOs betrifft die Verarbeitung der Internet Explorer Einstellungen, insbesondere der Site To Zone (S2Z) Mapping Liste. Folgende Einträge lassen sich a) im Eventlog oder b) in der CMD bei einem händisch ausgeführten gpupdate finden:

Computer-Richtlinie

The following warnings were encountered during computer policy processing:
Windows failed to apply the Internet Explorer Zonemapping settings. Internet Explorer Zonemapping settings might have its own log file. Please click on the "More information" link.

Benutzer-Richtlinie

The following warnings were encountered during user policy processing:
Windows failed to apply the Internet Explorer Zonemapping settings. Internet Explorer Zonemapping settings might have its own log file. Please click on the "More information" link.

Ein paar Details zu dem Fehler lassen sich aus dem Group Policy Client Service Log herauslesen, sofern dies aktiviert wurde. Aber auch ohne das Log liegt der Fehler i.d.R. daran, dass in der GPO, die das Zonenmapping konfiguriert, ein Syntax- oder Logikfehler drin ist.

Syntax

Die Site To Zone Assignment List (S2Z) besteht aus URLs. URLs bestehen aus maximal 5 Komponenten:

• Protokoll (z.B.: http, https, ftp, file)
• Benutzername/Passwort (z.B. ftp://user:password@ftp.company.de)
• Host (z.B. www.google.de) oder IP-Adresse (z.B. 10.0.0.101
• Port (z.B. www.company.de:8443)
• Pfad (www.company.de/blog/2020/article.html)

S2Z benötigt immer zwingend mindestens einen Host oder eine IP Adresse. Für SMB Server (file://) wird optional noch ein Share-Name benötigt. Die Angabe von Protokoll ist optional. Benutzername/Passwort  ist prinizipell nicht zulässig. Die Angabe von Port und Pfad ist ebenfalls optional und wird während der Verarbeitung entfernt.

Wird ein Host angegeben, muss dies entweder als einzelner Hostname oder als mindestens dreiteiliger FQDN (Hostname, SLD, TLD) angegeben werden.

Zusätzlich unterstützt S2Z an einigen Stellen „*“ Wildcards (keine „?“ Wildcards!), genauer gesagt zwei Wildcards: eine Wildcard für das Protokoll und eine Wildcard für den Hostnamen oder den letzten Teil der IP-Adresse. Nur dafür und für nichts anderes funktionieren die Wildcards (siehe auch Beispiele unten).

Leider ist die Syntax darüber hinaus extrem schlecht dokumentiert, dennoch kann man sich behelfen, wenn man nicht sicher ist. Dazu nutzt man einen Client, bei dem die GPO nicht angewendet wird und das Zonenmapping frei konfigurierbar ist. Auf diesem PC öffnet man die IE Einstellungen und fügt seine Einträge in die gewünschte Zonen-Liste ein. Ist alles korrekt, lässt sich sich speichern. Ist ein Eintrag falsch, erfährt man dies durch ein Popup, in dem auch auf einige Beispiele mit Wildcards eingegangen wird:

Man kann nun den Fehler entsprechend solange korrigieren, bis die Einträge gespeichert werden können. Jetzt kann man die Einträge 1:1 in die GPO übernehmen, da die Syntax in der GPO der Syntax einer manuellen Konfiguration entspricht.

Logik

Ein zweiter Fehler ist es, überlappende Hosts in unterschiedliche Zonen zu konfigurieren. Abgesehen davon, dass es generell nicht zulässig ist, z.B. zusätzlich zum Eintrag *.company.net noch den Eintrag www.company.net zu konfigurieren (www ist ja logischerweise Bestandteil von *), ist es gleich doppelt falsch, www.company.net in eine andere Zone zu konfigurieren als *.company.net. Dies führt zu einem Konflikt und folglich zu einem Verarbeitungsfehler bei der GPO Anwendung.

Protokoll Requirement

Ein weiteres Problem, welches zu der Fehlermeldung führen kann ist, dass die Einträge ohne Angabe des Protokolls https:// vorgenommen werden (z.B. weil die Konfiguration auch z.B. für http:// oder für file:// gelten soll) und im IE die Option Require server verification (https:) for all sites in this zone () aktiviert ist. Die aktivierte Option bewirkt, dass die Einträge mit dem Protokoll https:// gemacht werden müssen und auch nur für dieses Protokoll gültig sind.

Ändern kann man dies, indem man per GPO die Option deaktiviert, entweder auf Computer-Ebene oder (wie im folgenden Beispiel) per User.

Deaktivieren der Option für die Zonen Local Intranet und Trusted Sites:

REG ADD "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\1" /v Flags /t REG_DWORD /d 43 /f
REG ADD "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\2" /v Flags /t REG_DWORD /d 43 /f

Aktivieren der Option für die Zonen Local Intranet und Trusted Sites:

REG ADD "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\1" /v Flags /t REG_DWORD /d 47 /f
REG ADD "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\2" /v Flags /t REG_DWORD /d 47 /f

Und noch ein lustiges Phänomen mit Google, vielleicht hat da ja einer von euch eine Idee.

Ich habe in meiner Site to Zone Assignment List Policy mehrere Wildcard Einträge wie z.B. *.salesforce.com und *.travelclick.com. Alles gut. Enhält meine Liste allerdings den Eintrag *.googleapis.com, schlägt das Internet Explorer Zonemapping fehl. Ich finde einfach keinen Fehler, Syntax ist richtig und andere Wildcard Einträge funktionieren tadellos. Trage ich einen explizten Host von googleapis.com ein (z.B. maps.googleapis.com) funktioniert das Zonemapping auch. WTF?

Praxisbeispiel

Gültige Einträge

• www.company.com
  • Der Eintrag beschreibt einen FQDN. Da kein Protokoll angegeben ist, wird der Eintrag für alle Protokolle (http, https, ftp, file) angewendet.
• *://www.company.com
  • Der Eintrag beschreibt einen FQDN und gibt eine Wildcard als Protokoll an. Im Ergebnis ist der Eintrag identisch zum ersten Eintrag ohne Protokoll
• https://intranet
  • Der Eintrag besteht aus einem Protokoll und einem Hostnamen. Da keine Domain angegeben ist, wird der Eintrag auf den Host in der Domain des primary DNS Suffix angewendet.
• *.corporate.net
  • Der Host ist als Wildcard und die Domain ist vollständig angegeben. Der Eintrag findet somit Anwendung für alle Hosts in der Domain corporate.net.
• file://fileserver/files
  • Der Eintrag besteht aus der Protokollangabe für SMB, einem Hostnamen und einem Share.
•  10.0.0.1
  • Der Eintrag besteht aus einer IP Adresse.
• 10.0.0.*
  • Der Eintrag besteht aus einer IP Adresse, bzw. einer Wildcard für alle Hosts im angegebenen Subnetz.
• 10.0.1-255.*
  • Der Eintrag besteht aus einer IP Range und aus einer Wildcard für alle Host in der Range.
• https://company.de
  • Der Eintrag ist gültig. Dennoch ist in diesem Fall Vorsicht geboten. Der Eintrag wird NICHT als Host company in der Domain de interpretiert sondern konvertiert in *.company.de. Warum? Die Konvertierung ist eine Folge der vorangegangenen Regeln. Wird ein FQDN verwendet, muss dieser aus mindestens 3 Teilen bestehen. Da wir in diesem Fall jedoch nur 2 Teile haben, wird der Eintrag als Domain interpretiert und durch eine Wildcard vervollständigt.

Teilweise gültige Einträge

• https://www.corporate.net:8443
  • Der Eintrag besteht aus Protokoll, FQDN und Port. Der Port wird bei der Anwendung ignoriert und der Eintrag für alle Ports des Hosts angewendet.
• http://intra.company.com/index.html
  • Der Eintrag besteht aus Protokoll, FQDN und Pfad. Der Pfad wird bei der Anwendung entfernt und der Eintrag für alle Pfade des Hosts angewendet.

Ungültige Einträge

• *host.company.de
  • Eine Wildcard ist nicht erlaubt als Teil des Hostnamens sondern nur als Platzhalter für den kompletten Hostnamen
• www.corporate.*
  • Eine Wildcard darf nur den Hostnamen ersetzen, nicht das Ende Domain.
• www.*.corporate.com
  • Eine Wildcard darf nur den Hostnamen ersetzen, nicht einen Teil der Domain
• http*://www.company.net
  • Eine Wildcard darf kein Platzhalter für einen Teil des Protokolls sein, sondern nur für die gesammte Protokollangabe.
• *.*.corporate.org
  • Ein Eintrag darf nur eine Wildcard enthalten und nur für den Hostnamen und nicht die Domain.
• 10.0.*.1
  • Eine Wildcard darf nicht auf den ersten 3 Positionen der IP-Adresse verwendet werden, sondern nur an 4. Position

Sonderfall: 2-Zeichen SLDs mit 2-Zeichen TLDs

Wurden in älteren Versionen Wildcard Hosts in Kombination mit einer 2-Zeichen Second-Level-Domain (SLD) und einer 2-Zeichen Top-Level-Domain (TLD) verwendet (z.B. *.co.uk oder *.hp.de) war dieser Eintrag ungültig. Grund hierfür war es zu verhindern, dass ganze SLDs einiger Länder (wie z.B. *.co.uk, etc.) zu einer IE Zone hinzuzufügen. Erst mit Windows 10 wurde dieses Verhalten geändert und der Eintrag gültig.

Beispiele

Hier ein Beispiel einer gültigen Site-List

Nr.  Host                     Zone
1    *.company.de             2
2    *.xyz.com                2
3    www.company.net          2
4    intra.company.net        1
5    extra.company.net        2
6    10.0.101-200.*           1

Im Gegensatz hierzu eine fehlerhafte Site-List

Nr.  Host                     Zone
1    *.company.com            2
2    www.*.com                2
3    *corporate.net           2
4    https://www.company.com  1
5    *.*.server.net           1
6    www.xyz.*                1
7    10.0.*.1                 2
8    http://company.com       2

Was an dieser Liste fehlerhaft ist, erklärt sich größtenteils auf Grund der vorangegangenen Erklärungen. Eine Besonderheit hat’s noch bei Eintrag 4. Dieser Eintrag ist gleich auf Grund mehrerer Fehler ungültig. Einerseits ist der Host www bereits in Eintrag 1 (Wildcard) enthalten. Andererseits ist der Eintrag für die Zone Local Intranet konfiguriert, was einen Konflikt mit der in Eintrag 1 konfigurierten Zone Trusted Sites darstellt.

Quellen:
https://docs.microsoft.com