Site To Zone Assignment List Wild Card Syntax In Literature

Internet Explorer site to zone assignments - is it valid and why not?

Hi there.

Time for a new post finally... Recently, I got involved in a discussion about IE zone assignments via Group Policy. This post discusses which entries are valid or not.

How to assign a site to a zone?


There are two possible ways to assign a security zone to a URL:
  1. Native Group Policy - MVP colleague Alan Burchill has a nice tutorial on that: http://www.grouppolicy.biz/2010/03/how-to-use-group-policy-to-configure-internet-explorer-security-zone-sites/
  2. Registry (through Group Policy Preferences Registry) - MVP colleague Joseph Moody has a nice tutorial on that: https://deployhappiness.com/managing-internet-explorer-trusted-sites-with-group-policy/
The first method prevents users from adding sites on their own. If this is desired, use it. The second method allows users to add sites on their own. 

What can I add as a site?

Site to zone assignments (s2z) takes URLs. A URL basically has up to 5 parts:
  • Protocol (http, ftp, file...)
  • User and password (ftp://johndoe:johnspass@somehost.dot.com)
  • Hostname (www.bing.com) or IP address
  • Port (wsus.intern.com:8531)
  • Path (evilgpo.blogspot.de/2012/02/loopback-demystified.html) 
s2z always requires a hostname or IP adress - for file:// it requires a server and optionally a share. User and password is never allowed. The protocol is optional. Port and path can be entered in the assignment, but are stripped upon processing.

If a hostname is provided, it must be either a plain hostname (no domain part) or a FQDN that consists of at least 3 parts. Hosts in root domains are not possible. If the FQDN consists of 3 parts only, the second level domain must have more than 2 characters in Windows versions prior to 10.

In addition, s2z supports wildcards. To be precise, it supports exactly 2 asterisk wildcards - one for the protocol and one for the plain host name in a FQDN or for the last part of an IP address. Repeat that: It is only 2 * wildcards (no ?), and they are only allowed for the protocol and for the plain host name or last IP address part - nowhere else.

If you have invalid entries, all valid entries will be still processed. s2z will log an event to the group policy eventlog with ID 1085 and error code 87 ("The parameter is incorrect"). Unfortunately, it will not add the site that caused the error to the event nor will it add the GPO that contained that entry.

So in case of errors it is up to you, the busy admin, to identify the invalid entries. To do so, check all GPOs for s2z entries and validate them. To assist you with this task, Microsoft provides some valid and invalid patterns here:
https://msdn.microsoft.com/library/ms537143.aspx
https://support.microsoft.com/kb/259493

And to further assist you, here are some more comprehensive samples of s2z entries and explanations why they are valid or not.

Valid entries

  • www.microsoft.com

    Valid entry - consist of a fully qualified host name (FQDN). Since no protocol is specified, it will be applied for all protocols.
  • https://intranet

    Valid entry - consist of a protocol and a plain host name. Since no domain is specified, it will be applied to a host sitting in the primary dns suffix domain.
  • https://www.mycorp.com:8080

    Partially valid entry - consist of protocol, host and port. The port will be transparently stripped, it will be applied for all ports on that host.
  • http://www.mycorp.com/index.html

    Partially valid entry - consist of protocol, host and path. The path will be transparently stripped, it will be applied for all paths on that host.
  • *://www.microsoft.com

    Valid entry - since the protocol is a wildcard, it is identical to specifying www.microsoft.com (without a protocol)
  • *.mycorp.com

    Valid entry - since the plain hostname is a wildcard, it applies to all hosts in the domain mycorp.com.
  • 192.168.1.15

    Valid entry - IP addresses are allowed as well as hostnames.
  • 192.168.1-255.*

    Valid entry - consists of an IP range and a wildcard for all hosts in that range.
  • http://microsoft.com

    Valid entry - but be aware that this is not an entry for the host microsoft in the domain com, but s2z converts this to *.microsoft.com. This is an implication of one of the rules above: If you use a FQDN, it must consist of at least 3 parts. Since we have only 2 parts here, s2z assumes this to be a domain.

Invalid entries

  • *hosts.mycorp.com

    Invalid entry - a wildcard is not allowed as a part of the hostname, but for the whole hostname only.
  • www.mycorp.*

    Invalid entry - the wildcard replaces a part of the domain.
  • www.*.mycorp.com

    Invalid entry (same as above) - the wildcard replaces a part of the domain.
  • http*://www.mycorp.com

    Invalid entry - a wildcard is not allowed as a part of the protocol, but for the whole protocol only (which of course is the same as omitting the protocol at all).
  • 192.168.*.1

    Invalid entry - a wildcard for IP addresses can only be used in the last position.
  • *.*.mycorp.com

    Invalid entry - only one wildcard is allowed, and only for the hostname.
Remark: In earlier versions of windows, if you provided a wildcard with a second level domain with only two letters (*.co.uk e.g.), this was an invalid entry. This was to prevent the whole SLD of some countrys to be added. At the time of this writing, this type of entry has become valid in Windows 10.

Credits

The discussion I mentioned above involved those two guys I wish to give credits:

MVP Jeremy Moskowitz - http://www.policypak.com and http://www.gpanswers.com

IT Consultant Carl Webster - http://carlwebster.com, specifically http://carlwebster.com/troubleshooting-microsoft-group-policy-site-to-zone-mapping/ which was the first result of our discussion. Thanks Carl for clarifying the thing about ports and paths that get stripped and the second level domain auto-wildcarding :)

One of the nice things about being an independent consultant is the new stuff learned while on projects. I learned some new information about Site to Zone Mapping I wanted to share with you.

[Testing updates are at the bottom of the article. Article last updated 5-Oct-2016.]

A project I worked on recently had users complaining about how long it took to logon and launch their published applications. As is my practice, the first thing I start doing is looking in the event logs. One of this issues I found was this mysterious message in the System event log:

Windows failed to apply the Internet Explorer Zonemapping settings

OK, what group policy did this come from? Is this really a problem? Was this slowing down the logon or application launch?

I did a quick PowerShell script to gather all the 1085 EventIDs from the System event log from their hundreds of XenApp 6.5 servers. What I found was there were many hundreds of these events every day on every XenApp server. Looking in the details, I saw this was causing an issue with logons and application launches.

The shortest delay I found was:

Figure 1

The longest delay I found was:

Figure 2

Most of the delays were in the 5 to 6 second range.

Now to find out what group policy was causing the issue.

The cached copies of profiles are deleted so I couldn’t run a Resultant Set of Policy on a user’s name or the server. Since I am an outsider with limited account access and limited visibility into Active Directory, I turned to the lab on my laptop. I built a test group policy with a few Site to Zone Mapping entries and saw that the settings were saved in a file called seczones.inf. Next step was to borrow some code that Michael B. Smith wrote for the XenApp 6.5 documentation script that traverses SYSVOL looking for the Citrix group policy file. I slightly modified Michael’s code to look for the seczone.inf file instead of the policies.gpf file.

Here is the code I used to scan SYSVOL looking for all policies that contain a seczone.inf file.

$pwdpath = $pwd.Path If($pwdpath.EndsWith("\")) { #remove the trailing \ $pwdpath = $pwdpath.SubString(0, ($pwdpath.Length - 1)) } [string]$FileName1 = "$($pwdpath)\SecZonePolicies.txt" $root = [ADSI]"LDAP://RootDSE" $domainNC = $root.defaultNamingContext.ToString() $root = $Null $xArray = @() $domain = $domainNC.Replace( 'DC=', '' ).Replace( ',', '.' ) Write-Host "$(Get-Date): Searching \\$($domain)\sysvol\$($domain)\Policies" $sysvolFiles = @() $sysvolFiles = dir -Recurse ( '\\' + $domain + '\sysvol\' + $domain + '\Policies' ) -EA 0 If($sysvolFiles.Count -eq 0) { Write-Host "$(Get-Date): Search timed out. Retrying. Searching \\ + $($domain)\sysvol\$($domain)\Policies a second time." $sysvolFiles = dir -Recurse ( '\\' + $domain + '\sysvol\' + $domain + '\Policies' ) -EA 0 } ForEach( $file in $sysvolFiles ) { If( -not $file.PSIsContainer ) { #$file.FullName ### name of the policy file If( $file.FullName -like "*\User\microsoft\IEAK\BRANDING\ZONES\seczones.inf" ) { #"have match " + $file.FullName ### name of the Citrix policies file $array = $file.FullName.Split( '\' ) If( $array.Length -gt 7 ) { $gp = $array[ 6 ].ToString() $gpObject = [ADSI]( "LDAP://" + "CN=" + $gp + ",CN=Policies,CN=System," + $domainNC ) $xArray += $gpObject.DisplayName ### name of the group policy object } } } } $cnt = 0 If($xArray -is [array]) { $cnt = $xArray.Count $xArray = $xArray | Sort } Else { $cnt = 1 } Write-Host "$(Get-Date): Output list of $($cnt) policies" Out-File -FilePath $Filename1 -InputObject $xArray If(Test-Path "$($FileName1)") { Write-Host "$(Get-Date): $($FileName1) is ready for use" }

Running this script produces a sorted list of policies that need further research. Just because a policy folder contains a seczones.inf file does not mean that policy contains Site to Zone Mapping. Now I needed to review every policy to see which ones actually use Site to Zone Mappings. As I reviewed each policy (by looking at the Settings tab for the GPO), I copied the Site to Zone Mappings to Excel. Once all policies had been reviewed, I used Excel to remove all the duplicate entries and sorted the remaining entries.

So what entries were causing the problem? What exactly are valid entries?

I reached out to Group Policy MVP Jeremy Moskovitz (owner of PolicyPak and GPAnswers) for help. He then reached out to a friend of his, Martin Binder, who sent back some useful information. The reply from Martin about what is valid and invalid:

This is a bug in how Windows processes the lists in that policy setting. The only valid items are: Valid: [(http|ftp|someotherprotocol|*)://](Host|*).dom.tld (The protocol spec is optional...) Everything else is invalid. *.tld - invalid www.google.com/maps - invalid www.bing.*- invalid *cdn.amazon.com - invalid *tp://www.policypak.com - invalid *.*.microsoft.com - invalid Tip: In Win10, 2 letter domains like *.co.au or *.co.nz are now allowed. These were forbidden in earlier windows versions and threw errors and possibly caused slowdowns.

Being the [email protected]@$$ that I am, I now had to prove his list and test what now looked like the invalid entries in the customers Site to Zone Mappings.

My laptop lab’s domain controller is Server 2012 R2 and the Forest Functional Level is 2012 R2. By this time, the customer had granted me much higher level of access so I was able to do a small test in their 2003 Forest and their 2008 R2 Forest. Results were the same in all three Forests.

I created a test VM, joined to the domain and logged in with local administrator credentials for the tests.

The first thing I did was create a Site to Zone mapping with a known valid entry of https://Receiver.Citrix.com in zone 2.

Figure 3

On my test VM I then ran GPUpdate /force, open Internet Explorer (IE), looked at my Trusted Sites and my entry was there.

Figure 4

Next I wanted to try what looked like an invalid entry from the customer, a URL with no Zone number.

Figure 5

Running GPUpdate /force, gives me:

Figure 6

So a URL with no Zone number is an invalid entry. Looking at my Trusted Sites shows just the original entry is there.

Figure 7

Another possible invalid entry from the customer. Notice the * after the .com.

Figure 8

Running GPUpdate /force shows that putting an * after the TLD is an invalid entry.

Figure 9

What about a popular entry of putting a port number in the URL?

Figure 10

Running GPUpdate /force shows success.

Figure 11

Or is it?

Figure 12

What happened to the port number? It is not even saved in the registry. So adding a port number is invalid but the valid data before the port number is saved.

Figure 13

Now let’s go through the list of invalid entries from Martin.

*.tld

Figure 14

GPUpdate /force shows it is an invalid entry.

Figure 15

Next on the list is www.google.com/maps.

Figure 16

GPUpdate /force appears to like what he said was an invalid entry.

Figure 17

But Trusted Sites shows anything after the TLD is removed. Just like with adding a port number, anything after the TLD is just removed.

Figure 18

Next up on the list is www.bing.*.

Figure 19

I can tell you that GPUpdate /force didn’t like that entry so I will not bother you with another image of that.

Next up is *cdn.amazon.com.

Figure 20

Trust me, that is not valid and neither is *tp://www.policypak.com or *.*.Microsoft.com.

My next question is what happens if you have a mix of valid and invalid entries.

Figure 21

Obviously GPUpdate /force is not going to like this.

Figure 22

But what does my Trusted Sites show.

Figure 23

Did you notice that the entries in my Trusted Sites does not match the order they were entered in the policy?  It appears Trusted Sites is a sorted list and all capitalization is removed.

What I would like to see is the Warning in the System event log would give more information. For example, what group policy caused the warning and what mappings are invalid. There is just not enough information in the recorded event.

Figure 24

Figure 25

What I learned:

  • Using Site to Zone Mappings is expensive
  • The more Mappings you use, the more time it takes
  • If there are any invalid Mapping entries, the time increases even more
  • All capitalization is removed
  • The URLs placed into the various Zones are sorted

As I was wrapping this up, I was asked about *://domain.tld. So of course I had to test it.

Figure 26

Running GPUpdate /force and it is valid. What shows in Trusted Sites is:

Figure 27

*://CarlWebster.com becomes just *.carlwebster.com.

If you have any other URLs you would like me to test, just email me. [email protected]

Thanks for your help Jeremy and Martin.

Update 5-Mar-2016: Someone asked about the time savings. If we use an average delay of six seconds and add a delay for one logon and one application launch that is a total delay of 12 seconds per day per user. If we low ball the number of users to 2000 then that is 24000 seconds lost. 24000 seconds divided by 3600 (the number of seconds in an hour) we get 6.67 hours lost per day. Multiply that by more users and more application launches and we start getting into real time lost which costs real money and cost real productivity.

Update 7-Mar-2016: Someone asked me to test http://10.218.* and it is invalid but http://10.218.*.* is valid.

Figure 28

My tests were done on the User Configuration but you should see the same on the Computer Configuration.

Does this Event ID only get recorded for this warning? To test, I cleared my Application Event Log and ran GPUpdate /force. The only entry now is “Security policy in the Group policy objects has been applied successfully.” In the Group Policy event log, I get the following three events recorded:

Completed Security Extension Processing in 297 milliseconds.
Completed manual processing of policy for computer WEBSTERSLAB\XA652$ in 1 seconds.
Next policy processing for WEBSTERSLAB\XA652$ will be attempted in 99 minutes.

Next question is does the time it take for processing Site to Zone Mappings still the same when all entries are valid as when there are invalid entries? I don’t have enough entries in my lab to know. When I do Change Control for the customer and fix all their Site to Zone mapping policies, I will let you know what I find out.

Update #2 7-Mar-2016:

I found the following three articles from Microsoft and will test more patterns.

IInternetSecurityManager::SetZoneMapping method
Problems Adding Top-Level Domains to Zone Sites List
Internet Explorer’s Explicit Security Zone Mappings

Tested the following patterns from the articles:

*://*.example.com – Valid, becomes *.example.com
http://*.contoso.co.uk  – Valid
*://server.contoso.com – Valid, becomes server.contoso.com
ftp://192.168.0.0/ – Valid
https://example/ – Valid
file:\example\share – Invalid even though the first article says it is valid
*://172.16-31.0.0.* – Valid, becomes 172.16-31.0.0

http://*.server.example.com – Valid even though the first article says it is invalid
ftp://* – Invalid

I then tested file:\\example\share and that shows as Valid but becomes file://example (the \share is dropped).

Patterns from the second article that are not in the first article.

ftp://157.54.23.41/ – Valid
file:\\localsrv\share – Valid but becomes file://localsrv (the \share is dropped)
*://157.54.100-200.* – Valid but becomes 157.54.100-200.*

After seeing the *://172.16-31.0.0.*  and *://157.54.100-200.* examples, I wondered how far that could be taken.

192-193.0.0.0 is Valid.
192-193.1-10.0.0 is Valid
192-193.1-10.20-30.0 is Valid
192-193.1-10.20-30.40-50 is Valid

Update 10-Mar-2016: Martin wrote an article on Internet Explorer site to zone assignments – is it valid and why not? Check it out.

Update 5-Oct-2016: Reader left a comment wanting two tests run. file:\\1.2.3.4 [with a valid IP address] and file:\\ComputerName [valid computer name with no domain added].

Here are the GPO settings.

Figure 29

I forced replication between my two domain controllers, did a gpupdate /force and even restarted the servers just to make sure. Running gpupdate /force reported no errors but neither entry appears in the Trusted Sites zone.

Figure 30

Thanks

Webster

0 Thoughts to “Site To Zone Assignment List Wild Card Syntax In Literature

Leave a comment

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *