When enabling / disabling external authentication on the portal, there seem to be at least a couple of gotchas. In general, the whole process of enabling external sign in through different authentication providers is described here:
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/configure-oauth2-settings
However, if you wanted to disable external authentication, you might use false for the following site setting: Authentication/Registration/ExternalLoginEnabled
But, as per the documentation above, Azure authentication won’t be affected:
So your portal users will still see Azure signin option:
What will disable Azure AD signin is using false for the following site setting:
Authentication/Registration/AzureADLoginEnabled
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/azure-ad-b2c
On the other hand, if you keep the signin enabled, as in the example below:
You will find that, once the portal user has signed in, they will see a few options on the profile page which make sense for the portal-based authentication but which don’t seem to make that much sense for the external authentication:
What’s happening there is that the same portal account/contact in Dynamics can represent a local portal account, and, also, can be linked to a number of external identities. I can check which identities are associated to my portal account on the portal side:
My portal account is a local account, but I can use google signin. And I can also go to Dynamics to see what’s happening there – there will be an external identity associated with this contact:
The only problem with this process is that, if somebody chooses to signin with Google (for example) when registering on the portal, and once they click “Change Password” in their profile, here is what they are going to see:
Which is a bit confusing because of the header and because it’s not quite clear which Username this page is talking about. It’s actually suggesting to create a local portal account, so it’s really just a matter of changing the header to make it clear (and, since we can’t disable this functionality, I think that’s just what we have to do – change the header).
That header corresponds to the following site setting in Dynamics:
So we can replace out-of-the-box value with something more appropriate:
And this is what we’ll see:
Once the local account has been created, that header disappears, and that’s more or less how we need it to be:
