Wondering how to use azure active directory for sso with dynamics 365 on-premise? We can help you.

At Bobcares, we offer solutions for every query, big and small, as a part of our Server Management Service.

Let’s take a look at how our Support Team help a customer  deal with this query.

How to use azure active directory for sso with dynamics 365 on-premise?

Azure active directory provides more security, advanced attack protection methods, auditing, logging.

Even tho that Dynamics 365 installation requires Active Directory, you don’t need to use AD as an identity provider nor store users there.

Removing user’s dependency on Active Directory can allow you to deploy cloud-only IdP with on-premise Dynamics 365.

Also, you can have Internet Facing Deployment (IFD) of Dynamics 365 without having to expose your ADFS to the internet while being protect by Azure AD.

Basically, there are two paths for getting this deployed.

Firstly,  is migrating from existing Claims Based Authentication setup with ADFS.

Secondly, is getting a vanilla deployment of Dynamics 365 setup with Azure AD.

Today, let us see the common setup steps followed by our Support techs:

• Firstly, navigate to Azure Portal and select Azure Active Directory or alternatively use Azure AD Portal directly.
• Then, select Enterprise Applications and from Add your own app create a Non-gallery application and create it with your preffered name.
• Once you create the application navigate into the properties, and optionally turn off User assignment required option.

This is going to allow everyone from your AAD to authenticate with Dynamics 365.

• Next navigate to Single sign-on from the left menu. Select SAML-based Sign-on from the drop down.
• 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.
  • Non-IFD: You should have your instance address there, so for example: https://1box-01.crmlabs.tntg.cz
• 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.

Then, ssave 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.

• Firstly, 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.

• On the server, open the Dynamics 365 Deployment Manager.

From the left menu, choose Configure Claims-Based Authentication.

• Stepping through the wizard, enter the address of the FederationMetadata.xml you uploaded before.
• Then, choose the encryption certificate.
• Once you apply the changes, switch to the In-Private browser window you opened before and choose to create a new user.
• Fill out the UPN of a user from AAD which you will use for Administrator.

Fill out the user’s Full Name and save.

Then, you have to assign _System Administrator role to the user so you can sign-in and perform administrative tasks.

• If you enable trace logging, you are going to fing out the error relates to an exception being thrown by username being undefined.

So we have to override the IdentityClaim configuration in the database.

• Next, open up your SSMS, connect to your Dynamics 365 SQL instance and open MSCRM_CONFIG database.
• 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.
• Now once you save the changes and restart the site, you will be open to open the Dynamics and login with the account which you created in step 8.
• Next, under this account, open the Users page again and modify the original user’s User Name to their UPN.
• You shouldn’t have to use that account since your Azure AD account is already a System Administrator.
• 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.

However when turning it back on, you just click through the wizard and the configuration including the IdentityClaim is going to stay.

• Now you can create your users with their AAD User Principal Names and you are good to go.

Modifying existing IFD deployment

• Firstly, 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).

• 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.

• 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.

• 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 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.

• Next, save the manifest and you should be good to go.
• Finally, modify existing user’s User Names in Dynamics so they can access it and it’s done.

[Need a solution to another query? We are just a click away.]

Conclusion

Today, we saw steps followed by our Support Engineers to use azure active directory for sso with dynamics 365 on-premise