Deep Dive Into Resource-Based Constrained Delegation – Part 2

Posted on by

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

Posted on by

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.

Azure AD and SharePoint Online / OneDrive for Business Part 3

Posted on by

So you’ve read through part 1 and part 2 in this series as well as the attached links, right? 🙂 Excellent, let’s dive right into it.

Introducing Guest Users

When a licensed user of Office 365 needs to share data with a business partner the concept of an Azure AD guest user comes into play. Guest users are representations of Microsoft Live and Azure AD users that exist outside the user’s tenant. AAD Guest Users are created using three primary methods:

  1. User is added through Azure AD tab of the Azure Management Portal using the option User in another Microsoft Azure AD Directory
  2. User accepts an invite sent through an Office 365 application such as SharePoint Online
  3. User is invited through Azure AD B2B

When one of three above actions are taken, a subset of information about the user’s identity is copied from the source identity (whether it be a Microsoft Live or Azure AD identity). At the time of this writing this is a one time sync. Microsoft has hinted that this may change as the expand the System for Cross-domain Identity Management (SCIM for short) capabilities in Azure AD. What does this one time sync mean to you? Well if information in the guest user’s source AAD changes, that data may not be updated on the AAD Guest User object.

AAD Guest Users always authenticate to their own identity provider, no credentials are synchronized during the provisioning process. This also means that you do not have the ability to enable MFA on a guest user. This may change at a later date, but is a limitation at this time. This link provides more detail on guest users including limitations..

Review of Configuration

Now that I’ve provided an overview of guest users, let’s dive a little deeper. Recall from part 1, I’m using the following configuration:

  • Azure AD Tenant 1
    Name: feltonma.onmicrosoft.com
    DNS Domain: feltonma.com
    Subscriptions: Azure AD Premium, Office 365 Business PremiumWe’ll refer to this instance of AAD as the destination AAD.
  • Azure AD Tenant 2
    Name: journeyofthegeek.onmicrosoft.com
    DNS Domain: journeyofthegeek.com
    Subscriptions: NoneThis is an independent instance of AAD.
  • Azure AD Tenant 3
    Name: junkfelton.onmicrosoft.com
    DNS Domain: None
    Subscriptions: NoneThis instance of AAD has been provisioned by a global admin of the destination AAD. This means that the global admin has the ability to add users from this instance of AAD to the destination AAD through the Azure Management Portal.
  • Azure AD Tenant 4
    Name: geekintheweeds.onmicrosoft.com
    DNS Domain: geeksintheweeds.com
    Subscription: NoneThis instance of AAD doesn’t exist yet. It will be provisioned when we leverage the B2B feature to invite a user that has an email address with the geeksintheweeds.com domain name.

Scenario 1 – Method 1 – Adding user through Azure Management Portal

In this first scenario I’ve added the user clark.devereaux@junkfelton.onmicrosoft.com from Azure AD Tenant 3 to our destination AAD via method 1. Let’s take a look at three key attributes using the Azure AD PowerShell module.

Queried from Azure AD Tenant 3 (source AAD)

clarksource.png

Queried from Azure AD Tenant 1 (destination AAD)

clarkdest

Notice anything? The AlternateEmailAddresses attribute in the destination AAD doesn’t include the value from the source AAD. This means that the destination AAD doesn’t know about the user’s email address. Additionally, this user has no value in CloudExchangeRecipientDisplayType attribute (more on this attribute later). The net result of these two issues is the user is not considered mail enabled by Office 365 applications preventing Office 365 users from using built in features to email these users.

After I’ve granted the user access to a site in SharePoint Online and attempt to access that site as the clark.devereaux@junkfelton.onmicrosoft.com user, I receive the following error:

clarkerror

Why is this occurring? I will hold off on answering that question until we cover some additional scenarios.

Scenario 1 – Method 2 – Using SharePoint Online Invite System

In the second scenario I have added the user michael.walsh@journeyofthegeek.onmicrosoft.com from Azure AD Tenant 2 to the destination AAD via method 2. There are some interesting differences in what information is populated in the destination AAD.

Queried from Azure AD Tenant 1 (destination AAD)

walshdest

Notice that the SignInName attribute has a value equal to the email address the invitation link was sent to. Additionally you’ll notice that values in the ProxyAddresses attribute include the user’s email address that has been configured in the AlternateEmailAddresses attribute in the source AAD instance. The CloudExchangeRecipientDisplayType also comes into play here.

The CloudExchangeRecipientDisplayType attribute is used to denote a mail-enabled user in Office 365. This attribute is the counterpart of the Exchange on-premises attribute msExchangeRecipientDisplayType as explained in this link. From my experience so far, AAD Guest User accounts that are mail-enabled have a value of 6 which means it is a Remote Mailbox (explained here. Interesting that the AAD Guest User we added via Method 1 doesn’t have a value of 6 isn’t it?

Scenario 3 – Method 3 – Inviting User through Azure AD B2B

In the last scenario I’ve added the user lawrence.cohen@geekintheweeds.com from Azure Tenant 4 via the Azure AD B2B feature. As I’ve explained above, prior to my invite there was no Azure AD instance associated with the geekintheweeds.com domain. After I accepted the B2B invite and went through the process of setting up the new Azure AD account, Microsoft spun up a new Azure AD instance associated with the geekintheweeds.com domain. This new instance can be taken over by anyone who can prove ownership of the geekintheweeds.com domain.

Let’s take a look at the user in the destination AAD instance and the source:

Queried from Azure AD Tenant 1 (destination AAD)
lawdest

Queried from Azure AD Tenant 4 (source AAD)
lawsource

Here we see that the AAD Guest User in this scenario is very similar to the AAD Guest User in the second scenario. The only significant difference is the source directory ProxyAddresses attribute is populated with a value. Note that while not displayed, this user also has a CloudExchangeRecipientDisplayType attribute with a value of 6.

Users in scenarios 2 and 3 can access the shared Office 365 content without issues. So why does the user in scenario 1 fail? Well, the best I can offer is a guess since I’ve been unable to find information on the identifier SharePoint Online uses to query for a user in Azure AD. From comparing how the users are represented in the destination, my guess is it has something to do with the user’s email address. In both scenarios that worked, the user’s SignInName attribute had a value of the user’s email address.

There is one other quirky thing I noticed when adding a user to the destination AAD using method 1. Let’s take a look at some of the most interesting attributes of the three users when queried via PowerShell from the destination AAD.

  • User added through Azure Management Portal
    AlternateEmailAddresses: {clark.devereaux@junkfelton.onmicrosoft.com}
    CloudExchangeRecipientDisplayType:
    SignInName: clark.devereaux@junkfelton.onmicrosoft.com
    StrongAuthenticationUserDetails: Microsoft.Online.Administration.StrongAuthenticationUserDetails
    StrongPasswordRequired: True
    UserPrincipalName: clark.devereaux_junkfelton.onmicrosoft.com#EXT#@feltonma.onmicrosoft.com
    UserType: Member
  • User added through an invite via SharePoint OnlineAlternateEmailAddresses: {michael.walsh@journeyofthegeek.onmicrosoft.com}
    CloudExchangeRecipientDisplayType: 6
    ProxyAddresses: {smtp:michael.walsh_journeyofthegeek.onmicrosoft.com#EXT#@feltonma.com, SMTP:michael.walsh@journeyofthegeek.com}
    SignInName: michael.walsh@journeyofthegeek.com
    UserPrincipalName: michael.walsh_journeyofthegeek.onmicrosoft.com#EXT#@feltonma.com
    UserType: Guest
  • User added through Azure AD B2BAlternateEmailAddresses: {lawrence.cohen@geekintheweeds.com}
    CloudExchangeRecipientDisplayType: 6
    ProxyAddresses: {smtp:lawrence.cohen_geekintheweeds.com#EXT#@feltonma.onmicrosoft.com, SMTP:lawrence.cohen@geekintheweeds.com}
    SignInName: lawrence.cohen@geekintheweeds.com
    UserPrincipalName: lawrence.cohen_geekintheweeds.com#EXT#@feltonma.onmicrosoft.com
    UserType: Guest

Notice something odd? The user I added through the Azure Management Portal is configured as a UserType of Member instead of a Guest. Odd huh? If this is by design, I haven’t been able to find any articles describing the reason why.

Take a look at the users within the Azure AD tab in the Azure Management Portal:

portal

All users display as being sourced from another directory, yet this user is a user type guest. Super weird.

Summing it all up

It seems that users added via Method 1 cannot natively access information shared with them in Office 365. I plan on playing with the attributes a bit to see if can make it work, but even if that works, that is an ugly solution.

Method 2 and 3 both work as they should. So what’s the big deal? Well it comes down to control. If I want to have tight control over who my users can share data with, Method 1 would be a reasonable solution because it would require either the User Management or Global Admin role in Azure AD and I could even provision another tenant and provision users to it. Those users could have both company and consumer email addresses.

Method 2 means I have to give us some of my control to my users. In a large enterprise where roles and responsibilities are highly distributed and the enterprise has very sensitive data, there could be significant risk to handing over that control.

Method 3 seems to be the direction Microsoft wants to move. While B2B is extremely slick, there are limitations that come with it. One such limitation is the users I need to share data with can’t use consumer email domains. I haven’t tested whether or not Microsoft Live accounts associated with a consumer email address work, so that needs to be tested.

Diving deeper into situations like this really help put the puzzle pieces together on how each part of Azure works together to form the solution. It also helps reinforce the speed of change and innovation occurring within Azure and how important it is to have a good knowledge set in the foundations of the solution to keep up with that change.

In my next post I’ll dive a bit deeper and try to test some of the unknowns I’ve discussed above.

Azure AD and SharePoint Online / OneDrive for Business Part 2

Posted on by

Welcome back. Today I will do a high level overview of the the options available for sharing information from within SharePoint Online and OneDrive for Business.

A SharePoint Online/OneDrive for Business subscription is associated with an AAD instance. Users that exist outside of that AAD instance are considered “external” users. Microsoft has configured four primary options for sharing information within SharePoint Online / OneDrive for Business. These options are:

  1. Don’t allow sharing outside your organization
  2. Allow sharing only with the external users that already exist in your organization’s directory
  3. Allow external users who accept sharing invitations and sign in as authenticated users
  4. Allow sharing with all external users, and by using anonymous access links

This link has a great explanation of the differences in each option from a functionality perspective, but I’ll spend some time on explaining what these things mean from an Azure AD perspective.

Option 1 is self explanatory if you read the above link so I won’t be covering that one.

Option 2 limits a user to sharing information with users who are directly members of their AAD instance or have already been configured as guest users. When a user attempts to add a user that doesn’t fall into those two categories, he or she observes the following error when attempting to share a SharePoint Online site (wonderfully descriptive by the way MS):

outsideorg.png

The error when attempting to share a OneDrive for Business folder is much more informative:

onedrive

Option 3 limits a user to inviting users who have or obtain a Microsoft Live ID or Azure AD identity. When the user receives the invite and authenticates to AAD, the user is provisioned into destination AAD as a guest user. My next post will spend more time talking about guest users.

Option 4 is similar to Option 3 but additionally allows for anonymous access via shared links.

These sharing options can be configured at the subscription and site collection level.

For more information on these options and how to configure them, take a read through the links below.

In my next post I’ll spend some time examining the different methods to add guest users and how the method of adding the user can affect the ability to share with that guest user. Additionally, I’ll spends some time exploring how a guest user looks from an attribute perspective.