How To Integrate Microsoft Azure Active Directory to Authenticate SharePoint 2013 for External Users


A few days ago I was designing a new Extranet solution for one of our clients.

The customer had the following requirements for the extranet with regard to authentication of external users.

– Manage external users and groups is an easy to use interface

– Users can manage their passwords themselves

– 2-factor authentication

– No access to other resources

Our first idea was to implement external access using ADFS with the federated parties, although it will work great for other extranet scenario’s, it did not met all of our requirements.

The second idea was to use Azure with WAAD (Windows Azure Active Directory) and ACS (Access Control Services) to met our goals. The WAAD would provide identities for our environment, supports multifactor authentication and users can reset their passwords themselves!

Get Started

So lets gets started with our Proof-of-Concept! The first hit on google regarding this scenario is a great blog post from Steve Pescka (http://blogs.technet.com/b/speschka/archive/2013/05/10/integrating-sharepoint-2013-with-azure-active-directory-part-1-configuration.aspx). He wrote several blog items about this topics which was really supporting the configuration.

Prerequisities

– Azure account (https://account.windowsazure.com/signup?offer=ms-azr-0044p to sign up)

– SharePoint 2013 Environment

Create Azure Active Directory

– Login to https://manage.windowsazure.com

– Go to Active Directory

– Press Add

– If you want to use an existing Azure Active Directory (like the one you use for Office 365), choose for Existing Directory. You will be asked to re-signin with an global administrator of the Office 365 tenant, after this process the Azure Active Directory is connected to you Azure account.

– For a new directory, fill in your directory details, if you want to use a custom domain you can add this afterwards.

– The Directory is ready to use. To use the features, password reset and groups you also need to Enable Active Directory Premium

– Click on Add a user

– Fill in the wizard and choose the role “Global Administrator”

– Download the Windows Azure Active Directory Shell
http://technet.microsoft.com/en-us/library/jj151815.aspx#bkmk_installmodule

Create ACS Service in Azure

If you have already setup a ACS namespace you can skip this step.

– Go to https://manage.windowsazure.com

– Press New, and add a new Access Control namespace

– Fill in a name and region and proceed

– Your ACS namespace will now be created

Configure Identity Provider in ACS

Configure the WAAD as an identity provider in ACS

– Go to https://manage.windowsazure.com

– Go to Active Directory

– Go to Access Control Namespaces and select your newly created namespace

– Go to Manage

– Go to Trust relationshops > Identity Providers

– Click on Add Identity Provider

– Choose a WS Federation provider

– Fill in a Descriptive Name and use https://accounts.accesscontrol.windows.net/<waad-name>/FederationMetadata/2007-06/FederationMetadata.xml as WS metadata URL. Provide your own WAAD or use a more general approach to allow multiple WAAD’s to sign in to your SharePoint 2013 environment using the federation url https://login.windows.net/common/FederationMetadata/2007-06/FederationMetadata.xml

Configure Relying Party Trust in ACS

Now we need to configure the on-premises SharePoint 2013 environment as the relying party

– Go to relying party applications

– Click on Add, choose to enter settings manually.

– Fill in a realm, in this example urn:sharepoint:acs, but it can be any realm (and take note of this, we need this later on)

– Select Token form SAML 1.1. (unfortunately SharePoint 2013 (and 2010) do not support SAML 2.0)

– Select the identity provider selected earlier

– Press Save

Configure Group Rules

Now we need to generate and configure the claim translation from the WAAD claim to an workable claim for SharePoint 2013.

– Go to Group Rules

– Click on Add, fill in a Group name “AAD Rules” and click Save

– Click on Generate

– Select the IdP created earlier and click Generate

– Select the Output claim UPN

– Set the input claim type to http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name instead of upn, because this input claim is empty. The name claim will contain the upn.

– Set the output claim type to http://schemas.microsoft.com/ws/2008/05/identity/claims/upn , which will be accepted by the STS of SharePoint.

– Click on Save

Enabled Application for WAAD to authenticate

– Execute the following Powershell

<code>

$replyUrl = New-MsolServicePrincipalAddresses –Address “https://<youracs>.accesscontrol.windows.net/v2/wsfederation”

New-MsolServicePrincipal –ServicePrincipalNames @(“https://<youracs>.accesscontrol.windows.net/”) -DisplayName “Joran Markx Tenant” -Addresses $replyUrl

</code>

Configure SharePoint to use ACS

– Go to Development -> Application integration

– Copy and paste the WS-Federation Metadata into the internet browser

– Copy and paste the base64 code in EntityDescriptor>RoleDescriptor>KeyDescriptor>..>X509Certificate to a notepad and save as .cer file (Certificate)

– Open the certificate to check if it is working great! If it does not, please check if you copied the whole X509Certificate and the file is saved with ANSII.

– Copy the .cer to the SharePoint 2013 Server

Create and configure STS in SharePoint

Now we need to create a new Trusted Root Authority and configure the Trusted Identity Token Issues.

– Open the SharePoint Management Shell (as Administrator)

<code>
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“c:aadcert.cer”)

New-SPTrustedRootAuthority -Name “ACS Token Signing Certificate” -Certificate $cert

$map = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.microsoft.com/ws/2008/05/identity/claims/upn” -IncomingClaimTypeDisplayName “UPN” -SameAsIncoming

$map2 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.microsoft.com/ws/2008/06/identity/claims/role” -IncomingClaimTypeDisplayName “Role” -SameAsIncoming

$map3 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress” -IncomingClaimTypeDisplayName “EmailAddress” -SameAsIncoming

$map4 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname” -IncomingClaimTypeDisplayName “GivenName” -SameAsIncoming

$map5 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname” -IncomingClaimTypeDisplayName “SurName” -SameAsIncoming

$map6 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/jobtitle” -IncomingClaimTypeDisplayName “JobTitle” -SameAsIncoming

$map7 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/office” -IncomingClaimTypeDisplayName “Office” -SameAsIncoming

$realm = “urn:sharepoint:acs”

$ap = New-SPTrustedIdentityTokenIssuer -Name “AAD” -Description “ACS” -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2,$map3,$map4,$map5,$map6,$map7 -SignInUrl “https://litware.accesscontrol.windows.net:443/v2/wsfederation” -IdentifierClaim http://schemas.microsoft.com/ws/2008/05/identity/claims/upn
</code>

– Create or configure a webapplication in SharePoint with Claims Authentication and select the new TrustedIdentityToken Issuer

– Authorize add at least one user from the WAAD to the a site in the webapplication

– You’re ready to go!

Test the solution

– Fire up a browser and go to your SharePoint site

– Select AAD, you will not get this screen if you disable Windows Authentication (and have only one authentication provider)

– Then select one of the IdP in ACS, you will not see this screen if you only have one IdP configured.

– You will now get the Azure Active Directory Login screen

– After entering your username and password, you will be redirected to SharePoint 2013 and will be logged in!

Known issues

– People picker will not find people in the directory
http://blogs.technet.com/b/speschka/archive/2013/05/12/integrating-sharepoint-2013-with-azure-active-directory-part-2-the-custom-claims-provider.aspx

Advertisements

About Cloud Architect Joran Markx
I have been working on Microsoft Technology since 2003. In addition to (lead) developer and software architect, I am certified Microsoft Specialist and active in design and implementation of Hybrid Cloud platforms. In 2011 I have achieved a Master of Science in IT Management. This made me capable to solve complex issues from the business in an efficient and structured way. As Cloud Architect I am working on various challenging projects with a variety of clients. Within my organisation I fullfill a leading role when it comes to internal development and sharing of knowledge. My goal is to provide reliable and predictable services to our clients with a strong focus on the results achieved for the organisations I am working for.

8 Responses to How To Integrate Microsoft Azure Active Directory to Authenticate SharePoint 2013 for External Users

  1. Thomas Petersen says:

    I get a response from SharePoint that Access is Required (_layouts/15/AccessDenied.aspx). But I have added the user to the site. Any suggestions for troubleshooting?

    • Hi Thomas, can you try to create a new standard teamsite and assign permissions to the given user?. You can inspect the ULS logs, to find out which object is causing the issue.

  2. Michael Vasquez says:

    I am receiving the following error message when running the powershell

    Connect-MsolService
    # Load the extended module to support the right parameters needed
    Import-Module MSOnlineExtended -Force
    # Set up the address with the root access of your ACS
    $replyUrl = New-MsolServicePrincipalAddresses –Address

    PS C:\Windows\system32> C:\ConnectPsigenACS.ps1
    Connect-MsolService : The type initializer for ‘Microsoft.Online.Administration.Automation.ConnectMsolService’ threw an exception.
    At C:\ConnectPsigenACS.ps1:1 char:1
    + Connect-MsolService
    + ~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : OperationStopped: (:) [Connect-MsolService], TypeInitializationException
    + FullyQualifiedErrorId : System.TypeInitializationException,Microsoft.Online.Administration.Automation.ConnectMsolService

    The following symmetric key was created as one was not supplied cB5PMlqbMssNulymtURJ4lX0TSr2u+NDsmPZmZiVCxs=
    New-MsolServicePrincipal : You must call the Connect-MsolService cmdlet before calling any other cmdlets.
    At C:\ConnectPsigenACS.ps1:7 char:1
    + New-MsolServicePrincipal –ServicePrincipalNames @(“https://psigen2.accesscontrol …
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : OperationStopped: (:) [New-MsolServicePrincipal], MicrosoftOnlineException
    + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.MicrosoftOnlineException,Microsoft.Online.Administration.Automation.NewServicePrincipal

  3. Michael Vasquez says:

    the following is exactly my same issue, but his resolve did not work for me. I am currently updating my server to see if that helps.

    • Michael Vasquez says:

      http://grishbi.com/2014/03/104/

      • Thank you Michael, for adding your solution.

  4. Michael Vasquez says:

    Still not working. i never got your script to run and Enabled Application for WAAD to authenticate.

    Do you have the script available for download and all dependencies? I am using Windows Server 2012 R2

    • The only dependency I am aware of is the Azure Active Directory powershell and the SSO Assitant BETA. Maybe You can find some more background on Steve pescka blog.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: