Top 25 Active Directory Security Best Practices

This is the most comprehensive list of Active Directory Security Best Practices online.

In this guide, I’ll share my recommendations for Active Directory Security and how you can improve the security of your Windows domain environment.

You don’t have to spend a fortune to improve security there are many no cost and low cost solutions that I’ll show you in this guide.

Let’s dive right in.

Table of contents:

  1. Limit the use of Domain Admins and other Privilaged Groups
  2. Use at least two accounts
  3. Secure the domain administrator account
  4. Disable the local administrator account (on all computers)
  5. Use Laps
  6. Use a secure admin workstation (SAW)
  7. Enable audit policy settings with group policy
  8. Monitor for signs of compromise
  9. Password complexity sucks (use passphrases)
  10. Use descriptive security group names
  11. Find and remove unused user and computer accounts
  12. Remove Users from the Local Administrator Group
  13. Do not install additional software or server roles on DCs
  14. Patch management and vulnerability scanning
  15. Use secure DNS services to block malicious domains
  16. Run supported operating systems
  17. Use two factor for office 365 and remote access
  18. Monitor DHCP logs for connected devices
  19. Monitor DNS logs for malicious network activity
  20. Use latest ADFS and azure security features
  21. Use office 365 secure score
  22. Have a recovery plan
  23. Document delegation to Active Directory
  24. Lock down service accounts
  25. Use security baselines and benchmarks
  26. Bonus #1 Enable windows firewall on all systems
  27. Bonus #2 Use application whitelisting
  28. Bonus #3 Block powershell for regular users

Active Directory Security Concerns

In many organizations, Active Directory is the centralized system that authenticates and authorizes access to the network. Even in the cloud or hybrid environments, it can still be the centralized system that grants access to resources. When accessing a document on the network, OneDrive, printing to the network printer, accessing the internet, checking your email, and so on, all of these resources often go through Active Directory to grant you access.

Active Directory has been around a long time and over the years malicious actors have discovered vulnerabilities in the system and ways to exploit them. In addition to vulnerabilities its become very easy for hackers to just steal or obtain user credentials which then gives them access to your data. If they can get access to your computer or your login then they could potentially gain Full access to Active Directory and own your network.

1. Limit the use of Domain Admins and other Privilaged Groups

Members of Domain Admins and other privileged groups are very powerful. They can have access to the entire domain, all systems, all data, computers, laptops, and so on.

It is recommended to have no day to day user accounts in the Domain Admins group, the only exception is the default Domain Administrator account.

Domain Admins are what the bad guys try to seek out.

Microsoft recommends that when DA access is needed, you temporarily place the account in the DA group. When the work is done you should remove the account from the DA group.

This process is also recommended for the Enterprise Admins, Backup Admins, and Schema Admin groups.

What’s the big deal?

It’s become way too easy for attackers to obtain or crack user credentials.

Once attackers gain access to one system they can move laterally within a network to seek out higher permissions (domain admins).

One method of doing this is called pass the hash.

Pass the hash allows an attacker to use the password hash to authenticate to remote systems instead of the regular password. These hashes can be obtained from end user computers.

Scary right?

All it takes is for one compromised computer or a user account for an attacker to compromise a network.

Cleaning up the Domain Admins group is a great first step to increasing your network security.  This can defiantly slow down an attacker.

The process to remove accounts from the DA group is not easy. I know first hand as I’ve recently gone through this process. It’s very common to have way too many accounts in the DA group.

Things will break so be prepared.

Summary

  • Inventory privilaged groups
  • No day to day account should be in a privilaged group
  • Discuss and review access with your team
  • Slowly start removing privilaged accesss
  • It can be a painful process but is a huge first step in reducing your attack surface

2. Use at least two accounts (regular and Administrator account)

You should not be logging in every day with an account that is a local admin or has privileged access (Domain Admin).

Instead create two accounts, a regular account with no admin rights and a privileged account that is used only for administrative tasks.

BUT

Do not put your secondary account in the Domain Admins group, at least permanently.

Instead, follow the least privileged administrative model. Basically, this means all users should log on with an account that has the minimum permissions to complete their work.

You may read in other articles and forums to put your secondary account in the Domain Admins group.

This is not a Microsoft best practice and I would advise against it. Again temporary is OK but it needs to be removed as soon as the work is done.

With that said Microsoft does not make it easy to get away from Domain admin rights. There is no easy process to delegate rights to all systems like DNS, DHCP, group policy and so on. This is often the reason so many people have Domain Admin rights.

You should use a regular non admin account for day to day tasks such as checking email, browsing the internet, ticket system, and so on. You would only use the privileged account when you need to perform admin tasks such as creating a user in Active Directory, logging into a server, adding a DNS record, etc.

Look at these two scenarios.

Scenario 1 – IT Staff with Domain Rights

Steve logs into his computer with a privileged account, checks his email, and inadvertently downloads a virus. Since Steve is a member of the DA group the virus has full rights to his computer, all servers, all files, and the entire domain. This could cause serious damage and result in critical systems going down.

Now, take the same scenario but this time Steve is logged in with his regular non admin account.

Scenario 2 – IT Staff with Regular Rights

Steve checks his email and inadvertently downloads a virus. The virus has limited access to the computer and no access to the domain or other servers. This would cause minimal damage and prevent the virus from spreading through the network.

By simply using a regular account you can increase security and avoid causing serious damage.

Here are some common tasks that can be delegated to a secondary admin account.

  • Rights to Active Directory Users and Computers
  • DNS
  • DHCP
  • Local admin rights on servers
  • Group Policy
  • Exchange
  • Local admin rights on workstations
  • Vsphere or Hyper-v Administration

Some organizations use more than two accounts and use a tiered approach. This is defiantly more secure but may be an inconvenience to some.

  • Regular account
  • Account for Server Administration
  • Account for Network Administration
  • Account for Workstation Administration

Summary

  • Use at least two accounts
  • 1 account has no administrator rights and is used for daily work like checking email, browsing the internet and so on. This account should also not have admin rights on the local computer.
  • The 2nd account is used for administartive tasks such as creating AD accounts, folder permissions managing VMs, backups, etc.
  • The 2nd account (admin account) should not have VPN access, email and if possible no internet.

3. Secure the Domain Administrator account

Every domain includes an Administrator account, this account by default is a member of the Domain Admins group.

The built in Administrator account should only be used for the domain setup and disaster recovery (restoring Active Directory).

Anyone requiring administrative level access to servers or Active Directory should use their own individual account.

No one should know the Domain Administrator account password. Set a really long 20+ characters password and lock it in a vault. Again the only time this is needed is for recovery purposes.

In addition, Microsoft has several recommendations for securing the built in Administrator Account.  These settings can be applied to group policy and applied to all computers.

  • Enable the Account is sensitive and cannot be delegated.
  • Enable the smart card is required for interactive logon
  • Deny access to this computer from the network
  • Deny logon as batch job
  • Deny log on as a service
  • Deny log on through RDP

For more details on securing the Domain Administrator account see this Microsoft article, Securing Built in Administrator Accounts in Active Directory

4. Disable the local Administrator account (on all computers)

The local administrator account is a well known account in Domain environments and is not needed.

Not needed, is that true?

Yes

You should be using an individual account that has the necessary rights to complete tasks.

What is the problem with the local admin account?

Two Problems.

  1. It is a well known account, even if you re-name it the SID is the same and is well known by attackers.
  2. It’s often configured with the same password on every computer in the domain.

Attackers just need to compromise one system and now they have local admin rights on every domain joined computer. They could then use this account to pivot to another system with the goal of finding domain admin access.

If you need to perform admin tasks on the computer (install software, delete files, etc)  you should be doing so with your individual account, not the local admin account.

Even if the account is disabled you can boot into safe mode and use the local administrator account.

As an administrator, I know these best practices are not always practical or introduce a huge inconvenience.

What if the network is down or the NIC card died, what if you need to drop it from the domain and re-add it? There are ways around this but it can really slow you down.

If you cannot disable the account here are recommendations for securing the account. A better alternative is to use the Microsoft LAPS tool (Covered below in tip #5)

  • Deny access to this computer from the network
  • Deny log on as a batch job
  • Deny log on as a service
  • Deny log on through RDP

For more details see the following article, Securing local administrator accounts and groups

Summary

  • If you can it is best to disable the local administrator account on end user devices. This can be challenging to do but it is best to authenticate with a seperate account to end user devices.
  • If this is not an option then check out tip #5 on using LAPS.

5. Use local Administrator Password Solution (LDAPS)

Local Administrator Password Solution (LAPS) is becoming a popular tool to handle the local admin password on all computers.

LAPS is a Microsoft tool that provides management of local account passwords of domain joined computers. It will set a unique password for every local administrator account and store it in Active Directory for easy access.

This is one of the best free options for mitigation against pass the hash attacks and lateral movement from computer to computer.

It’s very common that organizations deploy Windows using an image based system. This makes it quick to deploy a standard configuration to all devices.

But..

This often means the local administrator account will be the same on every computer. Since the local Administrator account has full rights to everything on the computer, all it takes is for one of them to get compromised, then the hacker can access all the systems.

LAPS is built upon the Active Directory infrastructure so there is no need to install additional servers.

The solution uses the group policy client side extension to perform all the management tasks on the workstations. It is supported on Active Directory 2003 SP1 and above and client Vista Service Pack 2 and above.

If you need to use the local admin account on a computer you would retrieve the password from Active Directory and it would be unique to that single computer.

For step by step instructions on installing LAPS see this article, How to Install Local Administrator Password Solution (LAPS)

Summary

  • The local administrator account is a well known account that attackers use to gain access to your computers.
  • Companies often use computers that have been imaged so the admin password ends up being the same on all computers.
  • LAPS can help resolve this issue by setting a random password for the local administrator account on every computer.

6. Use a Secure Admin Workstation (SAW)

A secure admin workstation is a dedicated system that should only be used to perform administrative tasks with your privileged account.

It should not be used for checking email or browsing the internet. In fact… it should not even have internet access.

What tasks would you do on a SAW? 

  • Active Directory administration
  • Group Policy
  • Managing DNS & DHCP Servers
  • Any task that requires admin rights on servers
  • Admin rights to Management Systems such as VMware, Hyper-v, Citrix
  • Office 365 Administration

You get the idea.

Basically, when you need to use your privileged account to perform admin tasks you should be doing it from a SAW. Daily use workstations are more vulnerable to compromise from pass the hash, phishing attacks, fake websites, keyloggers, and more.

Using a secure workstation for your elevated account provides much greater protection from those attack vectors. Since attacks can come from internal and external it’s best to adopt an assumed breach of security posture.

Due to the continuous threats and changes to technology the methodology on how to deploy a SAW keeps changing. There are also PAW and jump servers to make it even more confusing.

Here are some tips to help get you started:

  • Use a clean OS install (use latest Windows OS)
  • Apply hardening security baseline (See tip#25)
  • Enable full disk encryption
  • Restrict USB ports
  • Use personal firewall
  • Block internet
  • Use a VM – Terminal Server works well
  • Minimal software installed
  • Use two factor or smart card for access
  • Restrict systems to only accept connections from the SAW

Here is my typical workflow using a SAW:

  1. Log into my computer with my regular account to check email and view new support requests.
  2. If I have some administrative task I will log into my SAW with my privileged account that has rights to modify AD group membership and add the user to the necessary AD security group.

Pretty straightforward right?

It may seem like a hassle but I actually find it more convenient this way. I can remote in when off network and have a server that has all the tools I need. I also don’t have to worry about re-install all of my support software if I need to re-image my computer.

Resources:

https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/privileged-access-workstations

Summary

  • Use a secure workstation (SAW, PAW, Jump Server) for doing administrative tasks
  • Use your local computer for things that don’t require escaled permissions
  • The SAW machine should be locked down with limited access, implement MFA to the SAW if you can.
  • If you have a security breach an SAW can help limit unathoized access to your systems and data.

7. Enable audit policy settings with group policy

Ensure the following Audit Policy settings are configured in group policy and applied to all computers and servers.

Computer Configuration -> Policies -Windows Settings -> Security Settings -> Advanced Audit Policy Configuration

Account Logon

Ensure ‘Audit Credential Validation’ is set to ‘Success and Failure’

Account Management

Audit ‘Application Group Management’ is set to ‘Success and Failure’
Audit ‘Computer Account Management’ is set to ‘Success and Failure’
Audit ‘Other Account Management Events’ is set to ‘Success and Failure’
Audit ‘Security Group Management’ is set to ‘Success and Failure’
Audit ‘User Account Management’ is set to ‘Success and Failure’

Detailed Tracking

Audit ‘PNP Activity’ is set to ‘Success’
Audit ‘Process Creation’ is set to ‘Success’

Logon/Logoff

Audit ‘Account Lockout’ is set to ‘Success and Failure’
Audit ‘Group Membership’ is set to ‘Success’
Audit ‘Logoff’ is set to ‘Success’
Audit ‘Logon’ is set to ‘Success and Failure’
Audit ‘Other Logon/Logoff Events’ is set to ‘Success and Failure’
Audit ‘Special Logon’ is set to ‘Success’

Object Access

Audit ‘Removable Storage’ is set to ‘Success and Failure’

Policy Change

Audit ‘Audit Policy Change’ is set to ‘Success and Failure’
Audit ‘Authentication Policy Change’ is set to ‘Success’
Audit ‘Authorization Policy Change’ is set to ‘Success’

Privilege Use

Audit ‘Sensitive Privilege Use’ is set to ‘Success and Failure’

System

Audit ‘IPsec Driver’ is set to ‘Success and Failure’
Audit’ Other System Events’ is set to ‘Success and Failure’
Audit ‘Security State Change’ is set to ‘Success’
Audit ‘Security System Extension’ is set to ‘Success and Failure’
Audit ‘System Integrity is set to ‘Success and Failure’

Malicious activity often starts on workstations, if you’re not monitoring all systems you could be missing early signs of an attack.

In the next section, I’ll cover what events you should be monitoring.

Summary

  • If you do not have the proper auditing and logging settings configured you can’t monitor for malicious activity or investigate a security breach.

8. Monitor Active Directory for signs of compromise

You should be monitoring the following Active Directory events to help detect compromise and abnormal behavior on the network.

Here are some events you should be monitoring and reviewing on a weekly basis.

  • Changes to privileged groups such as Domain Admins, Enterprise Admins and Schema Admins
  • A spike in bad password attempts
  • A spike in locked out accounts
  • Account lockouts
  • Disabled or removal of antivirus software
  • All actives performed by privileged accounts
  • Logon/Logoff events
  • Use of local administrator accounts

How do you monitor events in Active Directory?

The best way is to collect all the logs on a centralized server then use log analyzing software to generate reports.

Some log analyzers come pre built with Active Directory security reports and others you will need to build them yourself.

Here are some of the most popular log analyzers.

With a good log analyzer, you will be able to quickly spot suspicious activity in your Active Directory environment.

Here are some screenshots from an analyzer that I use. The first screenshot shows a spike in account lockouts.

That is definitely not normal.

In this screenshot, you can see a huge spike in logon failures. Without a log analyzer, these events would be hard to spot.

Summary

  • You should have a log analyzer installed to monitor and alert for malicious activity on the network.
  • The benefit is you can see malicious attempts and cut attackers off before they breach your systems
  • A log analyzer also helps for analyzing events after a breach but is more important to spot abnormal activity early on.

9. Password complexity sucks (use passphrases)

8 characters with complexity is no longer a secure password. Instead, use a minimum of 12 characters and train users on passphrases.

The longer the password the better.

Passphrases are simply two or more random words put together. You can add numbers and characters if you want but I wouldn’t make it a requirement.

Studies have shown when you require complexity it is used in a similar pattern and then repeated.  Hackers have caught onto this and there are now huge passwords lists (freely available) that contain millions of easy to guess passwords.

Know anyone that uses passwords like this?

S@mmer2018, or Winter2018! June2018$

These are awful passwords and are easily guessed.

Long passwords and using the passphrase technique make it more difficult for password cracking software and for hackers to guess.

Better Password Policy

  • Set 12 character passwords
  • Remember 10 password history
  • use passphrases
  • Lockout policy 5 attempts

The key to using passphrases is to be totally random with each word, you don’t want to type out a sentence where the next word can be guessed.

Good passwords using passphrases

Bucketguitartire22
Screenjugglered
RoadbluesaltCloud

The above examples are totally random. These would take a very long time to crack and most likely no one would guess them.

Bad passphrase examples

Ireallylikepizza22
Theskyisblue44

NIST recently updated their password policy guidelines in Special Publication 800-63 to address new requirements for password policies.

If your organization must meet certain standards then make sure those standards support these password recommendations.

Also, be sure to update your companies written policy.

Summary

  • Use longer passwords, 15 characters at a minimum.
  • Longer passwords are harder to crack and provide better protection

10. Use descriptive security group names

First of all, make sure you apply permissions to resources with security groups, not individual accounts, this makes managing resources much easier.

Next, don’t name your security groups with a generic name like helpdesk or HR Training.

When you have generic names like this they will get used on all kinds of resources and you will have lost all control of security.

And there is no easy way to see what all a security group has permissions to. Yes, there are tools that you can run but if you have a medium or large size environment this will be a huge task.

Here is an example

IT_Local is very generic. Just by looking at the name, I don’t know what this is used for. Yes, it’s probably used by the IT department but where?

This is how permissions can get out of control and you could end up giving people access to things they shouldn’t have access to. Some sysadmin might get a request for access to the IT department network share and add users to this group. But what he doesn’t know is that group might be used on other systems. Now he just gave some users full permissions to some other systems.

When you use a descriptive name like the “N Drive HR_Training” group you can look at the name and have a good idea of what it is for. In this example, it’s for the N drive, it’s for HR and has something to do with Training. Your IT staff should have a good idea what this is just by the name.

Here is a real world example of how bad group names can lead to issues.

I was working with a client on cleaning up permissions to Active Directory. There were multiple security groups that had delegated permissions to Active Directory.

There was a group called helpdesk, another group IS Support, and one more called AD Modify.

I was under the impression only Helpdesk staff had rights to Active Directory to reset passwords and unlock accounts.

Come to find out these groups were used for other resources such as the helpdesk software, network share, and printers. So it included various IT staff.

Once I removed these groups I got phone calls from programmers and business analysts asking why they couldn’t reset user’s passwords anymore. Why on earth are programmers resetting user passwords?

I clear precise Security group name would have prevented this from happening.

If you don’t name the security group specific then it can be a catch all for permissions to many other things.

Here are some good examples of how to name groups.

Example 1: Allow helpdesk to reset passwords

Security group name: IT-Helpdesk-PW-Reset

Since the group name is precise, this would help prevent it from being used on other resources like a printer or network share.

Example 2: Allow HR rights to a shared folder

Security group name: N Drive HR-Training-Folder-RW

Again, this has a very specific name and helps identify what it should be used for.

You can come up with your own naming convention just get specific with the name and avoid generic one word group names.

Summary

  • Generic group names can lead to major security issues
  • Use descriptive group names that you can easily determine what it is used for
  • Come up with a naming convention, document it and share with your IT staff

11. Find and remove inactive user and computer accounts

You need to have a procedure in place to detect inactive users and computer accounts in Active Directory.

You don’t want a bunch of unused accounts sitting in Active Directory just waiting for an attacker to discover and use. This can also cause issues with reporting, patching, and slow down group policy.

CIS Critical Security Controls says “There are many ways to covertly obtain access to user accounts, including weak passwords, accounts still valid after a user leaves the enterprise, dormant or lingering test accounts”

CIS recommends deleting or disabling dormant accounts after 45 days of inactivity

I created a tool called AD Cleanup Tool that lets you quickly find inactive users and computer accounts.

If you want more details on finding inactive users or how to do this with PowerShell check out this article titled Finding inactive Users in Active Directory

12. Remove Users from the Local Administrator Group

A regular user should not be in the local administrator group on computers.

A user with local admin rights gives them full access to the entire Windows Operating system. This can lead to all kinds of security issues, such as installing software, disabling antivirus, downloading and installing malware, stealing data, hacking credentials, pivoting to other computers, and so on.

A Microsoft vulnerabilities report says:

“Of all the Windows vulnerabilities discovered in 2018, 169 of these were considered ‘critical’. Removing admin rights could have mitigated 85% of these critical vulnerabilities”

By removing users from the local administrator group you greatly reduce the opportunities for attackers to gain access to your computer and network.

I recommend you control the local administrator group by using group policy. If you remove them from the computer with no centralized control then someone will just add the rights back. I have fought this battle many times with helpdesk. I remove the rights then they just add it back when troubleshooting an issue.

By using group policy and restricted groups, this will prevent your staff from leaving accounts in the group.

I wrote a complete guide on this check it out here -> Remove Users from Local Administrator Group using Group Policy.

13. Do not install additional software or server roles on DCs

Domain controllers should have limited software and roles installed on them.

DC’s are critical to the enterprise, you don’t want to increase security risks by having additional software running on them.

Windows Server Core is a great option for running the DC role and other roles such as DHCP, DNS, print servers, and file servers. Server Core runs without a GUI and requires fewer security patches due to its smaller footprint.

Server core can have its challenges though with some 3rd party software not being compatible.

Summary

  • Don’t install a bunch of crap on your critical servers
  • Installing more stuff on your domain controllers can lead to additional security risks
  • Keep your DCs lean and clean

14. Patch management and vulnerability scanning

Attackers are quick to exploit known vulnerabilities.

If you do not regularly scan and remediate discovered vulnerabilities you are at a much greater risk for comprise.

There are a large number of vulnerability and scanning tools available, see my list of the top 6 patch management software compared.

Tips for Continues Vulnerability Management

  • Scan all systems at least once a month to identify all potential vulnerabilities. If you can scan more frequently than that’s even better.
  • Prioritize the finding of the vulnerability scans and first fix the ones that have known vulnerabilities in the wild.
  • Deploy automated software updates to operating systems
  • Deploy automated updated to 3rd party software
  • Identify out of date software that is no longer supported and get it updated.

15. Use secure DNS services to block malicious domains

You can prevent a lot of malicious traffic from entering your network by blocking malicious DNS lookups.

Anytime a system needs to access the internet it will in most cases use a domain name. Computers talk to each other by IP address so the computers use DNS to map a domain name to an IP address.

There are several services available that check DNS queries for malicious domains and blocks them.

How does this work?

These DNS services gather intelligence about malicious domains from various public and private sources. When it gets a query for a domain that it has flagged as malicious it will block access when your system attempts to contact them.

Here is a video from Quad 9 that explains their DNS service.

Here is an example:

Step1: Client clicks a link that goes to example.net

Step2: Local cache is checked

Step 3: DNS Service checks if the domain is on its threat list, it is so it returns a block reply.

In the above example since the DNS query returned a block, no malicious traffic ever entered into the network.

Here are some of the most popular secure DNS services

Quad9
OpenDNS
Comodo Secure DNS

I’m currently using Quad9, it’s free and easy to setup.

Also, most IPS (Intrusion Prevention Systems) systems support the ability to check DNS lookups against a list of malicious domains.

Summary

  • Using a secure DNS service is an easy way to help block known malicious traffic
  • Some of these services are Free such as Quad9
  • You can even use this at home by changing your DNS settings on your local nic card.

16. Run supported operating systems

With each new version of Windows OS, Microsoft includes built in security features and enhancements. More importantly, you get security updates.

Just staying on the latest OS will increase overall security.

New Security Features in Server 2016

  • Shielded Virtual Machines
  • Just Enough Administration
  • Headless Windows Defender
  • Credential Guard
  • Device Guard

Here is a good video from Microsoft on Windows Server 2016 Security.

Summary

  • Unsupported Operating sustems do not receive security updates. This is a big issue.
  • Keep track of your systems and know ahead of time the end of life and end of support dates.
  • Having supported systems will allow them to get security updates and use the latest security features.

17. Use two factor for office 365 and remote access

Compromised accounts are very common and this can provide attackers remote access to your systems through VPN, Citrix, or other remote access systems.

Check your Office 365 or ADFS logs, you will be surprised at how many login attempts are coming from China and Russia.

One of the best ways to protect against compromised accounts is two factor authentication. This will also help against password spraying attacks.

Let’s say a user fell for a phishing attempt that asked the user to verify their username and password.

Now the attacker has that user’s Active Directory credentials. The attacker could now gain access to a number of systems from anywhere.

If the user had two factor enabled this could prevent access even though the account has been compromised. The attacker would need the second set of credentials to get logged in.

There really is no stopping accounts from getting compromised there are too many ways for attackers to gain the credentials.

If you are using Office 365 and depending on what package you have MFA may be included. Take advantage of this feature.

Popular two factor authentication solutions

18. Monitor DHCP logs for connected devices

You should know what is connected to your network if you have multiple locations with lots of users and computers this can be challenging.

There are ways to prevent only authorized devices from connecting but this can be costly and a lot of work to set up. If you have the resources then that is the way to go.

Another method that is already available to you is to monitor the DHCP logs for connected devices.

You should have all end user devices setup to use DHCP. You can then look at the logs to see what is connecting. You should have a naming convention for your equipment, this will make it easy to spot possible unauthorized devices.

In the screenshot below I can easily spot a device that does not follow my computer naming convention.

minint-1bdvd67 is not something I recognize. I will need to look into this and see if it is an authorized device.

19. Monitor DNS logs for malicious network activity

Most connections start with a DNS query. All domain joined systems should be set up to use your local Windows DNS server.

With this setup, you can log every internal and external DNS lookup. When a client device makes a connection to a malicious site it will log that site name in the DNS logs.

These malicious domains are usually odd, random character domains that don’t look normal.

Here are some screenshots of suspicious DNS lookups from my logs. These repeatedly show up in my logs for a handful of devices.

I seriously doubt a user is trying to go to this site intentionally. These kinds of lookup need to be looked into to determine if it’s malicious or not.

To view the DNS lookups you first need to enable the DNS debug logs on the Windows Servers.

Steps to enable DNS debug logs on Windows Server

Step 1: Open the DNS Management Console

Step 2: Right click and select properties

Step 3: Click Debug Logging Tab

Step 4: Check the box “Log packets for debugging

Once you have the debug logs setup you can import those logs into an analyzer to quickly spot malicious activity.

You can also convert the log file to a CSV to make it easier to read and filter.

20. Use latest ADFS and Azure security features

ADFS and Azure have some great security features. These features will help with password spraying, account compromise, phishing, and so on.

No matter what level of office 365 you are on there are some features you should look into.

Of course, premium subscriptions have the best security features.

But

Microsoft does improve and add new features at every level (At least this is what I’ve noticed since being on Office 365).

Here are some features that are worth looking into:

  • Smart Lockout – Uses algorithms to spot unusual sign on activity.
  • IP Lockout – Uses Microsoft’s database of known malicious IP addresses to block sign on ins.
  • Attack Simulations – You should be doing regular phishing tests to help train end users. Microsoft will be releasing phish simulator software very soon.
  • MFA Authentication – Microsoft’s 2 factor solution
  • Banned passwords – Checks passwords against a known list
  • Azure AD Connect Health – Provides several good reports
  • Custom bad passwords – Ability to add custom banned passwords to check against.

I’m currently running a hybrid office 365 setup. In azure I can see several risky sign on reports.

Azure alerted me to a sign on that came from China from one of our accounts.

Some of these features are available with the latest ADFS version and some are included with an office 365 subscription.

Definitely check out all the available security features in ADFS, Office 365, and Azure.

Resources:

https://cloudblogs.microsoft.com/enterprisemobility/2018/03/05/azure-ad-and-adfs-best-practices-defending-against-password-spray-attacks/

21. Use Office 365 secure score

Secure score analyzes your office 365 organization security based on activity and security settings.

Secure Score checks your Office 365 services then checks your settings and activities and provides you a security score.

Once it analyzes your score it will provide a detailed list of what was scored and recommended actions to fix the issues.

You will need a Premium or Enterprise subscription to access this feature, in addition, you will need to be assigned the global admin or custom role.

Microsoft continues to expand and add additional features to Secure Score.

If you have access to this feature then take advantage of it.

22. Have a recovery plan

If your network was compromised today or hit with RansomWare, what would you do?

Do you have a response policy? Have you tested and trained staff on how to handle such an event?

Cyber attacks can shut down systems and bring business operations to a halt.

The City of Atlanta was shut down by a cyber attack, this prevented residents from paying online utility bills. In addition, Police officers had to write reports by hand.

Last I checked it cost more than $5 million for them to recover from the attack.

A good incident response plan could have limited the impact and enabled services back online much faster.

Here are a few things to include in an incident response plan

  • Create an incident response policy and plan
  • Create procedures for performing incident handling and reporting
  • Establish procedures for communicating with outside parties
  • Establish  response teams and leaders
  • Prioritize servers
  • Walkthrough and training

NIST has a great guide on computer security incident handling.
https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf

23. Document delegation to Active Directory

The best way to control access to Active Directory and related resources is to use Security Groups.

If you are delegating rights to individuals then you are losing control of who has access.

Create custom groups with very specific names, document who has rights, and a process for adding new users. Don’t just allow users to be added to these custom groups without an approval process. This is just another way permissions can get out of control.

Know what groups are delegated to what resources, document it, and make sure your team is on the same page.

24. Lock down service accounts

Service accounts are those accounts that run an executable, task or service, AD authentication, etc.

These are wildly used and often have a password set to never expire.

These accounts will often end up with too many permissions and more often than not are a member of the domain admins group.

Bad..very bad

Sometimes this is suggested by the vendor.

Don’t allow that to happen, there are ways to make it work without DA access.

Here are some tips for locking down service accounts.

  • Use Managed Service Accounts instead
  • Use long Strong passwords
  • Give access to only what is needed
  • Try to avoid granting local administrator rights
  • Do not put in Domain Admins
  • Deny logon locally
  • Deny logon as a batch
  • Require vendors to make their software work without domain admin rights

Summary

  • Service accounts need to be properly configured and locked down.
  • These accounts are often added with way more rights then needed. I see a lot of these accounts added to the domain admins group… So wrong.
  • Look into using Managed Service Accounts instead of a regular account.

25. Use security baselines and benchmarks

A default install of the Windows Operating system has many features, services, default settings, and enabled ports that are not secure.

These default settings should be reviewed against known security benchmarks.

Establishing a secure configuration on all systems can reduce the attack surface while maintaining functionality. There are several resources that provide security benchmarks.

Microsoft has a Security Compliance Toolkit that allows you to analyze and test against Microsoft’s recommended security configuration baselines.

Another great resource is CIS SecureSuite

It also provides security configuration baselines. In addition, it provides tools that can scan a system and provide a report on failures.

Most of the recommended settings can be set up using Group Policy and deployed to all computers.

Here is a screenshot of the CIS Securesuite tool. It ran a scan on my computer and generated a report on all the settings that passed and failed.

CIS Securesuite can also scan against other systems like Cisco, VMware, Linux, and more.

What did I miss? Do you have any Windows security tips?

Top 25
Active Directory
Security Checklist

Download this FREE PDF checklist that includes the top 25 best practices for securing Active Directory and Windows systems.

58 thoughts on “Top 25 Active Directory Security Best Practices”

  1. HI,
    great guide, really!
    What about application that may require admin rights (e.g. Backup)?
    Is there any best practice in term of using one admin credentials OR create dedicated ones and assign a human responsible… ?

    BR

    Reply
    • Limit the permissions as much as you can. There are programs such as Powerbrowker for windows that can escalate permissions to a program only when its executed, you can also specify the credentials. So instead of escalating permissions to a domain account you could use the local system account.

      To answer your question though I find it best to create credentials specific to the application or function. Backups for example, create an account for that program, limit permissions as much as you can so that it can only perform that function.

      Reply
  2. Robert,
    I’ve enabled policies according to step 7. Enable Audit policy Settings with Group Policy
    If a user fails logon with bad password, will I see this on a domain controller log ? what log, where ?
    I definitely see it on the workstation log, but I would like to see it on the DC. Maybe I need a rebpoot of DC’s . let me know. Thanks . The guide is great

    Reply
    • I left out some important details.

      You will need to enable this in the default domain controller policy or create a new GPO and link it to the domain controllers OU. This will log security related events on the domain controllers security event logs.

      Reply
  3. Great information!! A great consolidated list of high hitting items that give you best bang for your time as system admins.

    Reply
  4. Setting account lockout threadhold to 3 is too low. Three is too low because users maybe logon to multiple computers or getting email with mobile devices which will easily cause the account lockout when changing new password. 10 is the lowest number recommended by Microsoft.

    Reply
    • I agree 3 is too low and would recommend 5 bad password attempts. I would only recommend 10 if you can set your password length to a minimum of 15 characters.

      Reply
  5. Nice summary, but you haven’t mentioned:
    Account lockout analysis tools (which is quite important)
    Sysinternals tools – there’s plenty of them
    Netwrix – to review audit logs (free version)

    Reply
    • Hi Mike. There are many log and analysis tools out there, I did list a few of them under tip #8. ManageEngine ADAudit Plus is a great tool for auditing and analyzing account lockouts. I’m also creating a simple PowerShell tool that will help troubleshoot account lockouts and test for weak passwords.

      Reply
      • When will you have PowerShell tool available? Do you have a more detail list then what you posted that you can share?

        Reply
        • Hi David. I have a lockout tool created, I’ll be posting it soon. It’s nothing fancy, it finds all locked account and allows you to quickly unlock it. It also has a function that finds the source of account lockouts.

          Reply
  6. Hi, Robert. Excellent info here. Quick question if there are no Domain Admins what account is used to grant temporary access to Domain Admins especially since it states no one should know the Built-in Administrator password?

    Reply
    • The default domain administrator account should still be in the domain admins group. This account can be used to add accounts into the domain admins groups. The domain admin account should have a very strong password.

      Reply
  7. Great to see this information clearly listed in a single location. If I rename the different AD ‘privileged groups’ can it be considered a valid security measure too?

    Reply
  8. Under the “Monitor Active Directory Events for Signs of Compromise” section, you listed some popular log analyzers:

    Elk Stack
    Lepid
    Splunk
    ManageEngine ADAudit Plus
    Windows Event Forwarding

    Just curious which analyzer you currently use? If you don’t mind sharing.

    Thanks!

    Reply
    • I’m currently using ManageEngine ADAudit Plus. It has some really good pre-configured audit reports and it’s easy to setup.

      Reply
    • Homayoon,

      Very important, it should be enabled on every computer and server. I need to add this to the article.

      Thanks for the comment.

      Reply
  9. Hello,
    Great article ! 🙂
    I have a question, I want to know your opinion what is better for logging into domain servers (DC even member servers):
    IT staff user Steve has two account. First account with “Regular Rights” (e.g. SteveD) and second account with “privileged Domain Rights” (e.g. Admin01).
    Scenario 1 : Steve logs into domain server as Admin01 and he does his all job with “privileged Domain Rights”.
    Scenario 2 : Steve logs into domain server as SteveD and he does his job with “Regular Rights”. If he needs escalate he use “run as administrator … Admin01”.
    Thanks for reply.

    Reply
    • Hi Radim.

      I would not recommend logging into a domain controller and doing daily work from there.

      Logging into a computer with a regular account then escalate as needed is ok. A better option is to set up a dedicated workstation for performing tasks that require escalated rights. This dedicated workstation would be locked down with things like two factor authentication, no internet access and so on. Microsoft calls these secure admin workstations and has some good documentation on it.

      https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/privileged-access-workstations

      I typically setup a server with remote desktop services for admin work. Most admin tools get installed on this server and then consoles and access to critical infrastructure can be locked down to this admin server.

      Reply
  10. u miss a MUST in the IT server Admin procedure !!!!

    APPLOCKER !!!!!
    APPLOCKER for admin and user is a MUST in every server !!!!
    so whitelist just installed app , and no NEW app can RUN from user.
    so usually virus .exe .visual cannot run and install !!
    so No more Cryptofile or virus!!
    And that must do on all SERVER , Domain , active , terminal server, Gateway.

    Reply
  11. Hi,

    Excellent Article by the way.

    What would be your recommended approach as to how to create system accounts vs user accounts. Many times have seen systems accounts created in AD like a user account. Using the same OU and DC as user account. Other than looking at the general information?

    Reply
    • Make a firewall rule and only allow the saw access to the azure cloud and only allow the needed ports.

      Example firewall rule. The FQDN is made up, you would need to look up the correct FQDN.

      Source IP: 192.168.15.10
      Destination FQDN: azure.cloud.com
      Destination port: https

      In addition, you could require this firewall rule to include ldap authentication.

      Reply
  12. This is a wonderful guide. Thank you very much for it. I am still new in system administration, so I need article on how to secure office 365

    Reply
  13. Amazing guide!

    Can you please share your feedback about Account Operators and Administrators groups?

    Best practices on these two groups. Thanks in advance.

    Reply
  14. Thanks for this great summery of a admin best practice!

    Topic 2 mentions under Scenario 2 what rights a second admin-account might have.
    Is there a tutorial anywhere, how to set this up?

    Reply
    • Seems like I remember seeing a guide from Microsoft but now I can’t find it. Here is a process I use:

      1. For anyone that needs admin rights to a system they get a secondary admin account
      2. This secondary account gets added to an AD group that gives them access to only what they need. For example, a database administrator needs rights to the SQL server. This user’s admin account will go into the AD-SQL-ADMIN group. VMware admins go into the AD-VMWare-ADMIN group. You would need to configure each system to set these groups as administrators. Like in vmware you would need to configure it to set the AD-VMWare-Admin group as admins to that system, or whatever rights you want to give it.
      3. I then monitor each privileged group for changes. Anytime a user is added/removed from an admin group I get an email alert.
      4. No admin account has remote access and ideally no internet access.

      Reply

Leave a Comment