If you are the administrator in charge of your Active Directory domain and are thinking of securing your domain, this guide contains best practices you can use to help lower the risk of any potential unwanted attacks and lower your vulnerability to any unwanted threats.

Granting administrative rights

First, you should make sure that all users in your domain aren’t local administrators of their computers unless there is a specific business reason they need this type of access. Even domain admins shouldn’t log in to their desktop using their admin account. IT staff should have two accounts: one for logging in to their PC as a user with basic privileges and one for performing administrative tasks (for example, logging in to servers) as a domain admin. This practice lowers the risk of any potential attacks on your network; a virus that infects computers while admins are logged in with their domain admin account could cause a lot of harm within your network.

One way to achieve this is to set up a GPO for restricted groups to determine the users with administrator rights.

Logging in to servers

Another best practice is to limit who can log in to servers. Admins shouldn’t need to log in to servers to perform their admin tasks. Admins can perform most of their tasks using the remote administration tools, which they can install on their desktop or on a dedicated terminal server that all admins use to perform admin tasks.

If you want to limit who has remote access to your servers, you can apply this GPO and filter the login access to a specific security group.

Renaming the Admin account

You should rename your local administrator accounts on all your desktops and servers. This lowers the chance of an attacker trying to guess the password of your administrator accounts if he doesn’t know the username. You can achieve this by creating a GPO that renames your local admin user accounts. You should also disable the guest user account as this is never used.

Enforcing passwords

Follow this best practice for enforcing password policy for your users. Make sure to set up your default domain password policy correctly, with the following options:

  • Enforce password history
  • Maximum password age
  • Minimum password age
  • Minimum password length
  • Passwords must meet password complexity requirements
  • Store password using reversible encryption for all users

Password Policy in the Group Policy Management Editor

You should set the values according to what your business needs and how secure you want your environment. This guide will show you how to set those values.

Securing domain controllers

If you have physical servers for your domain controllers, it is a good idea to lock them away somewhere secure where no one can access them. If you have remote domain controllers in a remote office with no administrators, it is a good idea to configure these as read-only domain controllers (RODCs). Another good idea is to set up your domain controllers as core Windows servers without the GUI.

Remote domain controllers as RODC

Remote domain controllers as RODCs

Limit the number of users you have in your domain admin and enterprise admin groups. Limit the number of applications and services you have running on your domain controllers. You should have no other applications running on your DCs. You should have no other applications or services running on your DCs.

You can also limit which ports you have opened on your domain controllers. Only those ports that are needed for communication should be opened between a domain controller and your computers.

Configuring Windows Firewall

Configuring Windows Firewall

Following are the ports that Active Directory uses for specific Active Directory communication, including MS traffic, DNS, Kerberos authentication protocol, Lightweight Directory Access Protocol (LDAP), and LDAP ping activity:

Communication Type MS Traffic DNS Kerberos LDAP LDAP Ping NETLOGON
User network logon over a firewall TCP 445
UDP 445
TCP 53
UDP 53
TCP 88
UDP 88
UDP 389
Computer logon to a domain controller TCP 445
UDP 445
TCP 53
UDP 53
TCP 88
UDP 88
UDP 389
Verification of trust relationships between domain controllers TCP 445
UDP 445
TCP 53
UDP 53
TCP 88
UDP 88
TCP 389
TCP 686 (SSL)
UDP 389 UDP: 137, 138
TCP: 139
Creation of a trust relationship between domain controllers located in different domains TCP 445
UDP 445
TCP 53
UDP  53
TCP 88
UDP 88
TCP 389
TCP 686 (SSL)
UDP 389

Securing your Active Directory installations

Microsoft has a great guide you can follow to secure your Active Directory installation. The guide’s several chapters cover the following:

  • Planning in-depth Active Directory security
  • Establishing secure Active Directory boundaries
  • Deploying secure domain controllers
  • Strengthening domain and domain controller policy settings
  • Establishing secure administrative practices
  • Securing DNS

Follow Microsoft best practice for securing your active directory installation.

Setting up auditing in your domain

Auditing is a very useful tool to monitor what is happening in your domain and to keep a record of any changes. You should audit failed logons and successful and failed account management tasks, object access, and policy changes. Useful guides are Security Auditing Overview and Monitoring and Auditing.

Audit Policy in the Group Policy Management Editor

Audit Policy in the Group Policy Management Editor

6 Comments
  1. jjingles 8 years ago

    Hello, please take note about more “vectors” to exploit that need our attention:
    https://adsecurity.org/?p=1929

    Search too any relate to Pass-the-Hash (or mimikatz or WCE)

    Regards!

  2. Fans Security 8 years ago

    please,Make video steps

  3. Anon 8 years ago

    So, from a security perspective, unless I am misunderstanding, I would say do not enable ‘Store password using reversible encryption for all users’ Disabling that setting if enabled would be the best option if possible (some apps require this)

  4. EliadTech 8 years ago

    Hi Andrew.

    Great article.
    Just wanted to give you a heads up – your site (networkangel) might have been hacked (and serving some malware), and is now blacklisted on Quttera, Sucuri and Fortinet.

  5. Author

    HI Anon, yes good point. As you say it depends on your environment and what your applications require

    Eliad Tech, thanks for your message. Ive cleared any malware on the site 🙂

  6. Dennis 7 years ago

    You should have mentioned the use of Microsoft Security Compliance Manager to harden security on Domain Controllers through group policy.

Leave a reply

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2023

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account