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
M1015: Active Directory Configuration describes 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 manag...
Executive priority
M1015: Active Directory Configuration is an official MITRE ATT&CK mitigation. Glexia treats it as defensive behavior context for prioritizing monitoring, control validation, and response planning without using the object by itself as an attribution claim.
Technical view
Security teams should validate M1015: Active Directory Configuration by reviewing the official ATT&CK relationships, mapped tactics (the mapped ATT&CK tactic context), supported platforms (the platforms named in the official object), and available local telemetry before making detection or mitigation decisions.
Likely telemetry
- Official ATT&CK relationships and object metadata
Detection direction
- Validate whether M1015: Active Directory Configuration appears in your detection coverage and tabletop scenarios.
- Use the object to align executive risk language with SOC, incident response, and detection engineering work.
- Do not treat ATT&CK relationship context as attribution without corroborating evidence.
Mitigation priorities
- Map the object to existing controls and identify missing telemetry or response ownership.
- Prioritize mitigations that reduce exposure on the listed platforms and tactics.
- Review adjacent ATT&CK relationships before changing policy, detections, or reporting language.
Additional notes and limits
Baseline Glexia take generated from the official MITRE ATT&CK STIX object, source hash, tactics, platforms, and detection fields. It is safe to replace with a richer model-generated take for the same source hash later.
This baseline take is source-grounded and schema-validated, but it does not include environment-specific telemetry, incident evidence, or threat-intelligence corroboration.
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 | 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.CitationMicrosoft MS14-025 |
| 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. CitationMicrosoft Trust Considerations Nov 2014 CitationMicrosoft SID Filtering Quarantining Jan 2009 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: CitationMicrosoft Netdom Trust Sept 2012 * 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. CitationMicrosoft Netdom Trust Sept 2012 CitationAdSecurity Kerberos GT Aug 2015 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.CitationMandiant Defend UNC2452 White Paper |
| 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.CitationMicrosoft Protected Users Security Group |
| Enterprise | T1550 | Use Alternate Authentication Material | Configure Active Directory to prevent use of certain techniques; use SID Filtering, etc. |
| Enterprise | T1552.006 | Group Policy PreferencesSub-technique | Remove vulnerable Group Policy Preferences.CitationMicrosoft MS14-025 |
| Enterprise | T1078 | Valid Accounts | Disable legacy authentication, which does not support MFA, and require the use of modern authentication protocols instead. |
| 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.CitationADSecurity Kerberos and KRBTGT 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.CitationSTIG krbtgt reset |
| 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.CitationSTIG krbtgt reset |
| 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.CitationSpecterOps Certified Pre Owned Also consider enforcing CA Certificate Manager approval for the templates that include SAN as an issuance requirement. |
| 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.CitationSTIG krbtgt reset |
| Enterprise | T1003.006 | DCSyncSub-technique | Manage the access control list for "Replicating Directory Changes" and other permissions associated with domain controller replication.CitationADSecurity Mimikatz DCSyncCitationMicrosoft Replication ACL |
| Enterprise | T1003 | OS Credential Dumping | Manage the access control list for “Replicating Directory Changes All” and other permissions associated with domain controller replication. CitationAdSecurity DCSync Sept 2015 CitationMicrosoft Replication ACL Consider adding users to the "Protected Users" Active Directory security group. This can help limit the caching of users' plaintext credentials.CitationMicrosoft Protected Users Security Group |
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(2)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.2 | 1.2 | Current bundle | 4111bf5707a0… | ||
| 19.1 | 1.2 | Older 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]mitre-attackM1015Open 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.