Risk to Domain members in a Domain that's extended into the DMZ

Question

I am an AD administrator trying to look at things from an application server owner's perspective.

Imagine a scenario where an AD domain covers authentication in both the corporate LAN and the DMZ. The LAN has RWDC's the DMZ has RODC's, standard firewall sandwich.

The RODC's have been hardened; no accounts are cached, a filtered attribute set (FAS) has been applied, there's a delegated RODC admin account, a firewall is in place, have AV, the servers are patched.

For application servers in the DMZ I can only manage them as much as AD allows me to; I restrict the number of users with admin privileges to the servers, I ensure the firewall is in place, the servers are patched, have AV, maybe there's some account Kerberos restriction.

There are other defences in the DMZ; e.g. the network team have their network firewall, but I can't control that and I can't control what the application owners do outside what I have stated above.

How does the security of the servers in the DMZ look, would they be in good shape? If a server were compromised in the DMZ, what's the blast radius from that; is the domain at threat, are other servers in the DMZ and the LAN at threat?

What would be the most likely escalation path of compromise?

Glossary:

AD: active directory
DMZ: demilitarized zone; location for internet facing servers
LAN: (internal network; separated from DMZ by firewall
RWDC: read/write domain controller
RODC: read only domain controller

Answer 1

I would principaly worry about what is allowed by the firewall(s), and what are the privileges of the accounts used in the DMZ on the internal machines. The real question is IMHO what could happen if an attacker could break the security of an application running on a DMZ server:

• does the firewall allow connections from that server to the internal lan?
• does any internal server (or client machine holding shared resources) accept connections from one of the users used in the DMZ?

If above risks (DMZ -> internal zone) are already covered, you can then considere DMZ -> DMZ, meaning if one application in the DMZ is compromised, is this account able to do anything on other applications from same server, and what about the other servers.

I know those are just hints, but it is the best I can without more elements on your actual configuration, including the small details as noticed by paj28 in its comment.

Answer 2

I'm going to use the ISC2 for reference.

There are 10 General Domains that are the focus of security. Here's an overview of them for reference.

You discussed a lot and for this answer I am going to try and focus on (3) which seem to concern you the most:

• Access Control
• Cryptography
• Security Architecture and Design

Security Domains

Before I get into this, Security Domains are broad, and focus on a lot of different aspects of the identified domain. I am limiting my points, and they are generalized. People can broadly identify risk, but it's hard to know how limited that risk is without access into the environment.

Access Control

Based on you scenario, I would guess the RODC is used for Authentication and/or Authorization. If not, I don't know why you have one sitting out there. You appear to have a good understanding of securely setting up an DC, so I would say your larger risk here involves what rights you Application needs/has to perform it's duties. I would guess a locked down service account for this application should be sufficient. I would verify with the App Owner what they need for the application

Cryptography

Not specifically discussed, but I always suggest (or demanded depending on the scenario) that secure communication is used. LDAPS, TLS, etc should be common, and if you are externally accessing these systems, I always prefer Third Party Signed Certs over Internal CA certs.

Security Architecture and Design

This is likely you larger question. Is what you designed a good implementation? In short, what you described is fine, standard even (I've seem many similar setups.)

This topic is extremely broad, and you could ask many questions about it:

• What are your provisioning / de-provisioning practices for Admins?
• What users will access to the Application?
• Are other DC secured the same way?
• If I compromise a reconfigured DC in a different DMZ, can I get access to the RO in this one?

I could go on. (In general, this is why we work in scopes, cause asking these questions are endless).

So What is the likely escalation path?

From general experience, external compromise are usually:

• Application Development flaw (E.G SQL Injection)
• Application Server flaw (E.G Mis-configured .htaccess file)
• Exposed service on the firewall (E.G Telnet opened through the Firewall)

If you have a reasonable confidence in you other team to configure their systems, you should feel reasonably confident that you're DMZ is safe. The big question you may want to consider is: If my DMZ is compromized, what is my risk to the Internal network?

Your RODC likely needs to get back to the RWDC through a Firewall. What if a computer that's not your RODC connects to the RWDC? Might be a red flag.