• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 931
  • Last Modified:

Exchange 2010 with TMG using RODC in DMZ

In our previous environment we had an Exchange 2003 dual server configuration with the Front end in a DMZ (provided by a hardware firewall) and the back end in our internal LAN, running on a windows 2003 R2 domain.  We have now rolled out a single server Exchange 2010 environment with Windows 2008 R2 domain level and have a TMG 2010 server awaiting deployment as the Exchange "front end".  Our environment has changed somewhat in the last few months - since upgrading to 2008 domain level we have deployed an RODC in the DMZ and have a number of servers connecting to it providing various services (IIS etc); which leads me to the question!

What would be the best configuration for me to use to present the exchange services through the TMG for the outside and inside access?  The TMG server needs to sit in the DMZ, and i would think now the best option would be to join it to the domain using the RODC server, or would it be best to set the TMG up as a secondary RODC Server?  We currently provide OWA, Outlook Anywhere and limited IMAP services to exchange; SMTP is locked down to only allow connections from our third party spam/av provider so unsure if i would need to direct that through the TMG as well or just leave SMTP pointing directly at the Exchange server?
Finally - would i be best using a single NIC setup or a dual NIC configuration, with one in the DMZ and one directly to the internal LAN?
  • 3
  • 2
2 Solutions
Bruno PACIIT ConsultantCommented:

In my opinion, from a "security" point of view, the best option is to leave the TMG out of a domain, as a standalone server in the DMZ.
TMG doesn't need to be a member of a domain. You can publish internal services (like OWA) with authentication using LDAP authentication or RADIUS authentication.

In my own opinion, a DMZ should never contain a DC of an internal domain. You can create an Active Directory domain for the DMZ safely but having some DCs of your internal domain in the DMZ is not secure.

Servers in a DMZ might be hacked control of them can be taken by an external attacker... well... at least you should always think about this possibility.
In my opinion, as soon as you consider that a server in a DMZ can be controlled by an external attacker then you must consider that ALL the servers in this DMZ are also controlled, because inside the DMZ there is no firewalls between servers.

That's why having a DC of the domain inside the DMZ is not secure, even if it's a RODC.
RODC are useful in case of server robbery... In that case, you are aware that the server has been lost and you have to change passwords of each stolen account.
In a DMZ, you won't be aware that an attacker has took control of your server, so you won't have time to change passwords or disable accounts before the attacker find a way to use informations stored in the RODC...

OK. That's my opinion: no DC in the DMZ, and TMG is not a member of a domain...

If your NEED TMG to be a member of an AD domain, it's less secure but it can be considered as secured enough for your situation. But personnally I would make things so that ALL DCs are on the LAN and no DCs are in the DMZ. You'll have to open TCP ports so that TMG can reach its controllers.

What you must NEVER do is to install RODC and TMG on the same machine !!! NEVER !!!!!!!!!!
You must always consider that TMG is a target for attackers. These attackers must not find ANY information on the TMG that can be useful to go forward and attack deeper in your network.

About SMTP, as you have a av/spam partner that acts as a SMTP relay for your incoming mails, redirecting e-mail through TMG won't bring any security...

Finally, as your TMG server is already inside a DMZ you don't need TMG to act as a firewall so a unique NIC is enough for your  situation.

Have a nice day.
Jian An LimSolutions ArchitectCommented:
Let's start with business sense

Do you really worry about having a DMZ? do you have a security compliance to do so? what is your size, and what industries you are in?

and given TMG is end of life, do you plan to replace the product in a few years down the road?

then next topic is security related.

since you have your email flow directly out from your internal network to the internet, therefore what your DMZ design usage? inbound purpose? or just because you want to do a like-to-like exchange 2003 front end replace with TMG?

usually there is some guideline says that no direct access from internet to internal network without passing DMZ.  do you uphold them?

RODC in DMZ is really a security question on how much your DC expose. while it offers flexibility.


So to answer all your question in a straight forward manner,

1. TMG and RODC is supported. (question is do you want to, like do yo uhave a seperate IT team to run different component, will it offers complexity on RODC with TMG? remember EOL on TMG means lesser experts in some future.)

2.  whether to repoint those services to TMG or not, as discussed earlier, it is up to what you want to achieve. If you uphold the "no direct connection should allow between internal and internet", then you should push all traffic to TMG so you know that is your entry door to your network. But if you have "it is not broken why fix" rule, then it is OK to allow direct connection.

3. single NIC or dual NIC. personally i will go with dual NIC.
this is more up to the TMG design you have.
dual NIC offers a very clear direction on where is the traffic comes from, is this internal or external. Of course, if you have no such requirement, then you can go with single NIC
Amaze_ITAuthor Commented:
Thanks for the replies people!  to give a general response here - no there is no compliance to deal with as such; a while ago one of our clients requested that we removed all direct port 80 access into the internal network to prevent any possible exploits allowing direct connection to our systems.  This is common sense as far as I can see; I have always worked on the basis that a public facing site should ideally be isolated from the main network - unfortunately that wasn't the situation for various reasons.  For the same reason, we added a Front end to our Exchange 2003 server in the DMZ to prevent direct WWW external traffic onto an internal server.  (When I say direct access, I do mean through a hardware firewall with a translation rule in place to the internal IP address of the server).  Moving forward, We have established a DMZ on our network, and any public facing servers are being transferred into it (FTP, IIS etc).  For this reason, I was to use TMG for the Front end access for exchange 2010 instead of direct access to the server internally.

With regards to access; we are quite relaxed in what our internal staff have access to; their internet access is NATed directly through the hardware firewall to the internet, so the TMG will purely be used as a Web publishing front end - hence the single Nic setup.

To move on from this, I've actually implemented the server as a single NIC and managed to get it the OWA to publish through the TMG ok...but then run into the issue of not being able to use the same IP to register the second listener for the Outlook Anywhere/Activesync authentication; so the plan now is to have a separate IP for webmail and another for other services.  My plan is to direct all internal staff through DNS to the TMG for these services also to avoid the need for a second Virtual Site on the exchange server.
So - my next questions!  although people access the server using mail.domain.com for all services currently, the server itself has a different name server01.domain.com - but the internal and external URLs for the virtual folders all reference the mail.domain.com address (although autodiscover is configured to look directly at server01.domain.com). My question is will i now need to change these to so internal is server01.domain.com?  I plan to use the mail.domain.com address to push directly to the TMG internally and externally (I feel it will make things simpler not having to tell people to change the configuration of their phones/macs etc!) Is this approach likely to cause any issues, or would this be ok for what i am trying to achieve?
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

Jian An LimSolutions ArchitectCommented:
well, i won't see a big issues,
just that approach will generate unnecessary connection from client to TMG then back to CAs server.

i will make split DNS, i.e. we will have mail.domain.com consistent internal or external

the difference is the local dns should resolve locally, but when in external, then dns should point to the TMG.

this way, you will get simple design and not making your TMG the point of failure. (given if tmg failed, no one i.e. internal/external can access exchange?)
Amaze_ITAuthor Commented:
Thanks for the response - That is what I am thinking of doing; but doing it this way will require me to set up a secondary Virtual directory for internal clients will it not?

Essentially, what I was trying to do was make it so internal and external clients would access the TMG at, say webmail.domain.com - this would do the FBA and pass back to the CAS server.

I am also seeing massive problems with TMG being able to work at all - i can get to the FBA on webmail, and it is clearly authenticating the user, but then just hangs, and will not go any further.  If i connect directly to the CAS Server using the internal name, is works fine.  The TMG server is connected to an RODC in the DMZ, but would not have thought this would make any difference?
Jian An LimSolutions ArchitectCommented:
what is the service pack of TMG (and hotfix) you are currently on?

I will do a troubleshooting about the system. at the moment, it could be anytime from hardware to configuration (harder to troubleshoot as I can't see your configuration without logging in). go through the list below and see whether it assist or not.


Given you know clearly, it is a TMG issue, you either need to work through it or skip it
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now