Linked Server problem, apparently with double-hop problem

Ok, I have read several posts about this problem, and even an explanation on how NTLM fails in double-hop scenarios. I understand it.

I, however, cannot understand why it is failing, as I am working in a AD environment with domains in Windows 2000 native mode which should be using Kerberos and not NTLM.

My setup is this: Server A is my own server, a Windows Server 2003 Standard setup with SQL Server 2000. We also have Server B, same OS and same SQL Server; I am NOT admin for Server B, but I am for Server A. Both SQL Servers are setup for Windows Authentication only.

Now, I have a web application (ASP.NET 2.0) running on Server A that connects to SQL Server in Server A. I have learned that the website connects to SQL server as the user NT AUTHORITY\NETWORK SERVICE (as opposed to classic ASP where the user was impersonated), so I created a SQL server login for NT AUTHORITY\NETWORK SERVICE. The website successfully connects to SQL Server A.

The next step is to create a stored procedure on Server A that retrieves data from Server B in the form of a linked server. This way the ASP.NET application has access to the desired data.

This is where the problem presents itself:

Msg 18456, Level 14, State 1, Line 2

Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.

The SQL Server login in Server B is a local server security group that contains two AD accounts: domainA\myownlogin, and domainA\ServerA, where the latter is the computer object for Server A. Server B is in domainB, and two-way trusts are in place through transivity via the forest root domain. My own account is there for easy testing of scripts in my workstation, but the idea is to remove it and have the website use the computer credentials once it hits production.

Any ideas? Should I check something in the domains? How can I verify that kerberos is being used so I can discard this as a possibility? Any and all feedback is welcome.

Look into using an 'Application Pool' for login security on the web server (create an appropriate domain login account for the application). In AD, give that login account Delegation permission. Then in ServerB, give that login account permissions to access the data.

sql