Securing Active Directory domains on a potentially hostile network

Solution 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.

Solution 2:

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.

Solution 3:

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.