Verifying Constrained Delegation

Applies To: Active Directory

When using Kerberos with SharePoint 2010 you run into the requirement to use Constrained Delegation all over the place. Basically, even though you have the SPNs setup, you’ll need to specify which services your accounts can delegate to by using Active Directory. This is all covered elsewhere and can be found using some simple Google searches so I won’t go into any more detail.

The problem I run into is that I’m not allowed to set this up in Active Directory in our production environment and I have to trust someone else to do this. I don’t mind that, but I do want to be able to check the settings when troubleshooting. Using the Active Directory tools (Here’s a guide to getting these setup), even if you don’t have permission to edit anything, you can take a look at most of the account information. Unfortunately, the delegation tab has everything disabled.

Names hidden to protect the innocent

If you just have a few items setup, then you can see the first six or so, but you can’t scroll down and you can’t expand the entries. Why Microsoft made this impossible to view is beyond me, but you can get to it using the command line.

Since you’ve got the tools installed, fire up a command prompt (Go ahead and Run as Administrator). Then type this command:

ldifde -f C:\ConstrainedDelegation.txt -d "cn=SharePoint AppPool,ou=SharePoint,ou=Services,dc=MyDomain,dc=Com" -l msDS-AllowedToDelegateTo

This will write a list of all the services the account can delegate to (To see all the properties just leave the msDS-AllowedToDelegateTo off the end). Also, make sure you replace the part in quotes with the actual path to your account.

The easiest way to figure out the correct path is to open the Active Directory Users and Computers and expand the OUs (folders) until you find your account. Then take the display name of the account as the cn= part and work backwords up the “folders” specifying ou= for each. Finally, add the dc= for each part of your FQDN. Usually something.something. In the above example, I had expanded MyDomain.com then the Services folder and then then SharePoint folder to find my account named SharePoint AppPool.

In your face Microsoft! I used your tools to get around your tools! Hopefully this can help relieve some of the frustration of troubleshooting Kerberos errors during installation or configuration. Even with the above tip, you’re gonna want a hanky to cry into and a teddy bear to squeeze.

4 thoughts on “Verifying Constrained Delegation

  1. Hi. This can also be done with PowerShell if you have the Active Directory module installed. Try: Get-ADUser -Properties msDS-AllowedToDelegateTo | select -ExpandProperty msDS-AllowedToDelegateTo

  2. Thanks for both the article and your followup comment hugheser.

    I’m very much a Powershell noob, so can’t quite get what I want, but I’m close.

    I’ve taken hugheser’s code and before the pipe added -LDAPFilter “(name=sp*)” -SearchScope Subtree -SearchBase “OU=SvcAcct,DC=corp,DC=company,DC=com” to look up the delegation info on all service accounts with names starting with sp. This works, except it pumps out a long list of delegation info for all accounts but with no way to tell what belongs to what account. How can I get a nicely formatted list output with the Account name first, then the delegation info, then the next account and so on?

Leave a reply to Eric Cancel reply