Microsoft introduced Internet Explorer Enhanced Security Configuration (IE ESC) in Windows Server 2003 (it's in Windows Server 2008 as well). IE ESC follows the "secure by default" mantra and locks down
In this tip, we'll look at why some admins think IE ESC is more trouble than it's worth and why you might want to stick with it despite some of the hassles associated with it.
The issue with IE ESC is the classic balance of utility vs. security. IE ESC strengthens Microsoft Windows server security by preventing the insecure, but too uncommon practice of browsing the Web on a server. But, the strict configurations lead many administrators to disable IE ESC. IE ESC's strong security settings can interfere with the normal operation of legitimate websites, applications and Universal Naming Convention (UNC) paths to intranet resources, such as scripts and executable files. It doesn't prevent you from going to the sites, but does block most file downloads, and prevents running multimedia, scripts and ActiveX components.
The Microsoft solution is to allow explicit website exceptions in IE trusted zones. However, in all but the simplest environments, you'll need to set up a process for identifying and nominating exceptions, which may mean working with user groups in some cases, and periodically updating them as needed -- yet another chore for overworked IT admins.
And yet, you will be less secure if you disable IE ESC. The rationale may be that, as an admin, you know what you're doing and you'll be very, very careful and only go to trusted websites. The question is: How many people have admin privileges on the server, and are they all as cautious as you?
For simple use cases such as file servers and domain controllers, said John Savill, advisory architect for EMC's Microsoft consulting practice and 10-time Microsoft MVP, there are only a few sites, such as MS Update, the hardware vendor site and the antivirus update you need to consider as trusted exceptions. You can whittle that down further if you manage AV updates centrally and use Windows Server Update Services or System Center Configuration Manager so the server doesn't need an Internet connection to Microsoft for updates.
What's more, while most hardware vendors will use ActiveX to scan a server for driver versions and install updates, that's just one more potential security exposure or another set of exceptions to administer in IE ESC.
"It comes down to laziness if admins can't be bothered to log off, access what they need by a client and copy files to the server," Savill said.
Terminal services create an interesting case, in which you may decide to enable IE ESC for admins and disable it for users. Typically, end users don't have direct access to the server. But enabling IE ESC on terminal servers could cause a lot of headaches and help desk calls if Web apps stop working properly, since the users are accessing the application directly via Windows Server. Savill said it's possible, but difficult to enable IE ESC for admins and disable it for users in Windows Server 2003. It's difficult to distinguish between admins and users, he said, and requires a lot of difficult manual work with Group Policies.
However, if you use Windows Server 2008, it's a simple selection in the Server Manager GUI.
If terminal services are only being used for a single app, say an ERP program, you may want to exclude the browser altogether, he said. If they need Internet access, you may need to accept the risk, because unlike administrators, they have limited user privileges.
"If it's their main desktop, you may have issues with restricting them if they need Internet access," Savill said. "You may have problems: 'How much can I really lock this thing down?'"
More complex servers require careful and somewhat detailed management, especially if you are managing IE ESC on multiple servers, some with different trusted website requirements. Rather than configure IE ESC on each machine, Savill said, use Group Policy in Active Directory to centrally control settings, both for changes and new installations.
This was first published in October 2009