Securing Active Directory domains on a potentially hostile network

Question

Active Directory is one of the best features of Windows Server, but it's also a big shiny target. If compromised it gives the attacker your Windows network.

In an environment with externally facing Windows servers (web servers in my case), what steps are necessary to protect Active Directory from attack? How do you reduce the damage potential if a domain member is compromised? Finally, is there any way to reduce the damage potential if a domain controller is compromised?

I'm looking for info that relates specifically to Active Directory (2003 and 2008). Universal best practices (read your logs, secure Administrator passwords, etc) should be a given.

Answer 1

• Don't log into any machine on your network with a Domain Admin or similarly privileged account, except for your DCs. That way a compromised system can't steal your credentials.

• Have a separate privileged account for managing your web facing machines.

• Have a tight network level firewall on your web facing machines if possible.

• Have your web facing machines in a DMZ if possible - which is basically just a subnet with limited connectivity to the rest of your internal network.

• If a Domain Controller is compromised ... strictly speaking your Domain is gone and needs to be rebuilt. More practically it depends on the type of compromise and is something you would have to assess on a case by case basis. I've inherited two domains that were strictly speaking "compromised", I rebuilt one and repaired the second. There are a lot of factors to consider.

Answer 2

A Microsoft best-practices document I read once suggested that your Internet-facing servers (web, e-mail, etc.) should either be stand-alone machines or be in a separate Active Directory forest from your corporate forest. This separate forest should exist entirely in a DMZ, while your corporate AD forest should exist entirely within your corporate firewall's strictest boundaries. Far fewer users need access to Internet-facing servers than to regular corporate computing resources, so setting up a system in this way should not impose significant extra administrative overhead in terms of user support. You just have to remember your separate usernames and passwords for each domain.

Answer 3

Here are the general methods I use. Hopefully I can add a lot to these:

• Domain Controllers are on their own network segment. All traffic to or from the Domain Controllers must pass through the network firewall.

• Domain Controllers run no externally accessible services.

• RPC port ranges are restricted on all domain controllers/members to a known group of ports:

  1. Administrative tools -> Component Services -> Component Services -> Computers
  2. My Computer -> Properties -> Default Protocols -> Connection-Oriented TCP/IP -> Properties
  3. Add
  4. Set port range (something like 6051-6071). The larger your network and the more you use RPC, the wider range you'll need. For a network of 25-30 Windows machines, I've found 20 ports to be more than enough.
  5. Set both Port range assignment and Default dynamic port allocation to "Internet Range"
  6. OK
  7. Reboot

• Allow the domain members only the following access to the Domain Controller (both in network firewall, the Domain Controller's host firewall, and the Domain Member's host firewall - use Group Policy to enforce this):

  • TCP/UDP port 53 (DNS)
  • TCP/UDP port 88 (Kerberos)
  • UDP port 123 (NTP)
  • TCP/UDP port 135 (RPC Endpoint Mapper)
  • TCP/UDP port 137 (NetBIOS)
  • UDP port 138 (NetBIOS)
  • TCP port 139 (NetBIOS)
  • TCP/UDP port 389 (LDAP)
  • TCP/UDP port 445 (SMB-over-IP)
  • TCP port 3268 (LDAP Global Catalog)
  • TCP/UDP port 6051-6071 (RPC - replace with whatever range you chose above)

• Set IPSec Policy so all Domain Controller to Domain Controller traffic is encrypted over the wire

• Use Group Policy to reinforce network firewall rules at the host's firewall. Specifically:

  • Restrict Remote Desktop to your admin workstations/network
  • Restrict SNMP to your admin and monitoring workstations/network
  • Restrict outbound syslog (I use event-to-syslog) to your logging server
  • Restrict outbound SMTP to your mail server
  • The standard "restrict all in/out to only what the server requires" tactic

• Configure all network services to run as Active Directory users (IIS apps run under users named "svc-servicename"). These users are assigned to a single group with nerfed privileges and removed from the Domain Users group.

• Rename the Administrator account to something else, add "Administrator" as a disabled guest account (trivial to overcome, but it can block some dumb scripts).

• Externally facing servers are in a separate domain than the HQ/Office machines. I have a one-way trust (DMZ trusts HQ) to simplify some logins, but am looking at phasing this out.

Answer 4

This is a somewhat contrary view. I work at a higher ed with a wireless LAN segment that students (and somewhere between one to three devices in their bags) can connect to. This is inside our internet border firewall, but is still firewalled to some extent from the juicy goodness of the greater network. However, there are some constraints.

In order to allow student printing from their laptops, we have to allow domain logins which in turn requires visiblity to the DC's. The same holds true for the network shares. What's more, student laptops are not domained, and we do not have any kind of controls for what is on them.

When I first got here I was surprised that a Windows network this open could survive at all. But it did. Yes, Slammer was a royal pain to root out. Yes, we did have the occasional hacked server (from the Internet side, not WLAN side). All in all, the amount of evil-ware we've seen on the WLAN is more interested in sending large amounts of email than it is in scanning everything local to the machine to worm its way around.

We do have an auth barrier between the WLAN and anything interesting, which helps.

Also, we're forever going to the WLAN login logs to see who was on what IP when the RIAA sends us an offender notice for a torrenter.

Answer 5

I'd recommend reading Best Practice Guide for Securing Active Directory Installations.

Things that I think are important on an untrusted network:

• IPSec for auth traffic
• Use two-factor authentication (smartcard or challenge-response is cheap)
• Disable NTLM

The first two suggestions require that you setup a PKI service. Implementing PKI can be a real pain in the neck, but it can give you alot of really interesting capability and allows you to effectively and securely operate in an untrusted environment.

Answer 6

A general rule is that the only thing that goes on a DC is Active Directory itself. It's not always achievable, of course, but it's all about reducing the number of services that are potentially exposed.