If you have made the decision to conduct an Active Directory Security Assessment for your production AD Forests, it is crucial to recognize the potential security threats that may exist within your Active Directory environment. However, neglecting to address common configuration mistakes in Active Directory poses a significant security risk. In this article, we will explore the importance of performing a “complete” Active Directory assessment, in addition to recommended security tests by organizations such as MITRE and ANSSI. This article explains importance of health and configuration checks as part of Active Directory security assessment.
Let’s explore the assessment categories and methodology before delving into the specifics of the tests. Each assessment tool, whether it focuses on Active Directory, Office 365, or any other technology, should encompass five essential assessment categories: Health Check, Misconfiguration, Security and Risk, Non-Compliance, and Performance.
While the Assessment Categories assist in selecting the appropriate Active Directory Assessment tool, the Methodology provides an overall perspective for both the IT Management Team and IT Operations Team. The tool should adopt a methodology that caters to the needs of both teams. The methodology should include the following:
With our expert’s extensive experience in Active Directory and we being certified ADRAP engineers, we have conducted numerous ADRAP engagements. While ADRAP primarily focused on assessing potential configuration issues and performing health checks on AD components like KCC functionality, domain controller health, Active Directory site related tests, bridgehead, replication topology, ISTG, DC Services, and identifying undefined subnets, it did not give much attention to the security threats we observe in Active Directory environments these days and some of the misconfiguration that we see in Active Directory environments. Therefore, it is important to understand that maintaining a healthy Active Directory environment and resolving all configuration and health issues is imperative in order to eliminate security threats entirely. Here’s why we believe this to be the case.
Below screenshot, taken from SmartProfiler for Active Directory, shows misconfiguration for Domain Controllers.
Active Directory functions as a multi-master replication system, enabling changes made in one site to be replicated to other sites within the network. In the context of fixing dangerous permission issues on the AdminSDHolder object, it is crucial to ensure that these changes are replicated across all domain controllers in the AD Forest. Successful replication is needed for various important modifications, including:
In a large AD environment even if replication breaks normal users authentication would still happen with cached credentials but you cannot ensure that security items fixed as part of the assessment are replicated to all domain controllers unless you fix the replication issue. Therefore, it is important that proper AD replication is essential for guaranteeing the successful propagation of critical changes, maintaining the security and integrity of the Active Directory environment.
If you are a legitimate Active Directory Admin, you would typically avoid making excessive failed logon attempts. In the event that your password fails to work after two or three attempts, it is advisable to seek assistance from a colleague to reset your password. However, if you observe a significant number of failed logon attempts from an AD Admin account, particularly if they occur rapidly, it may indicate that your Active Directory environment is being targeted by a potential attack.
While you may have Account Lockout Policies configured in the Default Domain Account Policy, it is essential to consider FGPP for privileged accounts. If these FGPP policies do not have Account Lockout values configured, it could present a security risk. It is highly recommended to protect all privileged accounts by implementing FGPP policies that enforce a robust set of password rules including account policies. However, some administrators may overlook configuring account lockout policies even within FGPP due to negligence or oversight.
By default, DNS Scavenging is not enabled on domain zones and Active Directory DNS Servers. However, enabling the Scavenging process is crucial as it plays a vital role in eliminating outdated or stale accounts from the DNS database. This process significantly contributes to faster loading of the DNS Database, which is particularly important when dealing with a high volume of DNS queries from various AD applications, users, and computers.
During a security assessment, if it is discovered that an attacker has registered a DNS record as part of their attack strategy, it becomes imperative to promptly remove those entries from the DNS Server. However, in case you inadvertently forget to remove these DNS entries, the DNS Scavenging process will recognize them as stale records and automatically remove them. This proactive measure acts as a deterrent against attacks that rely on the successful registration of a DNS record.
By enabling DNS Scavenging and diligently managing DNS entries, you can establish a more secure DNS environment. This practice ensures the elimination of stale records and enhances the responsiveness of the DNS service to meet the demands of AD applications, users, and computers.
Granting Full Control permission to IT support accounts or the EVERYONE group on business organizational units presents a significant security risk. In the event of an issue where an IT support account encounters an “Access is Denied” error, it is common for administrators to assign Full Control permissions to troubleshoot the problem. However, during my ADRAP engagements with customers, I have observed that many organizational units have these excessive permissions assigned.
This configuration creates a potential vulnerability. If an attacker manages to gain access to a normal user account within the same organizational unit, they can easily exploit the granted Full Control or EVERYONE permissions. This access enables them to delete objects or gain unauthorized access to other objects residing in that specific OU.
To ensure the security of domain controllers and Active Directory admin systems, it is crucial to disable the Print Spooler service due to potential vulnerabilities. Although seemingly innocuous, any authenticated user has the ability to remotely connect to the domain controller’s Print Spooler service and request updates on new print jobs.
Furthermore, users can instruct the domain controller to send notifications to the system with unconstrained delegation, thereby posing a risk of exposing the domain controller computer account credentials since the Print Spooler is owned by SYSTEM account. Therefore, disabling the Print Spooler service becomes imperative in order to mitigate these risks of exposure. Disabling the spooler service should be included as a standard checklist item when deploying a new domain controller in AD Forest.
Cyber attackers often exploit legacy protocols as part of their attack strategies, targeting organizations that have not yet implemented appropriate countermeasures. One such protocol, TLS 1.1, which is nearly two decades old, has been identified as vulnerable to attacks like BEAST and POODLE. Additionally, TLS 1.1 supports weak cryptography, rendering modern connections inadequately secure.
TLS 1.1 can be likened to a forgotten middle child. It shares the flaw of supporting inadequate cryptography, much like its younger sibling TLS 1.0. In most software implementations, TLS 1.2 has surpassed TLS 1.1, making the latter relatively uncommon. However, from an attacker’s perspective, it becomes a potential weapon in their arsenal. So please include in your standard domain controller deployment guide to disable TLS 1.1 support completely.
In a large Active Directory environment, organizations often implement different password policies using FGPP to cater to various teams’ requirements. However, it is crucial to acknowledge that the default setting for the “Minimum Password Length” in FGPP is set to 7, which is not considered secure and poses a significant risk.
To address this misconfiguration and enhance security, it is necessary to evaluate all existing FGPP policies and Domain Account Policy and identify those with the “Minimum Password Length” set to 7. It is recommended to set a minimum password length that is sufficiently long and robust to resist common password attacks. Microsoft recommended 8 characters as minimum password length.
Additionally, review and update the “Minimum Password Length” configuration in the Domain Account Policy. This policy applies to all user accounts within the domain that are not covered by FGPP policies.
Note: FGPP overrides Domain Account Policy parameters.
By addressing the “Minimum Password Length” misconfiguration in both FGPP and the Domain Account Policy, you can establish more robust password requirements across Active Directory environment, mitigating the risks associated with weak passwords.
By default, the built-in administrator account in Active Directory is not adequately protected. To ensure enhanced security, it is essential to take specific actions related to the default administrator account. These actions include renaming the account, disabling it, and applying the “account is sensitive and cannot be delegated” setting in each domain.
Considering the importance of securing the default administrator account, it is recommended to include these actions in the “misconfiguration” category. Because an Active Directory deployment should adhere to a standard deployment checklist that encompasses protecting the default administrator account as a crucial step.
The absence of administrative ownership for Domain Controller computer accounts poses a significant security risk and can be considered both a security vulnerability and a misconfiguration. If domain controller computer accounts are managed by non-privileged accounts, an attacker could exploit this and potentially gain full control over the Active Directory environment. To mitigate this risk, it is highly recommended to conduct regular checks to verify ownership of all domain controllers, ensuring that each one is assigned a privileged account as its owner. The same principle should be applied to all business organizational units within your environment.
Even if you have defined the list of subnets in Active Directory for all your physical sites, it does not guarantee that an attacker cannot authenticate to a domain controller from an “undefined” subnet. It is important to note that Active Directory does not inherently restrict logon requests based on subnet definitions.
If you notice logon requests originating from a subnet that has not been defined or accounted for in your Active Directory configuration, it is crucial to investigate and address this security risk. You should obtain a list of these unrecognized subnets and review them carefully. By doing so, you can identify any unauthorized or suspicious network activity and take appropriate measures to eliminate the potential security vulnerabilities. This may involve adjusting your subnet definitions in Active Directory, implementing additional security measures, or investigating the source of the logon requests for further remediation.
Note: As part of the standard AD Deployment or AD Site creation process you are required to identify the subnets to be associated with the AD Site.
Granting anonymous access to Active Directory poses a significant security risk. Anonymous access allows authenticated users to read the Active Directory database using LDAP or other tools. This means that if an attacker gains unauthorized access within your network, they can connect their laptop and query all user accounts, including privileged accounts marked with AdminCount=1.
Once an attacker identifies the privileged accounts, they can potentially launch a brute force attack to compromise the security of the Active Directory environment. This task becomes even easier if the “Minimum Password Length” is set to a relatively short value, such as 7 characters.
To mitigate this risk, ensure that anonymous access to Active Directory is disabled. By doing so, you significantly limit the potential for unauthorized users to query sensitive information and launch attacks against your Active Directory infrastructure. Additionally, it is recommended to implement strong password policies, including longer minimum password lengths, to enhance the security of privileged accounts and make brute force attacks more challenging to execute successfully.
The BadLogonCount attribute on each user and computer object in Active Directory provides information about the number of authentication attempts that resulted in failures. It serves as a valuable indicator for security testing, helping identify potential security risks.
Account lockout policies play a critical role in mitigating these risks by ensuring that user accounts that exceed a certain threshold of unsuccessful login attempts are locked out. However, it is important to note that in Active Directory, there is no built-in mechanism to keep an account locked out indefinitely if the number of unlock attempts surpasses a certain limit.
While account lockout policies offer an essential layer of protection, it is crucial to strike a balance between security and usability. Setting appropriate thresholds for lockout policies helps prevent unauthorized access while also considering the possibility of legitimate users experiencing login issues due to password mistakes or other reasons. It is recommended to regularly review and adjust these policies based on the organization’s security requirements and the risk tolerance level.
The default replication interval for each Active Directory (AD) Site is set to 180 minutes. However, in large environments, it is advisable to configure a lower replication interval for AD Sites. This adjustment ensures that changes made within the AD environment are replicated as quickly as possible. You are expecting those changes to be replicated to all domain controllers world-wide that you addressed as part of your security assessment.
Adding users to privileged groups like Domain Admins and Enterprise Admins in Active Directory is not restricted. However, it is crucial to establish a procedure that mandates approval and review by the IT Management team for each user added to these highly privileged groups. There are several compelling reasons to support this practice:
Protected Users security Group is designed as part of a strategy to manage credential exposure within the enterprise. Members of this group automatically have non-configurable protections applied to their accounts. Membership in the Protected Users group is meant to be restrictive and proactively secure by default. The only method to modify these protections for an account is to remove the account from the security group.
Allowing unsecure DNS updates in Active Directory is a big security risk. You cannot allow any unauthenticated users to register the DNS records in DNS Server. If you allow to do so:
Always configure secure updates to all Active Directory domains.
A security group without members if it is also a member of a privileged group and if an attacker adds a user account to that empty security group the attacker can gain access to Active Directory as a privileged user. In case of organizational unit without any objects and if someone assigns EVERYONE full control permission to that OU.
NOTE: Most Active Directory admins I have worked with do not have tendency to look at members of a nested security group. I would recommend if something is not in use in Active Directory then just disable it or move to an organizational unit called “Unused”. This way you can find all objects that are not in use in Active Directory easily.
It is important to recognize that a comprehensive backup of each AD partition is required for successful disaster recovery. Ideally, each AD partition should be backed up at least once every 7 days to maintain data integrity.
However, if an attack or issue is identified after 10 days, a backup from two weeks ago can be utilized to restore the AD data. This highlights the need to retain multiple backup copies to accommodate such scenarios.
One challenge with Active Directory is that it does not provide explicit information on whether a partition has been successfully backed up or not, unless you specifically run a PowerShell script or check using tools like LDP, ADSIEdit.msc, or attribute editor.
It is crucial to pay attention to various misconfiguration and health check items when conducting an Active Directory assessment. Even Microsoft suggests checking misconfiguration in Active Directory in their on-demand tool. These items highlight potential vulnerabilities and areas of concern that require attention. Some noteworthy examples include identifying unsupported operating systems, manual replication connection objects, and ensuring adequate AD site coverage, among others.
To facilitate these assessments, SmartProfiler for Active Directory has been specifically developed. This tool is designed to perform comprehensive health checks, misconfiguration assessments, and security and risk evaluations for multiple Active Directory forests. It offers a wide range of 168 tests, covering not only MITRE tests but also security items identified by organizations such as ANSSI. Utilizing SmartProfiler enables organizations to gain valuable insights into the health, security, and risk posture of their Active Directory infrastructure.
Try SmartProfiler, a unified tool to help with security evaluation across many Microsoft technologies.