Using Azure Active Directory for SSO with Dynamics 365 On-Premise

While Dynamics 365’s documentation is full of articles and tutorials about setting it up with Active Directory Federation Services, there is no mention of using Azure Active Directory for Single Sign On. Many replies in communities say that this is not possible, but today we are going to prove them wrong. As you might have guessed from the intro, using Azure Active Directory for authentication is possible even with Dynamics 365 on-premise. Which we are going to explore in this article.

Please note, that this is more of a Proof of Concept article and due to the limitations we discovered along the way, this method is not recommended for production.

Why use Azure AD directly?

There may be many reasons: First off, it provides more security, advanced attack protection methods, auditing, logging and much, much more. Next, even tho that Dynamics 365 installation requires Active Directory, you don’t need to use AD as an identity provider (except for the Deployment Administration) nor store users there (yes, for real! Dynamics doesn’t have to source users from Active Directory like many of the forums incorrectly state). Removing user’s dependency on Active Directory can allow you to deploy cloud-only IdP with on-premise Dynamics 365. And one more important thing - thanks to Azure AD, you can have Internet Facing Deployment (IFD) of Dynamics 365 without having to expose (or even run) your ADFS to the internet while being protected by Azure AD.

Existing solutions

Like I already mentioned, there are some solutions existing already, however none of them integrate Azure AD directly. I am going to shortly describe the alternative scenarios. Azure Access Control Service (ACS) This was probably the best solution, however since ACS is discontinued, you cannot use it anymore. Using independent ADFS with Azure AD as Claims Provider This solution is something we have being doing internally as well. Basically an independent ADFS deployment which has Azure AD configured as a Claims Provider (so ADFS acts like a proxy). There are few downsides of this - for example, you will have hard time extending login expiration period, since it is being inherited from Azure AD token. This is what we use in production.

Getting started

There are two paths for getting this deployed. First is migrating from existing Claims Based Authentication setup with ADFS and second (trickier) is getting a vanilla deployment of Dynamics 365 setup with Azure AD. We are going to start with the common setup - registering the Dynamics 365 instance into Azure Active Directory:

1. Navigate to Azure Portal and select Azure Active Directory or alternatively use Azure AD Portal directly.
2. Select Enterprise Applications and from Add your own app create a Non-gallery application and create it with your preffered name (I will be using 1box-01.crmlabs.tntg.cz).
3. Once you create the application navigate into the properties (there you can set a Logo for the users for example), and optionally turn off User assignment required option. This is going to allow everyone from your AAD to authenticate with Dynamics 365 (you can keep it on if you want to assign users to it manually or use group assignment).
4. Next navigate to Single sign-on from the left menu. Select SAML-based Sign-on from the drop down.
5. There, you have to set the application’s identifier and reply URL. Both should have the same value depending whether you are setting up the IFD or not:
   • IFD: You should have _https://auth.your-ifd-address.tld _there (you will have to do few more steps in the IFD specific section).
   • Non-IFD: You should have your instance address there, so for example: https://1box-01.crmlabs.tntg.cz
6. Next, download the Metadata XML from the SAML Signing Certificate section. You will want to upload that to your web server so it can be accessible by the Dynamics instance. Note the URL down, because you are going to need it in the next step (for me it was https://share.hajekj.net/1box-01.crmlabs.tntg.cz/FederationMetadata.xml). And save the changes.

Now, we are going to proceed to the deployment specific configuration.

Setting up Claims Based Authentication without IFD

This is the starting point if you are creating a new Dynamics 365 deployment. The pre-requisities are:

• Dynamics 365 deployed with Windows Authentication login
• Enabled HTTPS for Dynamics 365 deployment
• SQL Server Management Studio (SSMS) or SQL Operations Studio if you feeling experimental
• Application created in Azure AD (which we did in previous step)

This part is a bit tricky, so bear with me on this one. What we need to achieve is to set AAD as a Claims Based Authentication provider while no local users exist in your AD. By default, Dynamics 365 stores user names in DOMAIN\alias format (for example AD\hajekj, my UPN is hajekj@ad.crmlabs.tntg.cz), however I haven’t found a way to force login through AAD with the NT logon name, so we have to do following:

1. Now, we are getting to the tricky part: Open an In-Private browser window, navigate to your Dynamics 365 instance and login using Windows Authentication. Then navigate to the User management under Settings > Security > Users.
2. On the server, open the Dynamics 365 Deployment Manager. From the left menu, choose Configure Claims-Based Authentication.
3. Stepping through the wizard, enter the address of the FederationMetadata.xml you uploaded before.
4. Choose the encryption certificate (usually, the same certificate you are using for HTTPS).
5. Once you apply the changes, switch to the In-Private browser window you opened before and choose to create a new user. You may get few Windows Authentication prompts, just skip them and continue filling out the details.
6. Fill out the UPN of a user from AAD which you will use for Administrator - Jan Hajek@thenetw.org. Fill out the user’s Full Name and save (optionally set CAL _related information depending on your licensing). Then, you have to assign _System Administrator role to the user so you can sign-in and perform administrative tasks.
7. Note: If you now try to login, you are going to end up in a redirect loop. If you enable trace logging, you are going to fing out the error relates to an exception being thrown by username being undefined. This is caused by the fact, that Dynamics expects the username to be passed in http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn claim, however, Azure AD is unable to send it because it is part of restricted claims for some reason whereas ADFS has no issue with sending the claim. So we have to override the IdentityClaim configuration in the database. So far, I am not aware of this change having effect on any Dynamics functionality so you should be safe, however, if you are unfamiliar with SSMS, I suggest you backup the database, snapshot the server or something so you can revert the change.
8. Next, open up your SSMS, connect to your Dynamics 365 SQL instance and open MSCRM_CONFIG database. Find the table named dbo.FederationProvider, right click and choose Edit Top 200 Rows.
9. Find the row which is named IdentityClaim and change the value for all providers to http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier. This is going to make Dynamics to source the username from a different claim.
10. Now once you save the changes and restart the site (from Internet Information Services for example), you will be open to open the Dynamics and login with the account which you created in step 8.
11. Next, under this account, open the Users page again (Settings > Security > Users) and modify the original user’s User Name to their UPN (so hajekj@ad.crmlabs.tntg.cz in my case).
12. You shouldn’t have to use that account since your Azure AD account is already a System Administrator, however it may become necessary at some point (for example if you need Deployment Manager permission for deploying certain solutions).
13. Optional: In order to access CRM as the original account sourced from Azure AD, you have two options: Disable Claims-Based Authentication temporarily, which will return back to Windows Authentication (which will prevent AAD users from signing in), however when turning it back on, you just click through the wizard and the configuration including the IdentityClaim is going to stay.
14. Now you can create your users with their AAD User Principal Names and you are good to go. The user doesn’t have to exist in the Active Directory, since Dynamics will treat them as Federated users which they are anyways.

Modifying existing IFD deployment

The beginning and most of the steps are going to be similar as above, so I am going to refer to those by numbers so that I don’t have to copy paste same text multiple times.

1. First, go to your User administration (Settings > Security > Users) and verify whether users have their usernames set to their User Principal Names in AAD. If not, either modify existing user (who has System Administrator permissions) or create a new user (step 8 above).
2. Next, go to your Dynamics 365 Deployment Manager and choose Configure Claims-Based Authentication. Use the metadata you uploaded in the Getting Started section and generally follow steps 2, 3, and 4 from above. You can keep the encryption certificate the same you used before.
3. Once finished, restart your Dynamics 365 through IIS. If you then head to your IFD address - https://auth.your-ifd-address.tld, you should authenticate with Azure AD and access your default instance. However, you are very likely to have more instances in separate subdomains - https://prod.*, https://dev.* etc. If you try to access those, you will get an AADSTS70001 error from Azure AD stating that the identifier is invalid. Adding those as identifiers is the tricky part.
4. In Azure Portal, navigate to App Registrations tab (on the same level as Enterprise Applications), from the dropdown, choose All apps and from the list select the app you created above (1box-02.crmlabs.tntg.cz in my case) and select Manifest. In the manifest, find identifierUris and replyUrls and add all known addresses to the JSON lists. Leave the other identifiers and URLs as is. I don’t suggest modifying anything else in the manifest, since you could break the application.
5. Save the manifest and you should be good to go.
6. Next step would be to modify existing user’s User Names in Dynamics so they can access it and it’s done.

Summary

In this article, I have demonstrated how to setup both non-IFD and IFD deployments of Dynamics 365 with Azure Active Directory as Claims-Based Authentication Provider directly, which can reduce your infrastructure overhead. Additionally, I suggest looking at Dynamics 365 Online offering from Microsoft which is a hosted solution which communicates with Azure AD directly and therefor makes a lot of things much easier. Next time, we might explore the ADFS > Azure AD setup with Dynamics on-premise.

Downsides

So far we discovered one downside with this solution, but they may be more. Like I have already mentioned above, this shouldn’t be used for production. Mobile Applications If you plan to use Dynamics 365 mobile/Outlook applications, they are not likely to work. The issue is that they require to be registered with the identity provider, which is actually impossible with AAD, since Microsoft has claimed those application IDs for Dynamics Online obviously and you cannot integrate with your own application. You could probably work around it with URL rewrite - rewrite the clientId to a clientId of yours back and forth, but I think it could be problematic.