Skip to main content

Notifications

Announcements

No record found.

Microsoft Dynamics 365 | Integration, Dataverse...
Unanswered

Multi-domain user access on CRM through trusts

Posted on by 10

Hi, 

We are implementing an on-premise D365 CRM solution for one of our clients where the requirement is like this, There are going to be users on two completely different domains (These domains are not sub-domains) i.e. they are completely different domains on different infrastructure setup.

CRM would be installed on Domain A with the following URL to access it https://crm.domaina.com or crm.domaina.local which is fine.

What is Required:

  1. Domain B users need to access the URL https://crm.domaina.com 
  2. Domain B users need to authenticate and login on https://crm.domaina.com 

Now from what we have read, there can be two options, Option 2 has some confusion for me:

  1. Establish ADFS servers on both Domain A and Domain B and configure relying party trust between these two. Expose CRM over internet through IFD and publish the CRM URL https://crm.domaina.com over internet. Once that is done, both users from Domain A and Domain B will be able to do the following:
    1. Access https://crm.domaina.com URL as its published over internet so publicly available.
    2. Authenticate from Domain A & Domain B as claims based authentication & relying party trust is configured between the two.
  2. Establish one-way or two way trust between Domain A & Domain B without setting up ADFS, IFD & CBA. For this option, we are not sure how the URLs of CRM will be exposed/accessible to the other domain. Is it something that is completely simple and related to network/firewall level configuration which I am over complicating or this will not work ?
    1. Access https://crm.domaina.com URL : Can someone explain how this will be accessible for Domain B, assuming trust has been established between the two but no ADFS/IFD/CBA setup has been done. I have read it somewhere that this is completely possible on the network level by enabling communication between the two separate networks. Is this correct? 
    2. Authenticate from Domain A & Domain B will be possible as trust has been established between the two domains.

For Point 1 above, I think it is understood, I would like to know how Point 2(a) works, (if that works) or did I misunderstand something from the following links as the articles and the verified answer suggests that you don't need to have ADFS/IFD setup to be able to authenticate user from two different domains:

https://docs.microsoft.com/en-us/previous-versions/dynamicscrm-2016/deployment-administrators-guide/hh699704(v=crm.8)?redirectedfrom=MSDN

https://community.dynamics.com/crm/f/microsoft-dynamics-crm-forum/170883/dynamics-crm-on-premise---multiple-domain-access/490820

Looking forward to your suggestions and clarifications. Thanks

  • shaheerzep Profile Picture
    shaheerzep 10 on at
    RE: Multi-domain user access on CRM through trusts

    Hi Phil,

    1. What is the relationship between domain A and domain B, same organisation/corp e.g. like a branch office?

    They are partner organizations. One indirectly report to the other but not parent/child, they are partner organizations.

    2. The current network configuration, how and if are domain A and B connected network wise, same LAN, linked eg. fixed VPN tunnel such or nothing at all, just internet between (I'm not thinking of the domain setup here, as I already understand they currently are two different domains(forests)).

    They are not on same LAN, different ISPs most probably, internet in between. Fixed VPN tunnel is what i was thinking they could go with if they don't want to go for ADFS setup, otherwise currently it wont have anything and are simply put two different domains on different networks with internet separating them.

    What do you think about the VPN tunnel approach ?

    And for the ADFS option, shouldn't the ADFS be setup on both sides with federation trust instead of only one ADFS and asking Domain B to use Domain A credentials to sign in to CRM deployed on Domain A? Is this a recommended practise that a replica user is to be created every time a new user from Domain B needs to access the application or SSO is the way to go with two ADFS and trust in between them, Please also note these are government organizations and long term recommended solution is needed.

  • PhilipK Profile Picture
    PhilipK 611 on at
    RE: Multi-domain user access on CRM through trusts

    For me the most important questions here that is unclear.

    1. What is the relationship between domain A and domain B, same organisation/corp e.g. like a branch office?

    2. The current network configuration, how and if are domain A and B connected network wise, same LAN, linked eg. fixed VPN tunnel such or nothing at all, just internet between (I'm not thinking of the domain setup here, as I already understand they currently are two different domains(forests)).

    There are a lot of more questions to this to determine the right approach than the two above ones, but the simplest solution is most likely (assuming domain A and B are separated via internet):

    Setup ADFS for CRM in domain A and create users accounts for the users in domain B in domain A and expose the CRM via IFD and let the users in domain B authenticate thru ADFS sign-in(forms) page.

    Of course, the users in domain B would have to live without SSO as they would use their credentials in domain A to authenticate, but hey it gets the job done.

    Setting up a forest/domain trust can be a big or small task depending on the network topology, but simply put this is nothing you do for a single app or service.

    Nowadays you typically only setup trusts when merging or transitioning organisations that cannot easily consolidate their domain infrastructure either to an existing one or a new one.

  • shaheerzepp Profile Picture
    shaheerzepp 5 on at
    RE: Multi-domain user access on CRM through trusts

    Hi Hueseyin,

    Thanks for the detailed response which puts things into perspective now, However i would just like to get more clarification on some of the points that you mentioned. We are fine with WIA or Forms authentication both as long as multi domain access issue is taken care of. I understand we will only get forms authentication if we go for proper IFD with ADFS.

    Would appreciate if you can elaborate some of the points a bit more:

    Important: Publishing Dynamics CRM outside the own Domain / Network is only supported / suggested by using Internet Facing Deployment with ADFS!

    So in that case what about the option with WIA with trust between domains separated by internet/wan?

    • Option WIA (Windows Authentication) you will require a Domain Trust between Environment A (CRM) and Environment B (Users).

    To reach CRM via Windows Authentication you need to configure the DNS properly by using for example a conditional forwarder and the DNS must be reachable. If there is the WAN between (internet) external DNS entries are required for this.

    So what exactly would be required by the Network team to make two separate domains not connected to each other, talk to each other? Is it a VPN or any specific term that is to be setup between these networks to reach each other so user from Domain B can open a non-IFD Domain-A CRM URL without having to connect a remote VPN client? And is this not a recommended approach as mentioned in previous bullet.

    Domain B Users can be only created when a one-way trust at least is created.

    So this trust is different than the relying party trust that is configured on the ADFS server with the CRM server? For a single domain IFD deployment, I suppose you have to configure Claims Based Authentication, Relying Party Trust between the ADFS and CRM server and its good to go. For multi-domain IFD, do we have to establish a different kind of trust between the ADFS-A & ADFS-B ? Is this the same as relying party trust or its something else? And for a multi-domain IFD, 2 trusts are to be created, one between ADFS-A and CRM, and two between ADFS-A & ADFS-B? is this correct?

    CRM (Domain A) <-> ADFS Domain A || DMZ (maybe WAP or Proxy) || Internet / WAN with DNS entries authcrm.domain.com, discovery.domain.com, adfs.domain.com, crmorg.domain.com || DMZ || <- Users Domain B

    From the above, shouldn't ADFS-B also be there before Users Domain B  as they will login on ADFS-B and then ADFS-B will do the talking to ADFS-A?

    Appreciate your support on this Hueseyin. Looking forward to your response.

    Also, if you have any resource link for multi-domain IFD/ADFS configuration please share.

    Thanks

  • RE: Multi-domain user access on CRM through trusts

    Hello shaheerzep,

    so we have two different topics here. (Be aware that DNS and Network configurations are mandatory changes / settings you will require to make the environment reachable) 

    Topic a) Authentication / Authorization:

    You need to answer the question if the customer wants to use Windows Authentication or Form-Based (Username & Password)
    Should the authentication handled by the Domain Controller or ADFS?

    If we assume that there are Users in Domain B and they want to access CRM in Domain A where the enviroment is hosted in different places the authentication must be handled.

    Important: Publishing Dynamics CRM outside the own Domain / Network is only supported / suggested by using Internet Facing Deployment with ADFS!

    • Option WIA (Windows Authentication) you will require a Domain Trust between Environment A (CRM) and Environment B (Users).

    To reach CRM via Windows Authentication you need to configure the DNS properly by using for example a conditional forwarder and the DNS must be reachable. If there is the WAN between (internet) external DNS entries are required for this.

    • Option Form-Based (IFD) *suggested*

    This is the suggested way to "publish" Dynamics CRM to external (non-Domain A Users).
    The Users from Enviroment B will access the CRM via the external URLs and will login via Username and Password.

    The Users in Environment A can use the Claim Based URL (Internal via Windows Authentication) or local DNS entries to resolve the IFD URLs via Form-Based login

    You could federate 2 ADFS Servers via claims provider trust (WS-FED) so users from B could do a SSO on Enviroment A. (as Form-Based is used anyways there is no need for this step, the benefit here would be Active Directory based authentication as the federation connects the environments and Users will "talk" to their own ADFS) 

    Topic b) User creation:  

    Besides of the Authentication Dynamics CRM must be connected to the Active Directory.

    Domain A Users can be easily created as CRM runs in the same Domain. 

    Domain B Users can be only created when a one-way trust at least is created.

    Our user creation process queries Active Directory values and we must be able to reach the foreign domain. 

    (Keep in mind if Domain B users should receive Deployment Administrator rights a two-way trust is required.) 

    This suggestion is based on the CRM software requirements and best practices. 

    So in short the architecture: 

    CRM (Domain A) <-> ADFS Domain A || DMZ (maybe WAP or Proxy) || Internet / WAN with DNS entries authcrm.domain.com, discovery.domain.com, adfs.domain.com, crmorg.domain.com || DMZ || <- Users Domain B

    Hope this helps. 

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

December Spotlight Star - Muhammad Affan

Congratulations to a top community star!

Top 10 leaders for November!

Congratulations to our November super stars!

Tips for Writing Effective Suggested Answers

Best practices for providing successful forum answers ✍️

Leaderboard

#1
André Arnaud de Calavon Profile Picture

André Arnaud de Cal... 291,280 Super User 2024 Season 2

#2
Martin Dráb Profile Picture

Martin Dráb 230,235 Most Valuable Professional

#3
nmaenpaa Profile Picture

nmaenpaa 101,156

Leaderboard

Product updates

Dynamics 365 release plans