Managing Internet facing resources

  • Last Post 29 June 2016
idarryl posted this 21 June 2016

Hi folks,
I'm interested to hear how people manage their Internet facing resources with AD; that it's to say, servers that have permanent ports open to accept sessions from the Internet. 
I have servers with customer facing applications that have proprietary user databases. I need a solution to manage the servers, there wouldn't be any user management required. I need the simplest solution that doesn't substantially increase the risk to the corporate forest.
I've had a few thoughts of my only, haven't performed any risk analysis on them, but wanted to put them out to gather opinions:

  • Second DMZ Forest (possibility with a one trust from the corporate forest), with RWDCs in the LAN, and RODCs in the DMZ
  • Utilise Web Application Proxy servers in a domainless DMZ, host the application servers in the current corporate domain on the LAN
  • Expose the corporate domain to the DMZ, using RODC's, join those internet facing systems to the corporate domain
thanks in advance~

Order By: Standard | Newest | Votes
DhirajHaritwal posted this 21 June 2016

  • Expose the corporate domain to the DMZ, using RODC's, join those internet facing systems to the corporate domain

Why do you want to join internet facing systems to corporate domain?  What’s the requirement? Why you want to expose corporate domain to DMZ?









kurtbuff posted this 22 June 2016

If I had my druthers, I'd stick the databases in the DMZ (and the
customer-facing web sites), and manage them in their own forest.

If the DMZ databases need data from the production network, or vice
versa, the production servers should initiate contact - never allow
the DMZ to initiate contact to production.

Manage the DMZ forest via RDP connection to a protected jump box in the DMZ.



ken posted this 22 June 2016

The approach probably depends on how much resource you can throw at the problem, which in turn probably depends on how big an environment

 you have.


We’ve taken various approaches over time – whether that be separate AD forest for DMZ, through to not having any general compute in

the DMZ full stop (everything is proxied through WAFs or other hygiene appliances/proxies). Probably needs to be coupled with your overall infrastructure strategy – e.g. do you still share other resources with the DMZ (SAN for example). How will you manage/monitor

these DMZ machines?






idarryl posted this 27 June 2016

Thanks for your replies.  I must say information from Microsoft is limited on this subject, even the guide ( doesn't explain the risks to each of these models, and that's what I'm struggling with. My head knows the Isolated model is the easiest win; security boundary - done. But you have to believe me when I say that I'm still finding Forests in our company, the last thing I want to do is put in another one unnecessarily. 
I can't get over the fact that extending the forest into the DMZ is a valid option (according to M$), and has less admin overhead, so I'm trying to find a bloody good reason not to do it. I understand the risks to the Domain Controllers in the DMZ, and how to mitigate them, what I'm still struggling with is the risk to the other members of the Forest (whether it be extending or Isolated), if one member were to be compromised. How can I, as the AD guy, mitigate the risks to other domain members?
Also, if I have one server that must be in the domain and in the DMZ with an RODC, is it enough to say, well I've got the the infrastructure there now, I may as well use it for others, as I'm increase risk?
@Ken; how machines are monitored is down to the Data Centre teams, they are happy to work with what I get them, as for shared components, it's a good, but hard question to answer.


ken posted this 28 June 2016

@Ken; how machines are monitored is down to the Data Centre teams, they are happy to work with what I get them, as for shared components, it's a good, but hard question to answer.


The way I see it: your security policy would tell you what’s acceptable/not acceptable. Operational concerns would then give you what’s

feasible to implement, and Active Directory is just one thing that supports operational model…


For example, if your security policy says strict separation of resources from DMZ and Internal domains, then:


Physically everything needs to be separate (storage, network, hosting)


Logically everything needs to be separate (tools etc. see below)

Ergo, that would drive the decision to have a separate Active Directory. Creating a single operational view of the organisation (e.g.

monitoring and event management, SIEM) has to work with these policies and constraints – e.g. through connected/federated tools.


If your security policy says that this separation is not enforced, then at some level, the risk of contamination is acceptable/within

appetite. You mitigate risk by patching, locking down ingress points via your firewalls, monitoring for malicious traffic, separate service accounts, separation of duties etc., that make it hard for someone on a compromised host to get to another one and compromise

it (at least, without being detected).


The reason I asked about “monitoring/management” was around what are your current toolsets for monitoring/patching/backup/endpoint

protection/batch scheduling/log management/service bus/etc/etc/etc. Will they work in an isolated Forest scenario? Or will you be needing to stand-up new instances? I guess financial reality/pragmatism + managing operational complexity also tends to play a

big part in what option gets chosen. AD provides just one way for someone to get from one host to another – as soon as you start sharing infrastructure or tooling instances you provide other ways of getting from one host to another.





idarryl posted this 29 June 2016

Thank you for your advice, your points are very valid.  I completely agree with you and now understand I need to take a step back and involve other stack-holders in the organisation, and look towards the security policies for directions, before looking at a technical solution.