NTLM Authentication with SharePoint Part 2


In my last post I laid out the basic flow of NTLM authentication with SharePoint when all the accounts (user, service and machine) reside in the same domain. In this post I will discuss the implications of multiple domains in two different scenarios.

Scenario 1:

Active Directory Forest=Farbrikam.com; Domain for users= CHILD.Fabrikam.com; SharePoint WFE, SQL DB have machine accounts in Fabrikam.com; SharePoint Application Pool and SQL Service accounts are in Fabrikam.com.

In this scenario the secure channel DC servicing SharePoint has to contact its peer DC in the CHILD domain via the trust. By default the MaxConcurrentApi for a Domain controller over a trust is one. That’s right one concurrent request (one user at a time) will be processed over the trust. That’s why adjusting the MaxConcurrentApi on the DC’s servicing SharePoint (or any other high volume application, ISA comes to mind) is important. Again profile and test don’t just jump to ten.

Scenario 2:

Active Directory Forest=Farbrikam.com; Domain for users= CHILD.Fabrikam.com; SharePoint WFE, SQL DB have machine accounts in Fabrikam.com; SharePoint Application Pool and SQL Service accounts are in GrandChild.Fabrikam.com.

In this scenario you have the same need to walk the trust for users but you also have a new need to walk the trust for the service accounts.

These two scenarios require another item to consider under high volumes of authentication, Secure Channel “float”. There are a handful of reasons as to why secure channel resets to a different DC. The first is a response greater than or equal to 45 seconds. This is usually the result of a secure channel being established over a slow link or a Secure Channel to a DC that is overloaded (high CPU). Second, there is a network failure to get to the secure channel DC. This can be caused by a physical network failure; Spanning Tree running on the switch which is outlined here; a hiccup from auto negotiate (determining the speed and duplex settings) at the NIC to the switch outlined here; or the Secure Channel DC being rebooted. Once the secure channel is unbound from a DC it goes through the DC Locator process to find a DC. If you have multiple geographical sites in your environment it is important to designate Active Directory Sites to keep your SharePoint servers using local DC’s. Under a high load the last thing you want is your Secure Channel DC being over a slow WAN link and this can happen if you don’t architect this into your design. This can also happen if you place DC/GC over slow links for the domains you are authenticating. For example, in Scenario 1 if the DC/GC for the CHILD domain is over a slow link a bottleneck will be possible. The better design would have DC/GCs for the Fabrikam.com and CHILD domains close (high speed links) to the SharePoint servers and an Active Directory Site specified to keep Secure Channels local if the DC Locator process is called.

To sum up my recommendations for best performance:

  1. Consider creating an Active Directory site just for the SharePoint boxes (if in the same forest) and add GC’s for each domain going against SharePoint.
  2. Make certain that the DC/GC’s are physically as close (high speed links) as possible to the SharePoint boxes.
  3. If possible make all DC’s GC’s if in Native Mode.
  4. Hard set NIC’s and Switches Speed and duplex settings to avoid loss of connecting during auto negotiate.
  5. Check with your switch vendor on the settings for spanning tree to avoid Secure Channel drops. Most vendors have an option to keep this from happening while still benefiting from Spanning Tree.
  6. Increase MaxConcurrentApi and profile DC/GC (for domains in play) with SPA to see if they can handle the load. Make certain to do this on the SharePoint servers and DC/GC for all domains in play.
  7. Monitor Secure Channels with NLTest.exe after patches that cause a reboot to ensure that secure channels don’t float to slow link DC/GCs.
  8. For extreme performance consider the use of x64 DC/GCs. See the impressive results here.

To see a good explanation as to the troubleshooting process check out SPAT’s blog post on the subject.

Why am I taking the time to point this out with regard to SharePoint specifically? Because slow NTLM authentication is one of the leading causes of the dreaded Cannot connect to the configuration/site database and this is rarely considered in troubleshooting this error (problem). It is also a factor in slow portal search crawls because of the number of Group Membership evaluations that are required for Security Trimming.


Comments (7)
  1. paalam says:

    Hi. A have a strange problem. A few weeks ago we set up a trust between two domains. The problem is that while we can import user profiles from the trusted domain, we cannot add users. When I try adding a user with "trusteddomain.dkuser1", this is the error I get:

    "None of the users or cross-site groups you entered could be added. Please make sure there were no typing mistakes on the previous page and semicolons were used to separate the names."

    The trusted domain resides in another country.

    Do you believe this problem could relate to any of the factors you mention in your article?

  2. Cgideon says:

    Hi Paalam,

    The first thing I would check is the account you are using for the applicaiton pool and check it against the login/permissions it has in SQL (Make sure that account is Security Admin and DBO). At that point I would also ensure (since we are talking about portal) that we are using Windows Authentication back to SQL. If you are using Windows Integrated Authentication back to SQL then you might want to examine:

    827749 You receive an "Unable to retrieve user information from Active Directory directory service" error message when you try to add users to your portal site

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;827749

    Hope this helps,

    Chris

  3. Anonymous says:

    I recently found out about Chris Gideon’s postings about SharePoint 2007 and authentication. Very interesting…

  4. JoeMoorman says:

    We’re running WSS 2.x and are trying to connect users from a trusted domain. It looks like the users from the trusted domain are authenticating in sharepoint and are able to open the home page. However, the they are unable to download images or open subsites on WSS hosted on the trusting domain. Any Thoughts?

    Thanks,

    Joe

    jmoorman@covlife.org

  5. aaron_00 says:

    Hi,

    I’m having an issue with adding users into my SharePoint farm, from a trusted domain. I can find the user ok i.e. domainusername, and it adds the user to the site fine- but they are missing all their AD information- most importantly is their e-mail address.

    Is there a fix for this anywhere?

    Any help much appreciated.

    Thanks,

Comments are closed.

Skip to main content