sql server connect: Login failed for user '(null)' -- sql server connect

haltenberg NO[at]SPAM yahoo.com
6/24/2004 3:21:48 AM

sql server connect:

I am running a third-party web application (mainly ASP and specific
pages with their own extension that are processed by a third-party
ISAPI dll) on a Windows 2000 Server (IIS 5.0) which is also a domain
controller and has MS SQL 2000 installed. Anonymous access in IIS for
this application is set to use a domain account. This account is also
granted access to MS SQL 2000 database. Everything works just fine.

For performance purposes I moved MS SQL 2000 Server to a new machine
(Windows 2003 server, domain member). When I did so, asp scripts in
the application work perfectly well. I have auditing turned on on MS
SQL running on Windows 2003 and I can see successful logins to MSSQL
for the user which is configured for anonymous access in IIS running
on Windows 2000.

But, when I try to access any of those specific pages with their own
extension that are processed by ISAPI dll, the IIS log shows the
following error:
Out-of-process+ISAPI+extension+request+failed. 503
and the MSSQL errorlog shows the following error at once:
Login failed for user '(null)'. Reason: Not associated with a trusted
SQL Server connection.

According to this application's documentation, TCP/IP and Named Pipes
are required on MS SQL (and they are there!). There's also a specific
mentioning that that particular ISAPI requires and works through Named
Pipes only.

For testing purposes I have also deployed IIS on Windows 2003 and
installed the application telling it to use MS SQL server on the
Windows 2000 DC and this worked fine! But when I do backwards, I get
Login failed for user '(null)' and
Out-of-process+ISAPI+extension+request+failed. 503 in IIS.

I need to have IIS on Windows 2000 DC and MS SQL on Windows 2003
domain member and it doesn't work, but works fine when I do vice versa
(IIS on 2003 and MS SQL on 2000 DC). I have checked all the policies
for 'access this computer from the network', 'log on locally',
'accounts trusted for delegation', 'computer trusted for delegation'
and the behavior is still the same:

- if IIS is on Win2000 DC and MSSQL is also there, everything works;
- if IIS is on Win2000 DC and MSSQL is on Windows 2003 domain member:
error;
- if IIS is on Win2003 domain member and MSSQL is on Win2000 DC:
everything works.

Re: Login failed for user '(null)'

Steve Thompson
6/24/2004 9:38:53 AM

Hi Paul,

I'm posting a message from Peter Afonin that had a very similar issue -- see
if this helps you:
~~~~~~~~~~~~~~~
Some time ago I posted a message here about my problem: after upgrading the
domain controller to Windows Server 2003, I couldn't use the SQL server
trusted connection due to the error: Login failed for user '(null)'. Reason:
Not associated with a trusted SQL Server connection.

To solve this problem, I had to open a case with Microsoft. Since recently
I've received several emails from people with the same problem, I realized
that I was not alone with this issue, so I decided to post the solution
here.

There are two ways to fix this problem: to remove TCP/IP protocol from SQL
server or to impersonate users.

Remove TCP/IP

1. Go to SQL Server properties, then to General tab - Network configuration.
Remove TCP/IP protocol there.

This worked for me. However, since TCP/IP is required for replication, I had
to add it back.

Impersonate SQL Server users.

Usually you can impersonate users by going to the Local security policy in
Administrative Tools, then to Impersonate a client after authentication.
However, if you deal with the Domain controller, most of the controls there
are disabled. So:

1. Go to the Active Directory, right-click on Domain Controllers and select
Properties
2. Go to the Group Policy tab and highlight Default Domain Controller
Policy, click Edit
3. Go to Windows Settings - Security Settings - Local Policies - User Rights
Assignment
4. Double-click Impersonate a client after authentication

Then Microsoft suggested to uncheck the box Define these policy settings,
then go to the Local security policy and add users there. It worked.
However, I think it would be better just add the users right there, without
going to the Local security policy.

Either way, this solved my problem.

Hope this helps.

--
Peter Afonin
~~~~~~~~~~~~~~~

[quoted text, click to view]