One of the last areas where more tool support is needed is in monitoring the various attributes in Active Directory (AD). Recently I got curious about the delegation flags, and, more to the point, how to tell which accounts have been trusted for delegation. This could be of great import if, for instance, you have to produce reports of privileged accounts.
KB 305144 gives a certain amount of detail about how delegation rights are presented in Active Directory. However, it is unclear from that article how to discover accounts trusted for full delegation, as opposed to those trusted only for constrained delegation; and the various flags with "DELEGATION" in them are not as clearly explained as I would like. Nor was I able to glean any insight into this from the various security guides and recommendations for Windows. I asked around, and got great answers from Ken Schaefer. By spinning up a Windows Server 2003 Domain Controller in Amazon EC2 and running a few tests, I was able to verify that Ken was indeed correct.
Delegation rights are represented in the userAccountControl flag on the account object in AD, whether a user or a computer account. There are a couple of different flags involved, however. Here are the values set in various circumstances:
For a computer account, the default userAccountControl flag value is 0x1020, which is equivalent to the WORKSTATION_TRUST_ACCOUNT & PASSWD_NOTREQD values being set. A user account is set to 0x200 (NORMAL_ACCOUNT) by default.
When you enable full delegation, 0x80000, or TRUSTED_FOR_DELEGATION, gets ANDed to the userAccountControl flag. This is irrespective of domain functional level. In other words, in a Windows 2000 compatible domain, checking the "Trusted for delegation" box; and, in higher functional levels, checking "Trust this computer for delegation to any service" using the "Kerberos Only" setting, both result in the same flag being set. The same flag is set on user accounts when you check the "Account is trusted for delegation" checkbox.
In a Windows Server 2003 or higher functional level domain you gain the ability to trust an account for delegation only to specific services: constrained delegation. If you configure constrained delegation using Kerberos only, the userAccountControl value is not changed at all. The account simply gets a list of services it can delegate to in the msDS-AllowedToDelegateTo flag.
However, if you configure constrained delegation using any protocol, the userAccountControl value gets ANDed with 0x1000000, or TRUSTED_TO_AUTH_FOR_DELEGATION.
There is also a flag in userAccountControl called NOT_DELEGATED. This flag is set when you check the box "Account is sensitive and cannot be delegated."
This tie-back to the graphical user interface, as well as explanation of the various flags, should help an auditor construct a query that lists all accounts trusted for delegation in an arbitrary domain. Obviously, any account with TRUSTED_FOR_DELEGATION set should be considered extremely sensitive; as sensitive as a Domain Controller or Enterprise Admin account. An account with TRUSTED_TO_AUTH_FOR_DELEGATION set is probably less sensitive, depending on which specific services it can connect to, but still quite sensitive as it can use other protocols than Kerberos. Finally, and least sensitive of those accounts trusted for some form of delegation, are those that are only permitted to delegate to specific services using Kerberos.