Strange Windows Authentication Behavior

I was writing an ASP.Net 2.0 web application using Windows authentication (since I needed to capture users’ credentials). The web application saves data into a MS SQL 2005 database using a SQL server account. While developing this application, I ran into a very strange issue.

Since the database access is using a SQL Server account rather than integrated authentication, in theory the database access code should not be affected by whether I use Forms authentication or Windows authentication in the web application.

However, the problem I ran into was that if I use Forms authentication mode, everything works fine. But if I switch the authentication mode to Windows, I would get the following error message emitted from the data access layer after the application was deployed to the server:

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 – Could not open a connection to SQL Server)

What is weirder is that if I tried to use the application locally on the web server after deployment, everything would work fine. And after “touching” the deployed website on the server, the web pages can then be remotely accessed via client browser for a while (10 minutes maybe) but after that the same error would occur again.

So I searched many forums but could not find any conclusive explanations or remedies.

The Not So Satisfying Solution

One of my coworkers took a look at my code and confirmed that there were no coding errors but noticed that I did not have port information in the connection string (Note, even though we use non-standard ports, this has never been necessary). So as he suggested, I plugged in the port number and it worked!

Clearly, I am still as confused as before. The authentication modes differences must have somehow affected the way the connection string is interpreted…

Be Sociable, Share!


  1. Rich says:

    So I assume it’s still working? That sure was weird and I agree not so satisfying since the “fix” didn’t make a whole lot of sense. In retrospect, we could have tried running SQL Server Profiler to see if a connection was actually being made or ask the network guys to run a sniffer trace if it really got bad.

  2. Matt Neerincx (MSFT) says:

    Yes, this is difficult behavior to explain but I can take a crack.

    If the SQL Server is a default instance and running on a non-standard port (not running on 1433), then tcp protocol will always fail. You have to specify the port for tcp. What happens next is the client provider will try named pipes protocol after tcp protocol fails. Named pipes uses a well known named pipe and will work as long as the thread of execution has sufficient NT security to perform SMB request to remote server.

    Depending upon how you configure ASP.NET security the named pipe can fail or succeed. Tcp is agnostic to NT security and will succeed as long as you supply the port.

    This applies to default instance, if it’s a named instance client does not have to supply port the port is determined by running a UDP 1434 lookup.

Leave a Reply