Welcome to our version on Thoughts of Primary School Tech, ironically with me, a college tech (and manager I might add), my my we have moved one since we first starting blogging on here.
Lets sort the questions out once and for all and get some pictures involved. None of this, "just add it to gpo" generic responses, or "that is trusted zone, just add it there", nothing more annoying when someone posts up a solution in their own language and you have no clue how to solve the problem.
The Policies
First lets bring up a picture, we all understand pictures.
For those with visual difficulty, this picture shows a side by side comparison of the Server 2012 group policy which affects the 4 security zones found on the security tab in Explorer.
In Group Policy this is found in the following location:
Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page -> Site to Zone Assignment List.
On the Client machine the security page is found by going to:
In go to Tools (Alt+X), then go to Internet Settings. Choose the Security Tab.
Now even though we are playing within Internet explorer settings, you should know windows well enough to know that a window that shows your files is using the Explorer.exe process. Just because these settings live in internet explorer, doesn't mean they do not affect the settings within the rest of the operating system. This is a big reason to why removing internet explorer is almost impossible without breaking something else, it is part of the operating system and the settings affect the system as well.
Drive Mappings
Right a mapped drive defined by either a script or preferences is just putting a friendly look on what would would be an UNC path which non technical folk, bless them, would never understand.
The mapped R:\ drive for example, would actually be the location \\Servername\sharename\resources but we cannot expect our users to know this, so we just say it's the R:\ drive. Simple.
Now you can map this location in five potential (realistic) ways.
- You map it based on the NETBIOS name of the server, so lets say our server is called File-SVR-01, so the map would look like \\File-SVR-01\Sharename\resources.
- You can map it based on the server's IP address so: \\192.168.10.4\Sharename\resources
- You can map it based on an alias of your server so: \\Files\Sharename\resources
- You can map it based off a DFS namespace so: \\domain.local\NS\Sharename\resources
- You can map it based off the full FQDN of the file server so: \\File-SVR-01.domain.local\Sharename\resources
There are probably plenty of others, especially we get SANS involved, but I feel for the majority of us, these five should be the most common ways.
Now I know that stuff like using NETBIOS or the FQDN are essentially the same, and yes in all intensive purposes you would be correct, but for this file security warning we suffer on a daily basis it can matter in which method you used. Consistency is important when mapping drives, if you use the FQDN, then you must use it for every share, do not cut corners here or you can get some unexpected results.
Fix the problem
Lets fix the problem on one machine first, prove the fix and just get rid of that open file security warning once and for all. I do not want you to start deploying out policies you might not have full understanding of because whats the point if you do not learn anything from it.
Get on a machine, login, ideally you need to be on an account that has permission to alter the internet explorer security settings, so domain administrator on a machine in a different OU unrestricted by policies. You need to have mapped drives however to test.
Find a .exe file in the mapped drive and attempt to use it. It should not run immediately and you get the famous:
Open Security File Warning
Notice that even as an administrator, this still appears.
Notice at the bottom the warning you receive, this is important.
"While files from the internet can be useful, this file type can potentially harm your computer. Only run software from publishers you trust"
This is the error we would like to see, as this entire topic is based on this particular one. The following two errors are different problems:
User Account Control Error
Digital Signature Error
Fix found here: Fix Digital Signature Security Warning
Now that you understand the differences between the three errors above, lets assume you have got the first error screen the one specifying it is a file from the internet and poses a security risk.
Now you know that the file is not from the internet and is from your local network, you know this because you know your mapped drive is a server location. So now you need to add your server to your intranet zone, not trusted zone, not restricted, not internet zone, your intranet zone.
This is important as there are a lot of people out there that are all like, stick it in your trusted zones, this can actually cause you more headache sometimes. The reason being is because in all server versions with the exception of 2008R2 and above, the trusted zone would of actually worked.
Weird right? I never tested this theory but apparently after endless searches and realization of the pattern, everyone who has this problem on 2008 or lower, resolved it, yet those that have 2008R2 or higher, said it doesn't, so I have to make that connection there. Might not be true, but I never said I was honest.
The reason being is that trusted sites does not turn off prompts, intranet does.
Before we even touch server side, lets make it work on one machine, then we know what to type in on the server, as the server does not have any validation of the information you type into it, meaning you might attempt to force incorrect keys onto your clients, which is not good and causes errors, these errors will be explained at the end of this post.
Go to: In IE -> Tools (Alt+X) -> Internet Settings -> Security Tab -> Local Intranet -> Sites -> Advanced
Type in *.domain.local (filling in domain.local with the full name of your domain).
If you do not type it in correctly, you will be presented with this error:
This error explains the syntax that can be put in this setting. If you do not meet the syntax requirements, it tells you about it. However, if you type the incorrect syntax on the sever, it will still accept it. This is why we do it on the client first, once we do it right here, we know exactly what to type on the server.
After you have typed in your wildcard domain, press ok and exit out of Internet explorer.
Now try to open your .exe you tried before and hopefully the security file type will vanish. You have successfully found the fix for the problem and can move to the Server Side Policies.
Continue Only if the security file prompt still appears, if it has vanished, go to the server side settings.
If it is still not working, then continue.
Now go back to the same advanced menu and remove the *.domain.local setting, since we know it does not work with just this, there is no point in it now.
Now the reason this wouldn't work is most likely because of the way you are mapping your drives, if your drives are not being mapped with a Netbios or FQDN name, then this would the reason for it. If you map using IP Addresses, then this is a common reason for the failure.
So this time in the advanced menu you must put the IP Addresses of your file server(s) and if you want the entire scope to treat the entire domain as intranet.
Remember the syntax and no /24 /23 subnets do not qualify.
The trick now is trial and error and requires you to make some decisions. I do not know your network and frankly would confused you if I started recommending some things. Try different combinations. The benefit however is that you know when you type something in, it is valid if it accepts it and is invalid if it doesn't, take advantage of this validation as the server does not give you this luxury.
Eventually you will find that it accepts something and as you test the .exe from the mapped location, bang, the .exe starts to run without the warning, at this point cheer! Remember the setting, the exact setting remember the syntax like it was your own name. Lets move to the server now.
IMPORTANT - Remember this setting, it is your fix and you need to type it in on the server.
Server Side
- Go to your primary domain controller
- Open up group policy management.
- Go to: Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page
- In here I have manually enabled the following policies:
- Intranet Sites: Include all local (intranet) sites not listed in other zones
- Intranet Sites: Include all sites that bypass the proxy server
- Intranet Sites: Include all network paths (UNCs)
- I have disabled
- Turn on automatic detection of intranet
These polices affect the settings in the Local Intranet window found by going to:
In IE -> Tools (Alt+X) -> Internet Settings -> Security Tab -> Local Intranet -> Sites
Applying the policies above will grey out and prevent change in this area.
Now Site to Zone Assignment policy (below) will affect everything within the Advanced menu from here, as you can see the "advanced" button above.
Site to Zone Assignment
This is the advanced menu where the settings will appear.
The setting will not appear if you do not specify the value of "1" to the value name (see next image)
Within this policy you can specify the security zones for your intranet.
Values are:
1. Intranet Zone
2. Trusted Site Zone
3. Internet Zone
4. Restricted Zone
To prevent file security windows appearing when opening up a certain file type from a mapped drive, you must know how your mapped drive is mapped first. The setting you discovered by following this document will be the setting you need to deploy out.
So type in your setting e.g. *.domain.local in the Value name field and type in 1 in the value field.
Now remember that Validation error:
This will not happen if you make a mistake here, the server will accept it regardless of if it is right or not. This is bad and should not be done.
Gpupdate and RESTART your client machines once you have put in the setting and applied it in group policy.
Open up a client affected by the policy, go to the advanced menu in Internet explorer intranet settings and see if your policy has applied.
Try and open a .exe as a restricted user and by magic, your file security warnings now vanish as if they were never a problem. Such a pain in the backside, but all this work is worth it, especially if you use software that when updated server side runs .exes when loading up client side.
Known Errors
If you find other errors that relate to this, please tell us in comments, the longer the list the easier it is for those struggling to find this blog.
Error 1
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.
Cause
You've typed something in wrong in the Site-to-Zone Assignment policy that does not meet the requirements of the syntax.
Resolution
Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page -> Site to Zone Assignment
Stick to the recommended syntax sequence, below is an image showing examples of the correct sequences supported by Windows.
Great post - thanks for sharing - problem resolved.
ReplyDelete