Deep Dive Into Resource-Based Constrained Delegation – Part 2

In this post we’ll dive right into the weeds. To demonstrate how RBKCD works I built an environment in my Azure lab with the following properties:

  1. Two Active Directory forests named contoso.local and fabrikam.local.
  2. Two-way Active Directory forest trust between the two forests.
  3. Server configuration
    • SERVER12.CONTOSO.LOCAL (Windows Server 2012 R2) – AD DS
    • SERVER13.CONTOSO.LOCAL (Windows Server 2012 R2) – IIS
    • SERVER14.FABRIKAM.LOCAL (Windows Server 2012 R2) – AD DS
    • SERVER15.FABRIKAM.LOCAL (Windows Server 2012 R2) – File Server

We’ll be using a web application developed by Brian Murphy Booth named DelegConfig. The application is a bit dated, but will serve our purpose in testing RBKCD. You can download a copy from here.

On SERVER13 we’ll be adding the application to IIS and running it under the Default Application Pool for simplicity sake. We’ll use the application to access an SMB share on SERVER15 and we’ll be accessing the application from a web browser on SERVER12.

The SMB share has had the share permissions configured so that the mfelton user account has read permissions on the share. SERVER13 has not been configured for any type of delegation. Let’s see what happens when we attempt to access the share via the web application. We’ll use Microsoft Network Monitor running on SERVER13 to perform a packet capture and examine the authentication exchanges.

The first Kerberos exchange we see is performed in the two frames below.


Let’s dig into frame 45 and look more deeply at the request. In the image below we that SERVER13 is obtaining a service ticket for itself on behalf on the mfelton user as detailed in this link. SERVER13 will use this ticket to request additional tickets for the user mfelton in order to access SERVER15.


The next Kerberos exchange is performed in these two frames.


Here we have SERVER13 requesting a Kerberos ticket for the CIFS share on SERVER15 on behalf of the user mfelton. If we dig into the PaData of the request we see that the PA-PAC-OPTIONS are included. Although I’m unable to find a way to enumerate the bits, contained in the PAC-OPTIONS are a bit that says resource-based constrained delegation is supported by the client (more detail in this link). Since this is a Windows Server 2012 or later DC, the DC supports resource-based constrained delegation and supplied the application with a ticket it can use to access the FABRIKAM domain.


In the third exchange the application delivers the ticket it received from the CONTOSO domain and requests a ticket for SERVER15 on behalf of the user mfelton.

But wait, is that a KDC_ERR_BADOPTION we see? Well one thing you’ll notice I never did was configure resource-based constrained delegation and I receive the expected error as outlined in this link. So let’s remedy that and look at the differences.

First off, the eternal question, how do we configure resource-based constrained delegation? Well it’s a simple two liner depending on whether or not you’re configuring it on a user or computer account. In our scenario it is the following:

$Computer = Get-ADComputer -Identity SERVER13
Set-ADComputer -Identity SERVER15 -PrincipalsAllowedToDelegateToAccount $Computer

The first two exchanges look exactly the same as the previous example:


The third exchange is where see a difference:


Here we see we are successfully able to obtain a ticket to the SMB share on SERVER15 successfully impersonating the mfelton user account as seen in the frame below.


That’s all there is to it to enable a pretty neat feature in the legacy authentication protocol realm. Hopefully these posts have helped you better understand the feature and how it works. If anything, this series will point to the right articles where you can read more about it.

Deep Dive Into Resource-Based Constrained Delegation – Part 1

Hello all.

Today I wanted to take a step back from cloud and step back into the world of “legacy” authentication protocols. Many of you reading this blog should be familiar with the Kerberos authentication protocol, its usage, and its plusses and minuses. If you’re unfamiliar with the protocol there are plenty of resources online that will walk you through the basics.

The best overview I’ve seen is the Mark Minasi “Cracking Open Kerberos: Understanding How Active Directory Knows Who You Are” presentation. The challenge there is you’ll need to find a working stream of the video as the Channel 9 video seems quite dead. If you enjoy nerding out like I do you can read through the following RFCs and standards:

  • The Kerberos Network Authentication Service V5 RFC 4120
  • MS-KILE Kerberos Protocol Extensions
  • MS-SFU Kerberos Protocol Extensions for Service for User and Constrained Delegation Protocol

For this blog post I’ll be focusing on Resource-Based Kerberos Constrained Delegation (RBKCD). RBKCD provides new capabilities to the Microsoft implementation of Kerberos and was introduced in Windows Server 2012. I am not a fan of re-creating documentation when someone has already done a wonderful job putting together the information, so take a read through the links below for a wonderful overview of the different types of delegation and information as to how RBKCD works.

So what types of business problems could we solve with RBKCD? Let’s suppose two organizations wish to collaborate and leverage a single shared solution to provide data analysis and the solution must meet the following requirements:

  1. The solution will be owned by Company A and hosted using Company A’s infrastructure.
  2. The solution must be capable of querying data sources in both Company A and Company B.
  3. The solution must be accessible by users within both Company A and Company B.
  4. The solution must only return the data the user is authorized to see.
  5. The solution must make security a top priority.

In the above scenario we can satisfy requirement 3 through a standard Active Directory trust between Company A and Company B. Requirement 1, 2, and 4 could be satisfied by Kerberos Unconstrained (Open) Delegation. However, requirement 5 requires we leverage the more secure Kerberos Constrained Delegation. The problem we have with that solution is Kerberos Constrained Delegation can’t satisfy requirement 2 when combined with requirements 3 and 4. Prior to Windows Server 2012, we’d have to accept the risk and loss of features such as protocol transition when using Kerberos Unconstrained Delegation. With Windows Server 2012 and later, we can leverage RBKCD to satisfy all five requirements. There are additional benefits to RBKCD in simplifying administration, but I won’t go into those, you can read about them in the links above.

So now we know what value it can bring to the business, but how does it work and what does it look like? The links I provide above answer a bit of the first question, but not much of the second. We’ll take a look at the latter question in my next blog post.