Using Azure AD to enable partner access to SharePoint 201x

Introduction

The following summarizes my experience with setting Azure AD as authentication provider for Sharepoint 2013 or 2016. This setup enables access to SharePoint for external users (business partners, customers). While there are other approaches that could be used for this purpose, e.g. an on-premises AD with ADFS, using Azure AD has a number of advantages:

1. No need to create new identities for these users, which implies costs and risks of having own processes to manage user life-cycle in the directory (e.g. handling lost/forgotten passwords).
2. No need to create and maintain hardware and network infrastructure to maintain the directory.
3. External users can use their own corporate or social credentials or manage their own passwords.

Lastly, when the on-premises SharePoint is moved to O365  SharePoint Online, all that is needed is a simple checkbox selection to maintain the external user access to the new environment: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-b2b-o365-external-user.

Architecture

The basic architecture of this approach is shown below.

The Root Azure AD tenant serves as the primary token supplier to SharePoint. However, using the Azure Ad B2B features, it contains links to other users invited to be guests in that tenant: https://azure.microsoft.com/en-us/documentation/articles/active-directory-b2b-collaboration-overview/. These user’s credentials are maintained in their own host tenants. Users whose organizations already have an Azure AD tenant (e.g. because they are using O365) will use their regular corporate credentials to authenticate. For others, Azure AD will set up a viral, in-managed tenant and ask these users to create a new password. Users with Microsoft Accounts will be able to these to login as well.

ADFS in this scenario serves to convert tokens issued by Azure AD from the SAML2.0 to SAML1.1 format needed by SP. It also normalizes the UPN claim handled differently for work and social accounts in Azure AD.

Setup steps

The sequence of steps needed to set this environment up is described below. It assumes that both an Azure AD tenant (root tenant) and SharePoint installation with AD, ADFS and WAP have been completed. In addition to that, the following set up will be needed:

1. Configure Azure AD to service token requests from ADFS
2. Configure ADFS to use Azure AD root tenant to a Claims Provider
3. Configure SharePoint as Relying Party in ADFS
4. Configure SharePoint to use Azure AD to provide People Picker data (optional)
5. Invite external users using the B2B process

Optionally, the user experience can be enhanced by ensuring that on-premises users always use AD rather than being presented with a choice of using AD or Azure AD, and by enabling a People Picker in SharePoint which uses Azure AD as source of user information.

Configure Azure AD to service token requests from ADFS

Use Azure portal (https://portal.azure.com) or PowerShell to add your ADFS as an application. You will need to configure the following parameters:

Application id must be the same as the ADFS’ Federation Service Identifier (see below).

Reply url must be the public address of the ADFS server with adfs/ls suffix, e.g. https://myadfs.contoso.com/adfs/ls

Signin url should be the public address for the SharePoint site. It will be used in the user’s myapps.microsoft.com portal as entry point to SharePoint. This approach works only if there is only one site all users will be accessing. If there are multiple sites, the myapps portal cannot be used.

Configure ADFS to use Azure AD

Use ADFS management console or PowerShell to add Azure AD as a Claims Provider. All that is needed is to provide Claims Provider functionality with the Azure AD Federation Metadata address, e.g. https://login.windowsazure.com/contoso.onmicrosoft.com/federationmetadata/2007-06/federationmetadata.xml.

Configure ADFS to accept all claims from Azure AD

Use the following claim rule to pass all incoming claims from Azure AD to the issuance pipeline:

c:[]  => issue(claim = c);

Configure SharePoint as relying party in ADFS

Use ADFS management console or PowerShell to SharePoint as a Relying Party. The following values will need to be used in this operation (replace contoso with your organization name)

Relying party identifier: urn:sharepoint:contoso

Enable WS-Federation and provide the following passive reply url: https://<address of the SP site>/_trust/

Configure Claim Issuance rules for SharePoint

SharePoint will use UPN as user identifier. Azure AD uses different claim types for users who logged in with work or social addresses. Therefore the following claim issuance rules will be needed:

Convert an incoming name claim (work address user) to UPN:

c:[Type == “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name”]
 => issue(Type = “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn”, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

Convert an incoming email claim (social user) to UPN:

c:[Type == “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress”]
 => issue(Type = “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn”, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

Configure ADFS to use AD only for intranet users (optional)

If the ADFS is also used as federation provider to Azure AD (for O365 users for example) configure the following setting using PowerShell:

Set-AdfsRelyingPartyTrust -TargetName <name of Azure AD as RP in ADFS, e.g. O365 Directory> -ClaimsProviderName @(“Active Directory”)

To automatically redirect all users redirected to ADFS by SharePoint, use the following PowerShell command:

Set-AdfsRelyingPartyTrust -TargetName <name of SP as Relying Party in ADFS>  -ClaimsProviderName @(“Contoso AAD”)

Finally, to have all intranet users use AD and not be redirected to Azure AD execute the following command:

Set-AdfsProperties -IntranetUseLocalClaimsProvider $true

Where Contoso AAD is the name of the Azure AD tenant as Claims Provider in ADFS (see earlier step)

Configure SharePoint to use ADFS as federation provider

To configure SharePoint to use ADFS as token provider obtain the public key of the ADFS signing certificate. It can be obtained either directly or by extracting it from the federation metadata document of the ADFS. That file (.cer) is then used in the following PowerShell script:

Add-PSSnapIn Microsoft.SharePoint.PowerShell
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“c:\adfs cert file.cer”)
New-SPTrustedRootAuthority -Name “ADFS” -Certificate $cert
$map = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn” -IncomingClaimTypeDisplayName “UPN” -SameAsIncoming
$realm = “urn:sharepoint:contoso”
$ap = New-SPTrustedIdentityTokenIssuer -Name “ADFS” -Description “SharePoint secured by SAML from AAD via ADFS” -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map -SignInUrl “https://adfs.contoso.local/adfs/ls/” -ProviderSignoutUrl “https://adfs.contoso.local/adfs/ls/” -IdentifierClaim “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn”

Note that realm name must be exactly as entered earlier in ADFS and the provider sign/in/out url must correspond to the ADFS address. (SP 2013 update 2 needs to be installed before the sign out option shows up; in SP 2016 these options do not have the word ‘Provider’ in their name).

Finally enable use of ADFS in SharePoint through the Central Administration -> Security -> Specify authentication providers and selecting the appropriate zone. You should see the following ui:

Install AzureCP to enable People Picker (optional)

Without any other setup, external users can be given access to individual SP sites by adding their upn to the allowed users lists. To enable a People Picker which allows using the Azure AD tenant to list or search for users, use a custom picker. There is an excellent one available here: https://github.com/Yvand/AzureCP

Invite external users

Use the Azure portal (https://portal.azure.com) to invite individual users from the outside of your organization. You need to have ‘User inviter’ privileges to access this functionality. The following shows the UI of Add user panle, after entering an email address with domain other that the current Azure AD tenant:

The Azure classic portal (https://manage.windowsazure.com) allows bulk upload of external user email addresses via the Add User functionality. Lastly, there is the B2B invitation API that can be used in an application to have full control over how external users are invited to the root Azure AD tenant.