PowerShell : How do I set the delegation sensitive flag on users and computers ?


Kerberos Delegation, constrained and unconstrained is a complex topic, and one that often comes up when Security implications of External/Forests Trusts are discussed. Few days ago, on ActiveDir a similar topic was shed light upon. In brief Brian Arkills sums it up below,

The other security implication that most folks seem oblivious to is the one that comes with unconstrained Kerberos delegation across a trust. When you’ve got a single domain/forest by itself, your domain admin group controls who/what can use delegation. Once you setup a trust to another domain, you extend that ability to the domain admins in the other domain(s). In other words, the domain admins in the other domain can choose to allow a user/computer in their domain to permit unconstrained Kerberos delegation using the user accounts in *your* domain. Almost everyone says unconstrained delegation is bad, and the assumption is that no one will use it. But there are no controls in the product to prevent its use, except by also preventing any delegation (i.e. by marking all or a subset of user accounts as ‘sensitive to delegation’). And of course, unconstrained delegation is the only way to use delegation across a forest trust meaning it’s the only game in town for certain scenarios.

A service that runs under an account that is trusted for Kerberos delegation can assume/impersonate the identity of a client requesting the service. This parameter sets the TrustedForDelegation property of an account object. This value also sets the ADS_UF_TRUSTED_FOR_DELEGATION flag of the Active Directory User Account Control attribute.

It is that marking of the user accounts as “delegation sensitive” with PowerShell is what I would like to share with you.


For user and computer accounts, as stated above the setting is enclosed under the useraccountcontrol bits.


We take the TRUSTED_FOR_DELEGATION and its associated value in decimal i.e 524288 and assign it a variable.


Using Quest Cmdlets, we use the Set-QADUser and use the bitwise exclusive operator to set the flag as sensitive (Thanks to Shay Levy for helping me with the correct bitwise syntax)

Get-QADUser user1  |
    Set-QADObject $_ -ObjectAttributes @{userAccountControl= ($_.userAccountControl -bxor $NOT_DELEGATED)}

For computer accounts, there is an explicit parameter for the Set-QADComputer Cmdlet i.e -TrustForDelegation

With ADWS (the native AD Cmdlets) the same parameter (being applicable to both i.e users and computers) for Set-ADUser and Set-ADComputer is called –TrustedForDelegation.

By default, when an account has been granted delegation privileges *every* user account can be “impersonated” in this way. However, with above you can mark certain user accounts as “delegation sensitive”, which means that those user accounts can never be used in a delegation scenario. Marking admin accounts as delegation sensitive is highly recommended. Generally, delegation is used with Kerberos, but there is an option to use protocol transition so that NTLM might be used on some of the hops (this is called S4U). Also note that for service accounts (user accounts), the delegation tab will only appear (allowing for the constrained delegation) when there is a SPN registered against that user account.


More reading here :



Can a KMS Server activate clients in multiple domains ?


Yes, the KMS client activation is supported in multi-domain environment in which the KMS host belongs to one domain and needs to cater to the clients in others.

For this to work, you need to create a ‘multi-string value’ registry key under “HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionSoftwareProtectionPlatform” called “DNSDomainPublishList” on your KMS Server.


When done, restart the “Software Protection” sppsvc service on your KMS host and watch for the Event ID 12294 log under application logs. You should one event for each domain you have asked KMS to publish itself in.


Additionally, under each domain you can use NSLookup to verify the _vlmcs SRV record.

nslookup -type=srv _vlmcs._tcp

KMS communication happens over TCP Port 1688, if the domains you have added are in other region and you would like to verify if clients can talk to your KMS host, then from a client on the other side use PortQry to ascertain that port is not being blocked

portqry –n FQDN_of_your_host –e 1688 –p both

If the environment does not support Dynamic DNS, then SRV Resource Records can be manually created to publish the KMS host.

The KMS SRV RR is created under TCP node of your DNS Domain.


On how to setup and configure KMS Server/host a Server Core, see my other post.

Other details can be found under Technet Library : http://technet.microsoft.com/en-us/library/ff793419.aspx