SQL Server returns a "Login failed for user NT AUTHORITY \ ANONYMOUS LOGON." Error in a Windows application

Question

An application that works without problems (and did not actively develop on it after about 6 months or so) has recently started to not work with the database. Operations administrators cannot say what could change, what could cause the problem.

The client application uses the gated connection string with Integrated Security = True, but when applications try to create a database connection, it throws a SQLException which says: "Login failed for user" NT AUTHORITY \ ANONYMOUS LOGON ".

I can enter the database through Management Studio in this account without problems. Everything I saw for this problem is related to ASP.NET projects, and apparently this is a "double hop problem", which is a client application, best not a problem. Any help would be greatly appreciated.

Edit

The client computer and server, as well as user accounts, are in the same domain. This occurs when the Windows Firewall is turned off.

Leading Theory: The server was restarted about a week ago and was unable to register the Service Principal Name (SPN). Failure to register an SPN may result in Integrated Authentication returning to NTLM instead of Kerberos.

Answer 1

If your problem is related servers, you need to look at a few things.

Firstly, your users need to enable delegation, and if this is the only thing that has changed, most likely they will do it. Otherwise, you can clear the "Account is sensitive and cannot be delegated" checkbox, this is a user property in AD.

Secondly, your service account must be trusted with delegation. Since you re-changed your service account, I suspect it is a criminal. ( http://technet.microsoft.com/en-us/library/cc739474 (v = ws.10) .aspx )

You mentioned that you may have problems with the SPN, 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 that you are in the expanded view in Active Directory Users and Computers.

If you still do not see the delegation tab, even after fixing your SPN, make sure that your domain is not in 2000 mode. If so, you can "increase the level of the domain function."

Now you can mark the account as trusted for delegation:

In the details pane, right-click the user you want to trust and click Properties.

Go to the "Delegation" tab, select "Account" for delegation, select the check box, and then click "OK".

Finally, you will also need to install all the machines as reliable for delegation.

Once you do this, connect to the sql server and check your favorite servers. They should work.

Answer 2

First: My problem is not the same as yours, but this post is the first thing that appears on google for the Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' error at the time I wrote it. The solution can be useful for people who are looking for this error, because I did not find this specific solution anywhere on the Internet.

In my case, I used Xampp / Apache and PHP sqlsrv to try to connect to the MSSQL database using Windows authentication and received the Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' error you described. Finally, I found that the problem is that the Apache service itself is running under the user "LOCAL SERVICE" instead of the user account I was registered with. In other words, he literally used an anonymous account. The solution was to go to services.msc, right-click the Apache service, go to "Properties", go to the "Login" tab and enter the credentials for the user. This is consistent with your SPN issue, as your SPN is configured to work from a specific user in the domain. Therefore, if the correct SPN is not running, Windows Authentication will default to the wrong user (probably the "LOCAL SERVICE" user) and give you an anonymous error.

Here, where it differs from your problem. None of the computers on the local network are in the domain, they are only in the workgroup. To use Windows authentication with a workgroup, both a computer with a server (in my case, MSSQL Server) and a computer with service request data (in my case, Apache), you must have a user with the same name and identical password.

To summarize, the Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' error in both of our cases is apparently caused by the service not running and / or not for the right user. Ensuring the correct SPN or other service is in progress and the anonymous part of the problem should be resolved under the correct user.

Answer 3

I think that some changes in the AD group must have been used to authenticate against the database. Add the name of the web server in the \ webservername $ format domain to the AD group that has access to the database. Also, try setting the web.config attribute to false. Hope it helps.

EDIT . Going over what you edited. Most likely, this means that your SQL Server authentication protocol was dropped from Kerberos (by default, if you used Windows Integrated Authentication) in NTLM. To use the Kerberos service principal name (SPN), you must register the Active Directory directory service. Service Principal Name (SPN) are unique identifiers for services running on servers. For each service that uses Kerberos authentication, an SPN must be installed so that clients can identify the service on the network. It is registered in Active Directory under a computer account or user account. Although Kerberos is the default protocol, if the default fails, the authentication process will be verified using NTLM.

In your scenario, the client should make a tcp connection and most likely runs under the LocalSystem account and the SPN is not registered for the SQL instance, so NTLM is used, however, the LocalSystem account is inherited from the System Context instead of the real user-based context, thus failed as "ANONYMOUS LOGON".

To resolve this, ask your domain administrator to manually register the SPN if your SQL Server is running under a domain user account. The following links may help you more:
http://blogs.msdn.com/b/sql_protocols/archive/2005/10/12/479871.aspx
http://support.microsoft.com/kb/909801

Answer 4

One of my SQL jobs had the same problem. It included downloading data from one server to another. The error occurred because I used the SQL Server Agent service account. I created credentials using UserId (which uses Windows authentication), common to all servers. Then create a proxy server using these credentials. The proxy server is used in the sql server job, and it works fine.

Answer 5

You probably just need to provide a username and password in the connection string and set Integrated Security = false

Answer 6

Try setting "Integrated Security = False" in the connection string.

 <add name="YourContext" connectionString="Data Source=<IPAddressOfDBServer>;Initial Catalog=<DBName>;USER ID=<youruserid>;Password=<yourpassword>;Integrated Security=False;MultipleActiveResultSets=True" providerName="System.Data.SqlClient"/> 

Answer 7

FWIW, in our case (PHP) a website running on IIS, showed this message when trying to connect to the database.

It was decided to change the anonymous authentication on this website to use the application pool identifier (and we configured the application pool entry to use the service account dedicated to this website).