Microsoft’s June Cumulative Security Update for Internet Explorer (MS14-035 / KB2957689) had a change that caught many IT departments off guard. If you’re in an environment running Windows 7 with either Internet Explorer 9 or Internet Explorer 10 your users may have received an additional tab that opened after the reboot from their monthly updates applying:
Unfortunately, this still isn’t expected behavior in a corporate environment. End users tend to either ignore something like this completely or open a help desk ticket costing the IT organization money in the form of the help desk request. The problem is compounded by: (#1) Microsoft not warning corporate IT departments this change was coming, (#2) Microsoft not giving corporate IT departments a way to suppress the extra tab with the warning, and (#3) some users receiving the additional tab every time they open an IE window instead of seeing it just once.
The good news is that this extra tab can be suppressed with a Registry entry. The easiest way to do this in a managed environment is with Group Policy. In a Group Policy Object (GPO) that applies to user accounts, go to User Configuration > Preferences > Windows Settings > Registry. Right-click on Registry and choose New > Registry Item.
In the Properties for the new Registry item, set the following:
Action: Update Hive: HKEY_CURRENT_USER Key Path: Software\Microsoft\Internet Explorer\Main Value Name: PrivacyPolicyShown Value Type: REG_DWORD Value Data: 00000001
Obviously this won’t help you for the hordes of end users that have already received the extra tab, but it should prevent anyone logging into a system for the first time from seeing it down the road.
A few weeks back, I wrote about the Group Policy changes in the Windows 8.1 Update. One of the big changes in the Update was the addition of Enterprise Mode for Internet Explorer 11. Enterprise Mode allows web sites (either specified by the end user or via Group Policy) to be processed in such a way that they appear to to the site to be Internet Explorer 8. There are also some additional ActiveX security tweaks that happen in Enterprise Mode so that [hopefully] organizations can get away from being tied to older versions of IE.
I had that “Aha!” moment and put the site into Enterprise Mode and…. buzzer. Nope, same problem. What gives? This was supposed to fix this problem, right?
After banging my head against the desk a few times, it occurred to me that this particular web application has about 10 different URL’s behind it. You go to the published URL for the application that looks something like http://application.trekker.net, get kicked to https://app.auth.trekker.net, then get kicked to a central login service page (Shibboleth, ADFS, etc.). After logging in, you’re kicked to https://prod.app.authd.trekker.net:1234. [URL’s have been sanitized and replaced with trekker.net to protect the innocent!]
After looking at the source of the page (right click > View source), there were another two (!) URL’s in the page I’d never seen before: https://files.app.trekker.net and https://scripts.app.trekker.net. Another “Aha!” moment!
I added both of these sites to my XML file (here are instructions on how to set that up) and, voila! The app works! It appears that Enterprise Mode was taking my list literally and wasn’t including either of these URL’s since they were different than the main web application. Lesson learned: if using Enterprise Mode, make sure any other URL’s that are being called by the app get added to the Enterprise Mode IE website list to ensure that everything is running in Enterprise Mode.
One of the features include in Internet Explorer 9+ is performance notifications for plug-ins. With this feature, the user is notified when plugins are slowing down browser performance. As the screenshot below shows, the user is presented with a dialog at the bottom of the browser window that says, “Speed up startup and browsing by disabling add-ons.” The user has the option of disabling add-ons, being prompted later, or closing the dialog out by clicking the ‘x.’
The downside is that users can accidentally turn off browser plugins with this feature or, in a fully managed environment, generate calls to the help desk when browser plugins are pushed to computers. The good news is that the notifications can be disabled in Group Policy.
In a previous post, I covered disabling/enabling the Internet Explorer Enhanced Security Configuration (IE ESC) for Administrators via Group Policy. Disabling the IE ESC for Administrators is usually something I don’t recommend in a production environment. However, disabling it for Users/Non-Administrators is a different story. In most cases, you won’t have someone logging in to a console or over Remote Desktop (RDP) to your servers that doesn’t have Admin rights… that is unless your running Terminal Services/Remote Desktop Services or a third-party product like XenApp. In those environments, it is very normal to have users logged into a remote session that do need access to fully functional web browser. Microsoft didn’t give us any kind of obvious Group Policy setting to enable or disable the IE ESC. Like the setting for Admins, it is a Registry entry that can be tweaked with Group Policy Preferences for deployment to groups of servers so than you can make sure your end users are receiving a consistent environment.
One of the biggest security threats to a server is having a web browser installed. Running a server in Server Core mode resolves this problem; but, what do you do when you need the GUI enabled? This is the reason that Microsoft introduced Internet Explorer Enhanced Security Configuration in Windows Server 2003. Unfortunately, like a lot of other great features, Microsoft didn’t give us any kind of obvious Group Policy setting to enable or disable the feature. The good news? It is just a Registry entry that can be tweaked with Group Policy Preferences.