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 :



PowerShell : How to lookup Schema version of your forest ?


The schema version is revealed via the objectversion attribute off of the schema object from your configuration head of the forest i.e “cn=schema,cn=configuration,dc=yourdomain,dc=int”.

So using Quest Cmdlets, you can run this query :

Get-QADObject "cn=schema,cn=configuration,dc=yourdomain,dc=int" -ip objectversion | select objectversion


The –ip is the alias for includedproperties.

And, when using the native AD Cmdlets of Server 2008 R2 (ADWS), the syntax is slightly different ;

Get-ADObject "cn=schema,cn=configuration,dc=r2,dc=lab" -properties objectversion


Above, you see the query ran with Quest Cmdlets resulting in objectversion 31 which is against a Server 2003 R2 Forest, whereas the latter is for a Server 2008 R2 Forest i.e Schema version 47.

PowerShell : Set-ADAccountPassword cmdlet in Windows Server 2008 R2


Here is quick snippet of password set/reset ‘Set-ADaccountPassword’ cmdlet in 08 R2 via ADWS (native AD cmdlets) and a test screencast from me.


I highly recommend to use the built in cmdlet help to learn the syntax and available parameters. Whether you are using the cmdlet as an one-off task or trying to incorporate it into a script.

First we run, Help Set-ADaccountPassword -examples to look at what the options are and then use,

Set-ADaccountPassword -Identity Moyo -reset where the user id is moyo, and provide the new value of the password. Unlike many other functions where you must run the ADWS under elevated ‘administrative’ privileges, if you are running this cmdlet on your DC, you can run this under normal security context.

Active Directory Management Gateway Service is RTW


ADMGS aka AD Web Services aka Powershell Native AD cmdlets which is originally a Windows Server 2008 R2 feature is out of beta and can be downloaded from here for DCs running down level OSs.

The Active Directory Management Gateway Service enables administrators to use the Active Directory module for Windows PowerShell and the Active Directory Administrative Center running on Windows Server 2008 R2 or Windows 7 to access or manage directory service instances that are running on Windows Server 2008 or Windows Server 2003 DCs.

Note:    Installing the Active Directory Management Gateway Service on your Windows Server 2008–based or Windows Server 2003–based servers does not make it possible for you to install the Active Directory module or the Active Directory Administrative Center (which is available only on Windows Server 2008 R2 or Windows 7 operating systems) on these servers. “

For more info see http://www.shariqsheikh.com/blog/index.php/200907/what-is-active-directory-management-gateway-service-admgs/

What is Active Directory Management Gateway Service (ADMGS)?


Windows Server 2008 R2 provides a web service that is required by ADAC and native AD-Cmdlets of PowerShell, that service in known as ADWS and its part of proverbial ADMGS framework. So ADMGS equals ADWS out-of-box. The service lets Server 2008 R2 AD PowerShell cmdlets and other applications work against the DCs with ADMGS installed. And its final version has been released with Windows Server 2008 R2 which hit RTM earlier this week. That ADMGS framework and comparison of changes from 2008 to 2008 R2 was briefly discussed in a Brian Desmond’s webcast a few months back.


















Something not part of the original plan and considered due to high demand is that now you have ADWS add-on service/functionality available to manage your down-level DCs such as Windows Server 2003 and 2008 (non-R2). This means you don’t have to be at 2008 R2 FFL to run this.

Below is excerpted from ADPoSH Blog :

  1. Visit http://connect.microsoft.com and enter the invitation ID ADWS-FDBT-CVJK on the home page.
  2. Sign in using your live/hotmail ID
  3. Active Directory Management Gateway Service download details and instructions will be available to you on MS Connect site – http://connect.microsoft.com/ADWS/

Once you have it installed, you can take advantage of native AD PowerShell Cmdlets. This certainly adds good competitiveness to the cmdlets world and Quest Active Roles QAD cmdlets finally have something to compete against.

































For more information see : http://support.microsoft.com/default.aspx?scid=kb;en-us;969041&sd=rss&spid=12925