Constrained Delegation in Windows

The majority of sites around the web discuss constrained delegation in terms of web applications, SQL Server, or specialty services. There's not a whole lot of discussion on programmatic delegation, and I have yet to find a step-by-step guide for writing code that wants to take advantage of constrained delegation. I thought I'd write one.

I've created a scenario where a domain user runs a program that sends messages to a message receiver program. When the receiver gets a message, it impersonates the sender and then displays the message.

Because I'm going to need an Active Directory domain environment, I've created 3 virtual machines:

1. dc.example.com - windows server 2008 R2 domain controller
2. example-server.example.com - windows server 2008 R2 app server
3. wkstation.example.com - windows 7 workstation

I've set up a few accounts in the domain:

1. John@example.com - user account - will be sending messages
2. msgSvc@example.com - service account - will be receiving messages

To the right, you'll see that I set the msgSvc account up so that the password can't be changed and it never expires. This isn't a best practice at all - this is just me trying to create a working environment quickly.

With Windows Server 2008 R2 domains, it's possible to create "managed service accounts", which will set and change your password for you as well as create and update Service Principal Names (SPNs) on your behalf. I didn't do that for this blog post because there's no GUI to create or manage service accounts yet and I didn't want to get into powershell scriptlets. If you're interested, there's a step-by-step guide over here. In this blog post, I refer to msgSvc@example.com as a "service account" even though it is actually just a normal user account. It is definitely not a "managed service account."

The service account we've just created will be the account running the message receiver program on the application server (example-server.example.com). In order for the service account to authenticate itself as the "example" message receiver service, we must set a service principal name (SPN) onto the account. Look at the image below to see how this is done.

setspn -U -A example/example-server.example.com@EXAMPLE.COM msgSvc

Now that we've mapped the service account to the service principal name, we can configure constrained delegation to that service.

On the domain controller (dc.example.com), we open up Active Directory Users and Computers. In the computers folder, we locate example-server and open its properties page. One of the tabs available will be "Delegation". That tab contains radio buttons, including the choice: "Trust the computer for delegation to specified services only". Keep "Use kerberos only" checked, and then click the "Add" button and specify the msgSvc account.

That's it for part 1! I now have an environment, accounts, and settings that will allow constrained delegation for my message passing programs. Tomorrow, I will post Part 2, which will show the code that sends signed and encrypted messages between two mutually authenticated programs. The message receiver will then impersonate the sender and display the message.