Author: thalpius

Identity leverages Secure Score with twenty-seven recommended actions. In a series of blog posts, I will go through all twenty-seven recommended actions and what they mean, a plan of approach, their impact, and my security recommendations, hopefully helping others. The twenty-seven  one in the series is the “Ensure that all privileged accounts have the configuration flag” recommended action.

Introduction

You have twenty-seven recommendations if you filter the Secure Score recommended actions for Microsoft Defender for Identity.

• Resolve unsecure domain configurations
• Resolve unsecure account attributes
• Remove dormant accounts from sensitive groups
• Protect and manage local admin passwords with Microsoft LAPS
• Configure VPN integration
• Reduce lateral movement path risk to sensitive entities
• Stop clear text credentials exposure
• Disable Print spooler service on domain controllers
• Stop weak cipher usage
• Remove unsecure SID history attributes from entities
• Modify unsecure Kerberos delegations to prevent impersonation
• Install Defender for Identity Sensor on all Domain Controllers
• Set a honeytoken account
• Start your Defender for Identity deployment, installing Sensors on DC’s and other eligible servers
• Accounts with non-default Primary Group ID
• Change Domain Controller computer account old password
• Reversible passwords found in GPOs
• Unsafe permissions on the DnsAdmins group
• GPO assigns unprivileged identities to local groups with elevated privileges
• Remove access rights on suspicious accounts with the Admin SDHolder permission
• Remove local admins on identity assets
• Remove non-admin accounts with DCSync permissions
• GPO can be modified by unprivileged accounts
• Built-in Active Directory Guest account is enabled
• Change password for krbtgt account
• Change password of built-in domain Administrator account
• Ensure that all privileged accounts have the configuration flag

Some recommended actions are easy to configure, but others require time, proper planning, auditing, and expertise. This blog post will review the recommended action of “Ensure that all privileged accounts have the configuration flag.”

Update: Microsoft keeps updating the recommended actions list. I will do my best to keep the list up-to-date.

Configuration Flag

Kerberos delegation is a powerful feature in Active Directory that enables services and applications to authenticate to other resources on behalf of users. When properly implemented, delegation allows multi-tier applications to seamlessly pass user credentials through service layers, maintaining the user’s security context while accessing backend resources like databases or file shares. However, when privileged accounts are configured to allow delegation, this functional capability transforms into a critical security vulnerability that can be exploited to compromise your entire domain infrastructure.

Understanding the mechanics of Kerberos delegation is essential to recognizing why privileged accounts require special protection. When a user authenticates to a service that has delegation enabled, the service receives credentials that can be used to impersonate that user when accessing other services. In normal scenarios with standard user accounts, this impersonation is limited to the permissions of that particular user. However, when the authenticated user is a member of privileged groups such as Domain Admins, Enterprise Admins, or Schema Admins, the service gains the ability to impersonate these highly privileged accounts, effectively granting the service’s security context administrative access across your domain.

The security implications of allowing delegation on privileged accounts are severe and far-reaching. If an attacker compromises a service or application that has access to delegated credentials from privileged accounts, they inherit all the permissions associated with those accounts. This means that a vulnerability in a web application, a misconfiguration in a service account, or even a legitimate service that has been subverted can become a pathway for attackers to obtain Domain Admin credentials. The attack surface expands significantly because the attacker no longer needs to directly compromise the privileged account itself, they simply need to compromise any service or system where that privileged account has authenticated and allowed delegation.

Microsoft Defender for Identity specifically identifies privileged accounts that lack the critical protection setting known as “Account is sensitive and cannot be delegated.” This flag, when enabled, instructs Active Directory to prevent the account’s credentials from being delegated to any service, regardless of that service’s delegation configuration. Without this protection, your most powerful administrative accounts remain vulnerable to credential theft through delegation abuse. The recommendation applies to both user accounts that are members of privileged groups and computer accounts that should be protected from delegation scenarios, ensuring that credentials stored on these machines cannot be forwarded to access other services.

The challenge many organizations face is that privileged accounts are often configured without this protection by default, and the security implications of delegation are not immediately apparent during routine Active Directory management. Administrators may create accounts, add them to privileged groups for legitimate administrative purposes, and never consider the delegation settings because delegation is perceived as a feature meant for service accounts and applications rather than a security risk for administrative accounts. This oversight creates an invisible attack vector where privileged credentials can be harvested from memory on systems running services with delegation enabled, particularly when those privileged accounts authenticate to those systems for legitimate administrative tasks.

The Risk of Allowing Privileged Account Delegation

Failing to configure the “Account is sensitive and cannot be delegated” setting on privileged accounts creates one of the most exploitable vulnerabilities in Active Directory environments. When privileged accounts are permitted to be delegated, you are essentially allowing any service or application to which these accounts authenticate to inherit their full administrative permissions, creating multiple pathways for attackers to escalate privileges and compromise your domain.

The primary threat associated with delegated privileged accounts is credential theft through service compromise. When a Domain Admin or Enterprise Admin authenticates to a server running a service configured for delegation, the service receives credentials that can impersonate that administrator. If an attacker has compromised that service through application vulnerabilities, misconfigurations, or malicious code injection, they can extract those delegated credentials from memory and use them to authenticate to any resource in your domain with full administrative rights. This attack vector is particularly dangerous because it does not require the attacker to directly compromise the administrator’s workstation or crack their password, they simply need to compromise any service where the administrator has authenticated.

The scope of this vulnerability extends beyond obvious service accounts and applications. Any system where delegation is enabled becomes a potential credential harvesting point for privileged accounts. This includes web servers running internal administrative portals, database servers accessed by administrative tools, file servers where administrators manage permissions, and even workstations where services run under the local system context with delegation capabilities. Each of these systems represents a potential compromise point where an attacker can lie in wait for a privileged account to authenticate, capture the delegated credentials, and then pivot to domain-wide access.

What makes this risk particularly insidious is the difficulty in detecting abuse of delegated credentials. When an attacker uses legitimately delegated credentials to access resources, the authentication appears entirely normal to security monitoring systems. The Kerberos tickets are valid, properly signed by the domain controller, and appear to originate from the privileged account itself. Traditional security monitoring that focuses on unusual login patterns, failed authentication attempts, or suspicious account behavior may completely miss this attack vector because the authentication is technically legitimate from Active Directory’s perspective. The only indication of compromise might be unusual service behavior or unexpected resource access patterns that require deep investigation to uncover.

The lateral movement opportunities created by unsecured privileged account delegation are virtually unlimited. Once an attacker obtains delegated credentials from a Domain Admin account, they can access domain controllers directly, modify Active Directory objects including creating backdoor accounts, extract password hashes from the domain database, modify Group Policy to establish persistence, and access any system or data in the domain without restriction. The attacker effectively becomes indistinguishable from a legitimate domain administrator, making remediation extremely difficult because standard administrative actions and malicious activities generate identical audit trails.

Computer accounts configured without delegation protection present an equally serious but often overlooked risk. When privileged users authenticate to servers or workstations that lack the “not delegated” setting, those systems can forward the captured credentials to other services. This is particularly problematic for jump servers, administrative workstations, or privileged access workstations where administrators routinely authenticate with elevated credentials. If these systems are compromised or misconfigured, they become credential relay points that attackers can exploit to harvest administrative credentials and move laterally across your network without triggering typical security alerts.

The persistence of this vulnerability is another critical concern. Unlike password-based attacks where changing credentials can immediately revoke attacker access, delegation abuse can continue as long as the privileged account remains configured to allow delegation. Even if you detect and remediate an initial service compromise, attackers who have already captured delegated credentials can continue to use them until their Kerberos tickets expire, which could be hours or even days depending on your environment’s ticket lifetime policies. Without fixing the underlying delegation configuration on the privileged accounts themselves, the vulnerability remains exploitable in future attacks.

Organizations often compound this risk through common administrative practices that inadvertently maximize delegation exposure. Using a single privileged account for multiple administrative tasks across different systems, authenticating with Domain Admin credentials to perform routine server maintenance, or allowing privileged accounts to log into member servers rather than exclusively accessing domain controllers all increase the number of systems where delegated credentials might be captured. Each additional authentication point multiplies the attack surface and provides more opportunities for attackers to harvest privileged credentials through delegation abuse.

Mitigating the Risk Through Proper Delegation Controls

Protecting privileged accounts from delegation abuse requires implementing specific account controls that prevent their credentials from being forwarded to services, regardless of how those services are configured. The primary mitigation is enabling the “Account is sensitive and cannot be delegated” setting on all privileged user accounts and ensuring that privileged computer accounts are configured to block delegation scenarios. This protection must be applied systematically across all accounts that hold elevated privileges in your Active Directory environment.

For user accounts that are members of privileged groups such as Domain Admins, Enterprise Admins, Schema Admins, or any custom administrative groups with elevated permissions, the remediation process is straightforward. Open Active Directory Users and Computers, navigate to the account properties, select the Account tab, and locate the Account Options section. Within this section, enable the checkbox for “Account is sensitive and cannot be delegated.” This single setting immediately prevents the account’s credentials from being delegated to any service, effectively closing the credential theft pathway through delegation abuse. Once enabled, even if the privileged account authenticates to a service configured for delegation, Active Directory will refuse to provide delegated credentials to that service.

The approach for computer accounts requires a different implementation method because the user interface options differ from standard user accounts. Microsoft recommends using PowerShell to configure delegation protection for computer accounts, which provides precise control and can be easily scripted for bulk operations. The command Get-ADComputer -Identity "ComputerName" | Set-ADAccountControl -AccountNotDelegated:$true configures the specified computer account to prevent it from being used in any delegation scenario. This ensures that credentials stored on that machine cannot be forwarded to access other services, which is particularly important for jump servers, privileged access workstations, and any systems where administrators regularly authenticate with elevated credentials.

An alternative method for configuring computer account delegation protection involves directly modifying the UserAccountControl attribute through the Attribute Editor. Locate the computer account in Active Directory Users and Computers, open the properties, navigate to the Attribute Editor tab, and find the UserAccountControl attribute. Set this attribute to include the NOT_DELEGATED flag with the hexadecimal value 0x100000. While this method provides the same protection as the PowerShell approach, the command-line method is generally preferred for its clarity, auditability, and ease of automation across multiple accounts.

When reviewing Microsoft Defender for Identity’s recommendations, you will receive a list of exposed entities that includes all privileged accounts currently lacking delegation protection. Systematically work through this list, prioritizing accounts based on their privilege level and frequency of use. Accounts with Domain Admin or Enterprise Admin membership should be addressed immediately, followed by other privileged groups, and finally any computer accounts that serve as administrative jump points or privileged access workstations. Document each configuration change through your change management system to maintain an audit trail of security improvements.

It is essential to understand that enabling delegation protection on privileged accounts does not impact their normal administrative functions. These accounts will continue to authenticate successfully to domain controllers, member servers, and workstations. They can still perform all administrative tasks, manage Active Directory objects, modify Group Policy, and access resources according to their assigned permissions. The only functional change is that services can no longer impersonate these accounts to access other resources, which is precisely the behavior you want to prevent for security purposes. In the rare cases where legitimate delegation is actually required for a privileged account, this represents a significant security concern that should be carefully evaluated and likely addressed through alternative architectural approaches rather than weakening the delegation protection.

For organizations with large numbers of privileged accounts, implementing delegation protection should be approached as a systematic project rather than a one-time configuration change. Develop PowerShell scripts that can identify all members of privileged groups and automatically configure the delegation protection setting, then schedule these scripts to run regularly to catch newly created accounts or accounts that have been added to privileged groups. This automated approach ensures that delegation protection becomes a standard component of your privileged account lifecycle management rather than a manual configuration that might be overlooked during account provisioning.

Consider the broader context of privileged account security when implementing delegation controls. While preventing delegation is a critical protection, it should be combined with other security measures such as limiting the number of accounts with elevated privileges, implementing just-in-time administration where privileged access is granted only when needed and automatically revoked after use, restricting where privileged accounts can authenticate through authentication policies, and monitoring all privileged account activity for unusual behavior. Delegation protection is one layer in a comprehensive defense-in-depth strategy for securing administrative access to your Active Directory environment.

Regular auditing of delegation settings should become part of your ongoing security monitoring procedures. Even after initial remediation, periodically review your privileged accounts to ensure the delegation protection remains in place and has not been inadvertently removed during account modifications or administrative changes. Microsoft Defender for Identity will continue to monitor for accounts lacking this protection and surface them in security assessments, but implementing your own periodic validation through PowerShell scripts or compliance scanning tools provides an additional verification layer. Query Active Directory regularly for accounts that are members of privileged groups but lack the NOT_DELEGATED flag, and investigate any accounts that appear in these queries to determine whether they represent legitimate new administrative accounts that need protection or potential security gaps.

For computer accounts, pay particular attention to systems that serve as administrative jump points, bastion hosts, or privileged access workstations. These systems should always have delegation protection enabled because they are specifically designed to handle privileged credentials and represent high-value targets for attackers. Include delegation protection configuration as a mandatory step in your privileged access workstation deployment procedures, and verify this protection during security audits of administrative infrastructure. Any deviation from this standard should be treated as a security finding requiring immediate remediation.

Conclusion

Kerberos delegation, while designed as a legitimate feature for multi-tier application architectures, becomes a dangerous credential theft vector when privileged accounts are left unprotected. The “Account is sensitive and cannot be delegated” setting represents a critical security control that prevents your most powerful administrative credentials from being forwarded to services where they could be captured and exploited by attackers. This single configuration change effectively eliminates an entire class of privilege escalation attacks without impacting the normal administrative functions of these accounts.

Microsoft Defender for Identity’s recommendation to ensure privileged accounts are not delegated addresses a vulnerability that is both widespread and frequently overlooked in Active Directory environments. Many organizations focus on password policies, multi-factor authentication, and privileged access management while unknowingly leaving their Domain Admin and Enterprise Admin accounts vulnerable to delegation abuse. The remediation is straightforward, requiring only a simple checkbox for user accounts or a single PowerShell command for computer accounts, yet the security impact is substantial.

If your Defender for Identity assessment reveals privileged accounts without delegation protection, prioritize this remediation immediately. The combination of high privilege levels and delegation capabilities creates an optimal target for attackers seeking domain-wide access through service compromise rather than direct credential theft. Implement delegation controls systematically across all privileged accounts, incorporate this setting into your account provisioning procedures, and establish regular auditing to ensure this protection remains in place. By preventing delegation on privileged accounts, you are closing a critical attack pathway and significantly strengthening your Active Directory security posture against sophisticated adversaries who understand how to exploit Kerberos delegation for lateral movement and privilege escalation.

Identity leverages Secure Score with twenty-seven recommended actions. In a series of blog posts, I will go through all twenty-seven recommended actions and what they mean, a plan of approach, their impact, and my security recommendations, hopefully helping others. The twenty-sixth  one in the series is the “Change password of built-in domain Administrator account” recommended action.

Introduction

You have twenty-seven recommendations if you filter the Secure Score recommended actions for Microsoft Defender for Identity.

• Resolve unsecure domain configurations
• Resolve unsecure account attributes
• Remove dormant accounts from sensitive groups
• Protect and manage local admin passwords with Microsoft LAPS
• Configure VPN integration
• Reduce lateral movement path risk to sensitive entities
• Stop clear text credentials exposure
• Disable Print spooler service on domain controllers
• Stop weak cipher usage
• Remove unsecure SID history attributes from entities
• Modify unsecure Kerberos delegations to prevent impersonation
• Install Defender for Identity Sensor on all Domain Controllers
• Set a honeytoken account
• Start your Defender for Identity deployment, installing Sensors on DC’s and other eligible servers
• Accounts with non-default Primary Group ID
• Change Domain Controller computer account old password
• Reversible passwords found in GPOs
• Unsafe permissions on the DnsAdmins group
• GPO assigns unprivileged identities to local groups with elevated privileges
• Remove access rights on suspicious accounts with the Admin SDHolder permission
• Remove local admins on identity assets
• Remove non-admin accounts with DCSync permissions
• GPO can be modified by unprivileged accounts
• Built-in Active Directory Guest account is enabled
• Change password for krbtgt account
• Change password of built-in domain Administrator account
• Ensure that all privileged accounts have the configuration flag

Some recommended actions are easy to configure, but others require time, proper planning, auditing, and expertise. This blog post will review the recommended action of “Change password of built-in domain Administrator account.”

Update: Microsoft keeps updating the recommended actions list. I will do my best to keep the list up-to-date.

Change password of built-in domain Administrator account

The built-in domain Administrator account represents one of the most powerful and critical accounts in any Active Directory environment. Created automatically during domain installation, this default account possesses unrestricted access to every resource within the domain and holds full control over all domain management functions. Unlike other privileged accounts that can be created and deleted as needed, the built-in Administrator account is a permanent fixture in your Active Directory infrastructure that cannot be removed, making its security posture a fundamental concern for domain protection.

Understanding the unique characteristics of the built-in Administrator account is essential for maintaining a secure Active Directory environment. This account differs from other administrative accounts in several important ways. It carries the well-known Security Identifier (SID) ending in 500, making it easily identifiable to both legitimate administrators and potential attackers. The account maintains its privileged status regardless of group membership changes, and it cannot be locked out through failed login attempts, which is a feature designed to prevent accidental lockouts but also creates unique security considerations.

The security implications of the built-in Administrator account are significant precisely because of its elevated privileges and predictable nature. Attackers specifically target this account knowing that successful compromise grants them complete control over the domain and all its resources. The account’s inability to be deleted means that organizations cannot simply remove this potential attack vector, and its well-known SID makes it a consistent target across all Active Directory environments. These factors combine to make the built-in Administrator account one of the most attractive targets for attackers attempting to gain domain-wide access.

The Risk of Neglecting Built-in Administrator Password Rotation

What makes this account particularly vulnerable in many organizations is a common operational pattern where it is rarely used in day-to-day administration. Many organizations establish the built-in Administrator account password during initial domain setup and then create separate named administrator accounts for routine administrative tasks. While this practice of using named accounts is excellent for accountability and auditing purposes, it often leads to the built-in Administrator password remaining unchanged for extended periods, sometimes years. This creates a scenario where a highly privileged account with predictable credentials sits dormant in the environment, representing a significant security risk that is easily overlooked in routine security reviews.

Mitigating the Risk Through Regular Password Management

Protecting your Active Directory environment from attacks targeting the built-in domain Administrator account requires a disciplined approach to password management. Microsoft recommends that the built-in Administrator account password should be reset at least every 180 days to reduce the window of opportunity for attackers and minimize the risk of credential compromise. Organizations with heightened security requirements or those operating in high-risk environments should consider implementing even more frequent password rotations to further limit exposure.

The process of resetting the built-in Administrator account password is straightforward and can be accomplished through several methods. The most common approach is using Active Directory Users and Computers, where administrators can navigate to the Users container within the domain, locate the Administrator account, right-click and select Reset Password, then enter and confirm the new password. This simple procedure takes only minutes to complete but provides substantial security benefits by invalidating any previously compromised credentials and resetting the exposure timeline.

Unlike the KRBTGT account which requires a complex dual-reset procedure with waiting periods, the built-in Administrator account password can be changed in a single operation without concern for authentication disruptions. There is no need to wait between password changes or worry about replication timing, as the new password takes effect immediately across your domain controllers through normal Active Directory replication. This simplicity makes it even more important to establish and maintain a regular rotation schedule, as there are no technical barriers or operational complexities to prevent timely password updates.

When implementing your password rotation strategy, it is essential to consider how the new password will be securely stored and accessed. Many organizations use enterprise password management solutions or privileged access management systems to store the built-in Administrator password in an encrypted vault with strict access controls and comprehensive audit logging. This approach ensures that the password is available when needed for emergency recovery scenarios while maintaining tight security around who can access it and creating a clear audit trail of all password retrievals.

The password rotation process should be incorporated into your organization’s standard security maintenance procedures and documented in your change management system. Establish a clear schedule for rotation, assign responsibility for executing the password change to specific team members, and implement monitoring or alerting mechanisms to ensure the rotation occurs on schedule. When Microsoft Defender for Identity flags the built-in Administrator account password as exceeding 180 days, treat this as a priority remediation task rather than a routine suggestion. The effort required to reset the password is minimal, especially when compared to the potential impact of a compromised account with unrestricted domain access.

It is equally important to consider the broader security context around the built-in Administrator account beyond just password rotation. Ensure that the account is not being used for routine administrative tasks, as this increases the risk of credential exposure through everyday operations. Monitor the account for any unexpected authentication attempts or successful logins, as the built-in Administrator should typically remain dormant except for specific emergency recovery scenarios or planned maintenance activities.

For organizations discovering that their built-in Administrator password has not been changed in significantly longer than 180 days, immediate action is warranted. Prioritize this password reset as part of your security hardening efforts, and use the opportunity to establish formal procedures that will prevent this situation from recurring. Document the new password according to your organization’s secure storage procedures, communicate the change to relevant stakeholders who may need emergency access, and set calendar reminders or automated alerts to ensure future rotations occur within the recommended timeframe. By maintaining this discipline around built-in Administrator password management, you significantly reduce one of the most common and easily exploitable vulnerabilities in Active Directory environments.

Conclusion

The built-in domain Administrator account’s unrestricted privileges and permanent presence in your Active Directory environment make it a prime target for attackers. Microsoft Defender for Identity’s recommendation to reset this password every 180 days is a straightforward security control that directly reduces your organization’s exposure to credential-based attacks. Unlike the complex procedures required for KRBTGT password rotation, changing the built-in Administrator password is a simple operation that can be completed in minutes without risk of service disruption.

If your Defender for Identity assessment reveals that your built-in Administrator password has not been changed in over 180 days, treat this as an immediate priority. The minimal effort required to reset this password stands in stark contrast to the catastrophic impact of a compromised account with complete domain control. Establish a regular rotation schedule, implement secure password storage procedures, and ensure this critical security practice becomes part of your routine maintenance calendar. By maintaining discipline around built-in Administrator password management, you are closing one of the most commonly exploited vulnerabilities in Active Directory environments.

Identity leverages Secure Score with twenty-seven recommended actions. In a series of blog posts, I will go through all twenty-seven recommended actions and what they mean, a plan of approach, their impact, and my security recommendations, hopefully helping others. The twenty-fifth  one in the series is the “Change password for krbtgt account” recommended action.

Introduction

You have twenty-seven recommendations if you filter the Secure Score recommended actions for Microsoft Defender for Identity.

• Resolve unsecure domain configurations
• Resolve unsecure account attributes
• Remove dormant accounts from sensitive groups
• Protect and manage local admin passwords with Microsoft LAPS
• Configure VPN integration
• Reduce lateral movement path risk to sensitive entities
• Stop clear text credentials exposure
• Disable Print spooler service on domain controllers
• Stop weak cipher usage
• Remove unsecure SID history attributes from entities
• Modify unsecure Kerberos delegations to prevent impersonation
• Install Defender for Identity Sensor on all Domain Controllers
• Set a honeytoken account
• Start your Defender for Identity deployment, installing Sensors on DC’s and other eligible servers
• Accounts with non-default Primary Group ID
• Change Domain Controller computer account old password
• Reversible passwords found in GPOs
• Unsafe permissions on the DnsAdmins group
• GPO assigns unprivileged identities to local groups with elevated privileges
• Remove access rights on suspicious accounts with the Admin SDHolder permission
• Remove local admins on identity assets
• Remove non-admin accounts with DCSync permissions
• GPO can be modified by unprivileged accounts
• Built-in Active Directory Guest account is enabled
• Change password for krbtgt account
• Change password of built-in domain Administrator account
• Ensure that all privileged accounts have the configuration flag

Some recommended actions are easy to configure, but others require time, proper planning, auditing, and expertise. This blog post will review the recommended action of “Change password for krbtgt account.”

Update: Microsoft keeps updating the recommended actions list. I will do my best to keep the list up-to-date.

Active Directory KRBTGT account

The KRBTGT account in Active Directory is a built-in account that serves as the foundation of Kerberos authentication within your domain. This special account is responsible for encrypting and signing all Kerberos tickets, which enables secure authentication across your entire Active Directory environment. Unlike regular user accounts, the KRBTGT account cannot be deleted, making it a permanent fixture in your domain’s security infrastructure.

Understanding the critical role of the KRBTGT account is essential for maintaining a secure Active Directory environment. Every time a user authenticates to your domain, they receive a Ticket Granting Ticket (TGT) that is encrypted and signed using the KRBTGT account’s password hash. This means that the KRBTGT account essentially holds the keys to your entire authentication system. If an attacker compromises the KRBTGT account’s password, they can forge valid Kerberos tickets at will, granting themselves access to any resource in your domain through what is known as a Golden Ticket attack.

The security implications of a compromised KRBTGT account are severe. Because Kerberos relies entirely on the KRBTGT password to sign all authentication tickets, an attacker with access to this password hash can create tickets that appear completely legitimate to your domain controllers and other systems. These forged tickets can grant administrative access to any resource, persist even after passwords are changed, and remain valid until the KRBTGT password is properly rotated. This is precisely why closely monitoring the KRBTGT account and regularly rotating its password is one of the most critical security practices for Active Directory environments.

The Risk of Neglecting KRBTGT Password Rotation

Failing to regularly change the KRBTGT account password creates a significant and persistent security vulnerability in your Active Directory environment. When the KRBTGT password remains unchanged for extended periods, particularly beyond 180 days, you are essentially leaving a master key exposed that could grant attackers unlimited access to your entire domain.

The primary threat associated with an outdated KRBTGT password is the Golden Ticket attack. If an attacker manages to compromise the KRBTGT account’s password hash through methods such as domain controller compromise, credential dumping, or other attack vectors, they gain the ability to forge Kerberos Ticket Granting Tickets that your domain will accept as legitimate. These forged tickets are extraordinarily dangerous because they allow attackers to impersonate any user in your domain, including domain administrators, and access any resource without restriction.

What makes this threat particularly insidious is its persistence and stealth. Golden Tickets created with a compromised KRBTGT password hash remain valid until that password is changed, meaning an attacker could maintain access to your environment for months or even years if the password is never rotated. These forged tickets do not require the attacker to maintain a foothold on compromised systems, they do not trigger typical authentication alerts, and they bypass most conventional security monitoring because they appear to be legitimate authentication tokens issued by your domain controllers.

The extended validity period of an unchanged KRBTGT password also means that even if you detect and remediate an initial compromise, attackers may have already extracted the KRBTGT hash and created Golden Tickets during their access. Without rotating the KRBTGT password, you cannot be certain that you have truly removed their ability to authenticate, as those previously created tickets will continue to work. This creates a scenario where organizations may believe they have successfully expelled attackers from their network when in reality, those attackers retain a backdoor into the environment through valid-looking authentication tickets.

By allowing the KRBTGT password to age beyond 180 days, you are expanding the window of opportunity for attackers and increasing the potential damage from any security incident. Regular password rotation for this critical account is not just a best practice, it is an essential component of limiting the blast radius of potential compromises and ensuring that your domain’s authentication system maintains its integrity over time.

Mitigating the Risk Through Proper KRBTGT Password Management

Protecting your Active Directory environment from Golden Ticket attacks requires a systematic approach to KRBTGT password rotation. The recommended practice is to reset the KRBTGT account password at least every 180 days, though many security-conscious organizations opt for more frequent rotations, particularly in high-security environments or following any suspected security incident.

The process of resetting the KRBTGT password requires careful execution to avoid disrupting authentication services across your domain. Microsoft recommends using their official PowerShell script, which has been specifically designed to handle the complexities of KRBTGT password rotation safely. This script can be found in the Microsoft GitHub repository at https://github.com/microsoft/New-KrbtgtKeys.ps1 and incorporates recommended practices that have been refined through extensive testing and real-world implementation.

A critical aspect of proper KRBTGT password rotation is that the password must be reset twice to fully invalidate any potential Golden Tickets. This dual-reset approach is necessary because Active Directory maintains both the current and previous password hashes for the KRBTGT account to ensure backward compatibility with existing Kerberos tickets. Simply resetting the password once would leave the previous hash functional, meaning any Golden Tickets created with that hash would continue to work. Only after the second reset is the original compromised hash fully removed from active use.

However, you cannot perform both resets in rapid succession without risking authentication failures across your domain. The Microsoft-provided script enforces a mandatory waiting period of at least 10 hours between the first and second password resets. This waiting period aligns with Kerberos best practices and allows sufficient time for all domain controllers to replicate the password change and for existing legitimate tickets to be renewed with the new password hash. Attempting to rush this process by resetting the password twice in quick succession can result in widespread authentication issues, service disruptions, and user lockouts.

When planning your KRBTGT password rotation, coordinate with your IT operations team to schedule the activity during a maintenance window or period of lower activity. The first reset should be performed with adequate time for monitoring before the second reset occurs. Between resets, monitor your domain controllers and authentication services for any unusual behavior or error patterns. Once both resets are complete and the 10-hour window has elapsed, you can be confident that any previously created Golden Tickets based on the old password hashes have been invalidated.

For organizations that discover their KRBTGT password has not been changed in significantly longer than 180 days, this rotation becomes an urgent security priority. In cases where you suspect your environment may have been compromised or if you are remediating after a known security incident, the KRBTGT password reset should be part of your immediate incident response procedures. Remember that until you complete both password resets with the appropriate waiting period, you cannot be certain that attackers have been fully removed from your authentication infrastructure.

Regular KRBTGT password rotation should be incorporated into your organization’s routine security maintenance procedures, tracked through change management systems, and documented as part of your overall Active Directory hardening strategy. By maintaining this discipline, you significantly reduce the window of opportunity for Golden Ticket attacks and ensure that even if the KRBTGT hash is compromised, its useful lifetime to attackers is strictly limited.

Conclusion

The KRBTGT account represents one of the most critical security components in your Active Directory infrastructure, yet it is often overlooked in routine security maintenance. As the foundation of Kerberos authentication across your domain, this built-in account requires vigilant protection and regular password rotation to prevent catastrophic security breaches through Golden Ticket attacks.

Microsoft Defender for Identity’s recommendation to change the KRBTGT password every 180 days is not merely a suggestion, but a fundamental security control that directly impacts your organization’s ability to defend against persistent threats. When this account’s password remains unchanged for extended periods, you are essentially allowing attackers an unlimited timeframe to leverage any compromised credentials, forge authentication tickets, and maintain undetected access to your most sensitive resources.

The good news is that remediation is straightforward when approached methodically. By using Microsoft’s official PowerShell script and following the proper dual-reset procedure with the required 10-hour waiting period between resets, you can safely invalidate any potential Golden Tickets without disrupting your authentication services. This process should become a standard component of your security maintenance calendar, ensuring that your domain’s authentication integrity is regularly refreshed and that the window of opportunity for attackers is kept to an absolute minimum.

Do not wait for a security incident to prioritize KRBTGT password rotation. If your Defender for Identity assessment reveals that your KRBTGT password has not been changed in over 180 days, treat this as a high-priority remediation task. The effort required to properly rotate this password is minimal compared to the devastating impact of a successful Golden Ticket attack that could compromise your entire domain. By maintaining this discipline and incorporating KRBTGT password rotation into your regular security practices, you are taking a crucial step toward hardening your Active Directory environment against one of the most dangerous attack vectors facing modern organizations.

Identity leverages Secure Score with twenty-seven recommended actions. In a series of blog posts, I will go through all twenty-seven recommended actions and what they mean, a plan of approach, their impact, and my security recommendations, hopefully helping others. The twenty-fourth  one in the series is the “Built-in Active Directory Guest account is enabled” recommended action.

Introduction

You have twenty-seven recommendations if you filter the Secure Score recommended actions for Microsoft Defender for Identity.

• Resolve unsecure domain configurations
• Resolve unsecure account attributes
• Remove dormant accounts from sensitive groups
• Protect and manage local admin passwords with Microsoft LAPS
• Configure VPN integration
• Reduce lateral movement path risk to sensitive entities
• Stop clear text credentials exposure
• Disable Print spooler service on domain controllers
• Stop weak cipher usage
• Remove unsecure SID history attributes from entities
• Modify unsecure Kerberos delegations to prevent impersonation
• Install Defender for Identity Sensor on all Domain Controllers
• Set a honeytoken account
• Start your Defender for Identity deployment, installing Sensors on DC’s and other eligible servers
• Accounts with non-default Primary Group ID
• Change Domain Controller computer account old password
• Reversible passwords found in GPOs
• Unsafe permissions on the DnsAdmins group
• GPO assigns unprivileged identities to local groups with elevated privileges
• Remove access rights on suspicious accounts with the Admin SDHolder permission
• Remove local admins on identity assets
• Remove non-admin accounts with DCSync permissions
• GPO can be modified by unprivileged accounts
• Built-in Active Directory Guest account is enabled
• Change password for krbtgt account
• Change password of built-in domain Administrator account
• Ensure that all privileged accounts have the configuration flag

Some recommended actions are easy to configure, but others require time, proper planning, auditing, and expertise. This blog post will review the recommended action of “Built-in Active Directory Guest account is enabled.”

Update: Microsoft keeps updating the recommended actions list. I will do my best to keep the list up-to-date.

Active Directory Guest Account

The Guest account is a built-in, non-nominative account present in every Active Directory environment. Originally designed to provide temporary, anonymous access to domain resources, this account serves a seemingly helpful purpose: allowing users without formal credentials to access the domain. However, this convenience comes at a significant security cost.

What makes the Guest account particularly concerning from a security perspective is its ability to permit access to Active Directory without requiring a password. This fundamental characteristic transforms what appears to be a minor administrative feature into a potential security vulnerability that Microsoft Defender for Identity actively monitors and flags.

By default, Microsoft disables the Guest account in modern Active Directory deployments, and for good reason. When enabled, it essentially creates an open door to your domain, allowing anonymous access that bypasses standard authentication controls. This presents an attractive target for attackers seeking the easiest path into your environment.

Microsoft Defender for Identity’s security posture assessment specifically identifies enabled Guest accounts as a critical security finding. The recommendation is straightforward: ensure that the Guest account remains disabled across your domain. This assessment helps organizations maintain visibility into this often-overlooked security configuration and provides clear guidance on remediation.

In this post, we will explore why Microsoft Defender for Identity flags enabled Guest accounts, the security risks they introduce, and the steps you need to take to remediate this finding and strengthen your Active Directory security posture.

Real-World Attack Scenario: The Anonymous Intruder

Let us walk through a realistic attack scenario that demonstrates why an enabled Guest account poses a serious security risk to your Active Directory environment.

An attacker compromises a web server in yoshis.island’s DMZ through an unpatched vulnerability. The server has local administrator access but no domain credentials. From this position, the attacker runs a network scan and discovers they can reach the internal domain controllers.

They attempt to connect to Active Directory but hit a wall, anonymous LDAP queries are blocked, and they have no valid credentials to authenticate. The DMZ server is isolated from the rest of the DMZ network by design.

During reconnaissance, the attacker runs a simple check and discovers the domain’s Guest account is enabled with no password required. Within seconds, they authenticate to the domain without stealing a single credential.

Now authenticated as a domain user, the attacker enumerates the entire Active Directory structure. They map out users, computers, domain administrators, and service accounts. They discover internal file shares and applications that trust any authenticated domain user, including the Guest account.

One of these shares contains PowerShell deployment scripts. Inside the scripts, the attacker finds hardcoded credentials for a service account with elevated privileges across the network. They pivot from the Guest account to this service account, moving laterally from the DMZ into the core network.

Within hours, what started as a compromised DMZ server with no domain access becomes a full domain compromise. The Guest account transformed an isolated breach into an authenticated foothold, giving the attacker everything they needed to escalate privileges and achieve their objectives.

The Guest account did not just make the attack easier, it made it possible. Without it, the attacker would have remained trapped on a single DMZ server, unable to authenticate to the domain or move laterally into the internal network.

Mitigation

Disabling the Guest account is straightforward and should be done immediately across all domains in your Active Directory forest.

Using Active Directory Users and Computers

Open Active Directory Users and Computers, navigate to the Built-in container, right-click the Guest account, and select “Disable Account.” Repeat this process for every domain in your forest.

Using PowerShell

For a single domain, run the following command from a domain controller or a workstation with the Active Directory module installed:

Disable-ADAccount -Identity "CN=Guest,CN=Users,DC=yoshis,DC=island"

To disable the Guest account across all domains in your forest, use this script:

$Forest = Get-ADForest
foreach ($Domain in $Forest.Domains) {
    try {
        $GuestAccount = Get-ADUser -Filter {SamAccountName -eq "Guest"} -Server $Domain
        if ($GuestAccount.Enabled) {
            Disable-ADAccount -Identity $GuestAccount -Server $Domain
            Write-Host "Disabled Guest account in domain: $Domain" -ForegroundColor Green
        } else {
            Write-Host "Guest account already disabled in domain: $Domain" -ForegroundColor Yellow
        }
    } catch {
        Write-Host "Error processing domain ${Domain}: $_" -ForegroundColor Red
    }
}

Verification

After disabling the Guest account, verify the change by running:

Get-ADUser -Filter {SamAccountName -eq "Guest"} -Properties Enabled | Select-Object Name, Enabled, DistinguishedName

The output should show Enabled: False.

Microsoft Defender for Identity

Once you have disabled the Guest account, Microsoft Defender for Identity will update the security posture assessment. The recommendation status typically updates within a few minutes, though the overall security score may take up to 24 hours to reflect the change. You can monitor the status in the Microsoft Defender portal under the security posture assessments section.

Conclusion

The Active Directory Guest account represents a fundamental security weakness that transforms unauthenticated network access into authenticated domain access. As demonstrated in our scenario, an attacker confined to a compromised DMZ server with no credentials can leverage an enabled Guest account to gain immediate domain authentication, enumerate Active Directory, and ultimately escalate privileges to compromise the entire network.

Microsoft Defender for Identity flags enabled Guest accounts as a critical security finding because this misconfiguration eliminates the most basic security control: authentication. There is no acceptable use case for enabling the Guest account in modern Active Directory environments. The convenience it once provided has been replaced by better alternatives like time-limited user accounts with proper expiration dates and appropriate permissions.

Remediating this finding is simple—disable the Guest account across all domains in your forest using PowerShell or Active Directory Users and Computers. The security benefit is immediate and substantial. You eliminate an anonymous entry point into your domain, remove a persistence mechanism for attackers, and close a path that bypasses user behavioral analytics and attribution.

Take the time today to verify the Guest account is disabled in your environment. If Microsoft Defender for Identity has flagged this recommendation, don’t delay remediation. Every day the Guest account remains enabled is another day an attacker can gain authenticated domain access without stealing a single credential.

Secure your Active Directory foundation. Disable the Guest account.