![]() Second option is sourcing the identity from a federation provider - ADFS. That is why it is super important, to include the user’s SID in the claims (as the tutorial mentioned above states), else, even if you include the UPN or logon name, the user won’t get mapped. What happens on background in this case, is that Dynamics has a mapping table in MSCRM_CONFIG database, which is called SystemUserAuthentication and it basically maps the user’s SID to the identity in Dynamics 365. By default, and in most simple deployments with ADFS, you use the first one - user has an account in Active Directory and is created in Dynamics 365 with username like AD\Jan Hajek which is their logon name into the AD. Identities in Dynamics 365īasically, you have two kinds of identities in Dynamics 365 - identities sourced from Active Directory and identities sourced from a federation provider. Starting off, I am going to assume you already have ADFS installed and set up with Dynamics 365, if not I suggest starting here. In this article, we are going to explore a production ready solution by leveraging Active Directory Federation Service and Azure AD as a Claims Provider Trust. In previous article, we have looked at the possibility to connect Dynamics 365 on-premise directly with Azure AD, which is on one hand really cool, on the other, it doesn’t provide all the features like mobile apps integration. Setting up ADFS with Azure AD as Dynamics 365 Identity Provider ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |