I know this is a frequently asked question, but either many aren't answered, or are not my particular issue. So, at the risk of being redundant:
1 - Classic ASP Site.
2 - Windows Authentication enabled (test settings button all successful)
3 - Anonymous Authentication disabled
4 - Passthrough Authentication enabled
5 - AppPool ID set to domain\domainUserAccount
6 - domain\domainUserAccount set as LOGIN in SQL Server Security
7 - domain\domainUserAccount set as user in Database.
With all these options set, the site should use my own login creds to access IIS site resources. And it should use the AppPool Active Directory User service account to access SQL Server database. Right?
But, I get the dreaded:
Microsoft SQL Server Native Client 11.0 error '80040e4d'
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
I've tried everything I can think of, and usually the above solves the problem. But not this time.
Any ideas or advice on what to look for?
EDIT: If I give it an Active Directory service account in IIS in "Connect as... --> Specific User", it runs fine, but only if I give that service account Read/Write access to Windows/Microsoft.NET/Framework64/V4.0xxx/Temporary ASP.NET Files. This is somehow a monumental security risk for our Network Admin, even though I have explained that this is perfectly normal for an IIS/ASP service account to be able to R/W this temp files folder in order to run properly.
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.
Edit
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.
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.
First off: My problem isn't the exact same as yours, but this post is the first thing that comes up in google for the Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' error at the time I wrote this. The solution may be useful to people searching for this error as I did not find this specific solution anywhere online.
In my case, I used Xampp/Apache and PHP sqlsrv to try to connect to an MSSQL database using Windows Authentication and received the Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' error you described. I finally found the problem to be the Apache service itself running under the user "LOCAL SERVICE" instead of the user account I was logged in as. In other words, it literally was using an anonymous account. The solution was to go into services.msc, right click the Apache service, go to Properties, go to the Log On tab, and enter the credentials for the user. This falls in line with your problem related to SPN's as your SPN's are set up to run from a specific user on the domain. So if the correct SPN is not running, windows authentication will default to the wrong user (likely the "LOCAL SERVICE" user) and give you the Anonymous error.
Here's where it's different from your problem. None of the computers on the local network are on a Domain, they are only on a Workgroup. To use Windows Authentication with a Workgroup, both the computer with the server (in my case MSSQL Server) and the computer with the service requesting data (in my case Apache) needed to have a user with an identical name and identical password.
To summarize, The Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' error in both our cases seems to be caused by a service not running and/or not on the right user. Ensuring the right SPN or other Service is running and under the correct user should solve the anonymous part of the problem.
I think there must have been some change in AD group used to authenticate against the database. Add the web server name, in the format domain\webservername$, to the AD group that had access to the database. In addition, also try to set the web.config attribute to "false". Hope it helps.
EDIT: Going by what you have edited.. it most probably indicate that the authentication protocol of your SQL Server has fallen back from Kerberos(Default, if you were using Windows integrated authentication) to NTLM. For using Kerberos service principal name (SPN) must be registered in the Active Directory directory service. Service Principal Name(SPNs) are unique identifiers for services running on servers. Each service that will use Kerberos authentication needs to have an SPN set for it so that clients can identify the service on the network. It is registered in Active Directory under either a computer account or a user account. Although the Kerberos protocol is the default, if the default fails, authentication process will be tried using NTLM.
In your scenario, client must be making tcp connection, and it is most likely running under LocalSystem account, and there is no SPN registered for SQL instance, hence, NTLM is used, however, LocalSystem account inherits from System Context instead of a true user-based context, thus, failed as 'ANONYMOUS LOGON'.
To resolve this ask your domain administrator to manually register SPN if your SQL Server running under a domain user account.
Following links might help you more:
http://blogs.msdn.com/b/sql_protocols/archive/2005/10/12/479871.aspx
http://support.microsoft.com/kb/909801
You probably just need to provide a user name and password in your connectionstring and set Integrated Security=false
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"/>
One of my SQL jobs had the same issue. It involved uploadaing data from one server to another. The error occurred because I was using sql Server Agent Service Account. I created a Credential using a UserId (that uses Window authentication) common to all servers. Then created a Proxy using this credential. Used the proxy in sql server job and it is running fine.
FWIW, in our case a (PHP) website running on IIS was showing this message on attempting to connect to a database.
The resolution was to edit the Anonymous Authentication on that website to use the Application pool identity (and we set the application pool entry up to use a service account designed for that website).
A similar case solved:
In our case, we wanted to set up linked servers using cnames and with the logins current security context.
All in order we checked that the service account running SQL Server had its' proper spns set and that the AD-object was trusted for delegation. But, while we were able to connect to the cname directly, we still had issues calling a linked server on its' cname: Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
It took us far too long to realize that the cnames we used was for A-record, [A], that was set on a higher dns level, and not in its' own domain AD-level. Originally, we had the cname directing to [A].example.com and not (where it should) to: [A].domain.ad.example.com
Ofcourse we had these errors about anonymous logon.
Got it! Solved the issue modifying the user properties in security session of SQL Server. In SQL Server Management, go into security -> Logon -> Choose the user used for DB connection and go into his properties. Go to "Securators" tab and look for line "Connect SQL", mark "Grant" option and take a try. It works for me!
Regards
Just Go to app pool select Process model in Advance Setting then select Identity and in identity set your account details like username and password of your system.
Background:
ASP.Net MVC website. Hosted on IIS7, intranet.
Database: SQL Server. Accessed via NHibernate.
In the connection string, access is set to Integrated Security: SSPI.
(Permissions to DB are Active-Directory-based.)
In short, this is a typical double-hop situation,
where I need to pass client's credentials to IIS, and from IIS to SQL Server.
The Problem:
The problem is a yellow screen of death, with the error:
Login failed for user 'MyDomain\UserThatRunsAppPool'.
Things I tried doing to fix The Problem:
Configuring authentication to enable only Windows Authentication
and ASP.NET Impersonation
Setting Windows Authentication Provider to Negotiate:Kerberos
(After disabling Kernel-mode authentication)
Making sure that UserThatRunsAppPool's delegation is set to:
'Trust the user for delegation to any service (Kerberos only)' in Active Directory
Moving the NHibernate SessionFactory creation from Application_BeginRequest()
to Session_Start()
How successful I've been with my attempts to fix The Problem:
Not at all.
EDIT:
I also tried setting IIS server's delegation to 'Trust the user for delegation to any service (Kerberos only)' (in Active Directory).
In short, this is a typical double-hop situation,
where I need to pass client's credentials to IIS, and from IIS to SQL Server.
You've hit upon the "delegation" problem. If you want to remain sane, change your connection string to use a SQL username + password instead of SSPI.
If you feel like two weeks of frustrated debugging and quarreling with your domain admins, read Fun with the Kerberos Delegation Web Site.
We have a 3rd party product that allows some of our users to manipulate data in a database (on what we'll call SvrSQL) via a website on a separate server (SvrWeb).
On SvrWeb, we have a specific, non-default website setup for this application so instead of going to http://SvrWeb.company.com to get to the website we use http://application.company.com which resolves to SvrWeb and the host headers resolve to the correct website.
There is also a specific application pool set up for this site which uses an Active Directory account identity we'll call "company\SrvWeb_iis". We're setup to allow delegation on this account and to allow it to impersonate another login which we want it to do. (we want this account to pass along the AD credentials of the person signed into the website to SQL Server instead of a service account.
We also set up the SPNs for the SrvWeb_iis account via the following command:
setspn -A HTTP/SrvWeb.company.com SrvWeb_iis
The website pulls up, but the section of the website that makes the call to the database returns the message:
Cannot execute database query.
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
I thought we had the SPN information set up correctly, but when I check the security event log on SrvWeb I see entries of my logging in, but it seems to be using NTLM and not kerberos:
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Any ideas or articles that cover this setup in detail would be extremely appreciated!
If it helps, we are using SQL Server 2005, and both the web and SQL servers are Windows 2003.
There are several possible reasons for kerberos failures which includes lack of SPN and duplicate SPN as well.
If SQL is running under custom account you would need to add SPN for SQL as well.
Also keep in mind, you should be adding SPN for the FQDN which is the host (A) entry in DNS and not a CNAME.
Check the value of NTAuthenticationProviders
http://support.microsoft.com/kb/215383
Try DelegConfig which would show what is missing if its SPN or something else.
http://www.iis.net/community/default.aspx?tabid=34&g=6&i=1887
I am trying to run a SQL Server Reporting Services where the data for the report is on a SQL Server database that's on a different server. Integrated Authentication is turned on for both the Report Server and the report. I have confirmed that Kerberos delegation is working fine by using Internet Explorer to run the report from inside the network.
However, when I open the report server through the firewall, I cannot run the report. I get the following error: An error has occurred during report processing. Cannot create a connection to data source 'frattoxppro2'. Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
Does Kerberos authentication not work outside a firewall?
Kerberos requires a port 88 connection to the KDC, in this case, most likely your DC.
What you probably want to look at is HTTPS + Basic Authentication + Protocol Transition to take the Basic Authentication and translate it into a DC based Kerberos Ticket for delegation and back end authentication.
Protocol Transition with
Constrained Delegation Technical
Supplement
How To: Use Protocol Transition and
Constrained Delegation in
ASP.NET
Not exactly the easiest to set up, but when its working, it works amazingly well.
I'm not really in a position to tell you why kerberos isn't working for you, but did have a alternative suggestion for your configuration. You can use ISA services to expose the reporting server rather than simply poking a hole in your firewall. This is something our company has done successfully - it republishes the reporting services site so the browsers are talking to ISA, not directly to the server. ISA Services is quite happy to pass through your credentials as well.