Menu
An application that has been working without problem (and has not had any active development done on it in about 6 months or so) recently began failing to connect to database. Operations admins cant say what might have changed that would cause the problem.
The client application uses a hardcoded connection string with Integrated Security=True, but when the applications attempts to create a connection to the database, it throws an SQLException saying "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON".
I can log on to the database through Management Studio on this account without problem. All of the things that I have seen for this issue are for ASP.NET projects and it is apparently the "Double Hop Problem" which being a client application darned well better not be a problem. Any help would be greatly appreciated.
The client machine and server machine as well as user accounts are on the same domain. This occurs when Windows Firewall is off.
Leading theory is: Server was restarted about a week or so ago, and failed to register Service Principal Name (SPN). Failure to register an SPN may cause integrated authentication to fall back to NTLM instead of Kerberos.
750
When the OS can't validate who you are, you are NT AUTHORITY\ANONYMOUS LOGON. You typically see this in double hop situations like when you have a client connecting to SSRS and SSRS isn't on the same server as the SQL Server where the DB is located. As you might have guessed, they shouldn't have done this.
First, open SQL Server Management Studio and connect to the instance of your choice. Then, go down to “Server Objects” and right-click on “Linked Server” node. A contextual menu should appear. Click on “New Linked Server…”.
To register the SPN manually, you can use Setspn tool that is built into Windows. Setspn.exe is a command-line tool that enables you to read, modify, and delete the Service Principal Names (SPN) directory property.
If your issue is with linked servers, you need to look at a few things.
First, your users need to have delegation enabled and if the only thing that's changed, it'l likely they do. Otherwise you can uncheck the "Account is sensitive and cannot be delegated" checkbox is the user properties in AD.
Second, your service account(s) must be trusted for delegation. Since you recently changed your service account I suspect this is the culprit. (http://technet.microsoft.com/en-us/library/cc739474(v=ws.10).aspx)
You mentioned that you might have some SPN issues, so be sure to set the SPN for both endpoints, otherwise you will not be able to see the delegation tab in AD. Also make sure you're in advanced view in "Active Directory Users and Computers."
If you still do not see the delegation tab, even after correcting your SPN, make sure your domain not in 2000 mode. If it is, you can "raise domain function level."
At this point, you can now mark the account as trusted for delegation:
In the details pane, right-click the user you want to be trusted for delegation, and click Properties.
Click the Delegation tab, select the Account is trusted for delegation check box, and then click OK.
Finally you will also need to set all the machines as trusted for delegation.
Once you've done this, reconnect to your sql server and test your liked servers. They should work.
109
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
