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.

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

  • Good call on 1 and 2 (don't login with Domain Admin, use separate account for web server management). I'm guilty of using a Domain Admin account for most of my work. Can you give some details on how you do those and still maintain proper accounting? Do you have separate web-management logins for each member of your team, along with separate Domain Admin logins, separate "green-network" non Domain Admin logins, etc? – sh-beta Jun 9 '09 at 2:21

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.


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.


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.


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.

  • Surprisingly concrete guide from MS. Thanks for the link. – sh-beta Jun 11 '09 at 13:59

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.


You will need to understand pass-the-hash (PtH) and pass-the-ticket (PtT) attacks, as these are the primary means by which attackers spread throughout a Windows network. Microsoft has PtH guidance, but it may be a bit complicated if you're not already familiar with security issues: https://www.microsoft.com/en-us/download/details.aspx?id=36036

The best way is to use Microsoft's red forest design. The red forest is a separate forest with a one-way trust that houses your domain admin accounts. It requires extra effort and servers, but you can get 95% of the benefits without it if you are careful.

Any account with privileges in AD (domain admins, help desk, etc) should never log into any regular member server or workstation. I.e., you should set the Deny Logon rights to include Domain Admins and other privileged groups on regular member machines.

In general, all admin activity should occur on systems that have no access to the internet and restricted IP connectivity to machines that do.

Obviously, you can only restrict Domain Admins in that fashion if you have separate accounts for server and workstation administration. You should also have separate unprivileged accounts for web/email. This separation of roles is one of the key aspects of securing a network.

A domain admin should NEVER log into a DMZ system or an internet-connected machine. You shouldn't even RDP from one. You should have dedicated workstations for these accounts, and your regular workstation accounts should not be able to log into the AD admin workstations. There should be zero accounts which can log into both regular workstations and AD admin workstations. This prevents those highly privileged credentials from being stolen when an attacker gains admin/system privileges on one workstation and subsequently spreads to others (usually by stealing credentials when a workstation admin logs in).

In a similar fashion, there should be dedicated accounts for DMZ machines, and no accounts should have access to both DMZ and internal assets. It is also possible to setup a separate DMZ domain (with or without a trust to the internal domain).

Recovering AD after a compromise is possible, but it must be done absolutely correctly---and obviously, there will be some down time while the domain is being restored and sanitized. Our estimated recovery from a compromised DC was several days before implementing a red forest; it is under 12 hours with a red forest.

Note that each security measure is one piece of the total solution, and you need all of the rest. These suggestions are specific to securing AD. You still need to segment your network and have proper firewall/ACL restrictions. You still need to secure your user accounts properly with either Smart Cards (strongly recommended) or good password policies. You still need intrusion detection, antivirus, a good external firewall, and a web proxy.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.