Monday, March 30, 2015

Exchange 2013 Hardening - Admin Center Externally Accessible

In Exchange 2013 the admin UI is web based instead of the traditional mmc interfaces in past versions. Although I have traditionally been apprehensive of web based interfaces,  Exchange Admin Center (EAC) in Exchange 2013 is actually very well designed and easy to use. For more details see this article.

After a recent deployment I realized that EAC seems to be accessible externally by default if Outlook Web Access (OWA) is setup. I started looking for a place to disable external access. Searching online I found several workarounds.

Method 1 - Disable EAC Altogether

This article from Microsoft explains how to turn off EAC functionality completely with the Powershell command:

Set-ECPVirtualDirectory -Identity "serverName\ecp (default web site)" -AdminEnabled $false

 
Logically you can re-enable EAC by changing the $false to $true. After each of these commands it takes several minutes for them to take affect. You can do an IIS reset if you're not worried about annoying users, but I'd advise waiting a couple minutes

It's worth noting that disabling EAC takes away some functionality for OWA users to set "Out of Office" messages, manage their mobile devices, and a couple other things.

Method 2 - Using IP and Domain Restrictions in IIS

Another method several blogs talked about is using IP and Domain Restrictions in IIS to restrict access to the EAC virtual directory to specified IPs or subnets. There is a good writeup here, so I won't re-invent the wheel.

It's not a great security practice to use the Builtin Administrator account for any externally facing authentication because the lockout policy doesn't apply to it. An attacker could brute force the account without having to worry about locking it out. There's a good article here that says:

"Since the authentication is being handled by IIS the usernames are not being screened, and so a user encounters an HTTP 403 error when they are barred from using ECP but have been authenticated successfully (even if you remove the Administrator account from the ‘Organization Management’ Exchange Security Group), so the brute-force attacker can saturate the server with logon requests and precisely determine when they have cracked the Domain Admin credentials."

Several people commented on the blog above saying you still get a 403 even when IP and Domain Restrictions are in place for the EAC virtual directory. I haven't tested this method myself yet, but I plan to and will update the post at that time.

Method 3 - Microsoft's Suggestion

Microsoft says here they recommend installing a separate CAS server and configure it to only handle internal requests using the following command:

Set-ECPVirtualDirectory -Identity "InternalCAS\ecp (default web site)" -AdminEnabled $True

However, in typical big vendor fashion this solution is not a very feasible option for most small/medium businesses.  


Which Option is Best?

Once again it's the balancing act of security vs. usability. You need to evaluate your organization's risk and determine whether the business value of tools like OWA or Outlook Anywhere outweigh these risks.

No comments: