From domain data to defensible identity security decisions.

Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.

# Import the Active Directory module.
Import-Module ActiveDirectory

# Reset the password on a service account.
# Use a random 25+ character password from your
# password manager and save it there first.
# Replace <SamAccountName> with the target service account name.
$NewPassword = Read-Host -AsSecureString "New password for <SamAccountName>"
Set-ADAccountPassword -Identity "<SamAccountName>" -Reset -NewPassword $NewPassword

# Put the new password into every service and
# scheduled task that runs as this account, then
# restart them and confirm they start.

# Import the Active Directory module.
Import-Module ActiveDirectory

# Import a reviewed list of service accounts to remediate.
# CSV must contain columns: SamAccountName
$Accounts = Import-Csv -Path ".\ApprovedServiceAccounts.csv"

# Reset each service account password. At each prompt,
# enter a random 25+ character password from your
# password manager and save it there.
foreach ($Account in $Accounts) {
 $NewPassword = Read-Host -AsSecureString "New password for $($Account.SamAccountName)"
 Set-ADAccountPassword -Identity $Account.SamAccountName -Reset -NewPassword $NewPassword -WhatIf
 Write-Output "Processed: $($Account.SamAccountName)"
}

# Remove -WhatIf after the change has been reviewed and approved.
# Then put each new password into every service and
# scheduled task that runs as that account.

Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.

1. Open Active Directory Users and ComputersLaunch dsa.msc from an administrative workstation.
2. Locate the affected service accountNavigate to the OU or container containing the service account identified in the report.
3. Reset the passwordRight-click the account and select Reset Password. Enter a strong, complex password of at least 25 characters. Uncheck User must change password at next logon.
4. Update the dependent serviceLog in to the server or application hosting the service using this account. Update the service logon credentials with the new password using Services.msc or the application's configuration interface.
5. Restart the serviceRestart the dependent service to apply the new credentials and confirm it starts successfully.

Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.

# Import the Active Directory module.
Import-Module ActiveDirectory

# Disable the Guest account in Active Directory.
Disable-ADAccount -Identity "Guest"

# Confirm the account is disabled.
Get-ADUser -Identity "Guest" -Properties Enabled | Select Name, Enabled

Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.

1. Open Active Directory Users and ComputersLaunch dsa.msc from an administrative workstation.
2. Locate the Guest accountNavigate to the Users container (CN=Users) and locate the Guest account.
3. Disable the accountRight-click the Guest account and select Disable Account.
4. Confirm the changeVerify the account icon shows a downward arrow indicating it is disabled.

Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.

# Import the Active Directory module.
Import-Module ActiveDirectory

# Enable password expiration on a Domain Admin account.
# Replace <SamAccountName> with the target admin account.
Set-ADUser -Identity "<SamAccountName>" -PasswordNeverExpires $false

# Import the Active Directory module.
Import-Module ActiveDirectory

# Get all Domain Admins with non-expiring passwords.
$DomainAdmins = Get-ADGroupMember -Identity "Domain Admins" -Recursive |
 Get-ADUser -Properties PasswordNeverExpires |
 Where-Object { $_.PasswordNeverExpires -eq $true }

# Display the accounts identified.
$DomainAdmins | Select SamAccountName, PasswordNeverExpires

# Apply the change from an approved CSV.
# CSV must contain a column named SamAccountName.
$Accounts = Import-Csv -Path ".\ApprovedDomainAdmins.csv"
foreach ($Account in $Accounts) {
 Set-ADUser -Identity $Account.SamAccountName -PasswordNeverExpires $false -WhatIf
 Write-Output "Processed: $($Account.SamAccountName)"
}

# Remove -WhatIf after reviewing.

Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.

1. Open Active Directory Users and ComputersLaunch dsa.msc from an administrative workstation.
2. Navigate to the Domain Admins groupLocate and open the Domain Admins group. Review the Members tab and locate accounts with non-expiring passwords.
3. Update each accountOpen each account's properties, navigate to the Account tab, and uncheck Password never expires.
4. Communicate to affected administratorsNotify each administrator of the change and the upcoming password expiration timeline.

Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.

# Set the NTLM authentication level via registry on a single system.
# This is an alternative to GPO for standalone systems.

$RegistryPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"
Set-ItemProperty -Path $RegistryPath -Name "LmCompatibilityLevel" -Value 5 -Type DWord

# LmCompatibilityLevel values:
# 0 = Send LM and NTLM
# 1 = Send LM and NTLMv2
# 2 = Send NTLM only
# 3 = Send NTLMv2 only
# 4 = Send NTLMv2, refuse LM
# 5 = Send NTLMv2, refuse LM and NTLM (most secure)

Write-Output "NTLM level set to 5 on $env:COMPUTERNAME"

Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.

1. Open Group Policy Management ConsoleLaunch gpmc.msc from an administrative workstation.
2. Create or edit a GPO linked to the domain or Domain Controllers OURight-click the appropriate location and edit or create a GPO.
3. Navigate to the NTLM authentication level settingGo to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.
4. Configure the NTLM levelLocate Network security: LAN Manager authentication level. Double-click and set the value to Send NTLMv2 response only. Refuse LM and NTLM.
5. Deploy in phasesApply the GPO to a test OU first, monitor for authentication failures, and then extend the scope to the domain after validating compatibility.

Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.

# Import the Active Directory module.
Import-Module ActiveDirectory

# Reset the password on a privileged user account.
# Replace <SamAccountName> with the target privileged account.
Set-ADAccountPassword -Identity "<SamAccountName>" -Reset -NewPassword (Read-Host -AsSecureString "Enter new password") -PassThru

# Import the Active Directory module.
Import-Module ActiveDirectory

# Import a reviewed list of privileged accounts with stale passwords.
# CSV must contain a column named SamAccountName.
$Accounts = Import-Csv -Path ".\ApprovedPrivilegedAccounts.csv"

foreach ($Account in $Accounts) {
 Set-ADAccountPassword -Identity $Account.SamAccountName -Reset `
 -NewPassword (Read-Host -AsSecureString "New password for $($Account.SamAccountName)") -WhatIf
 Write-Output "Processed: $($Account.SamAccountName)"
}

# Remove -WhatIf after reviewing.
# Get each new password to the account's owner securely.

Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.

1. Open Active Directory Users and ComputersLaunch dsa.msc from an administrative workstation.
2. Locate the affected privileged accountNavigate to the OU containing the privileged account identified in the report.
3. Reset the passwordRight-click the account and select Reset Password. Enter a strong password meeting complexity requirements. Uncheck User must change password at next logon for service accounts; check it for human user accounts where appropriate.
4. Notify the account ownerContact the account owner through a secure channel to provide the new password or initiate a self-service reset flow.
5. Update dependent servicesFor service accounts, update the service logon credentials on all dependent systems and restart the services as needed.

Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.

# Import the Active Directory module.
Import-Module ActiveDirectory

# Clear resource-based constrained delegation from a single account.
# Replace <SamAccountName> with the target (computer accounts end with $).
Set-ADComputer -Identity "<SamAccountName>" -Clear "msDS-AllowedToActOnBehalfOfOtherIdentity"

# Import the required module for the remediation.
Import-Module ActiveDirectory

# Import a reviewed and approved list of affected objects to remediate.
$Items = Import-Csv -Path ".\ApprovedObjects.csv"

# Update only the objects included in the approved input file.
foreach ($Item in $Items) {
    # Replace the placeholder with the approved single-object command for Resource-Based Constrained Delegation.
    # Use -WhatIf when supported before applying the change.
    <Approved-Remediation-Command> -Identity $Item.SamAccountName -WhatIf
}

Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.

1. Open Active Directory Users and ComputersLaunch Active Directory Users and Computers from an administrative workstation and enable Advanced Features from the View menu.
2. Locate the affected accountNavigate to the computer or user account identified in the report.
3. Open the Attribute EditorRight-click the account, select Properties, and open the Attribute Editor tab.
4. Clear the delegation attributeSelect msDS-AllowedToActOnBehalfOfOtherIdentity, click Clear, then click OK.
5. Repeat for each objectRepeat the same process for every approved account listed in the remediation plan.

Microsoft and the security community recommend using either New-KrbtgtKeys.ps1 or Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1. Both scripts include health checks, simulation modes, replication monitoring, and RODC account handling.

Script repositories: https://github.com/microsoftarchive/New-KrbtgtKeys.ps1, https://github.com/zjorz/Public-AD-Scripts/blob/master/Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1

# Instructions for New-KrbtgtKeys.ps1
# Review the script, test the informational/simulation modes, and run from an approved admin workstation.

# Example workflow:
# 1. Run informational mode to review writable domain controllers and krbtgt status.
# 2. Run simulation mode to validate replication before making changes.
# 3. Run the production reset mode for the first krbtgt reset.
# 4. Wait longer than the domain Kerberos ticket lifetime, then repeat production reset mode.
# 5. Save the script transcript and validate replication after each reset.
.\New-KrbtgtKeys.ps1

The scripted remediation path is preferred as it provides checks, features, and controls that make this change safer for most environments.

1. Open Active Directory Users and ComputersOn an administrative workstation or writable domain controller, open Active Directory Users and Computers.
2. Enable Advanced FeaturesSelect View, then select Advanced Features so the krbtgt account is visible and manageable.
3. Locate the krbtgt accountExpand the domain container, select Users, and locate the krbtgt user account. Do not reset any RODC-specific krbtgt_number account unless separately instructed as part of an RODC recovery process.
4. Reset the krbtgt passwordRight-click the krbtgt account and select Reset Password. Enter and confirm a new password, then click OK. The specific password entered is not significant because Windows generates the actual strong password value automatically.
5. Allow ticket lifetime and replication delayWait at least 10 hours before performing the second reset, or longer if the domain uses a longer maximum lifetime for user or service tickets. Confirm replication health before proceeding.
6. Reset the password a second timeRepeat the password reset on the krbtgt account after the waiting period. The second reset clears older krbtgt password material from history and helps invalidate previously issued Kerberos tickets.
7. Monitor authenticationAfter each reset, monitor domain controller replication, Kerberos authentication, and service authentication for errors before closing the change.

Not applicable. A command-line remediation is not the preferred remediation method for this finding because domain controller patching should be performed through the approved patch management platform, Windows Update workflow, or maintenance process rather than an ad hoc command. Command-line tools may be used for post-change health checks, but they are not the primary remediation path.

Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.

1. Open Server ManagerLog in to the domain controller and open Server Manager.
2. Navigate to Local ServerClick Local Server in the left pane and locate the Windows Update section.
3. Check for updatesClick the Windows Update status link to open Windows Update settings. Click Check for updates.
4. Install all available updatesClick Install now to apply all pending updates.
5. Schedule a restartIf a restart is required, schedule it during the approved maintenance window. Confirm with the change control team before proceeding.
6. Verify post-restart functionalityAfter the restart, confirm domain controller services are running and use the approved validation process to confirm replication health.

Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.

# Enable LDAP signing enforcement on domain controllers via registry.
# This is an alternative to GPO for individual domain controllers.

$RegistryPath = "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters"
Set-ItemProperty -Path $RegistryPath -Name "LDAPServerIntegrity" -Value 2 -Type DWord

Write-Output "LDAP signing set to Require on $env:COMPUTERNAME"

# Values: 0 = None, 1 = Negotiate signing, 2 = Require signing

Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.

1. Open Event ViewerOn domain controllers, open Event Viewer and review the Directory Service log for LDAP signing-related events collected during the approved monitoring period.
2. Open Group Policy Management ConsoleLaunch Group Policy Management Console from an administrative workstation.
3. Edit the domain controller policyRight-click the Default Domain Controllers Policy or the approved hardening GPO linked to the Domain Controllers OU and select Edit.
4. Navigate to the LDAP signing settingGo to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.
5. Require LDAP signingOpen Domain controller: LDAP server signing requirements, set it to Require signing, and save the setting.
6. Review post-change eventsAfter normal policy refresh occurs, use Event Viewer to monitor the Directory Service log for rejected unsigned bind events and coordinate remediation for any affected applications.

Use this path when remediating multiple objects or when changes need to be executed, exported, and tracked.

# Transfer FSMO roles from the legacy domain controller to a replacement.
# Replace <TargetDCName> with the SAM account name of the replacement domain controller.
# Replace <LegacyDCName> with the name of the legacy domain controller being decommissioned.

Import-Module ActiveDirectory

# Transfer all FSMO roles to the target domain controller.
Move-ADDirectoryServerOperationMasterRole -Identity "<TargetDCName>" -OperationMasterRole `
 SchemaMaster, DomainNamingMaster, RIDMaster, PDCEmulator, InfrastructureMaster -Force

# Demote the legacy domain controller.
# Run the following on the legacy domain controller itself.
Uninstall-ADDSDomainController `
 -DemoteOperationMasterRole:$true `
 -RemoveApplicationPartitions:$true `
 -Force:$true

Use this path when changing a small number of objects or when an administrator prefers a visual confirmation flow.

1. Provision the replacement domain controllerUsing Server Manager on a supported Windows Server host, add the Active Directory Domain Services role and complete the domain controller promotion wizard according to the approved design.
2. Transfer FSMO roles using GUI toolsUse the appropriate Active Directory administrative consoles to transfer FSMO roles from the legacy domain controller to a supported domain controller. Use Active Directory Users and Computers for RID, PDC, and Infrastructure roles, Active Directory Domains and Trusts for the Domain Naming Master role, and the Active Directory Schema snap-in for the Schema Master role.
3. Demote the legacy domain controllerOn the legacy domain controller, open Server Manager and use the Remove Roles and Features wizard to remove the Active Directory Domain Services role. Complete the demotion wizard and restart the server if prompted.
4. Remove stale domain controller referencesUse Active Directory Users and Computers, Active Directory Sites and Services, and DNS Manager to remove stale computer objects, server objects, replication connection objects, and DNS records associated with the retired domain controller.
5. Confirm administrative console healthReview Active Directory Sites and Services, DNS Manager, and Server Manager to confirm the retired domain controller is no longer referenced and that remaining domain controllers appear healthy.