0% found this document useful (0 votes)
114 views2 pages

Domain and DMZ Critical Consideration

The document discusses placing domains and domain controllers in a DMZ. It recommends against directly extending an internal domain into the DMZ, as domain controllers contain highly valuable access control information and placing them in the DMZ would compromise security. It is better to use standalone DMZ servers with LDAP authentication back to internal domain controllers, or create a separate Active Directory forest in the DMZ with a one-way trust to the internal forest. While extending management with a separate forest increases complexity, compromising security by placing domains in the DMZ would undermine the purpose of having a DMZ.

Uploaded by

onyx
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
114 views2 pages

Domain and DMZ Critical Consideration

The document discusses placing domains and domain controllers in a DMZ. It recommends against directly extending an internal domain into the DMZ, as domain controllers contain highly valuable access control information and placing them in the DMZ would compromise security. It is better to use standalone DMZ servers with LDAP authentication back to internal domain controllers, or create a separate Active Directory forest in the DMZ with a one-way trust to the internal forest. While extending management with a separate forest increases complexity, compromising security by placing domains in the DMZ would undermine the purpose of having a DMZ.

Uploaded by

onyx
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

Domain and DMZ – critical consideration

capgemini.com/2011/07/domain-and-dmz-critical-consideration/

July 16, 2011

A DMZ separates an external network from directly


referencing an internal network. It does this by isolating the
machine that is being directly accessed from all other
machines. Most of the time the external network is the
Internet and what is in the DMZ is the web server but this is
not the only possible configuration. A DMZ can be used to
isolate a particular machine within a network from other
machines. This might be done for a branch office that needs
its own Internet access but also needs access to the corporate
network. In DMZ terminology, an internal connection is
generally thought of as having more secret or valuable
information than an external network. An easy way to understand which is the external and
internal network is to ask yourself which network am I protecting from the other. Using DMZ
we are protecting our internal domain from outside world that contains valuable
information.

It is not a good proposal to place domain controllers or extend internal domain within the
DMZ.

The primary advantage of a DMZ is that it provides a neutral ground, typically for services
that must be accessed (example, Web service) by both internal and external users.

Domain controllers, by their nature, are some of the most highly valued assets within the
organization. These are the servers that control access to the resources on a Windows
network, including the Active Directory database. If an attacker is able to compromise a
domain controller / domain, he or she essentially owns the entire Windows infrastructure.
Therefore, given the immense importance of keeping it protected, placing a domain
controller in DMZ is not a preferable solution.

The most common solution we experience is placing DMZ servers as standalone. If Active
Directory authentication is required to allow internal users privileged access to those servers,
use LDAP authentication back to the domain controller on the internal network. If you do
need a domain controller inside the DMZ to facilitate specific services, we can prefer creating
a separate Active Directory forest within the DMZ and then using a one-way trust mechanism
that permits systems in the DMZ to trust user accounts within the internal forest.

1/2
Now the argument is that by having a separate forest in domain we are increasing
management complexity. Nevertheless, for simplified management can we compromise a
significant security risk? I think we should be very careful regarding domain in DMZ as
otherwise the use of DMZ might be completely ineffective!

With windows 2008 R2 directory there is a possibility of extending domain in DMZ by


placing RODC. However this solution also has several ifs and buts and may not server
purpose of domain joining.

2/2

You might also like