IT admin may lock down the DMZ from an external perspective but fail to put that level of security on access to the DMZ from an internal perspective as you’ll have to access, manage and monitor these systems within the DMZ too, but in a slightly different manner than you would with systems on your internal LAN. In this post, we will discuss the Microsoft recommended DMZ Domain Controller best practices.
What is a DMZ Domain Controller?
In computer security, a DMZ, or demilitarized zone, is a physical or logical sub-network that contains and exposes an organization’s external-facing services to a larger and untrusted network, usually the Internet. The purpose of a DMZ is to add an additional layer of security to an organization’s LAN; an external network node has direct access only to systems in the DMZ and is isolated from any other part of the network. Ideally, there should never ever be a domain controller sitting in a DMZ to assist with authentication to these systems. Any information that’s considered sensitive, especially internal data shouldn’t be stored in the DMZ or have DMZ systems relying on it.
DMZ Domain Controller best practices
The Active Directory team at Microsoft has made available a documentation with best practices for running AD in a DMZ. The guide covers the following AD models for the perimeter network:
- No Active Directory (local accounts)
- Isolated forest model
- Extended corporate forest model
- Forest trust model
The guide contains direction for determining whether Active Directory Domain Services (AD DS) is appropriate for your perimeter network (also known as the DMZs or extranets), the various models for deploying AD DS in perimeter networks, and planning and deployment information for Read Only Domain Controllers (RODCs) in the perimeter network. Because RODCs provide new capabilities for perimeter networks, most of the content in this guide describes how to plan for and deploy this Windows Server 2008 feature. However, the other Active Directory models introduced in this guide are also viable solutions for your perimeter network.
That’s it!
In summary, access to the DMZ from an internal perspective should be locked down as tightly as possible. These are systems that can potentially be holding sensitive data or have access to other systems that have sensitive data. If a DMZ server is compromised and the internal LAN is wide open, attackers suddenly have a way into your network.
Read next: Verification of prerequisites for Domain Controller promotion failed
Should domain controller be in DMZ?
It is not recommended because you are exposing your domain controllers to a certain risk. Resource forest is an isolated AD DS forest model that is deployed in your perimeter network. All the domain controllers, members, and domain-joined clients reside in your DMZ.
Read: Active Directory Domain Controller for the domain could not be contacted
Can you deploy in DMZ?
You can deploy Web applications in a demilitarized zone (DMZ) to enable external authorized users outside your company firewall to access your Web applications. To secure a DMZ zone, you can:
- Limit internet facing port exposure on critical resources in the DMZ networks.
- Limit exposed ports to only required IP addresses and avoid placing wildcards in destination port or host entries.
- Regularly update any public IP ranges in active use.
