Hi James,
I'm not entirely certain I understand correctly what you would be
deploying on the DMZ. Will you be placing the actual domain controller(s)
in the DMZ, or are you planning on having DMZ servers authenticate against
the internal Active Directory infrastructure ?
- Allowing DMZ hosts to authenticate to internal domain controllers does
entail a number of additional risks. If such a DMZ host (e.g. a web
server) is compromised, the remote attacker will be able to launch queries
and authentication attempts towards the internal host, thereby probing for
sensitive information. It may also be possible for the attacker to
capture authentication strings right off the network, and transport them
outside of your network borders.
The cleanest solution to implement this would be to add a 3rd party
application on the internal network (or preferably, on a separate
authentication/authorization screened subnet of the firewall) which can
authenticate directly to the domain controller. Authentication between
your web server on the public DMZ and the internal authentication host can
then take place using e.g. radius, or some proprietary form of
authentication. Traffic towards this screened subnet can be limited to
purely this authentication traffic. This would prevent the risk of an
attacker performing a one-step compromise towards the internal network.
- Deploying the actual domain controllers on the DMZ poses additional
problems. I would heavily recommend against hosting the AD domain for
your internal network on the DMZ. It is much too accessible there, and
compromise of a public service could directly lead to compromise of
internal accounts.
There are two ways to resolve this issue, and they depend on what you wish
to achieve with your directory structure:
- Active Directory is required in the DMZ for system administration
purposes, e.g. patch management tools:
In this case, it would be wise to publish two separate domains, one which
is run solely on the DMZ, another which is run on the internal network.
This would require double effort on behalf of those engineers managing the
domain, but would still be easier than managing each host individually.
- Active Directory is required in order to share certain user accounts
within internal and DMZ child domains. In this case, you will need to
foresee replication between AD on both networks. In an absolute minimum
configuration, this would require LDAP (389) and RPC (445) ports to be
open between the DCs on both networks. Due to the closed nature of
Windows RPC, these protocols are difficult to monitor, and IDS would be of
limited value to counter this risk. I would advise against this setup.
Another alternative would be to use a tool such as ADAM (Active Directory
Application Mode). The security risk mentioned above would not be
mitigated by this, but you should be able to configure this tool as a
replacement for a full fledged AD server on the DMZ. You can reduce risk
by using it in combination with IIFP, which is Microsoft's Identity
Integration Feature pack. This allows you to replicate these accounts
using LDAP only, allowing you to avoid allowing the inherently difficult
RPC connection between ADAM and your domain controller. LDAP is a heavily
documented protocol (RFC 3377), and it shouldn't be too difficult to
perform application level monitoring of such connections. It might even
be possible to find some application level proxy which can do some
scrubbing of LDAP traffic.
I sincerely hope this provides some additional insight to your problem.
Should you have any other questions, feel free to contact me off-list.
Cheers,
Maarten
--
Maarten Van Horenbeeck, GCIA <maarten@daemon.be>
http://www.daemon.be/maarten
