ANONYMOUS LOGON error on Distrib Txn

  • Can anyone offer any help ?

    I have SQL2K on a cluster with 2 nodes and 2 instances of SQL(PROD1 and PROD2). I am trying to access data from a database on PROD1, by running an SP on PROD2. These are both set up as linked servers to each other and I am using a domain NT logon. The system is config'd to only allow NT authentication and the security is set to only allow EXEC permissions on SP's and Database Chaining passes through the security setting of the initial call.

    Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' is reported when trying to access the tables in PROD1.

    Thanks

  • Are you calling the SP from ASP or anything else?

    Have you grant 'NT AUTHORITY\ANONYMOUS LOGON' access SQL Server with proper permissions to tables in instance PROD1?

  • SP called from ASP appl using ASPNET and system configured to use localhost/ASPNET user through all connections.

    Password is the same on Web and both SQL servers in the cluste.

    There is no specific permissions on table within PROD1 - do not want to grant any SELECT/INSERT etc access directly to the tables

  • SP called from ASP appl using ASPNET and system configured to use localhost/ASPNET user through all connections.

    Password is the same on Web and both SQL servers in the cluste.

    There is no specific permissions on table within PROD1 - do not want to grant any SELECT/INSERT etc access directly to the tables

  • Thanks for these.

    The ASPNET login is configured to have EXEC permissions. Our policy is to prevent direct access to SQL statements, except through SP's.

    This all works correctly if the multiple instances are on the same physical server. It only becomes a problem, when the two databases are on two instances on two different physical servers.

  • Look at "Security Account Delegation" in the BOL. There are also knowledgebase articles on MSDN.

  • Are you doing linked server connections between the two DBs? If so, bbychkov has hit the nail on the head. You're in a double-hop situation.

    Delegation under Active Directory solves the problem. If you're still running under an NT 4.0 domain structure, you're going to have to make one connection a SQL Server login.

    K. Brian Kelley

    http://www.truthsolutions.com/

    Author: Start to Finish Guide to SQL Server Performance Monitoring

    http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1

    K. Brian Kelley
    @kbriankelley

  • I do have linked servers and I believe that the account delegation commands have been performed, but I will now check this further. I know that the setspn -L command did not appear to show anything different after performing the command.

Viewing 9 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic. Login to reply