locked
CRM in DMZ and ADFS RRS feed

  • Question

  • Hi,

    I have a bit of an issue. We have a CRM deployment in a DMZ in AD X, full CRM server, SQL server and AD. There is an ADFS proxy thingy (that's the technical term... don't know if it's some sort of adfs proxy or if it's a web aplication proxy) in the DMZ that connects to an ADFS server on the "inside" (AD Y). Now can I connect the AD X CRM in the DMZ to the ADFS in AD Y and still be able to log in using the account set up in AD X, or do I need to some more magic for instance using another ADFS server in the DMZ AD (X) that connects to the ADFS in AD Y with relying parties and claims provider and god knows what more?

    I haven't found any examples where the DMZ is in it's own AD when I've searched so the instructions in the IG is not useful AFAIK.

    Cheers!


    Rickard Norström Developer CRM-Konsulterna
    http://www.crmkonsulterna.se
    Swedish Dynamics CRM Forum: http://www.crmforum.se
    My Blog: http://rickardnorstrom.blogspot.se

    Thursday, March 31, 2016 1:48 PM

Answers

  • Hi Rickard.

    Yes as I see it there are 2 possiblities here

     1. Create a Forst/Domain trust between domain X and Y and use their ADFS server to handle the autentication for users in both domain over the trust.
    Without knowing the relationship between Domain X and Y i would say that this is "only" recommended if these 2 domains are controlled by the same organization
    If these are 2 separate organisations it's not the way to go.

    2. ADFS Federation relationship.
    You setup ADFS in domain X and create a federation relationship between the organizations (domain Y).
    Of course this will require quite a bit of a task setting up by that IT department, but I would say that it's worth the effort since as I see it, Claims based autentication is the modern way of authentication.

    Here are some resources that I see relevant:
    Active Directory Federation Services Overview
    Federated Identity: Scenarios, Architecture, and Implementation
    Configuring Claims-based Authentication for Microsoft Dynamics CRM Server

    The Configuring Claims-based Authentication for Microsoft Dynamics CRM Server describes the scenario of setting up the federation relationship between organizations using ADFS for Dynamics CRM.

    Hope this helps!

    BR. Philip

     
    Friday, April 1, 2016 12:08 AM

All replies

  • Hi Rickard.

    Yes as I see it there are 2 possiblities here

     1. Create a Forst/Domain trust between domain X and Y and use their ADFS server to handle the autentication for users in both domain over the trust.
    Without knowing the relationship between Domain X and Y i would say that this is "only" recommended if these 2 domains are controlled by the same organization
    If these are 2 separate organisations it's not the way to go.

    2. ADFS Federation relationship.
    You setup ADFS in domain X and create a federation relationship between the organizations (domain Y).
    Of course this will require quite a bit of a task setting up by that IT department, but I would say that it's worth the effort since as I see it, Claims based autentication is the modern way of authentication.

    Here are some resources that I see relevant:
    Active Directory Federation Services Overview
    Federated Identity: Scenarios, Architecture, and Implementation
    Configuring Claims-based Authentication for Microsoft Dynamics CRM Server

    The Configuring Claims-based Authentication for Microsoft Dynamics CRM Server describes the scenario of setting up the federation relationship between organizations using ADFS for Dynamics CRM.

    Hope this helps!

    BR. Philip

     
    Friday, April 1, 2016 12:08 AM
  • Hi Philip,

    Thanks for the reply, I'll mark it as the answer even though I doubt I will get to use the solution with the customer...

    Regards


    Rickard Norström Developer CRM-Konsulterna
    http://www.crmkonsulterna.se
    Swedish Dynamics CRM Forum: http://www.crmforum.se
    My Blog: http://rickardnorstrom.blogspot.se

    Tuesday, April 12, 2016 7:26 AM