M1015: Active Directory Configuration
Implement robust Active Directory (AD) configurations using group policies to secure user accounts, control access, and minimize the attack surface. AD configurations enable centralized control over account settings, logon policies, and permissions, reducing the risk of unauthorized access and lateral movement within the network. This mitigation can be implemented through the following measures:
Account Configuration:
- Implementation: Use domain accounts instead of local accounts to leverage AD’s centralized management, including group policies, auditing, and access control. - Use Case: For IT staff managing shared resources, provision domain accounts that allow IT teams to log in centrally, reducing the risk of unmanaged, rogue local accounts on individual machines.
Interactive Logon Restrictions:
- Implementation: Configure group policies to restrict interactive logons (e.g., direct physical or RDP logons) for service accounts or privileged accounts that do not require such access. - Use Case: Prevent service accounts, such as SQL Server accounts, from having interactive logon privileges. This reduces the risk of these accounts being leveraged for lateral movement if compromised.
Remote Desktop Settings:
- Implementation: Limit Remote Desktop Protocol (RDP) access to specific, authorized accounts. Use group policies to enforce this, allowing only necessary users to establish RDP sessions. - Use Case: On sensitive servers (e.g., domain controllers or financial databases), restrict RDP access to administrative accounts only, while all other users are denied access.
Dedicated Administrative Accounts:
- Implementation: Create domain-wide administrative accounts that are restricted from interactive logons, designed solely for high-level tasks (e.g., software installation, patching). - Use Case: Create separate administrative accounts for different purposes, such as one set of accounts for installations and another for managing repository access. This limits exposure and helps reduce attack vectors.
Authentication Silos:
- Implementation: Configure Authentication Silos in AD, using group policies to create access zones with restrictions based on membership, such as the Protected Users security group. This restricts access to critical accounts and minimizes exposure to potential threats. - Use Case: Place high-risk or high-value accounts, such as executive or administrative accounts, in an Authentication Silo with extra controls, limiting their exposure to only necessary systems. This reduces the risk of credential misuse or abuse if these accounts are compromised.
**Tools for Implementation**:
- Active Directory Group Policies: Use Group Policy Management Console (GPMC) to configure, deploy, and enforce policies across AD environments. - PowerShell: Automate account configuration, logon restrictions, and policy application using PowerShell scripts. - AD Administrative Center: Manage Authentication Silos and configure high-level policies for critical user groups within AD.
Security context for executives and security teams
Active Directory configuration is a high-value preventive control because many damaging intrusions depend on abusing legitimate accounts, cached credentials, Kerberos material, RDP access, or overly broad administrative privileges. The business value is not simply “harden AD”; it is reducing how far a compromised account can take an attacker before SOC and IR teams have a chance to contain the incident.
Executive priority
Treat this as an identity resilience and lateral-movement reduction priority. Leaders should ask whether privileged, service, executive, and high-value accounts have purpose-specific restrictions; whether RDP and interactive logon rights are limited to real business need; and whether Group Policy is producing auditable evidence of enforcement. This mitigation is especially relevant to reducing exposure tied to Valid Accounts, OS Credential Dumping, DCSync, Pass the Ticket, Kerberos ticket abuse, unsecured credentials in Group Policy Preferences, and related credential-access or lateral-movement behaviors identified in the ATT&CK relationships.
Technical view
SOC, IAM, and IR teams should validate that AD Group Policy is being used to centralize account settings, logon restrictions, permissions, RDP access, and authentication silos. Priority checks include: domain accounts used instead of unmanaged local accounts where appropriate; service and privileged accounts denied unnecessary interactive and RDP logons; RDP allowed only for authorized accounts on sensitive systems such as domain controllers or financial databases; separate administrative accounts used for different administrative purposes; and Authentication Silos or Protected Users-style restrictions applied to high-risk or high-value accounts where supported. Because ATT&CK provides no official detection text for this mitigation, detection work should focus on configuration verification, policy drift, and monitoring for activity that would indicate these controls are being bypassed or are absent.
Likely telemetry
- Active Directory Group Policy configuration and change records
- User, service account, privileged account, and administrative group membership data
- Interactive logon and remote logon events, including RDP session evidence
- Domain controller authentication and authorization events
- Kerberos authentication activity relevant to ticket use and abuse
Detection direction
- Validate that monitoring can distinguish normal administration from changes to logon rights, RDP permissions, group membership, authentication silos, and privileged account policy.
- Tune detections around risky exceptions: service accounts with interactive logon, broad RDP rights, privileged accounts usable across many systems, and unexpected changes to domain-wide administrative controls.
- Use relationship context to prioritize analytic coverage for credential-access and lateral-movement behaviors, especially OS Credential Dumping, Cached Domain Credentials, DCSync, Pass the Ticket, Golden Ticket, unsecured credentials in Group Policy Preferences, SAML token abuse, and authentication certificate abuse.
- Account for false positives from legitimate IT administration, software deployment, patching, and repository management; require change-ticket, owner, and business-purpose context where possible.
- Do not rely only on endpoint alerts. This mitigation’s effectiveness is often decided by identity configuration state, Group Policy enforcement, and domain controller telemetry.
Mitigation priorities
- Establish a baseline of current AD account types, privileged groups, RDP rights, interactive logon rights, service accounts, and policy exceptions.
- Use Group Policy to enforce centralized account configuration and reduce unmanaged local-account exposure where domain accounts are appropriate.
- Restrict interactive logons for service accounts and privileged accounts that do not require direct physical or RDP access.
- Limit RDP access to explicitly authorized accounts, with tighter restrictions for sensitive systems such as domain controllers and high-value business servers.
- Separate administrative accounts by purpose and scope to reduce unnecessary credential exposure.
Additional notes and limits
This object is a mitigation, not a detection or technique. Its strongest decision value comes from the ATT&CK relationships: it helps reduce the usefulness of stolen credentials and authentication material by constraining where accounts can log on, what they can access, and how broadly administrative credentials can be reused. For Glexia-style assessment work, this maps well to identity hardening, managed detection validation, incident response readiness, compliance evidence, and control-prioritization discussions.
ATT&CK does not specify platforms or tactics for this mitigation object and provides no official detection guidance. The related techniques include Windows, Linux, macOS, cloud, SaaS, IaaS, Identity Provider, Containers, ESXi, Network Devices, and Office Suite platforms, but the mitigation description itself is specifically about Active Directory configuration. Local AD architecture, hybrid identity design, business exceptions, and available telemetry are required to determine actual coverage and residual risk.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Active Directory Configuration
Implement robust Active Directory (AD) configurations using group policies to secure user accounts, control access, and minimize the attack surface. AD configurations enable centralized control over account settings, logon policies, and permissions, reducing the risk of unauthorized access and lateral movement within the network. This mitigation can be implemented through the following measures:
Account Configuration:
- Implementation: Use domain accounts instead of local accounts to leverage AD’s centralized management, including group policies, auditing, and access control. - Use Case: For IT staff managing shared resources, provision domain accounts that allow IT teams to log in centrally, reducing the risk of unmanaged, rogue local accounts on individual machines.
Interactive Logon Restrictions:
- Implementation: Configure group policies to restrict interactive logons (e.g., direct physical or RDP logons) for service accounts or privileged accounts that do not require such access. - Use Case: Prevent service accounts, such as SQL Server accounts, from having interactive logon privileges. This reduces the risk of these accounts being leveraged for lateral movement if compromised.
Remote Desktop Settings:
- Implementation: Limit Remote Desktop Protocol (RDP) access to specific, authorized accounts. Use group policies to enforce this, allowing only necessary users to establish RDP sessions. - Use Case: On sensitive servers (e.g., domain controllers or financial databases), restrict RDP access to administrative accounts only, while all other users are denied access.
Dedicated Administrative Accounts:
- Implementation: Create domain-wide administrative accounts that are restricted from interactive logons, designed solely for high-level tasks (e.g., software installation, patching). - Use Case: Create separate administrative accounts for different purposes, such as one set of accounts for installations and another for managing repository access. This limits exposure and helps reduce attack vectors.
Authentication Silos:
- Implementation: Configure Authentication Silos in AD, using group policies to create access zones with restrictions based on membership, such as the Protected Users security group. This restricts access to critical accounts and minimizes exposure to potential threats. - Use Case: Place high-risk or high-value accounts, such as executive or administrative accounts, in an Authentication Silo with extra controls, limiting their exposure to only necessary systems. This reduces the risk of credential misuse or abuse if these accounts are compromised.
**Tools for Implementation**:
- Active Directory Group Policies: Use Group Policy Management Console (GPMC) to configure, deploy, and enforce policies across AD environments. - PowerShell: Automate account configuration, logon restrictions, and policy application using PowerShell scripts. - AD Administrative Center: Manage Authentication Silos and configure high-level policies for critical user groups within AD.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1558 | Steal or Forge Kerberos Tickets | For containing the impact of a previously generated golden ticket, reset the built-in KRBTGT account password twice, which will invalidate any existing golden tickets that have been created with the KRBTGT hash and other Kerberos tickets derived from it. For each domain, change the KRBTGT account password once, force replication, and then change the password a second time. Consider rotating the KRBTGT account password every 180 days.[1] |
| Enterprise | T1078.004 | Cloud AccountsSub-technique | Disable legacy authentication, which does not support MFA, and require the use of modern authentication protocols instead. |
| Enterprise | T1072 | Software Deployment Tools | Ensure proper system and access isolation for critical network systems through use of group policy. |
| Enterprise | T1552 | Unsecured Credentials | Remove vulnerable Group Policy Preferences.[2] |
| Enterprise | T1134.005 | SID-History InjectionSub-technique | Clean up SID-History attributes after legitimate account migration is complete. Consider applying SID Filtering to interforest trusts, such as forest trusts and external trusts, to exclude SID-History from requests to access domain resources. SID Filtering ensures that any authentication requests over a trust only contain SIDs of security principals from the trusted domain (i.e preventing the trusted domain from claiming a user has membership in groups outside of the domain). SID Filtering of forest trusts is enabled by default, but may have been disabled in some cases to allow a child domain to transitively access forest trusts. SID Filtering of external trusts is automatically enabled on all created external trusts using Server 2003 or later domain controllers. [3] [4] However note that SID Filtering is not automatically applied to legacy trusts or may have been deliberately disabled to allow inter-domain access to resources. SID Filtering can be applied by: [5] * Disabling SIDHistory on forest trusts using the netdom tool ( * Applying SID Filter Quarantining to external trusts using the netdom tool ( * Applying SID Filtering to domain trusts within a single forest is not recommended as it is an unsupported configuration and can cause breaking changes. [5] [6] If a domain within a forest is untrustworthy then it should not be a member of the forest. In this situation it is necessary to first split the trusted and untrusted domains into separate forests where SID Filtering can be applied to an interforest trust |
| Enterprise | T1606.002 | SAML TokensSub-technique | For containing the impact of a previously forged SAML token, rotate the token-signing AD FS certificate in rapid succession twice, which will invalidate any tokens generated using the previous certificate.[7] |
| Enterprise | T1649 | Steal or Forge Authentication Certificates | Ensure certificate authorities (CA) are properly secured, including treating CA servers (and other resources hosting CA certificates) as tier 0 assets. Harden abusable CA settings and attributes. For example, consider disabling the usage of AD CS certificate SANs within relevant authentication protocol settings to enforce strict user mappings and prevent certificates from authenticating as other identifies.[8] Also consider enforcing CA Certificate Manager approval for the templates that include SAN as an issuance requirement. |
| Enterprise | T1003.005 | Cached Domain CredentialsSub-technique | Consider adding users to the "Protected Users" Active Directory security group. This can help limit the caching of users' plaintext credentials.[9] |
| Enterprise | T1003.006 | DCSyncSub-technique | |
| Enterprise | T1550 | Use Alternate Authentication Material | Configure Active Directory to prevent use of certain techniques; use SID Filtering, etc. |
| Enterprise | T1550.003 | Pass the TicketSub-technique | To contain the impact of a previously generated golden ticket, reset the built-in KRBTGT account password twice, which will invalidate any existing golden tickets that have been created with the KRBTGT hash and other Kerberos tickets derived from it.[12] For each domain, change the KRBTGT account password once, force replication, and then change the password a second time. Consider rotating the KRBTGT account password every 180 days.[1] |
| Enterprise | T1552.006 | Group Policy PreferencesSub-technique | Remove vulnerable Group Policy Preferences.[2] |
| Enterprise | T1078 | Valid Accounts | Disable legacy authentication, which does not support MFA, and require the use of modern authentication protocols instead. |
| Enterprise | T1558.001 | Golden TicketSub-technique | For containing the impact of a previously generated golden ticket, reset the built-in KRBTGT account password twice, which will invalidate any existing golden tickets that have been created with the KRBTGT hash and other Kerberos tickets derived from it. For each domain, change the KRBTGT account password once, force replication, and then change the password a second time. Consider rotating the KRBTGT account password every 180 days.[1] |
| Enterprise | T1003 | OS Credential Dumping |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Imported snapshots across ATT&CK releases(1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.2 | Current bundle | 4111bf5707a0… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
- [1]STIG krbtgt reset
UCF. (n.d.). The password for the krbtgt account on a domain must be reset at least every 180 days. Retrieved November 5, 2020.
Open source URL - [2]Microsoft MS14-025
Microsoft. (2014, May 13). MS14-025: Vulnerability in Group Policy Preferences could allow elevation of privilege. Retrieved January 28, 2015.
- [3]Microsoft Trust Considerations Nov 2014
Microsoft. (2014, November 19). Security Considerations for Trusts. Retrieved November 30, 2017.
Open source URL - [4]Microsoft SID Filtering Quarantining Jan 2009
Microsoft. (n.d.). Configuring SID Filter Quarantining on External Trusts. Retrieved November 30, 2017.
Open source URL - [5]Microsoft Netdom Trust Sept 2012
Microsoft. (2012, September 11). Command-Line Reference - Netdom Trust. Retrieved November 30, 2017.
Open source URL - [6]AdSecurity Kerberos GT Aug 2015
Metcalf, S. (2015, August 7). Kerberos Golden Tickets are Now More Golden. Retrieved December 1, 2017.
Open source URL - [7]Mandiant Defend UNC2452 White Paper
Mandiant. (2021, January 19). Remediation and Hardening Strategies for Microsoft 365 to Defend Against UNC2452. Retrieved January 22, 2021.
Open source URL - [8]SpecterOps Certified Pre Owned
Schroeder, W. & Christensen, L. (2021, June 22). Certified Pre-Owned - Abusing Active Directory Certificate Services. Retrieved August 2, 2022.
Open source URL - [9]Microsoft Protected Users Security Group
Microsoft. (2016, October 12). Protected Users Security Group. Retrieved May 29, 2020.
Open source URL - [10]ADSecurity Mimikatz DCSync
Metcalf, S. (2015, September 25). Mimikatz DCSync Usage, Exploitation, and Detection. Retrieved August 7, 2017.
Open source URL - [11]Microsoft Replication ACL
Microsoft. (n.d.). How to grant the "Replicating Directory Changes" permission for the Microsoft Metadirectory Services ADMA service account. Retrieved December 4, 2017.
Open source URL - [12]ADSecurity Kerberos and KRBTGT
Sean Metcalf. (2014, November 10). Kerberos & KRBTGT: Active Directory’s Domain Kerberos Service Account. Retrieved January 30, 2020.
Open source URL - [13]AdSecurity DCSync Sept 2015
Metcalf, S. (2015, September 25). Mimikatz DCSync Usage, Exploitation, and Detection. Retrieved December 4, 2017.
Open source URL - [14]mitre-attackM1015Open source URL
- [15]mitre-attackM1015Open source URL
- [16]mitre-attackM1015Open source URL
- [17]STIG krbtgt reset
UCF. (n.d.). The password for the krbtgt account on a domain must be reset at least every 180 days. Retrieved November 5, 2020.
Open source URL - [18]Microsoft MS14-025
Microsoft. (2014, May 13). MS14-025: Vulnerability in Group Policy Preferences could allow elevation of privilege. Retrieved January 28, 2015.
- [19]AdSecurity Kerberos GT Aug 2015
Metcalf, S. (2015, August 7). Kerberos Golden Tickets are Now More Golden. Retrieved December 1, 2017.
Open source URL - [20]Microsoft Netdom Trust Sept 2012
Microsoft. (2012, September 11). Command-Line Reference - Netdom Trust. Retrieved November 30, 2017.
Open source URL - [21]Microsoft SID Filtering Quarantining Jan 2009
Microsoft. (n.d.). Configuring SID Filter Quarantining on External Trusts. Retrieved November 30, 2017.
Open source URL - [22]Microsoft Trust Considerations Nov 2014
Microsoft. (2014, November 19). Security Considerations for Trusts. Retrieved November 30, 2017.
Open source URL - [23]Mandiant Defend UNC2452 White Paper
Mandiant. (2021, January 19). Remediation and Hardening Strategies for Microsoft 365 to Defend Against UNC2452. Retrieved January 22, 2021.
Open source URL - [24]SpecterOps Certified Pre Owned
Schroeder, W. & Christensen, L. (2021, June 22). Certified Pre-Owned - Abusing Active Directory Certificate Services. Retrieved August 2, 2022.
Open source URL - [25]Microsoft Protected Users Security Group
Microsoft. (2016, October 12). Protected Users Security Group. Retrieved May 29, 2020.
Open source URL - [26]ADSecurity Mimikatz DCSync
Metcalf, S. (2015, September 25). Mimikatz DCSync Usage, Exploitation, and Detection. Retrieved August 7, 2017.
Open source URL - [27]Microsoft Replication ACL
Microsoft. (n.d.). How to grant the "Replicating Directory Changes" permission for the Microsoft Metadirectory Services ADMA service account. Retrieved December 4, 2017.
Open source URL - [28]ADSecurity Kerberos and KRBTGT
Sean Metcalf. (2014, November 10). Kerberos & KRBTGT: Active Directory’s Domain Kerberos Service Account. Retrieved January 30, 2020.
Open source URL - [29]STIG krbtgt reset
UCF. (n.d.). The password for the krbtgt account on a domain must be reset at least every 180 days. Retrieved November 5, 2020.
Open source URL - [30]STIG krbtgt reset
UCF. (n.d.). The password for the krbtgt account on a domain must be reset at least every 180 days. Retrieved November 5, 2020.
Open source URL - [31]Microsoft MS14-025
Microsoft. (2014, May 13). MS14-025: Vulnerability in Group Policy Preferences could allow elevation of privilege. Retrieved January 28, 2015.
- [32]Microsoft MS14-025
Microsoft. (2014, May 13). MS14-025: Vulnerability in Group Policy Preferences could allow elevation of privilege. Retrieved January 28, 2015.
- [33]STIG krbtgt reset
UCF. (n.d.). The password for the krbtgt account on a domain must be reset at least every 180 days. Retrieved November 5, 2020.
Open source URL - [34]Microsoft Protected Users Security Group
Microsoft. (2016, October 12). Protected Users Security Group. Retrieved May 29, 2020.
Open source URL - [35]Microsoft Replication ACL
Microsoft. (n.d.). How to grant the "Replicating Directory Changes" permission for the Microsoft Metadirectory Services ADMA service account. Retrieved December 4, 2017.
Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.