Why you shouldn’t put an Exchange Server in the DMZ

3 08 2009

The official Microsoft documentation for Exchange Server is contradictory in terms of deploying an Exchange Server into your perimeter network (DMZ). In many cases, it is interpreted that placing an Exchange Server into this zone is a good idea.

This is a myth.

As a standard rule of managing your network, you should never place any machine joined to the domain into the DMZ. Exchange 2000, 2003 and 2007 (with the exception of the Edge Transport role – see below) must all be installed on machines joined to the domain – place them into the DMZ and you break the first rule of firewalls and Active Directory, which I mentioned above.

So why is this a bad idea?

An Exchange Server needs Active Directory to function because most of its configuration information is stored in the directory service. This is the reason why it must be deployed on a domain-joined server.

If you attempt to move an Exchange Server to the DMZ, you will quickly find that Exchange will break. This is because it loses the ability to find and communicate with the Domain Controllers on the private network. In situations like this, you would have to do one of two things:

  • Deploy an additional Domain Controller into the DMZ
  • Allow the Exchange Server access to the DCs on the private network

Completing either of the above tasks requires you to open ports between the DMZ and private network. The list of ports is extensive and includes sensitive services such as DNS, LDAP and NetBIOS. I heard a fellow Exchange Server MVP state the other day while referring to this list of ports: “open these ports and your firewall rules will look like Swiss Cheese”.

The bottom line is this defeats the principle of a DMZ. A DMZ is intended as a ‘safe’ location for machines which are not joined to the domain; you might put public web servers or public nameservers there, for example. In the DMZ, they are protected from the Internet, but anyone maliciously gaining access to those servers cannot cross the firewall into your private network. By opening the Active Directory ports I describe above and by placing a domain-joined machine in this insecure zone, any hacker in control of a compromised machine in the DMZ has a much easier route to access your Active Directory environment, perhaps bringing it to its knees.

Every Exchange MVP I know considers this to be a very, very bad idea. They would not configure an Exchange Server in this way and neither would I.

Any Exchange Server you deploy should always be on the private network. Located there, you can ensure it has access to the Domain Controllers without the need to compromise network security. From the outside, you only ever need ports 25 and 443 open to allow internal email to flow and for users to access Outlook Web Access and Exchange ActiveSync.

But what about Exchange 2000/2003 Front End Servers?

What about them? Again, it is a misconception – probably brought about by ambiguous documentation – that leads people to believe these servers are there for security reasons. They are not. Legacy Front-End Servers are designed for organisations with multiple mailbox servers. A front-end acts as a central connection point for access to OWA, OMA or ActiveSync under a single, common URL – it does not provide security.

If you are deploying a front-end server because you believe it will secure your Exchange environment, think again. Install Vamsoft ORF on a Virtual Machine or use an external spam filtering service as an alternative.

Exchange 2007 Edge Transport

With Exchange 2007, Microsoft have recognised this problem by adding the Edge Transport server role. This is the first time an Exchange Server role has been specifically designed to be located on the perimeter network. It is also the first time such a role exists for security reasons. The Edge Transport machine is designed to be on a workgroup – not a member of the domain – so it does not require sensitive ports to be opened between the DMZ and private network. It maintains its own copy of the Active Directory database using Active Directory Application Mode (ADAM) in Server 2003 or Active Directory Light-Weight Directory Services (AD LDS) in Server 2008.

I personally do not see a requirement for an Edge Transport server in an Exchange deployment, so I never deploy them. They are an unnecessary expenditure. Unlike a 2000/2003 front-end, they only process SMTP email traffic. Requests for OWA or Exchange Activesync still need to be made directly to the Client Access Servers (CAS), which are domain members and therefore still need to be located on the private network.

The minimal security advantage Edge Transport servers provide can easily be achieved directly on the Hub Transport servers – or by deploying a much cheaper Vamsoft ORF virtual server between the Internet and the Hub Transport server.


You should now have a better understanding of why an Exchange Server should not be deployed into the DMZ. I hope this prompts you to review your Exchange configuration and make appropriate changes to further improve your network security.

Illegal breakage found in headernever

Modifying Outlook Web Access Login Page

30 05 2009

After a recent Exchange 2007 deployment, I was asked to make some modifications to OWA to make it more intuitive for some of the less technically-proficient users to make use of OWA more effectively, and to personalise the OWA site to the company.

In Exchange 2007, the business logic which renders OWA is contained within the Client Access Server (CAS) role. This is a new addition; in 2003, this logic was handled by the back-end mailbox servers, with HTTP requests simply proxied via the front-end servers which acted in a similar fashion to a gateway. Therefore, on a 2007 Server, you need to be modifying the login screen on your Client Access Server(s).

The location of the OWA static content is C:\Program Files\Microsoft\Exchange Server\ClientAccess\OWA. Before you begin making modifications, I would suggest you take a backup of this entire folder and store it safely. There is a lot of ASP.NET programming in the various files; unless you are a proficient .NET programmer, you could easily break your forms-based OWA logon and several other aspects of OWA with just a few wrong clicks.

The changes I made were as follows:

  • I changed the header image on the front page (which says Microsoft Office Outlook Web Access) to include the company name below the text and the company logo in the upper right. This was particularly easy to modify using Photoshop, although any graphics editing suite would suffice.The file you need to take a backup of, then modify, can be found in the Current\themes\base folder below the ‘OWA’ directory referenced above. The file to modify is lgntopl.gif. It is in GIF format and opens in Photoshop as an Indexed image; if you are importing any graphics, you may need to change the image mode in Photoshop using the ‘View’ menu, to ensure colour content is retained.It looks particularly effective when the text for Company Name appears to the bottom right of the ‘Web Access’ line in the header image. That along with the addition of the company logo in the upper-right of the image personalises the OWA experience, and also acts as a potential security benefit – if users become used to seeing the header in this way, they may be deterred from logging in to any other OWA page which does not exhibit your modifications.
  • The logon page can be modified too. It can be found in the Auth directory, and is quite aptly named logon.aspx. If you did not make a backup earlier, it is very important you take a backup of this file prior to making modifications. You will see why when you right-click the file and choose to Edit it using Notepad or Wordpad.The page is built around a standard HTML table, and it is particularly easy to pick through the content to find out what does what. If, like me, it is unclear to you at the beginning, simply comment out sections of code and refresh your OWA login page to notice the effect. The HTML comment tags are <!– to start a comment, and –> to end the comment. All the HTML code you wish the browser to ignore should be within the two tags – but there is no limit to the number of comment tags you can have per page.The features I removed from the login page was the  ‘Public/Private’ login option and the ‘OWA Light’ version. The company decided it did not wish for these features to be visible to users. As a result, all users would login with sessions of type ‘Public’, and OWA would determine whether it operated in Premium or Basic mode based on browser (IE6 or above works in Premium, all other browsers operate in the cut-down, no frills Basic mode).I also added the following as a new row inside the main table which makes up the page:<tr>
    <td style=”width: 100%;font-size: 14pt; text-align:center;”>
    <p align=”center”>Welcome to <company>”s Web Mail</p>

    This added an additional line to the login page, once again to personalise OWA to the company.

Once you are happy with your changes, I suggest you make a note of exactly what changes you made. When any new Service Pack or Update Rollup applied to the server, it is likely the OWA files will be overwritten when the CAS role is upgraded, meaning you must implement your changes again. I do not advise that you copy/paste the original files back into their previous location for the simple reason that any SP/UR may upgrade these files, and overwriting them with your originals from the previous patch level will revert these changes.

I hope you have learnt something from this blog posting, and I look forward to hearing back from you as to how you have taken these modifications further with your OWA pages. You are not just limited to modifying the login page; within the ‘OWA’ directory there are plenty of other pages which can have changes made to them, and you can also access all the images which produce the various default themes and modify these as you wish.

Exchange 2007 access to all mailboxes for Administrator

24 05 2009

Deploying Exchange 2007 can have its problems at the best of times. The separation of Exchange management from the Active Directory tools also has a knock-on effect when it comes to granting Exchange-related permissions en masse. This seemingly easy task is now proving to be a minefield.

So, how do you grant an Administrator access to all the mailboxes for an Exchange 2007 Mailbox Database?

Remove the Default Permissions

Before you start, you need to remove the default permissions at the Exchange Organization Level. These apply to all mailboxes in the organization and specifically deny any administrative-type user the Send-As and Receive-As permissions. This may cause confusion later, so it is best to remove them.

The user accounts and groups which are denied the ‘Receive-As’ permission at the organization level are:

  • DOMAIN\Administrator
  • DOMAIN\Domain Admins
  • DOMAIN\Enterprise Admins
  • DOMAIN\Exchange Organization Administrators

In order to remove the Deny entry for all the above users, the following command should be used:

Get-OrganizationConfig | Remove-ADPermission -User “DOMAIN\Administrator” -AccessRights ExtendedRight -ExtendedRights Receive-As -Deny

Replace DOMAIN\Administrator with the other entries in the above list to remove the permission for those accounts too.

The Commands

Having removed the default permissions, you can now set about implementing the permissions needed. Prior to discussing the actul Powershell commands to use, it is important that you understand the different types of permission which can be granted:

  • FullAccess Mailbox Permission. This can only be granted at the individual mailbox level to a user or group of users; it allows the designated users the ability to access the mailbox via Outlook or the new feature to open another user’s mailbox in Outlook Web Access.This permission is granted directly on the mailbox using the cmdlet Add-MailboxPermission. An example might be Add-MailboxPermission -Identity JDoe -User MSmith -AccessRights FullAccess where MSmith is being granted the ability to access JDoe’s mailbox.This permission can also be granted via the Exchange Management Console. Selecting a Mailbox in Recipient view adds an option Manage Full Access Permission to the actions pane, where this permission can be managed in a similar fashion.The problem with granting permissions in this fashion is it has to be done on an individual mailbox basis. For granting permissions en masse, it would defeat the principles of granting permissions due to the administrative overhead of maintaining the ACLs. Instead, permissions should be granted on a common parent object and allowed to inherit to the child objects, in this case, the mailboxes.
  • Receive As Active Directory permission. This permission can be set either at the mailbox level, or at a higher level in the Active Directory tree. It has the same effect as Full Mailbox Access, with the difference that it can be set at the store or storage group level, and therefore will be inherited down by all decendent mailboxes.Generic Active Directory permissions related to Active Directory objects are granted and modified at the Management Shell using Add-ADPermission. This cmdlet expects the -Identity parameter to be a full Active Directory path – I believe a Distinguished Name is expected. It is, therefore, much easier to pipe this path from the result of a previous command, particularly when handling some of the more complicated Exchange objects with complex DNs. For example, to grant these permissions at the store level (the store being an Active Directory object), I could use: Get-MailboxDatabase -Identity “My Database” | Add-ADPermission -User “DOMAIN\Group of Users” -AccessRights ExtendedRight -ExtendedRights Receive-As

The problem with granting Receive As permissions is while Outlook will obey them and happily display a mailbox where the Receive As permission is inherited, the new feature of Outlook Web Access which allows other mailboxes to be opened does not. For the OWA feature to work, the user must be granted explicit Full Mailbox access on an individual mailbox basis, to every mailbox they need to access.

My Approach

To achieve the ultimate objective of allowing Domain Admins to access a mailbox, either from Outlook or OWA, I chose to use several commands.

I first granted Domain Admins ‘Receive-As’ access at the store level using the command I described above. Via Outlook, these permissions would allow any Domain Admin to open these mailboxes as additional mailboxes.

To counteract the OWA restriction, I had to grant the Full Access permission across every mailbox. While this is very messy to maintain, it is currently the only option. Furthermore, as new mailboxes will not have the permission set by default, I use a Scheduled Task with a small PowerShell script, to set the permissions for every mailbox once per day.

My PowerShell script (.ps1 file) consists of the following:

# Matt’s Powershell Script (see tigermatt.wordpress.com) to add Full Mailbox permissions to all mailboxes in the Exchange organization
Add-PSSnapin Microsoft.Exchange.Management.Powershell.Admin -erroraction silentlyContinue
$userAccounts = get-mailbox -resultsize unlimited
ForEach ($user in $userAccounts)
add-MailboxPermission -identity $user -user “Domain Admins” -AccessRights FullAccess

Via Task Scheduler (Windows Server 2008), you can launch the script by specifying powershell.exe as the application, and “& ‘C:\path\to\script.ps1′” as the parameter. Note the double-quote followed by single-quote, and the requirement to close both quotes at the end of the command.

On the basis defined by your Scheduled Task configuration (I would suggest the task runs daily during the night, when the load on the server is low), the script will enumerate all mailboxes in the Exchange Organization, adding the required Full Access permission to the Domain Admins group.

This concludes my entry on granting various permissions in Exchange using Powershell. I hope I have cleared up some concerns regarding the differences between adding Mailbox Permissions and adding Active Directory permissions, and that this helps you.

Extend Exchange 2007 OWA Automatic Logoff time

24 05 2009

If you find yourself being logged out from Outlook Web Access in Exchange 2007 more quickly than you would like, you may need to change some of Exchange’s security settings.

Firstly, it is paramount that you understand the ‘Public’ and ‘Private’ options on the OWA logon page:

  • Public is the default option for security reasons. If you log in to OWA using this option, your username will not be saved and your session will terminate after 15 minutes.
  • Private is intended for private computers. Selecting this option will cause your username to be remembered for subsequent visits to the site (you must, however, retype your password each time). Your session will also timeout after 8 hours, not 15 minutes.

If you wish to modify the default timeout settings for each type of session, you need to make some simple registry changes on the Client Access Server. This is, of course, the server where the business logic for Outlook Web Access resides, and is therefore the server which is processing the automated logoff.

Usual warnings apply – editing the registry can make permanent and potentially destructive changes to your computer. Perform the following at your own risk and with proper backups in place.

The key to modify on each CAS is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchange OWA.

The CAS looks for two DWORD entries within that key: PublicTimeout and PrivateTimeout. If one or both of these keys is not present, the session for which the key is omitted uses its default logoff value.

To modify the timeout in some way, you can edit or create one or both of the above keys. Set them as DWORD entries. When editing their values, choose the ‘Decimal’ option and enter a value from 1 to 43 200. The value is in minutes, meaning you can cause session to last anywhere from 1 minute up to a maximum of 30 days.

Having made the changes, restart IIS on the CAS server(s) for the changes to take effect. iisreset /noforce