How to configure a relying party trust between on-premises AD FS and Microsoft Azure AD for single sign-on in Microsoft Intune

ADFS_SSOOne of the things that is often requested by customers is to configure single sign-on for Microsoft Intune (with or without ConfigMgr integration). The main reasons for that request are simple, it’s to make the user experience better and to prevent the user from having different accounts and passwords. In this blog post I will show how relatively easy it is to federate on-premises Active Directory Federation Services (AD FS) with the Microsoft Azure Active Directory (Micorosoft Azure AD). The best thing about this is that after this configuration is done, all Microsoft Intune authentication requests will redirect to the on-premises AD FS.

Also, in this post I will skip a few important steps (see prerequisites). I assume that those steps are more common knowledge. If that’s not the case, please let me know.

Prerequisites

A few important installations and configurations should be in place before trying to use the configuration mentioned further in this post. To be able to configure a relying party trust between the on-premises AD FS and the Microsoft Azure AD make sure that following installations and configurations are in place:

Configuration

When all the prerequisites are in place, it’s time to start with creating the federation. In a maximum of six relatively simple steps it is possible to create a relying party trust between the on-premises AD FS and the Microsoft Azure AD. This trust will make sure that the Microsoft Azure AD will trust the authentication response of the on-premises AD FS. The easiest method to create this trust is to use PowerShell. In the following six steps I will name the required cmdlets and explain the actions that it will perform.

  1. The first step is to make sure that the Microsoft Azure Active Directory PowerShell Module is installed.
  2. The second step is to load the cmdlets by either starting Microsoft Azure Active Directory Module for Windows PowerShell, or by importing the module via the following command.
    Import-Module MSOnline

  3. The third steps is to connect to the Microsoft Azure AD (used by Microsoft Intune) by using the cmdlet Connect-MsolService. An easy method to provide the required credentials, to connect to the Micosoft Azure AD, is to use an empty variable. This empty variably will make sure that the cmdlet prompts for the credentials of the Microsoft Intune subscription. Simply use the –Credentials parameter to specify the credentials (parameter) by running a command like the following.
    Connect-MsolService –Credential $cred

  4. (Optional) The fourth step is to connect to the on-premises primary AD FS server by using the cmdlet Set-MsolADFSContext. Simply use the –Computer parameter to specify the name of the on-premises primary ADFS server by running a command like the following.
    Set-MsolADFSContext -Computer cldsrv01.ptcloud.local

  5. The fifth step is to add a new single sign-on domain, also known as an identity-federated domain, to the Microsoft Azure AD by using the cmdlet New-MsolFederatedDomain. This cmdlet will perform the real action, as it will configure a relying party trust between the on-premises AD FS server and the Microsoft Azure AD. Simply use the –DomainName parameter to specify the name of the single sign-on domain by running a command like the following.
    New-MsolFederatedDomain –DomainName petervanderwoude.nl

  6. (Optional) The sixth step is to convert the domain from standard authentication to single sign-on, also known as identity-federated, by using the cmdlet Convert-MsolDomainToFederated.  This cmdlet will perform the real action, as it will convert the domain from standard authentication to single sign-on and also configures a relying party trust between the on-premises ADFS server and the Microsoft Azure AD. Simply use the –DomainName parameter to specify the name of the single sign-on domain by running a command like the following. 
    Convert-MsolDomainToFederated –DomainName petervanderwoude.nl

Note: Step 4 is only required when the cmdlets are not used locally on the AD FS server and step 6 is only required if the new single sign-on domain already exists as a standard authentication domain. In that last case a very clear message stating New-MsolFederatedDomain : The domain already exists as a standard authentication domain.  To convert the domain to identity federation, use convert-MSOLDomainToFederated. will show after performing step 5.

Result

ADFS_exampleAfter setting up the federation with Microsoft Azure AD, every logon to one of the Microsoft Online Services will redirect to the on-premises AD FS when a user name with the UPN of @petervanderwoude.nl is used. This includes Microsoft Intune. For demonstration purposes I can go to https://admin.manage.microsoft.com/ to see if it all works. As soon as I use an user account with the @petervanderwoude.nl UPN, the login page will automatically redirect to the on-premises AD FS server. This way the credentials will be verified on-premises.

Other places to see the successful configuration are in the Account Portal of Microsoft Intune, in the on-premises AD FS configuration and of course via PowerShell by using the cmdlet Get-MsolFederationProperty.

Further reading

A simplified installation guide for single sign-on for Office 365: http://technet.microsoft.com/en-us/magazine/jj631606.aspx

A checklist to use AD FS to implement and manage single sign-on: http://technet.microsoft.com/en-us/library/jj205462.aspx

A scenario about managing identities for single-forest hybrid environments using on-premises authentication: http://technet.microsoft.com/library/dn550987.aspx

Share

3 thoughts on “How to configure a relying party trust between on-premises AD FS and Microsoft Azure AD for single sign-on in Microsoft Intune

  1. Hi!
    Is it possible to sign in with local AD user to application secured by OAuth WITHOUT synchronization of users from local AD to Azure AD? I would like to configure relying party trust, add custom domain but I don’t want to keep user from local AD in Azure AD. Has it sense?

Leave a Comment