Dynamics 365 Portal – Authentication Series (Part 1) – The Basics

I’ve been recently deployed a quite complex Dynamics 365 portal solution involving a custom authentication provider and other features such as Power BI Embedded and SharePoint integration.

In this series, I’ll discuss in more detail about the authentication side based on my lesson learned out of this challenge to get them working properly. My plan is to discuss the following topics in this series:

1. The basic – Local Auth
2. External Auth – Using Azure AD & Azure AD B2C
3. External Auth – 3rd party ID provider
4. Some tips and tricks around

Before we begin, I would admit that I’m not a portal expert, I learned the concept and knowledge from these great experts: Colin Vermander, Nick Doelman, George Doubinski and Dileep Singh. So, credit is to my great “teachers”.

So, to begin with, let’s try to understand the authentication methods that the Dynamics 365 portal supports (https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/configure-portal-authentication).

In a nutshell, Dynamics 365 portal’s authentication is based on the ASP.Net Identity, which is based on the OWIN Framework (The OWIN framework is the “jargon” that seems to be commonly being used by the auth provider in their documentation, so always good to know and understand how it works/behaves).

There are 2 methods of authentications in Dynamics 365 Portal:

1. Local Authentication

Purely based on Dynamics 365 Contact record to store the authentication details.

2. External Authentication

Utilising the ASP.Net Identity API to integrate with the external ID providers using either OpenID Connect or OAuth or SAML.

To ensure the portal authentication to work properly, ensure the following solutions exist in the environment. These solutions typically will always be there after the portal instance being provisioned, but I had a case where the overall authentication process is not working properly due to missing one of the following solutions (if you encountered the same issue as me, log a support ticket and the support team can add the missing solution fairly quickly).

The minimum viable option of the authentication would be using the local authentication. However, I would recommend to minimise the usage of the local authentication method and use External Authentication (if possible Azure AD-family) as much as possible, not only for the security compliance but also future proofing your portal investment. This is based on Colin Vermander’s blog post from last year: https://colinvermander.com/2018/05/19/dynamics-365-portals-authentication-deprecation/

Even though the link in the article is no longer showing the deprecation on it, but I reckon the intent to push to Azure AD B2C is still there.

Local Authentication in a Glance

When you are using the Local Authentication, the portal solution is storing the user creds within the contact entity. Password is stored as hashed text within Dynamics 365 (even though Dynamics handles the security and encryption at rest, this could be an “alarming” thing when the system is being audited by security experts. Thus, recommended to use external idp).

Some of the notable site settings that construct the basic behaviour of the local authentication in Dynamics 365 Portal:

• Authentication/Registration/Enabled
• Authentication/Registration/LocalLoginEnabled
• Authentication/Registration/OpenRegistrationEnabled
• Authentication/Registration/InvitationEnabled
• Authentication/Registration/RememberMeEnabled
• Authentication/Registration/ResetPasswordEnabled
• Authentication/Registration/ResetPasswordRequiresConfirmedEmail

The technical description of those settings are available in this documentation article: https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/set-authentication-identity

In the next post, I will discuss on how to configure the authentication using Azure AD & Azure AD B2C.

What matters with the Dynamics 365 v9.0

A quick disclaimer: this article is based on the preview program where the actual might differs.

Last week, I spent some more time watching again the recording of the Executive Briefing for Dynamics 365 July 2017 Preview Program. There is a massive load of good content and updates to Dynamics 365 in this next release. Traditionally, the preview program is under NDA and things that mentioned there are not for public consumption. However, a shift has happened in the direction of the preview program, where the information available there is no longer under NDA. A fellow MVP, Jukka Niiranen, posted a really good summary of this information on his blog: http://survivingcrm.com/2017/06/all-you-need-to-know-about-dynamics-365-v9-0-for-now/.

After spending a few hours digesting again the recording, I would like to share a few key things that I’ve learned and thought as the outcome of the Executive Briefing as well as from documentations that are currently available.

An Exciting UI Revamp

The Unified Client that was mentioned during the Executive Briefing addressed quite significant issues of usability of the system. Reduction of white spaces, better tab navigation, text not to be wrapped anymore is a good sign for the usability. With this change, we all hope that users adoption would become much better. Now, when we are talking about user adoption, Dynamics 365 customers might need to start considering and thinking the plan for the change management. From my perspective, the more preparation of the change is the better user adoption will be.

Business Edition

During the Executive Briefing, it was mentioned that the Business Edition (BE) will start with Sales & Marketing module and other capabilities will follow. The setup experience with the Business Edition seems to be simplified that much for the admin to setup, which is positive in a way. However, since it’s a new thing, everyone needs to learn it.

A few things that I noticed, would be as usual on what can/cannot be done in Business Edition. This screenshot from the presentation slide outlines the high-level limitation on Business Edition when it’s compared with the Enterprise Edition.

And as per the first release, based on the question during the briefing, it seems there is no downgrade path for Enterprise Edition to Business Edition, at least for now.

However, it seems to be possible to run Business and Enterprise edition in the same environment (still TBC though..)

And with the Business Edition, the configuration experience will also be different

My quick takeaway from the Business Edition: Be prepared to learn something (completely) new!

Platform Changes, Shift of Paradigm

With these exciting updates to the platform. Designing a Dynamics 365 solution is now no longer silo-ed within the Dynamics 365. Noticed that Microsoft Flow and Azure Logic Apps are becoming an integral part of Dynamics 365 solution. More and more integration and solutions will leverage this “native” capabilities (also become a space for us, Dynamics 365/CRM professional to start investing our time to learn).

With the Webhook supports, it opens up greater possibilities for Event-Driven processes/integration. This will work nicely with Azure function or any other APIs that support Webhook.

And Virtual Entity (this could be the end of data replication mindset)

Deprecation Announcements

With the release of v9.0, there are some components that are made deprecated.

• Outlook Client
• Service scheduling in Dynamics 365 for Customer Service
• Dialogs
• Parature knowledge base as the Dynamics 365
• Project Service Finder app
• Contracts, Contract Line Items, and Contract Templates
• Standard SLAs
• Relationship Roles
• Mail Merge
• Announcements
• Silverlight (XAP) web resource

For more detail, have a read on Microsoft’s official documentation on this: https://docs.microsoft.com/en-us/dynamics365/get-started/whats-new/customer-engagement/important-changes-coming

The deprecation announcement is important for us to start planning on how to handle the deprecation and move on with the latest available feature and start adopting the new feature for new implementations. The interesting ones are around Outlook Client, Dialogs, Contract-related entities and SLA. I believe this will require more planning.

For example, rolling out the new Outlook App might have some infrastructure/desktop rollout impact, as the current Outlook App has some compatibility gap with older version Exchange Server and Desktop Outlook (ref: https://technet.microsoft.com/en-us/library/dn946901.aspx). Office 365 definitely solves the upgrade/infrastructure compatibility issue (another compelling reason where organisations should start considering moving to the cloud ;)).

Currently, Dialogs are there as the only way to prompt users for a value that can be consumed by the processes/workflow. Without any equivalent replacement, this could be a tricky situation. Some organisations might still using the contract-related and older SLA, and they work fine. If it becomes deprecated, then a change to the system is required.

Changes for Developers

Within the same documentation above, there is a section on “Some client APIs are deprecated” and I noticed the popular Xrm.Page library is now deprecated. This is in-line to support the new Unified Client structure. This means a really good planning needs to happen to be prepared with this release and start learning the new Client API/library.

For more details, there is another documentation from Microsoft for developers: https://docs.microsoft.com/en-us/dynamics365/get-started/whats-new/customer-engagement/new-in-july-2017-update-for-developers

Conclusion

Dynamics 365 v9.0 is indeed a major upgrade, not only from the versioning, but also with the content. We all need to be ready to learn A LOT of new things and start embracing the latest and the greatest of the features to stay supported and ready for “undeniably” rapid changes to the platform. At this moment, we are just scratching the surface of the Dynamics 365 v9.0, I believe there are more to be unveiled and really excited about it!

Last but not least, even though the “briefing” for the upcoming preview program has completed, nothing is too late. Please feel free to sign up at https://connect.microsoft.com/DynamicsCustomerEngagement/

Managing Dynamics 365 Online Encryption Key

Today, when I navigate to edit one of the Dynamics 365 Online instances, I just noticed a new section that is available on my trial instance: “database encryption settings”

So, what can you do with this shiny new feature?

Based on the official documentation for this feature from Microsoft: https://technet.microsoft.com/en-us/library/mt492471.aspx

The manage keys feature lets you perform the following tasks.

• Enable the ability to self-manage database encryption keys that are associated with Dynamics 365 (online) instances.
• Generate new encryption keys or upload existing .PFX or .BYOK encryption key files.
• Lock a Dynamics 365 (online) instance.

  Caution

  You should never lock an instance as part of your normal business process. While a Dynamics 365 (online) instance is locked it takes the instance completely offline and it cannot be accessed by anyone, including Microsoft. Additionally, services such as synchronization and maintenance are all stopped. An appropriate reason why you would lock an instance is when you move your database from online to on-premises. Locking the instance can make sure that your online data is never accessed again by anyone. A locked instance can’t be restored from backup.

• Unlock a Dynamics 365 (online) instance. To unlock a locked instance of Dynamics 365 (online), you must upload the encryption key that was used to lock it. While a Dynamics 365 (online) instance is locked, it cannot be accessed by anyone.

 

One of the common request when I’m implementing Dynamics 365 (CRM) deployment, is the question around the security & encryption. One of the common ask is whether the platform allows customer-supplied encryption key or not? In the past, my answer is NO. It is all under Microsoft’s managed encryption key.

With this feature being made available, the answer is YES!

Read through the TechNet article above for more details of this new feature and considerations when you are implementing this BYOK 🙂

HTH!

Lesson Learned from PSA Deployment

Currently I’m in a project where our team is going to roll out Dynamics 365 Project Service Automation for one of our customers. Throughout the project, we’ve learned a lot about this new cool kid on the block 🙂

Some gotchas/lesson learned when we are rolling out this to the customer:

1. Choose Project Template carefully. Once created, the user can’t change the project template and need do it again from the scratch (not a big hassle, but definitely I mentioned this when during the training).

2. This is for Admin/Customizer, PSA-related controls limitation. Time Entry & Expense, WBS, schedule board, etc. They are pretty much static (hard coded), it is not honoring relabel, adding more options and even can’t add any new field. Seems like we need to treat PSA in a similar manner to other ISV solution, such as Click Dimensions, (compared to Sales/Service/Marketing that have more mature customization and configuration flexibility).

3. Do not mess with the OOTB processes or scripts. There are lots of processes coded in javascripts and plugins where the processes behind it are not really documented. So, my lesson on it, keep it out of the box, if a customization needed, I would recommend to not touching any of the OOTB fields and create custom processes or fields instead.

4. Pay attention to “metadata” records (Resource Role, Resource Skill, Price List, Expense Categories, etc) during deployment. Similar to Adx/portal scenario, where records are stored as configuration. To have ALM for PSA correctly, will need to pay attention to those records as part of the deployment process.

5. One of the biggest catch that I’ve got: can’t undo approval. Approvers need to be really really careful with their approval.

For this instance, I submitted an idea entry: https://crmideas.dynamics.com/ideas/dynamics-crm/ID0000986. From the feedback from the 2 customers that we have worked with, they need this feature to make an amendment to the entries, at least before it is processed for invoice (at least a flag or something to cater this scenario).

1. Data migration is a bit tricky, for some scenarios, we’ve got to deactivate some of the validation plugins to let the data in (need to have thorough testing on this, as I consider this as touching the OOTB process that is not well documented).

Hope this helps!