OWA published with a TMG array member of a domain located in the DMZ
We will describe in this post how to set up Threat Management Gateway in a domain located in the perimeter network (DMZ) in order to publish your Outlook Web Access external URL and ensure a secure SSL connection. The OWA site is installed on the CAS servers of your Exchange infrastructure. The internal URL, registered in your private DNS, is being accessed by the computers in your internal network which are members of your domain. The external URL, registered in your public DNS, is being accessed by any computer connected to the internet, which obviously is not necessarily a member of your domain. To get both internal and external URL launch the following command on the Exchange Management Shell:
Get-OwaVirtualDirectory | ft server,InternalURL,externalURL |
In our example the internal URL is mail.internal.ldap389.info, the external URL is mail.ldap389.info. We want to ensure a secure SSL connection from the client to the OWA Website: To achieve that a SAN certificate issued by our enterprise PKI and including both URLs is installed on each member of the CAS array.
The network traffic of the computers located in your internal network, accessing the mail.internal.ldap389.info internal URL, is balanced across the CAS servers with a HLB device (represented by green arrows on the below diagram).
The clients connecting from the internet via the mail.ldap389.info internal URL first contact the TMG array, the traffic is balanced across the TMG server’s external NICs with a HLB device, those IPs are located in the public DMZ. The network traffic of the clients accessing your OWA from the internet is represented by red arrows on the below diagram and detailed in the next paragraphs:
I suggest you purchase a certificate from an external certificate authority and set it up on the TMG’s OWA web listener, by using this kind of certificate the computers which are not members of the internal.ldap389.info domain will perform an SSL connection with the TMG without any warning displayed on their web browser. If you use a certificate issued by your enterprise PKI, the certificate of the enterprise root CA will not be installed on the Trusted Root Certification Authorities store on the computers which are not members of your domain. For those computers you will get this kind of warning when connecting to the Outlook Web Access:
Communication is also secured with SSL between the TMG’s internal NICs (located in the “private DMZ”) and the CAS servers. In order to perform a secure communication by using the SAN enterprise certificate installed on the CAS servers, you have to install the certificate of the enterprise root CA as a trusted root CA certificate on your TMG servers.
TMG presents an HTML Form in which the user enters a user name and password, which TMG can then authenticate against Active Directory over LDAP secure protocol. LDAPs connection is performed on a Windows 2008R2 Core RODC which is a member of your internal network domain (DNS name rodc.internal.ldap389.info). You can configure more than one RODC in the LDAP Server Set in order to provide redundancy. You can cache credentials on the RODCs for users using the OWA from the internet, in that case you need to configure one AD site per RODC. Your TMG OWA listener will be set up as below:
In order to perform an LDAP over SSL connection with your internal RODC, the TMG must resolve the rodc.internal.ldap389.info name by using a host file. In the same host file, the mail.ldap389.info name points to the HLB which balances the traffic across the CAS servers (see host file on the diagram).
If you want to get all the benefits of a TMG Enterprise array, including the EMS replication, it needs to be member of a domain (dmz.local). I suggest you read this document on how to set up a domain in a DMZ. In our case there is neither trust relationship nor DNS forwarders between the two domains dmz.local and internal.ldap389.info (that is why we use host files). We only allow SSL connections between the private DMZ network and the internal network.
Securing your dmz.local domain is very important because it is located close to the internet, here are a few leads on how to secure it: The domain controllers should be located in a dedicated subnet in your private DMZ. TMG servers only authenticate against Windows 2008R2 RODCs, they should only communicate with a RWDC on the DNS TCP 53 port, in order to allow DNS update (see How does the client DNS update referral mechanism work?). In order to join a TMG server through a RODC perform the steps described in this article. You can also set up administrator role separation on the RODCs and deny password caching for domain administrators. Finally, you can set up the CachedLogonCounts value to 0 on the TMG servers, but you will not able log on with a domain account if no domain controller is available. In that configuration your TMG array is member of a secured domain and you can enjoy all the features of the enterprise version.
This post is also available in: French
2 Comments
Other Links to this Post
RSS feed for comments on this post. TrackBack URI
By fitness first leesburg va, February 9, 2013 @ 1:34 pm
Hey there just wanted to give you a quick heads up.
The text in your post seem to be running off the screen in Opera.
I’m not sure if this is a format issue or something to do with web browser compatibility but I figured I’d post to let you know.
The design and style look great though! Hope you get the
problem fixed soon. Cheers
By ldap389, February 11, 2013 @ 7:22 pm
Thanks for the feedback, I check asap.