3

Windows servers in the DMZ need to communicate with the Active Directory. I do not like that the servers will have direct communication with my Active Directory, so I consider installing a Read-Only Domain Controller that replicate the real one.

It seems like there are security benefits with RODC only when it is not physical secure - no passwords are cached, if someone steals it, they still cannot modify the real AD or find the credentials to do so.

http://technet.microsoft.com/en-us/library/cc732801(v=ws.10).aspx:

Inadequate physical security is the most common reason to consider deploying
an RODC. An RODC provides a way to deploy a domain controller more securely in 
locations that require fast and reliable authentication services but cannot
ensure physical security for a writable domain controller.

Are there any real benefit with implementing a RODC when it comes to network security?

Dog eat cat world
  • 5,759
  • 1
  • 27
  • 46

2 Answers2

4

RODCs really are all about physcial security, and not at all about network security. They're an upgrade of ye olde Backup Domain Controllers, that had a nasty tendency to get stolen (and the database along with it).

RODCs come with a unique kbtgt account, so they can't intrude on Active Directory, or decipher kerberos tickets on behalf of WDCs, in case of a physical breach, and by default RODCs don't allow password caching, again in case of a physical breach.

By restricting cached credentials, to only user and computer accounts belonging to a branch office, you limit the fallout in case of a breach, and you allow the branch office to continue functioning in case of a link down.

I know Microsoft technically officially supports putting RODCs in the DMZ, but from experience I can say that this is really more trouble than it's worth. You'll have to audit every single one of your AD integrated applications to ensure that it supports working with a RODC. Why? Because there are still many scenarios that RODCs simply do not support. Certain RPC calls can and will simply fail without reason. These scenarios are described in the Microsoft document Planning and Deploying Read-Only Domain Controllers, subsection Read-Only Active Directory Database, SYSVOL, and Unidirectional Replication:

When a user or application in a site that is serviced by an RODC attempts to perform a write operation, one of the following actions can occur:

  • The RODC forwards the write request to a writable domain controller and then replicates the change back from the writable domain controller. For most write operations, the change is replicated back to the RODC during the next scheduled replication interval. In some other cases, the RODC attempts to replicate the change immediately. An RODC forwards a very limited set of writes, including the following:
    • Most types of password changes. For more information about password changes, see Password changes on an RODC.
    • Service principal name (SPN) updates. When a domain-joined computer has a secure channel to an RODC and Netlogon attempts to update SPNs, the forwarding is done over RPC.
    • Some updates to client attributes over Netlogon: client name, DnsHostName, OsVersionInfo, OsName, Supported Encryption Types
    • LastLogonTimeStamp. When a domain-joined computer has a secure channel to an RODC and Netlogon attempts to update these attributes, the forwarding is done over LDAP.
  • The RODC sends a referral for a writable domain controller to the client. The application from which the write operation originated can then chase the referral and target a writable domain controller to perform the write operation. By default, RODCs send referrals for Lightweight Directory Access Protocol (LDAP) updates and Domain Name System (DNS) record updates.
  • The write operation fails: it is neither referred nor forwarded to a writable domain controller. In this case, the application requesting the write should be updated to specifically target a writable domain controller. A number of RPC writes fall under this category.
Community
  • 1
mtnielsen
  • 56
  • 1
3

I believe that there are security benefits to deploying an RODC in a DMZ, namely because you can control what AD information is replicated. You can therefore selectively choose what information must be replicated (account attributes / passwords / etc) all while avoiding exposing a writable DC.

Microsoft released an article about putting domain controllers in the DMZ which proves an interesting read. Many believe that many internet-facing proprietary MS products can be exposed the internet with minimal risk (such as Exchange) which is why they discontinued TMG, however you'll need to address the requirements for a DC in the DMZ in your own environment.

The MS Document is here, and certainly worth a read to ensure you're covering all your bases.

DKNUCKLES
  • 9,237
  • 2
  • 37
  • 47
  • I have already read the document. Even though I can reduce the amount of data available in the RODC, the RODC and DC will likely have the same vulnerabilities (same services + OS). If the RODC is compromised, what will stop the real DC from being compromised as well? – Dog eat cat world Jun 30 '14 at 14:11
  • Yes but the document states that you should install a core installation and ensure that you minimize your attack surface (which may not be possible with a full DC). If your application is the only thing performing lookups on your RODC, the RODC is not accessible directly from the internet and you have appropriate firewall rules in place for communication between your RODC and applications then I would say your attack vector is smaller than a writeable DC, no? – DKNUCKLES Jun 30 '14 at 14:20