CRM - New User - Trusted Forest RRS feed

  • General discussion

  • Hi,

    Hoping someone can advise / help

    I look after a CRM instance with the following configuration:

    Clients In Domain A

    Dynamics Web / SQL Server in Domain B

    We have a Forest trust between the domains, Domain B trusts Domain A.

    The issue we are encountering (only started recently) is that when attempting to create a new user, specifying for Domain Logon Name the value "DomainA\UserName", Dynamics is unable to validate the credentials.   The cause we know is due to firewall preventing (can see in logs traffic being denied) LDAP on Port 389 from the Member Server (Web Server) in Domain B to the DC of Domain A.  

    The network team have assured us that the Firewall ACL has not been changed, is as it is and has been, for a number of years, so the questions are:

    Q1.  Why is the issue now manifesting?

    Q2.  How has the creation of new users from Domain A worked in the past if the ACL firewall hasn't changed?

    Q3.  Is it expected behaviour for LDAP Queries to go from the member server straight to the trusted Domain DC or should the expected behaviour be that a DC in Domain B executes LDAP Query to a Domain A DC on behalf of Member server in Domain A?

    Now obviously the easy answer is to amend the ACL and allow the traffic, but, our network security team want to understand the answers to the above enable them to make the correct decision.

    Any help greatly received.

    Friday, December 20, 2013 11:34 AM

All replies

  • Did the location of your forest's Global Catalog move to a server that is behind a firewall?

    Friday, December 20, 2013 2:03 PM
  • Hi Chris,

    Domain A is in a separate Forest, ForestA

    Domain B is in ForestB.  All DCs in Domain B are Global Catalog DCs

    As said before any help / advise / understanding on how the LDAP query should be handled between the two Forests / Domains greatly received.



    Monday, December 23, 2013 11:41 AM
  • Ah, you have separate Forests!  From what I have read, a GC is limited to one forest, so in your case CRM has to find a DC in Forest A to verify the authentication.

    Since a global catalog is limited to its own forest, the SPN is not found. The global catalog then checks its database for information about any forest trusts that are established with its forest, and, if found, it compares the name suffixes listed in the forest trust trusted domain object (TDO) to the suffix of the target SPN to find a match. Once a match is found, the global catalog provides a routing hint back 

    Monday, December 23, 2013 2:24 PM
  • Hi Chris,

    Sorry to be misleading! It isn't deliberate!

    I have spoken to the team which maintains the AD and Trusts and they have advised that the trust between the two forests / Domains is a not as I said a Forest Trust, it is a Domain Trust (now this is pushing my knowledge of trusts! I'm not sure if there is such a type of trusts! and if so what any differences mean!!)

    So, is it, that irrespective of what trust type, the fact that Domain A is in a separate Forest, Domain Logon verification will ultimately result in the Domain B DC providing to the member server (MS Dynamics) a Referral / Routing hint (Is the difference that a Referral is something that goes to a member server / workstation and a Routing Hint something which is passed between Domain and Forest DCs), which the member server will use to reissue the LDAP query with target of the Domain A DC which is at the other end of the Trust (of whatever Type!)

    If the above is the case I just wonder why it is that the validation of Domain Logons for users of the trusted Domain, has worked at times and then hasnt? 

    I guess if the above is true (Trust / SPN / Routing Hints) then the answer is simple! the ACL on the firewall must at different times permitted / denied the traffic and is currently denying, consequently, consistently resulting in the "Not a valid Domain Logon" msg box as a consequence of LDAP Timeout due to no reply, due to traffic being blocked by firewall! But networks assure me nothing of this type has gone on!

    So I guess, irrespective of the whys, wherefores, when, hows, the answer is simple, in this configuration, LDAP traffic between the member server in Domain B is required due to (Separate Forest / Trust / Routing Hint ...) 

    You concur?

    Many Thanks for your time to consider the issue and your valued view on MS Dynamics / LDAP / Trusts




    Thursday, January 16, 2014 6:26 PM