Troubleshooting CRM-AD Secure Channels and Trust Relationships

Troubleshooting CRM-AD Secure Channels and Trust Relationships

 

It is very important to understand the concept of secure channel between an AD and workstation machine or between 2 domains which are in trust. This article will give you an overall picture of a security channel. Also, it will explain what issues you will experience if the security channel is broken or how to identify issues due to broken channels.

Every computer that's joined to a domain—whether it's a workstation client, a server, or a DC—requires connectivity to DCs in order to fulfill some of the service requirements that AD domains require. For workstations and servers, that connectivity is to the DCs in the domain that they're a member of, as well as trusting domains' DCs. DCs in one domain need connectivity to DCs in other trusting and trusted domains. The name describing the cached values in that inter-domain connectivity is the "domain secure channel." To be clear, there are two kinds of secure channels:

 

  • Secure channels from a domain member to a DC in its domain
  • Trust secure channels between a trusted and trusting DC

 

Secure Channel between Trusted Domains

To validate access to resources in a trusting domain, the trusting domain controller establishes a secure channel with a domain controller in the trusted domain. Pass-through authentication then occurs over this secure channel. However, in WAN environments, the trusted domain's domain controllers may be dispersed over a wide variety of fast and slow links. If a fast link is unavailable when the trusting domain controller wants to establish a secure channel, the secure channel may be established with a domain controller over a slow link. Even when the fast link is reestablished, pass-through authentication may occur over the slow link to the trusted domain's domain controller. The mechanism for establishing a secure channel is very similar to the normal user -logon process. That is, the trusting domain controllers send out logon requests to all known domain controllers in the trusted domain. The trusting domain controllers then set up a secure channel with the first trusted domain controller that responds to this request. Normally, this method is preferred because the first domain controller to respond to a logon request is typically the controller that is located across the fastest communication link. However, if that link is down or the domain controller is unavailable, a domain controller over a slower link may respond first, and all pass-through authentications occur over the slow link.

 

Here is one of the errors that you will receive if the CRM –AD Security channel is broken. You will not be able to login to CRM Server and receive below error message.

 

 

Verifying Trust using NLTEST utility

There is a built-in mechanism in Windows that tracks how long authentication takes over the existing secure channel. If pass-through authentication takes longer than 45 seconds, that fact is noted. If two such authentications exceed that limit, a rediscovery process begins, the current secure channel is broken, and the trusting domain's PDC once again sends out logon requests to all known trusted domain controllers. However, because this mechanism tracks only those communications that last longer than 45 seconds, users may see a 40- second delay every time they attempt to use a resource without a secure-channel reset taking place. You can run the NLTEST utility on the trusting domain controller to break and re-initialize a secure channel (for example, when  the  secure-channel  password  was  last  changed)  and  obtain  information  about  an  existing  trust relationship. You can also use NLTEST to restart the discovery process for a new trusted domain controller. The syntax of NLTEST is:

NLTEST /sc_query:<account_domain>

 

If Security Channel is good, you should output something similar to below screenshot

 

If the security channel is broken, you shall receive error message as shown in below screenshot

 

Also, you can use nltest /sc_query:<domain.com>  to test the security channel status

 

If CRM-AD security channel is broken then you may see few of the listed problems:

  1. Unable to login to CRM

  2. Unable to add new users in CRM from trusted domain

    Error-1

    Business Management Error: You are attempting to create a user with a domain logon that does not exist. Select another domain logon and try again.

       

    Unhandled Exception: System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: LookupAccountNameW failed with error Detail:

    <OrganizationServiceFault xmlns:i="https://www.w3.org/2001/XMLSchema-instance" xmlns="https://schemas.microsoft.com/xrm/2011/Contracts">

      <ErrorCode>-2147214038</ErrorCode>

      <ErrorDetails xmlns:d2p1="https://schemas.datacontract.org/2004/07/System.Collections.Generic" />

      <Message>LookupAccountNameW failed with error</Message>

      <Timestamp>2013-12-19T16:24:35.8171875Z</Timestamp>

      <InnerFault i:nil="true" />

      <TraceText i:nil="true" />

    </OrganizationServiceFault>

     

    OR

     

    Error-2

    Unable to find AD object for SID

 

 

 

To know more about NLTEST and Troubleshooting Security Channel issues, please refer below articles:

https://social.technet.microsoft.com/wiki/contents/articles/16067.nltest-to-test-the-trust-relationship-between-a-workstation-and-domain.aspx

https://support.microsoft.com/kb/158148

https://blogs.technet.com/b/asiasupp/archive/2007/01/18/typical-symptoms-when-secure-channel-is-broken.aspx