Internet explorer zonemapping gpo ошибка

Обновлено 25.11.2019

Добрый день! Уважаемые читатели и гости крупного IT блога Pyatilistnik.org. В прошлый раз мы с вами научились узнавать IP-адрес у различных операционных систем. Сегодняшняя публикация снова будет посвящена терминальным столам и RDS фермам, на которых вы можете встретить ошибку групповой политики с кодом события ID 1085, где не удалось применить параметры Internet Explorer Zonemapping. Давайте разбираться, что это такое и для чего необходимо, а главное, как поправить, чтобы ошибка не появлялась.

Что такое Internet Explorer Zonemapping

Internet Explorer Zonemapping — это зоны безопасности в браузере Internet Explorer, которые используются для понимания уровня отношения к тому или иному сайту. Этот параметр политики позволяет управлять списком сайтов, которые вы хотите связать с определенной зоной безопасности. Эти номера зон имеют соответствующие параметры безопасности, которые применяются ко всем сайтам в зоне.

Internet Explorer имеет 4 зоны безопасности, пронумерованные от 1 до 4, и они используются этим параметром политики для привязки сайтов к зонам.

• (1) зона интрасети (Местная интрасеть)
• (2) зона доверенных сайтов (Надежные узлы)
• (3) интернет-зона (Интернет)
• (4) зона ограниченных сайтов (Опасные сайты)

Параметры безопасности могут быть установлены для каждой из этих зон с помощью других параметров политики, и их параметры по умолчанию: зона надежных сайтов (низкий уровень), зона интрасети (средний-низкий уровень), интернет-зона (средний уровень) и зона ограниченных сайтов ( Высокий уровень). (Зона «Локальный компьютер» и ее заблокированный эквивалент имеют специальные параметры безопасности, защищающие ваш локальный компьютер.)

Если вы включите этот параметр политики, вы можете ввести список сайтов и номера соответствующих зон. Связывание сайта с зоной гарантирует, что параметры безопасности для указанной зоны будут применены к сайту. Для каждой записи, которую вы добавляете в список, введите следующую информацию, это имя сайта и номер зоны. Если вы настраиваете это список через групповые политики и делаете ошибку в синтаксисе ее заполнения, то вы легко можете у себя в системе, в моем случае на RDS ферме встречать предупреждение:

Первым делом необходимо понять, какая групповая политика изменяет данную настройку. Для этого вам необходимо открыть журнал событий Windows и перейти в журнал Microsoft-Windows-GroupPolicy, напоминаю, что мы его уже использовали при долго висящей политике Microsoft Disk Quota. Открыв журнал Microsoft-Windows-GroupPolicy-Operational найдите там событие с кодом 4016.

Обратите внимание, что тут сразу пишется в каком объекте групповой политики находится данная настройка. Если хотите перепроверить и найти ее по GUID, то выберите вкладку «Подробности». Тут вы увидите GUID расширения, имя GPO и GUID, который кстати можете поискать.

Так же отфильтровав журнал вы можете обнаружить ошибку с кодом 7016:

Забыл отметить, что если посмотреть в ошибке 1085 на вкладке «Подробности» на поле ErrorDescription, то там увидите ошибку в виде «Недопустимых данных«. Это означает, что у вас неправильные записи в данной политики.

Правильная настройка политики Internet Explorer Zonemapping

Чтобы ваши журналы не забивались ошибками с кодом 1085 необходимо правильно настроить групповую политику или локальные настройки Internet Explorer. Откройте оснастку управление групповой политикой (gpmc.msc). Перейдите к изменений той групповой политики, через которую у вас настраиваются списки сайтов для зон internet Explorer. Найдите политику:

Включаем политику «Список назначений зоны для веб-сайтов» и нажимаем кнопку «Показать». У вас появится окно редактора в котором нужно писать адрес сайта и номер зоны, напомню еще раз цифры соответствующие зонам:

• (1) зона интрасети (Местная интрасеть)
• (2) зона доверенных сайтов (Надежные узлы)
• (3) интернет-зона (Интернет)
• (4) зона ограниченных сайтов (Опасные сайты)

При вводе данных в редакторе групповой политики нет ни синтаксиса, ни логической проверки ошибок. Затем это выполняется на самом клиенте, когда расширение групповой политики «Internet Explorer Zonemapping» преобразует реестр в формат, который использует сам Internet Explorer. Во время этого преобразования реализуются те же методы, которые используются Internet Explorer при добавлении сайта вручную в определенную зону безопасности. Если запись будет отклонена при добавлении вручную, преобразование также будет неудачным, если используется групповая политика и будет выдано событие 1085 . Подстановочные знаки для доменов верхнего уровня (TLD). Одним из сценариев, который отклоняется при добавлении сайтов, является добавление подстановочного знака в TLD (например, * .com или * .co.uk). Теперь вопрос в том, какие записи рассматриваются как TLD;, ниже я приведу рабочие варианты.

Правильные варианта синтаксиса сайтов Internet Explorer Zonemapping

• *://*.pyatilistnik.org – Работает
• http://*.pyatilistnik.org – Работает
• *://pyatilistnik.org – Работает
• ftp://192.168.0.0/ – Работает
• https://pyatilistnik.org/ – Работает
• 192-193.0.0.0 Работает.
• 192-193.1-10.0.0 Работает
• 192-193.1-10.20-30.0 Работает
• 192-193.1-10.20-30.40-50 Работает

Далее открываете на клиенте командную строку и вводите gpupdate /force, чтобы обновить политику. Если вы все сделали правильно и у вас нет ошибок в синтаксисе написания сайтов Internet Explorer Zonemapping, то вы увидите, что политики отработали корректно.

Если есть ошибки в синтаксисе, то увидите вот такую картину:

так же показателем, того что есть проблемы, это отсутствие вашего сайта в зонах Internet Explorer. Если в списке нет каких-то сайтов, то для вас это сигнал, где искать ошибку.

Редактирование Internet Explorer Zonemapping через реестр Windows

Я вам не перестаю повторять, что групповая политика меняет просто ключи реестра Windows на нужном объекте.

• Для пользователя — HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet SettingsZoneMapDomains создаем тут ключ REG_DWORD с нужным значением зоны IE
• Для компьютера —
• HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionInternet SettingsZoneMapDomains создаем тут ключ REG_DWORD с нужным значением зоны IE

• Для включения галки «Для всех сайтов зоны требуется проверка подлинности серверов (https)» необходимо создать запись REG_DWORD с именем Flags и значением 71 вместо 67 по пути HKEY_CURRENT_USER (или HKEY_LOCAL_MACHINE)SoftwareMicrosoftWindowsCurrentVersionInternet SettingsZones1
• Если вы хотите добавить диапазон IP адресов, тогда нужно добавлять 2 параметра. По пути HKEY_CURRENT_USER (или HKEY_LOCAL_MACHINE) SOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsZoneMapRangeslocal. Создать запись типа REG_SZ с Value name — :Range и Value Data – 192.168.1.0-254 и в SOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsZoneMapRangeslocal запись REG_DWORD с Value name — * (или нужный вам протокол) и Value Data – 1 (номер зоны)

На этом у меня все. С вами был Иван Семин, автор и создатель IT блога Pyatilistnik.org.

Дополнительные материалы

1. https://blogs.msdn.microsoft.com/askie/2016/04/05/description-of-event-id-1085-from-internet-explorer-zonemapping/
2. https://carlwebster.com/troubleshooting-microsoft-group-policy-site-to-zone-mapping/

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 log on and launch their published applications. As is my practice, the first thing I start doing is looking in the event logs. One of the 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 at the details, I saw this was causing an issue with logins and application launches.

Figure 1 shows the shortest delay I found.

Figure 2 shows the longest delay I found.

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

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

The cached copies of profiles are deleted so that 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. The 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 seczones.inf file instead of the policies.gpf file.

Here is the code I used to scan SYSVOL, looking for all policies that contain a seczones.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 "*UsermicrosoftIEAKBRANDINGZONESseczones.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 Sm@rt@$$ that I am, I now had to prove his list and test what now looked like the invalid entries in the customer’s 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 a much higher level of access 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 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://www.citrix.com/products/receiver.html in zone 2, as shown in Figure 3. [5-April-2021, this is no longer a valid URL]

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

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

Figure 6 shows running GPUpdate /force.

So a URL with no Zone number is an invalid entry. Looking at my Trusted Sites shows just the original entry is there, as shown in Figure 7.

Another possible invalid entry from the customer. Notice the * after the .com, as shown in Figure 8.

Figure 9 shows running GPUpdate /force shows that putting an * after the TLD is an invalid entry.

What about a popular entry of putting a port number in the URL, as shown in Figure 10?

Running GPUpdate /force shows success, as shown in Figure 11.

Or is it, as shown in 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, as shown in Figure 13.

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

*.tld, as shown in Figures 14 and 15.

GPUpdate /force shows it is an invalid entry.

Next on the list is www.google.com/maps, as shown in Figures 16 and 17.

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

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

Next up on the list is www.bing.*, as shown in Figure 19.

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

Next up is *cdn.amazon.com, as shown in 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, as shown in Figure 21.

Obviously, GPUpdate /force is not going to like this, as shown in Figure 22.

But what do my Trusted Sites show, as shown in Figure 23?

Did you notice that the entries in my Trusted Sites do not match the order 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 not enough information in the recorded event, as shown in Figures 24 and 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, as shown in Figures 26 and 27.

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

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

If you have any other URLs you would like me to test, email me. Webster@carlwebster.com

Thanks for your help, Jeremy and Martin.

Update 5-Mar-2016: Someone asked about the time savings. Suppose we use an average delay of six seconds and add a delay for one logon and one application launch with a total delay of 12 seconds per day per user. If we lowball 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, we start getting into the real-time loss, 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, as shown in Figure 28.

I did my tests 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 WEBSTERSLABXA652$ in 1 second.
Next policy processing for WEBSTERSLABXA652$ will be attempted in 99 minutes.

The next question is, does the time it takes for processing Site to Zone Mappings stay 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.

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:exampleshare – 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:exampleshare, which 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:localsrvshare – 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].

Figure 29 shows the GPO settings.

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

Thanks

Webster