Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a complex environment, many highend cisco network boxes, firewalls, and routers. I have many (100-200) connection timeout errors (just authenticating, not running any queries) connecting from IIS to SQL server 2005 using windows authentication. Our network engineers have poured over tcp/ip dumps, we don't have AD experts in house, Kerberos doesn't seem to work in our db environment, so I thought you all might be able to point to documentation on how IIS makes a connection to SQL server where the domain of the servers are different from the domain of the user and the user's domain is housed in another state over dedicated leased lines. Both locations have redundant DC controllers and site metrics setup. Network geeks think that the time it takes kerberos to fail and default to NTLM could be issue.

More info: We brought in MS premier consultant again, and we found LSASS.exe sp? was consuming tons of CPU on AD boxes. Culprit was Barracuda SPAM box doing queries against AD for non-existant meta data columns. If I found out how he figured that out, I will post.

TIA, Chuck

share|improve this question
Do the network boffins see this Kerberos failure and revert to NTLM behaviour? Also, regular Kerberos failures usually include timesync issues. – Froosh May 29 '09 at 5:47
Yep, I just haven't had the time to investigate deeper. I suspect SPN's just aren't getting created correctly or at all. – SQLGuyChuck May 29 '09 at 15:29

I am not sure you will get a good answer unless you break up your problem into smaller chunks.

I would start with these steps, undoing any changes that don't help. Please update your question as you obtain more information about the problem:

  • Check DNS -- make sure your DNS servers are responding promptly:

    • try using a hard-coded IP address in your data source, or
    • add an entry in the hosts file to eliminate name resolution latency as a problem.
  • Rule out NT auth as the problem by switching your web app to use SQL auth. Normally I would not even think of this but you mentioned some authentication problems in your question.

  • Verify that there is no packet loss between the web server and the DB server.

    • Try ping with a high packet size, even running several instances of the following ping command at once: ping -t -w 100 -l 5000 dbhost
  • Try altering your connection pooling settings.

share|improve this answer
We even had a Microsoft consulting team person on site to help and found issues that we resolved and did a bunch of tcpip testing with packet sizes. I am just looking for literature and testing methodologies like your ping test idea. I documented our tcpip tweaks here: – SQLGuyChuck May 29 '09 at 15:27

Microsoft's KB319723 describes using Kerberos with SQL Server and IIS. It should not be a problem to authenticate to SQL servers in one domain using user accounts from another domain, so long as they're within the same AD forest. I have, however, seen issues connecting to named instances of SQL server from outside of the domain. You have to set up a SQL alias for the named instance.

share|improve this answer

Here is the tool Premier support used to find why lsass was using so much CPU: spa_v2.msi “Server Performance Advisor” Change drop down value to active directory and with the aid of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics REG_DWORD change value from “0” to “5” then view Directory Services log for errors.

This revealed the culprit lookup of OtherMailBox.

He then pulled this out of his head, cmd window: Ldifde -F foo.txt –s corpdc01 –P subtree –d “DC=Corp,DC=redmond,DC=Local” –r “(OtherMailBox=*)”

To determine if we were using this object in the AD. We were not. The log showed the barracuda’s IP addresses and NSLOOKUP did the rest. Handed that info to IT Admins and they were able to fix.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.