Digging deep into the AD DS workstation logon process – Part 2

Welcome back.

Today I will continue my analysis of the workstation logon process. Please take a read through Part 1 if you haven’t already. We left off with the workstation obtaining a Kerberos service ticket in order to authenticate to the domain controller to access the SMB share.

Ready? Let’s go!

  1. Source: Domain-joined machine
    Destination: Same Site or Closest Site Domain Controller
    Connection: TCP
    Port: 445
    Protocol: SMB
    Purpose: The domain-joined workstation requests a new authenticated SMB session with the domain controller and provides its Kerberos service ticket as proof of authentication.
    Links:

  2. Source: Domain-joined machine
    Destination: Primary DNS Server
    Connection: UDP
    Port: 53
    Protocol: DNS
    Purpose: DsGetDcName API issues a DNS query for an SRV record to the domain-joined machine’s primary DNS server for a domain controller offering the Kerberos service within its site using the SRV record of _ldap._tcp.FAKESITE._sites.dc._msdcs.contoso.local. The primary DNS server returns the results of the SRV query.

  3. Source: Domain-joined machine
    Destination: Domain Controller resolved from IP returned from previous step
    Connection: UDP
    Port: 389
    Protocol: LDAP
    Purpose: DsGetDcName API on domain-joined machine issues a specially crafted LDAP query (referred to by Microsoft as an LDAP Ping) to the domain controller it receives back from the query and then queries the RootDSE for the NetLogon attribute. The detail query is as follows:

    • Filter: (&(DnsDomain=)(Host=HOSTNAME)(DomainGUID=)(NtVer=)(DnsHostName=))
    • Attributes: NetLogon

    The domain controller passes the query to the NetLogon service running on the domain controller which evaluates the query to determine which site the server belongs in. The domain controller returns information about its state and provides the information detailed below (https://msdn.microsoft.com/en-us/library/cc223807.aspx):

    • Flags:
      • DSPDCFLAG – DC is PDC of the domain
      • DSGCFLAG – DC is a GC of the forest
      • DSLDAPFLAG – Server supports an LDAP server
      • DSDSFlag- DC supports a DS and is a domain controller
      • DSKDCFlag DC is running KDC service
      • DSTimeServFlag – DC is running time service
      • DSClosestFlag – DC is in the closest site to the client
      • DSWritableFLag – DC has a writable DS
      • DSGoodTimeServFlag (0) – DC is running time service
      • DSNDNCFlag – DomainName is a non-domain NC serviced by the LDAP server
      • DSSelectSecretDomain6Flag – the server is a not an RODC
      • DSFullSecretDomain6Flag – The server is a writable DC
      • DSWSFlag – The Active Directory Web Service is present on the server
      • DSDNSControllerFlag – DomainControllerName is not a DNS name
      • DSDNSDomainFlag – DomainName is not a DNS name
      • DSDNSForestFlag – DnsForestName is not a DNS name
    • DomainGuid:
    • DnsForestName: contoso.local
    • DnsDomainName: contoso.local
    • DnsHostName: dc2.contoso.local
    • NetbiosDomainName: CONTOSO
    • NetbiosComputerName: DC2
    • Username:
    • DcSiteName: FAKESITE
    • ClientSiteName: FAKESITE
    • NextClosestSIteName: Default-First-Site-Name

    The client caches this information to its DCLocator cache.

  4. Source: Domain-joined machine
    Destination: Same Site or Closest Site Domain Controller
    Connection: TCP
    Port: 445
    Protocol: SMB
    Purpose: The domain-joined workstation sends an SMB TREE CONNECT Request to the domain controller for the IPC$ share accessed by \IPC$. The IPC$ share is used to setup a named pipe for further RPC calls to the service such as allowing the workstation to enumerate the shares available on the server. The domain controller responds with an SMB TREE CONNECT Response providing information about the capabilities of the IPC$ share.
    Links:

  5. Source: Domain-joined machine
    Destination: Same Site or Closest Site Domain Controller
    Connection: TCP
    Port: 445
    Protocol: SMB
    Purpose: The domain-joined workstation sends an SMB IOCTL Request to the domain controller with the control FSCTL_VALIDATE_NEGOTIATE_INFO (0x00140204). This control is used to verify that the domain controller hasn’t changed the authentication mechanism originally negotiated. The domain controller responds with an SMB IOCTL Response confirming the authentication mechanism has not changed. This helps to prevent man in the middle attacks.
    Links:

  6. Source: Domain-joined machine
    Destination: Same Site or Closest Site Domain Controller
    Connection: TCP
    Port: 445
    Protocol: SMB
    Purpose: The domain-joined workstation sends an SMB IOCTL Request to the domain controller with the control FSCTL_QUERY_NETWORK_INTERFACE_INFO (0x001401FC). This control is used to determine whether or not the server has multiple IPs and a new channel should be established. The domain controller responds with an SMB IOCTL Response providing an answer.
    Links:

  7. Source: Domain-joined machine
    Destination: Same Site or Closest Site Domain Controller
    Connection: TCP
    Port: 445
    Protocol: SMB
    Purpose: The domain-joined workstation sends an SMB IOCTL Request to the domain controller with the control SCTL_DFS_GET_REFERRALS (0x00060194). This control requests the DFS referral for the domain-based DNS root. The domain controller responds with an SMB IOCTL Response providing an answer with an entry for the FQDN and NetBios entries.
    Links:

  8. Source: Domain-joined machine
    Destination: Primary DNS Server
    Connection: UDP
    Port: 389
    Protocol: LDAP
    Purpose: The domain-joined workstation sends a DNS query for the A record for the second domain controller record it received back in the initial queries for the various SRV records. The domain controller responds with the answer to the DNS query.

  9. Source: Domain-joined machine
    Destination: Domain Controller resolved from IP returned from previous step
    Connection: UDP
    Port: 389
    Protocol: LDAP
    Purpose: DsGetDcName API on domain-joined machine issues a specially crafted LDAP query (referred to by Microsoft as an LDAP Ping) to the domain controller it receives back from the query and then queries the RootDSE for the NetLogon attribute. The detail query is as follows:

    • Filter: (&(DnsDomain=)(Host=HOSTNAME)(DomainGUID=)(NtVer=)(DnsHostName=))
    • Attributes: NetLogon

    The domain controller passes the query to the NetLogon service running on the domain controller which evaluates the query to determine which site the server belongs in. The domain controller returns information about its state and provides the information detailed below (https://msdn.microsoft.com/en-us/library/cc223807.aspx):

    • Flags:
      • DSPDCFLAG – DC is PDC of the domain
      • DSGCFLAG – DC is a GC of the forest
      • DSLDAPFLAG – Server supports an LDAP server
      • DSDSFlag- DC supports a DS and is a domain controller
      • DSKDCFlag DC is running KDC service
      • DSTimeServFlag – DC is running time service
      • DSClosestFlag – DC is in the closest site to the client
      • DSWritableFLag – DC has a writable DS
      • DSGoodTimeServFlag (0) – DC is running time service
      • DSNDNCFlag – DomainName is a non-domain NC serviced by the LDAP server
      • DSSelectSecretDomain6Flag – the server is a not an RODC
      • DSFullSecretDomain6Flag – The server is a writable DC
      • DSWSFlag – The Active Directory Web Service is present on the server
      • DSDNSControllerFlag – DomainControllerName is not a DNS name
      • DSDNSDomainFlag – DomainName is not a DNS name
      • DSDNSForestFlag – DnsForestName is not a DNS name
    • DomainGuid:
    • DnsForestName: contoso.local
    • DnsDomainName: contoso.local
    • DnsHostName: DCSERVER.contoso.local
    • NetbiosDomainName: CONTOSO
    • NetbiosComputerName: DCSERVER
    • Username:
    • DcSiteName: Default-First-Site-Name
    • ClientSiteName: FAKESITE
    • NextClosestSIteName: Default-First-Site-Name

    The client caches this information to its DCLocator cache.

All right folks, we’re going to break here. My next post will continue with the NetLogon process.

Thanks and see you then!

Digging deep into the AD DS workstation logon process – Part 1

Hi everyone. The holidays are over, spring is quickly approaching, and it’s been far too long since I’ve had a chance to do a deep dive. This year I have some work on the agenda for Microsoft Active Directory Domain Services (AD DS). That work will require a very strong understanding of the network flows, ports, and protocols that provide the service. While there are many different resources on the web, I haven’t found one that gets to the level I’d like to see. This made for the perfect opportunity for a series of blog posts.

Many of us have faced the challenge where there is a requirement to separate the domain controllers providing the AD DS service and the domain members with a firewall. Microsoft does a wonderful job defining the ports and protocols required for this scenario in this link (https://technet.microsoft.com/en-us/library/dd772723(v=ws.10).aspx). The integration is pretty straightforward with the only decision typically being whether to define static RPC ports or leveraging a firewall which is capable of handling dynamic RPC ports.

One of the things I’ve always wondered is when are each of these ports and protocols used? What better place to start than a common source for troubleshooting? For this series of blogs I will do a deep dive into the flows a domain-joined machine uses and what happens within those connections. Yeah I know, AD DS isn’t that glamorous in the year 2017, but all the moving parts, protocols, standards, and functions that power something as seemingly simple as a logon are fascinating and worth a deeper look.

To provide for this scenario I built a small lab in Azure with three Windows Server 2016 Standard VMs. Each VM is configured as seen below:

Name: DCSERVER
Roles: Active Directory Domain Services, DNS
IP: 10.0.10.101

Name: DC2
Roles: Active Directory Domain Services, DNS
IP: 10.0.10.102

Name: MEMBER
Roles: None
IP: 10.0.10.100

The AD DS forest uses the CONTOSO.LOCAL DNS namespace and has one custom site defined named FAKESITE. DCSERVER is servicing the Default-First-Site-Name and DC2 is servicing FAKESITE. FAKESITE has been assigned a subnet range that includes MEMBER. For tools I used Procmon to capture the registry entries that a domain-joined member’s Active Directory site is cached to. Additionally I used netsh to perform a network capture at boot up

Beyond the network flows, I was interested in observing the DCLocator (DSGetDcName) API behavior. I cleared the three registry entries listed below to ensure MEMBER would perform a DCLocator query at boot up. Additionally I used netsh to get a network capture at boot up (https://blogs.msdn.microsoft.com/canberrapfe/2012/03/30/capture-a-network-trace-without-installing-anything-capture-a-network-trace-of-a-reboot/) and Microsoft Network Monitor to analyze the capture.

– HKLMSystemCurrentControlSetServicesTcpipParametersDomain
– HKLMSystemCurrentControlSetServicesNetlogonParametersSiteName
– HKLMSystemCurrentControlSetServicesNetlogonParameterDynamicSiteName

With the background information taken care of, let’s jump into workstation authentication process.

  1. Source: Domain-joined machine
    Destination: Primary DNS Server
    Connection: UDP
    Port: 53
    Protocol: DNS
    Purpose: DsGetDcName API on domain-joined machine uses the information collected from the registries entries listed at the bottom of this step to issue a DNS query for an SRV record to the machine’s primary DNS server for a server offering an LDAP service _ldap._tcp.dc_msdsc.contoso.local. The primary DNS server returns the results of the SRV query.

    • HKLMSystemCurrentControlSetServicesTcpipParametersHostname
    • HKLMSystemCurrentControlSetServicesTcpipParametersDomain
    • HKLMSystemCurrentControlSetServicesTcpipParametersNameServer
    • HKLMSystemCurrentControlSetServicesTcpipParametersDhcpNameServer
    • HKLMSystemCurrentControlSetServiesNetlogonParametersSiteName
    • HKLMSystemCurrentControlSetServiesNetlogonParametersDynamicSiteName
  2. Source: Domain-joined machine
    Destination: Primary DNS Server
    Connection: UDP
    Port: 53
    Protocol: DNS
    Purpose: DSGetDcName API on domain-joined machine issues a DNS query for the A record of a domain controller from the results of the SRV query. The primary DNS server returns the results of the A record query.

  3. Source: Domain-joined machine
    Destination: Domain Controller
    Connection: UDP
    Port: 389
    Protocol: LDAP
    Purpose: DsGetDcName API on domain-joined machine issues a specially crafted LDAP query (referred to by Microsoft as an LDAP Ping) to the domain controller querying the RootDSE for the NetLogon attribute. The detail query is as follows:

    • Filter: (&(DnsDomain=)(Host=HOSTNAME)(DomainSID=)(DomainGUID=)(NtVer=)(DnsHostName=))
    • Attributes: NetLogon

    The domain controller passes the query to the NetLogon service running on the domain controller which evaluates the query to determine which site the server belongs in. The domain controller returns information about its state and provides the information detailed below (https://msdn.microsoft.com/en-us/library/cc223807.aspx):

    • Flags:
      • DSPDCFLAG – DC is PDC of the domain
      • DSGCFLAG – DC is a GC of the forest
      • DSLDAPFLAG – Server supports an LDAP server
      • DSDSFlag- DC supports a DS and is a domain controller
      • DSKDCFlag DC is running KDC service
      • DSTimeServFlag – DC is running time service
      • DSClosestFlag – DC is in the closest site to the client
      • DSWritableFLag – DC has a writable DS
      • DSGoodTimeServFlag (0) – DC is running time service
      • DSNDNCFlag – DomainName is a non-domain NC serviced by the LDAP server
      • DSSelectSecretDomain6Flag – the server is a not an RODC
      • DSFullSecretDomain6Flag – The server is a writable DC
      • DSWSFlag – The Active Directory Web Service is present on the server
      • DSDNSControllerFlag – DomainControllerName is not a DNS name
      • DSDNSDomainFlag – DomainName is not a DNS name
      • DSDNSForestFlag – DnsForestName is not a DNS name
    • DomainGuid:
    • DnsForestName: contoso.local
    • DnsDomainName: contoso.local
    • DnsHostName: DCSERVER.contoso.local
    • NetbiosDomainName: CONTOSO
    • NetbiosComputerName: DCSERVER
    • Username:
    • DcSiteName: Default-First-Site-Name
    • ClientSiteName: FAKESITE
    • NextClosestSIteName: Default-First-Site-Name

    The client caches this information to its DCLocator cache and will perform another LDAP Ping to another domain controller if it was determined the domain controller is not within the client’s site.

  4. Source: Domain-joined machine
    Destination: Same Site or Closest Site Domain Controller
    Connection: TCP
    Port: 445
    Protocol: SMB
    Purpose: The domain-joined workstation sends an SMB2 NEGOTIATE Request to the domain controller and receives back an SMB2 Negotiate Response. This process allows the machines to agree upon an authentication mechanism. This SMB session will be leveraged through the logon process to communicate with a domain controller’s SYSVOL to process group policy and run any startup scripts.
    Links:

  5. Source: Domain-joined machine
    Destination: Primary DNS Server
    Connection: UDP
    Port: 53
    Protocol: DNS
    Purpose: DsGetDcName API issues a DNS query for an SRV record to the machine’s primary DNS server for a domain controller offering the Kerberos service using the SRV record of _kerberos._tcp.dc._msdcs.contoso.local. The primary DNS server returns the results of the SRV query.

  6. Source: Domain-joined machine
    Destination: Domain Controller
    Connection: UDP
    Port: 389
    Protocol: LDAP
    Purpose: DsGetDcName API on domain-joined machine issues a specially crafted LDAP query (referred to by Microsoft as an LDAP Ping) to the domain controller querying the RootDSE for the NetLogon attribute. The detail query is as follows:

    • Filter: (&(DnsDomain=)(Host=HOSTNAME)(DomainGUID=)(NtVer=)(DnsHostName=))
    • Attributes: NetLogon

    The domain controller passes the query to the NetLogon service running on the domain controller which evaluates the query to determine which site the server belongs in. The domain controller returns information about its state and provides the information detailed below (https://msdn.microsoft.com/en-us/library/cc223807.aspx):

    • Flags
      • DSPDCFLAG – DC is PDC of the domain
      • DSGCFLAG – DC is a GC of the forest
      • DSLDAPFLAG – Server supports an LDAP server
      • DSDSFlag- DC supports a DS and is a domain controller
      • DSKDCFlag DC is running KDC service
      • DSTimeServFlag – DC is running time service
      • DSClosestFlag – DC is in the closest site to the client
      • DSWritableFLag – DC has a writable DS
      • DSGoodTimeServFlag (0) – DC is running time service
      • DSNDNCFlag – DomainName is a non-domain NC serviced by the LDAP server
      • DSSelectSecretDomain6Flag – the server is a notan RODC
      • DSFullSecretDomain6Flag – The server is a writable DC
      • DSWSFlag – The Active Directory Web Service is present on the server
      • DSDNSControllerFlag – DomainControllerName is not a DNS name
      • DSDNSDomainFlag – DomainName is not a DNS name
      • DSDNSForestFlag – DnsForestName is not a DNS name
    • DomainGuid:
    • DnsForestName: contoso.local
    • DnsDomainName: contoso.local
    • DnsHostName: DCSERVER.contoso.local
    • NetbiosDomainName: CONTOSO
    • NetbiosComputerName: DCSERVER
    • Username:
    • DcSiteName: Default-First-Site-Name
    • ClientSiteName: FAKESITE
    • NextClosestSIteName: Default-First-Site-Name

    The client caches this information to its DCLocator cache and will perform another LDAP Ping to another domain controller if it was determined the domain controller is not within the client’s site.

  7. Source: Domain-joined machine
    Destination: Same Site or Closest Site Domain Controller
    Connection: TCP
    Port: 88
    Protocol: Kerberos
    Purpose: The domain-joined machine attempts to verify its identity with the domain controller by sending a KRB-AS-REQ without pre-authentication data. The domain controller checks the object that represents the principal to determine if the account has the “Do not require Kerberos preauthentication.” If the option is not checked, the domain controller returns KRB_ERROR (25) indicating preauthentication data is required.

  8. Source: Domain-joined machine
    Destination: Same Site or Closest Site Domain Controller
    Connection: TCP
    Port: 88
    Protocol: Kerberos
    Purpose: The domain-joined machine re-attempts to verify its identity with the domain controller by sending a KRB-AS-REQ with pre-authentication data. The domain controller validates the principal’s identity and responds with a KRB-AS-REP which includes a Kerberos TGT for the principal to use to obtain additional Kerberos service tickets.

  9. Source: Domain-joined machine
    Destination: Same Site or Closest Site Domain Controller
    Connection: TCP
    Port: 88
    Protocol: Kerberos
    Purpose: The domain-joined machine requests a service ticket for CIFS service running on the domain controller by sending a KRB-TGS-REQ for the CIFS service principal. The domain controller validates the machine’s Kerberos TGT and returns a service ticket for the CIFS service. The domain-joined machine will use the service ticket to authenticate to the SMB service in order to access the SYSVOL share.

  10. Source: Domain-joined machine
    Destination: Same Site or Closest Site Domain Controller
    Connection: TCP
    Port: 88
    Protocol: Kerberos
    Purpose: The domain-joined machine requests a service ticket for CIFS service running on the domain controller by sending a KRB-TGS-REQ for the CIFS service principal name. The domain controller validates the machine’s Kerberos TGT and returns a service ticket for the CIFS service. The domain-joined machine will use the service ticket to authenticate to the SMB service in order to access the SYSVOL share.

  11. Source: Domain-joined machine
    Destination: Same Site or Closest Site Domain Controller
    Connection: TCP
    Port: 88
    Protocol: Kerberos
    Purpose: The domain-joined machine requests a Kerberos TGT by sending a KRB-TGS-REQ for the KRBTGT service principal name. I have to admit, I’m pretty clueless on this one. The only usage I can find online references cross realm.

As you can see, there’s a ton of interesting chatter that only gets more interesting once we begin breaking down the SMB conversation. The SMB portion involved a ton of reading on my end, because I haven’t often done any deep dive troubleshooting into the protocol. As always, I’ll include the links that helped me along the learning path as we cruise through those sections. See you on the next post!

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.

picture1

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.

picture2

The next Kerberos exchange is performed in these two frames.

picture3

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.

picture4

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.

picture5
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:

picture6

The third exchange is where see a difference:

picture7

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.

picture8

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.