This is somewhat outside my comfort zone as I am not at Dynamics/CRM expert by any means, but recently had a need to integrate B2B authentication from Azure AD to enable customers to log into our Dynamics Customer Engagement Portal. There is a whole document library from Microsoft on how to do this with B2C, but no B2B.
We wanted to leverage the Customer Engagement Portal for case management for our support services to our customers. Up until now, customers did not have to log into our Dynamics, but we did have hundreds of Contact records for our customers to associate projects, accounts and opportunities to. The key factor here is that Dynamics uses these Contact records as identities within the portal.
We could have simply enabled the ability for customers to register for the portal, which would have had them create a new username and password associated to their existing Contact record, but then they had new credentials to remember. Not to mention, this also put us in the business of having to manage another identity store for our customers requiring us to manage their access and help with things like password resets. This was not something we wanted to do.
To enable Azure AD B2B authentication, we first had to invite them as a guest into our Azure AD tenant. This sends the customer an email asking them to accept the invitiation, and enables them to log into our tenant using their tenant credentials (as a cloud services consultant, most of our customers have an Azure AD tenant).
Once accepted, we added an app registration in Azure AD so our support portal showed up under their My Apps page. This enabled them to go straight to our support portal to log in, but when they clicked the Azure AD button to sign in, they would receive an error that an existing contact with the same email address already existed.
If they did not have an existing Dynamics Contact record, the portal would create a new one and enable them to log in with their B2B credential. So for new users, this worked fine, but for those with existing contacts, this did not work.
Looking at the Dynamics Contact record created by the portal, the only difference we saw was that the automatically created contact had an External Identity record associated.
The External Identity can easily be manually created as the username is simply the object GUID of the guest user account in our Azure AD tenant. The identity provider is https://sts.windows.com/tenantID where tenantID is the Azure AD directory ID of our Azure AD tenant. But manually configuring these on an existing Contact record does not enable the use of B2B authentication, but rather displays a long HTML error page.
During our troubleshooting, we were able to link an existing Contact record if we sent the customer an invite from Dynamics, which required them to manually go through the registration process by redeeming a code, attempting Azure AD authentication, and setting up their profile manually in the portal (which gets written back to the contact). This was a lot of room for error and also seemed inefficient as the customer would have to accept a guest invite for our tenant first, then accept another invite to access the portal.
As mentioned before, there is plenty of documentation out there on enabling B2C authentication, but nothing on B2B... but because we could get a new guest user log in and the portal would automatically create a new contact that was properly configured, we knew it must be possible.
After hours of digging through Dynamics logs and comparing working Contacts created by the portal against pre-existing Contacts we were manually trying to configure, we ended up having to open a case with Microsoft as there was obviously something happening that is not exposed on the consumer side to make this work.
After escalation to Engineering, we finally came across a solution. Without going into too many details, there is a specific portal Site Setting we had to define, but it did not exist by default. Under Dynamics/Portals/Site Settings, there are several authentication settings pre-defined for OpenAuth, but B2B doe not actually use OpenAuth.
Instead, we had to manually create a new setting named:
Authentication/OpenIdConnect/AzureAd/AllowContactMappingWithEmail
… and set that with a value of True to enable the Customer Engagement Portal to automatically detect an existing Contact record based on the user email address and update it to leverage B2B authentication.
After this was created, when a user uses the Azure AD sign in option on the portal, as long as their guest username matches their email (unified UPN and SMTP), guests were able to immediately log into our Dynamics Customer Engagement Portal using their tenant credentials and their Contact record (as well as account association) are preserved so their support entitlements in Dynamics are automatically applied. Not to mention, we don't have to manage their identities as if a customer contact leaves the customer, the customer disables their account on their end which results in their inability to authenticate to our portal... win-win.
Comentarios