Accounts security posture assessments

Identify service accounts in privileged groups

Description

Lists Active Directory service accounts within your environment that are members of privileged groups, including direct and nested membership.

User impact

Service accounts often have long-lived credentials and are used by applications, scripts, or automated tasks. When these accounts are members of highly privileged groups (for example, Domain Admins or Enterprise Admins), they increase the organization’s attack surface. Compromise of one of these accounts can grant an attacker broad administrative access to critical systems and data. Additionally, because service accounts aren't tied to a specific user and often lack interactive monitoring, malicious activity performed under these accounts might go unnoticed, delaying detection and response.

Implementation

1. Review the exposed entities to identify Active Directory service accounts that are members of privileged groups, such as Domain Admins, Enterprise Admins, or Administrators.

2. Remove the account from the privileged group if elevated access isn't required, or disable the account if it's unused.

For example:

• Unused or decommissioned service account:

  • Disable the account in Active Directory after confirming no recent logons or dependencies.

  • Monitor for a short period (7–14 days). If inactive, delete it according to your policy.

• Active service account without need for admin rights:

  • Remove it from the privileged group as exposed on the report.

  • Grant only the minimal required access through delegated permissions or scoped security groups.

• Replace legacy accounts:

  • Migrate service accounts to Group Managed Service Accounts (gMSA) for automatic password rotation and reduced credential exposure.

• Accounts that must stay privileged

  • Restrict where they can log on using the Log on to property.

  • Limit interactive logons via Group Policy and enable focused auditing for their activity.

  • Require ownership, documentation, and periodic review of the privileged membership.

Locate accounts in built-in Operator Groups

Description

Lists Active Directory accounts (users, service accounts, and groups) that are members of built-in operator groups such as Server Operators, Backup Operators, Print Operators or Account Operators, including direct and indirect membership. These groups grant elevated privileges that can be used to compromise ___domain controllers or sensitive servers.

User impact

Operator groups provide broad control over servers, files, and system operations. Members of these groups can perform administrative actions such as stopping critical services, modifying files, or restoring data which can be exploited to escalate privileges or gain persistence. Because these groups are rarely needed in modern environments, leaving accounts in them unnecessarily increases the risk of privilege abuse or lateral movement.

Implementation

1. Review the list of exposed entities to identify which of your AD accounts are members of one of the built-in operator groups (for example, Server Operators, Backup Operators, Print Operators, and Account Operators).

2. Remove the account from the operator group if elevated access isn't required, or disable the account if it's unused.

For example:

• Remove the membership or disable service or admin account that were added to Backup Operators for a legacy backup process that no longer runs.

• If an account still performs operational tasks but doesn't require broad operator rights, delegate only the specific permissions it needs (for example, file restore or print management on a single server).

• If operator group membership is essential for a specific administrative function, monitor the account, restrict it to required hosts, and review it regularly periodically to confirm ongoing necessity.

Accounts with non-default Primary Group ID

Description

This recommendation lists all computers and users accounts whose primaryGroupId (PGID) attribute isn't the default for ___domain users and computers in Active Directory.

User impact

The primaryGroupId attribute of a user or computer account grants implicit membership to a group. Membership through this attribute doesn't appear in the list of group members in some interfaces. This attribute might be used as an attempt to hide group membership. It might be a stealthy way for an attacker to escalate privileges without triggering normal auditing for group membership changes. 

Implementation

1. Review the list of exposed entities to discover which of your accounts have a suspicious primaryGroupId.  

2. Take appropriate action on those accounts by resetting their attribute to their default values or adding the member to the relevant group:  

• User accounts: 513 (Domain Users) or 514 (Domain Guests);  

• Computer accounts: 515 (Domain Computers);  

• Domain controller accounts: 516 (Domain Controllers);  

• Read-only ___domain controller (RODC) accounts: 521 (Read-only Domain Controllers).

Remove access rights on suspicious accounts with the Admin SDHolder permission

Description

Having non-sensitive accounts with Admin SDHolder (security descriptor holder) permissions can have significant security implications, including:

• Leading to unauthorized privilege escalation, where attackers can exploit these accounts to gain administrative access and compromise sensitive systems or data
• Increasing the attack surface, making it harder to track and mitigate security incidents, potentially exposing the organization to greater risks.

Implementation

1. Review the recommended action at https://security.microsoft.com/securescore?viewid=actions for Remove access rights on suspicious accounts with the Admin SDHolder permission.

   For example:

   

2. Review the list of exposed entities to discover which of your non-sensitive accounts have the Admin SDHolder permission.

3. Take appropriate action on those entities by removing their privileged access rights. For example:

   1. Use the ADSI Edit tool to connect to your ___domain controller.
   2. Browse to the CN=System> CN=AdminSDHolder container and open the CN=AdminSDHolder container properties.
   3. Select the Security tab > Advanced, and remove any non-sensitive entities. These are the entities marked as exposed in the security assessment.

   For more information, see Active Directory Service Interfaces and ADSI Edit documentation

To achieve the full score, remediate all exposed entities.

Change password for krbtgt account

Description

This recommendation lists any krbtgt account within your environment with password last set over 180 days ago.

User impact

The krbtgt account in Active Directory is a built-in account used by the Kerberos authentication service. It encrypts and signs all Kerberos tickets, enabling secure authentication within the ___domain. The account can't be deleted, and securing it's crucial, as compromise could allow attackers to forge authentication tickets.
If the KRBTGT account's password is compromised, an attacker can use its hash to generate valid Kerberos authentication tickets, allowing them to perform Golden Ticket attacks and gain access to any resource in the AD ___domain. Since Kerberos relies on the KRBTGT password to sign all tickets, closely monitoring and regularly changing this password is essential to mitigating the risk of such attacks.

Implementation

1. Review the list of exposed entities to discover which of your krbtgt accounts have an old password.

2. Take appropriate action on those accounts by resetting their password twice to invalidate the Golden Ticket attack. 

Change password of built-in ___domain Administrator account

Description

This recommendation lists any built-in ___domain Administrator accounts within your environment with password last set over 180 days ago. 

User impact

The built-in ___domain Administrator account is a default, highly privileged AD account with full control over the ___domain. It can't be deleted, has unrestricted access, and is critical for managing the ___domain's resources.

Regularly updating the built-in Administrator account's password is essential due to its high privileges, which make it a prime target for attackers. If compromised, it can grant unauthorized control over the ___domain. Since this account is often unused and its password may not be updated frequently, regular changes reduce exposure and enhance security. 

Implementation

1. Review the list of exposed entities to discover which of your built-in ___domain Administrator accounts have an old password.  

2. Take appropriate action on those accounts by resetting their password.  

   For example:

Dormant entities in sensitive groups

Description

Microsoft Defender for Identity discovers if particular users are sensitive along with providing attributes that surface if they're inactive, disabled, or expired.

However, Sensitive accounts can also become dormant if they aren't used for a period of 180 days. Dormant sensitive entities are targets of opportunity for malicious actors to gain sensitive access to your organization.

For more information, see Defender for Identity entity tags in Microsoft Defender XDR.

User impact

Organizations that fail to secure their dormant user accounts leave the door unlocked to their sensitive data safe.

Malicious actors, much like thieves, often look for the easiest and quietest way into any environment. An easy and quiet path deep into your organization is through sensitive user and service accounts that are no longer in use.

It doesn't matter if the cause is employee turnover or resource mismanagement -skipping this step leaves your organization's most sensitive entities vulnerable and exposed.

Implementation

1. Review the recommended action at https://security.microsoft.com/securescore?viewid=actions to discover which of your sensitive accounts are dormant.

   

2. Take appropriate action on those user accounts by removing their privileged access rights or by deleting the account.

Remove non-admin accounts with DCSync permissions

Description

Accounts with the DCSync permission can initiate ___domain replication. Attackers can potentially exploit ___domain replication to gain unauthorized access, manipulate ___domain data, or compromise the integrity and availability of your Active Directory environment.

It's crucial to carefully manage and restrict the membership of this group to ensure the security and integrity of your ___domain replication process.

Implementation

1. Review the recommended action at https://security.microsoft.com/securescore?viewid=actions for Remove non-admin accounts with DCSync permissions.

   

2. Review this list of exposed entities to discover which of your accounts have DCSync permissions and are also nondomain admins.

3. Take appropriate action on those entities by removing their privileged access rights.

To achieve the maximum score, remediate all exposed entities.

Ensure privileged accounts are not delegated

Description

This recommendation lists all privileged accounts that don't have the "not delegated" setting enabled, highlighting those potentially exposed to delegation-related risks. Privileged accounts are accounts that are being members of a privileged group such as Domain admins, Schema admins, and so on. 

User impact

If the sensitive flag is disabled, attackers could exploit Kerberos delegation to misuse privileged account credentials, leading to unauthorized access, lateral movement, and potential network-wide security breaches. Setting the sensitive flag on privileged user accounts prevent users from gaining access to the account and manipulating system settings.
For device accounts, setting them to "not delegated" is important to prevent it from being used in any delegation scenario, ensuring that credentials on this machine can't be forwarded to access other services.

Implementation

1. Review the list of exposed entities to discover which of your privileged accounts don’t have the configuration flag "this account is sensitive and can't be delegated."

2. Take appropriate action on those accounts:

• For user accounts: by setting the account's control flags to "this account is sensitive and can't be delegated." Under the Account tab, select the check box to this flag in the Account Options section. This prevents users from gaining access to the account and manipulating system settings.  

  

• For device accounts:
  The safest approach is to use a PowerShell script to configure the device to prevent it from being used in any delegation scenario, ensuring that credentials on this machine can't be forwarded to access other services.

  $name = "ComputerA" 
  Get-ADComputer -Identity $name |
  Set-ADAccountControl -AccountNotDelegated:$true
  

  Another option is to set the UserAccountControl attribute to NOT_DELEGATED = 0x100000 under the Attribute Editor tab for the exposed device.

  For example:

  

Entities exposing credentials in clear text

Description

This security assessment monitors your traffic for any entities exposing credentials in clear text and alerts you to the current exposure risks (most impacted entities) in your organization with suggested remediation.

User impact

Entities exposing credentials in clear text are risky not only for the exposed entity in question, but for your entire organization.

The increased risk is because unsecure traffic such as LDAP simple-bind is highly susceptible to interception by attacker-in-the-middle attacks. These types of attacks result in malicious activities including credential exposure, in which an attacker can leverage credentials for malicious purposes.

Implementation

1. Review the recommended action at https://security.microsoft.com/securescore?viewid=actions.

   

   

2. Research why those entities are using LDAP in clear text.

3. Remediate the issues and stop the exposure.

4. After confirming remediation, we recommend you require ___domain controller level LDAP signing. To learn more about LDAP server signing, see Domain controller LDAP server signing requirements.

Microsoft LAPS usage

Description

Microsoft's "Local Administrator Password Solution" (LAPS) provides management of local administrator account passwords for ___domain-joined computers. Passwords are randomized and stored in Active Directory (AD), protected by ACLs, so only eligible users can read it or request its reset.

This security assessment supports legacy Microsoft LAPS and Windows LAPS.

User impact

LAPS provides a solution to the issue of using a common local account with an identical password on every computer in a ___domain. LAPS resolves this issue by setting a different, rotated random password for the common local administrator account on every computer in the ___domain.

LAPS simplifies password management while helping customers implement more recommended defenses against cyberattacks. In particular, the solution mitigates the risk of lateral escalation that results when customers use the same administrative local account and password combination on their computers. LAPS stores the password for each computer's local administrator account in AD, secured in a confidential attribute in the computer's corresponding AD object. The computer can update its own password data in AD, and ___domain administrators can grant read access to authorized users or groups, such as workstation helpdesk administrators.

Implementation

1. Review the recommended action at https://security.microsoft.com/securescore?viewid=actions to discover which of your domains have some (or all) compatible Windows devices that aren't protected by LAPS, or that haven't had their LAPS managed password changed in the last 60 days.

   

2. For domains that are partially protected, select the relevant row to view the list of devices not protected by LAPS in that ___domain.

   

3. Take appropriate action on those devices by downloading, installing, and configuring or troubleshooting Microsoft LAPS or Windows LAPS.

   

Remove discoverable passwords in Active Directory account attributes (Preview)

Description

Certain free-text attributes are often overlooked during hardening but are readable by any authenticated user in the ___domain. When credentials or clues are mistakenly stored in these attributes, attackers can abuse them to move laterally across the environment or escalate privileges.

Attackers seek low-friction paths to expand access. Exposed passwords in these attributes represent an easy win because:

• The attributes aren't access-restricted.

• They aren't monitored by default.

• They provide context attackers can exploit for lateral movement and privilege escalation.

Removing exposed credentials from these attributes reduces the risk of identity compromise and strengthens your organization’s security posture.

Microsoft Defender for Identity detects potential credential exposure in Active Directory by analyzing commonly used free-text attributes. This includes looking for common password formats, hints, 'description', 'info', and 'adminComment' fields, and other contextual clues that might suggest the presence of credential misuse. This recommendation uses GenAI-powered analysis of Active directory attributes to detect:

• Plaintext passwords or variations. For example, 'Password=Summer2025!'

• Credential patterns, reset hints, or sensitive account information.

• Other indicators suggesting operational misuse of directory fields.

Detected matches are surfaced in Secure Score and the Security Assessment report for review and remediation.

Implementation

To address this security assessment, follow these steps:

1. Review the recommended action at https://security.microsoft.com/securescore?viewid=actions for Remove discoverable passwords in Active Directory account attributes.

2. Review the exposed entries in the security report. Identify any field content that includes:

   • Cleartext passwords

   • Reset instructions or credential clues

   • Sensitive business or system information

3. Remove sensitive information from the listed attribute fields using standard directory management tools (for example, PowerShell or ADSI Edit).

4. Fully remove the sensitive information. Don’t just mask the value. Partial obfuscation (for example, P@ssw***) can still offer useful clues to attackers.

Remove Stale Service Accounts (Preview)

Description

This recommendation lists Active Directory service accounts detected as stale within the past 90 days.

User impact

Unused service accounts create significant security risks, as some of them can carry elevated privileges. If attackers gain access, the result can be substantial damage. Stale service accounts might retain high or legacy permissions. When compromised, they provide attackers with discreet entry points into critical systems, granting far more access than a standard user account.

This exposure creates several risks:

• Unauthorized access to sensitive applications and data.

• Lateral movement across the network without detection.

Implementation

To use this security assessment effectively, follow these steps:

1. Review the recommended action at https://security.microsoft.com/securescore?viewid=actions  for Remove stale service account.

2. Review the list of exposed entities to discover which of your service accounts are stale and haven't performed any login activity in the last 90 days.

3. Take appropriate actions on those entities by removing the service account. For example:

   • Disable the account: Prevent any usage by disabling the account identified as exposed.

   • Monitor for impact: Wait several weeks and monitor for operational issues, such as service disruptions or errors.

   • Delete the account: If no issues are observed, delete the account and fully remove its access.

Riskiest lateral movement paths (LMP)

Description

Microsoft Defender for Identity continuously monitors your environment to identify sensitive accounts with the riskiest lateral movement paths that expose a security risk, and reports on these accounts to assist you in managing your environment. Paths are considered risky if they have three or more non-sensitive accounts that can expose the sensitive account to credential theft by malicious actors.

For more information about lateral movement paths, see:

• Understand and investigate Lateral Movement Paths (LMPs) with Microsoft Defender for Identity
• MITRE ATT&CK Lateral Movement

User impact

Organizations that fail to secure their sensitive accounts leave the door unlocked for malicious actors.

Malicious actors, much like thieves, often look for the easiest and quietest way into any environment. Sensitive accounts with risky lateral movement paths are windows of opportunities for attackers and can expose risks.

For example, the riskiest paths are more readily visible to attackers and, if compromised, can give an attacker access to your organization's most sensitive entities.

Implementation

1. Review the recommended action at https://security.microsoft.com/securescore?viewid=actions to discover which of your sensitive accounts have risky LMPs.

   

2. Take appropriate action:

   • Remove the entity from the group as specified in the recommendation.
   • Remove the local administrator permissions for the entity from the device specified in the recommendation.

Unsecure Kerberos delegation

Description

Kerberos delegation is a delegation setting that allows applications to request end-user access credentials to access resources on behalf of the originating user.

User impact

Unsecure Kerberos delegation gives an entity the ability to impersonate you to any other chosen service. For example, imagine you have an IIS website, and the application pool account is configured with unconstrained delegation. The IIS website site also has Windows Authentication enabled, allowing native Kerberos authentication, and the site uses a back-end SQL Server for business data. With your Domain Admin account, you browse to the IIS website and authenticate to it. The website, using unconstrained delegation can get a service ticket from a ___domain controller to the SQL service, and do so in your name.

The main issue with Kerberos delegation is that you need to trust the application to always do the right thing. Malicious actors can instead force the application to do the wrong thing. If you're logged on as ___domain admin, the site can create a ticket to whatever other services it wishes, acting as you, the ___domain admin. For example, the site could choose a ___domain controller, and make changes to the enterprise admin group. Similarly, the site could acquire the hash of the KRBTGT account, or download an interesting file from your Human Resources department. The risk is clear and the possibilities with unsecure delegation are nearly endless.

The following is a description of the risk posed by different delegation types:

• Unconstrained delegation: Any service can be abused if one of their delegation entries is sensitive.
• Constrained delegation: Constrained entities can be abused if one of their delegation entries is sensitive.
• Resource-based constrained delegation (RBCD): Resource-based constrained entities can be abused if the entity itself is sensitive.

Implementation

1. Review the recommended action at https://security.microsoft.com/securescore?viewid=actions to discover which of your non-___domain controller entities are configured for unsecure Kerberos delegation.

   

2. Take appropriate action on those at-risk users, such as removing their unconstrained attribute or changing it to a more secure constrained delegation.

3. Use the remediation appropriate to your delegation type.

4. Disable delegation or use one of the following Kerberos constrained delegation (KCD) types:

Unconstrained delegation

1. Select Trust this computer for delegation to specified services only.

2. Specify the Services to which this account can present delegated credentials.

Constrained delegation

Restricts which services this account can impersonate.

1. Review the sensitive users listed in the recommendations and remove them from the services to which the affected account can present delegated credentials.

   

Resource-based constrained delegation (RBCD)

Resource-based constrained delegation restricts which entities can impersonate this account. Resource-based KCD is configured using PowerShell.

1. You can use the Set-ADComputer or Set-ADUser cmdlets, depending on whether the impersonating account is a computer account or a user account / service account.

2. Review the sensitive users listed in the recommendations and remove them from the resource. For more information about configuring RBCD, see Configure Kerberos constrained delegation (KCD) in Microsoft Entra Domain Services.

Unsecure SID History attributes

Description

SID History is an attribute that supports migration scenarios. Every user account has an associated Security IDentifier (SID) which is used to track the security principal and the access the account has when connecting to resources. SID History enables access for another account to effectively be cloned to another and is extremely useful to ensure users retain access when moved (migrated) from one ___domain to another.

The assessment checks for accounts with SID History attributes which Microsoft Defender for Identity profiles to be risky.

User impact

Organizations that fail to secure their account attributes leave the door unlocked for malicious actors.

Malicious actors, much like thieves, often look for the easiest and quietest way into any environment. Accounts configured with an unsecure SID History attribute are windows of opportunities for attackers and can expose risks.

For example, a non-sensitive account in a ___domain can contain the Enterprise Admin SID in its SID History from another ___domain in the Active Directory forest, thus "elevating" access for the user account to an effective Domain Admin in all domains in the forest. Also, if you have a forest trust without SID Filtering enabled (also called Quarantine), it's possible to inject a SID from another forest and it will be added to the user token when authenticated and used for access evaluations.

Implementation

1. Review the recommended action at https://security.microsoft.com/securescore?viewid=actions to discover which of your accounts have an unsecure SID History attribute.

   

2. Take appropriate action to remove SID History attribute from the accounts using PowerShell using the following steps:

   1. Identify the SID in the SIDHistory attribute on the account.

      Get-ADUser -Identity <account> -Properties SidHistory | Select-Object -ExpandProperty SIDHistory
      

   2. Remove the SIDHistory attribute using the SID identified earlier.

      Set-ADUser -Identity <account> -Remove @{SIDHistory='S-1-5-21-...'}
      

Unsecure account attributes

Description

Microsoft Defender for Identity continuously monitors your environment to identify accounts with attribute values that expose a security risk, and reports on these accounts to assist you in protecting your environment.

User impact

Organizations that fail to secure their account attributes leave the door unlocked for malicious actors.

Malicious actors, much like thieves, often look for the easiest and quietest way into any environment. Accounts configured with unsecure attributes are windows of opportunity for attackers and can expose risks.

For example, if the PasswordNotRequired attribute is enabled, an attacker can easily access the account. This is especially risky if the account has privileged access to other resources.

Implementation

1. Review the recommended action at https://security.microsoft.com/securescore?viewid=actions to discover which of your accounts have unsecure attributes.

   

2. Take appropriate action on those user accounts by modifying or removing the relevant attributes.

3. Use the remediation appropriate to the relevant attribute as described in the following table:

4. Use the UserAccountControl (UAC) flag to manipulate user account profiles. For more information, see:

   • Windows Server troubleshooting documentation.
   • User Properties - Account Section
   • Introduction to Active Directory Administrative Center Enhancements (Level 100)
   • Active Directory Administration Center

Next steps

• Learn more about Microsoft Secure Score
• Check out the Defender for Identity forum!