In This excerpt I will be delving into Active Directory and making useful recommendations to improve its security. In many organizations, Active Directory serves as the foundation for managing user accounts, permissions, and network resources, making it a prime target for attackers. I will provide practical tips and best practices based on my expertise and experience to strengthen the security of your Active Directory environment. This blog post will provide you with actionable insights to protect this critical component of your infrastructure, whether you are an IT professional responsible for managing Active Directory or an organization looking to strengthen its defenses. Stay tuned for useful recommendations to help protect your Active Directory from potential threats.These processes are also recommended for the Enterprise Admins, Backup Admins, and Schema Admin groups.
- Restrict the use of Domain Administrators and other Privileged Groups : Domain Admins and other privileged groups wield enormous power. They can access the entire domain, including all systems, data, computers, laptops, and so on.The only exception is the default Domain Administrator account, which should not have any day-to-day user accounts in the Domain Admins group.It is far too simple for attackers to obtain or crack user credentials. Once an attacker has gained access to one system, they can move laterally within a network in search of higher-level administrators (domain admins).Pass the hash is one method for accomplishing this.Passing the hash allows an attacker to use the password hash instead of the regular password to authenticate to remote systems. End-user computers can provide these hashes.
- Use two or more accounts (Regular and Administrator Accounts) : You should not be logging in every day with a local admin or privileged account (Domain Admin).Instead, create two accounts: one with no administrative privileges and one with administrative privileges only.BUT Do not, at least not indefinitely, add your secondary account to the Domain Admins group.Follow the least privileged administrative model instead. Essentially, this means that all users should log in with an account that has only the permissions necessary to complete their tasks. 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.
- Maintain the Domain Administrator Account Secure.Every domain has an Administrator account, which is automatically a member of the Domain Admins group.The built-in Administrator account should be used only for domain configuration and disaster recovery (restoring Active Directory).Anyone who needs administrative access to servers or Active Directory should create their own account.Nobody should know the password for the Domain Administrator account. Set a password that is at least 20 characters long and store it in a vault. Again, this is only required 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
- The local administrator account is a well-known account in Domain environments and is not needed. Rather than Local admin one should be using an individual account that has the necessary rights to complete tasks.The problem with the local admin account are following:
- It is a well-known account, even if you rename it the SID is the same and is well-known by attackers.
- 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.
- 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
- LDAPS (Local Administrator Password Solution):The Local Administrator Password Solution (LAPS) is a popular tool for managing the local administrator password on all computers.LAPS is a Microsoft tool for managing domain-joined computers’ local account passwords. It will generate a new password for each local administrator account and save it in Active Directory for easy access.This is one of the best free options for preventing pass the hash attacks and lateral movement between computers.To perform all management tasks on the workstations, the solution employs the group policy client side extension. It is compatible with Active Directory 2003 SP1 and later, as well as client Vista Service Pack 2 and later..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.
- 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.Since attacks can come from internal and external it’s best to adopt an assumed breach of security posture.
- 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
- Here are some tips to help get you started:
- Use a clean OS install (use the latest Windows OS)
- Apply hardening security baseline (See tip#25)
- Enable full disk encryption
- Restrict USB ports
- Enable the Windows 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
- What tasks would you do on a SAW?
- 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.
- Account Logon
- 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: Monitor Active Directory for Signs of Compromise One 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.
- 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 where security groups are being used. Yes, there are tools that you can run but if you have a medium or large size environment this will be a huge task.
- 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 password lists (freely available) that contain millions of easy to guess passwords.
- Find and Remove Inactive User and Computer Accounts
- Remove Users from the Local Administrator Group after usage and monitor regularly to changes in group members.
- Do Not Install Additional Software or Server Roles on Domain Controllers.
- Patch Management and Vulnerability Scanning
- Use Secure DNS Services to Block Malicious Domains
- . Use two-factor/ if possible multi factor authentication with Hardware usb key for office 365 and remote access.
- Monitor DHCP logs for connected devices and Monitor DNS Logs for Malicious Network Activity.
- Use Security Baselines and Benchmarks
- A default install of the Windows Operating system has
- 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.
- Lock 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.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
- Document Delegation to AD : 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.
- Have a Recovery Plan. 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
- Walk-through and training
- Use Latest ADFS and Azure Security Features: features that are worth looking into are listed below:
- 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
Credits to Team @ activedirectorypro
