Partilhar via

NTLM Authentication with SharePoint Part 2

  • Artigo

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.
  9. If possible change to Kerberos authentication.

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

  • Anonymous
    June 24, 2006
    The comment has been removed
  • Anonymous
    June 24, 2006
    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
  • Anonymous
    November 29, 2006
    I recently found out about Chris Gideon's postings about SharePoint 2007 and authentication. Very interesting...
  • Anonymous
    February 07, 2007
    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,Joejmoorman@covlife.org
  • Anonymous
    March 19, 2008
    PingBack from http://www.sharepointbuzz.com/index.php/2008/03/19/sharepoint-2007-and-authentication/
  • Anonymous
    October 30, 2008
    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,
  • Anonymous
    May 29, 2009
    PingBack from http://paidsurveyshub.info/story.php?title=chris-gideon-s-weblog-ntlm-authentication-with-sharepoint-part-2