OVERVIEW
You are deploying Microsoft Dynamics. You have a set of choices to consider, relating to:
- How it will be accessed (direct Internet access, VPN, private network only)
- Which constituents of users will authenticate to it
- How users will authenticate to it
- The authorisation or roles of those users
- Related products (e.g. CRM Portals/PowerApps)
- Multi-Factor Authentication
In “Zero Trust for the Digitally Disconnected” we propose a technique that means all applications are directly Internet connected (regardless of whether deployed as SaaS, in a DMZ, in a private cloud, public cloud, hybrid cloud, etc.). This gives maximal security and maximal ease of access.
User Constituent Considerations
- Full-time badged staff @mydomain only?
- 2 or more related entities (e.g. @city, @region, @county, @library, @fire)
- External contractors (e.g. @theatre)
- Temps, contractors, other non full-time staff?
- Channel Integration Framework (e.g. @ice-facility)
The broader the base of constituents you can reach securely and simply, the more value you can extract from the Microsoft Dynamics deployment.
If the sole use case is Full-time badged staff @mydomain, the simplest is to deploy using Azure Active Directory (if Microsoft Office 365 is already deployed), or to deploy Microsoft Active Directory Federation Services (ADFS) so that it is Internet facing. Both options allow creating “Authentication Clients” which allow external applications to do a set of claims-based identity authentication. Possible standards to use are OpenID Connect and SAML. Of these, OpenID Connect is a more modern Internet-style standard supporting both Identity and Profile, where SAML supports Identity and custom attributes to emulate Profile.
I encourage you to think of other constituents and stakeholders for which a federated identity would be more appropriate. These can be identified by e.g. User@gmail, User@Library, other Identity providers, and securely Authorised, Simply.
A video demonstrating what the user experience would be is available.
User Authentication
I would propose that you have zero users manually configured in Dynamics. All users would be available through a Federated login, with separated Authorisation.
Two modes of operation are available (called IdP-initiated, and SP-initiated). In the first, there is a single page for your organisation called ‘MyApps’, you sign into it, and it then has links to e.g. CRM which you follow, no additional login is shown.
In the latter (SP-initiated), the user navigates to CRM, is not logged in, is redirected to the login experience, and returns.
Both support single-sign-on, and are seamless. The SP-initiated is how more users are used to operating (e.g. go to gmail, go to google calendar, go to google docs) since they think of the application first.
Initial Configuration
In “Initial Setup — Active Directory” I show the initial setup steps that are required once Azure Active Directory or Active Directory Federation Services are deployed.
Note: if you do not have Azure Active Directory and do not have Active Directory Federation Services, there is still a simple method involving an Agent deployment that requires no changes to internal infrastructure.
Related Products
Other layered products may be built on or integrated into Microsoft Dynamics. An example is CRM Portals (PowerApps). These in turn might have a wider group of constituents, albeit with a more narrow role.
The most convenient and secure method is to enable OpenID Connect. This post shows some of the details.
For each application, a new “Authentication Client” is configured, and appropriate users & groups are given access by Role.