We have the infamous Kerberos double hop issue.
This is a brand new domain, being migrated from another provider where impersonation and delegation was previously working. We have upgraded OS's and to the latest SQL server (2017).
WPF app (using domain creds) -> Web Service (WCF app on IIS 10) -> SQL 2017 (named instance)
The web service is running under a domain account. The web service has an spn registered, Anonymous Auth is disabled as is forms auth, ASP.NET Impersonation and Windows Auth is enabled. Providers are "Negotiate and NTLM," "Kernal Mode" is disabled, "Use App Pool credentials" is enabled. SPN created:
HTTP/<url of web service> <AppPool Creds>
We are able to login to the web service via a browser on a remote computer, enter domain credentials and have the expected response (web page displayed). IIS Log shows domain user creds as expected.
The SQL server is a named instance, running under domain creds. SPNs created:
MSSQLSvc/<fqdn>:<Instance> <SQL Domain Creds>
MSSQLSvc/<sql server netbios>:<Instance> <SQL Domain Creds>
MSSQLSvc/<fqdn>:<port> <SQL Domain Creds>
MSSQLSvc/<sql server netbios>:<port> <SQL Domain Creds>
The IIS App Pool user account in AD is setup for constrained delegation to the SQL server for both the port and the named instance.
When logging in through software to web service (WPF calling WCF Service with no database call), a normal response is seen.
When logging in through software to web service with a database call, sql profiler shows Anonymous Logon. With Kerberos Logging enabled on IIS box, the following error is received:
Error Code: 0xd KDC_ERR_BADOPTION
Extended Error: 0xc0000225 KLIN(0)
Server Name: MSSQLSvc/<sql server fqdn>:49942
Target Name: MSSQLSvc/<sql server fqdn>:49942#<domain.com>
We also tried unconstrained delegation, but received same result.
SETSPN -X shows no duplicates.
Thank you in advance for your help!
When all else fails, and you've literally spent days and days working on the problem and reading every article on the Internet:
REBOOT
Yup. That was the fix. Rebooting the IIS server which was the server delegating the permissions, fixed the issue.
For those looking to quickly and easily setup constrained delegation between IIS and an instance of SQL, both running under custom domain creds, set your settings exactly as above and reboot.
Best wishes.
I am following http://msdn.microsoft.com/en-us/library/ff647294.aspx to add authentication to a WCF. My SQL Server is on a different machine than the development server. In Step 1, I am not using SQLExpress but using SQL Server 2012. When I get to the Step 8: Create a User in the User Store, under Security Tab of ASP.net Web Site Administration Tool I see the following message:
There is a problem with your selected data store. This can be caused by an invalid server name or credentials, or by insufficient permission. It can also be caused by the role manager feature not being enabled. Click the button below to be redirected to a page where you can choose a new data store.
The following message may help in diagnosing the problem: Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
So looks like setting Windows Authentication is the problem. I am not sure what in the multi-step process I have to modify to add authentication to my WCF. Any help will be appreciated.
The example in Your link Access to SQL server is given to a local user NetworkService. This is the default Identity for the Application pool.
In Your case you cannot use a local user account, since the SQL Server is on a different machine.
You need to:
Create a domain account
Grant Access to SQL server to that domain account
Change the Identity for Your Application pool to that of the domain accout
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.
I have been attempting to configure SQL Server 2008 R2 (Standard) for replication between two instances running on Windows 2008 R2. Both machines are on an internal AD domain (2008R2 domain). The issue I am having is specifically with the subscription process being unable to push transactions (yes, doing transactional replication) from the distributor to the subscriber. It is using a domain user (sqlrepl_distrib) which is in the domain users group by default to do this.
The error from the logs is:
Login failed for user 'XXXX\sqlrepl_distrib'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors. [CLIENT: ]
I have tried numerous things to get it work, but the only way I could get the subscription to work was to use my domain admin login (which is obviously unacceptable as a permanent solution).
The sqlrepl_distrib user has permissions as db_owner on both the publisher and subscriber database, as well as the distribution database, so that shouldn't be related to the issue. SQL Server is configured for Windows authentication only. I verified the user/pass also works by logging into the domain with it. DBs and MSSQL instances are owned by the domain administrator, I think this may possibly be the problem, but not sure.
I have also tried to disable UAC on both SQL Server machines, but this did not help (yes I rebooted).
Hoping someone would have a clue as to what's going on. I am fairly new to SQL Server, so I expect it could be something dumb, but Google has failed me to find a solution (the error that comes up in google seems to be with users being unable to access SSMS, which isn't my problem... that works fine).
To setup the replication, I followed the guide from Microsoft at http://msdn.microsoft.com/en-us/library/aa337389.aspx. It does not mention this particular error. I tried 3 times to setup the process all over again with the same results.
Anything pointing me in the right direction would be helpful (but please don't point me to a 1000 page long MSDN article and expect me to parse through that).
Thanks!
What's the user running the service?
Do check if the spn of the named instance is registered, and also the spn for sql server browser service, as a named instance will force the kerberos authentication to be delegated from the browser service.
And make sure that the browser service is enabled to delegate to the sql spn on windows ad.
First check in SOL server configure manager LOG ON with what users---> for
example user log on as :-NT AUTHORITY\NETWORK SERVICE
check all publisher and distributor and subscriber 'logins' (for this goto your instance--> security-->logins . you must check 'NT AUTHORITY\NETWORK SERVICE' this login is there or not. if dose't have login create New login with the name 'NT AUTHORITY\NETWORK SERVICE' all publisher and distributor and subscriber.
you can right click the above login--> take properties-->usermapping--> change options-->here select that database and give permitions DB_woner and PUBLIC to database
like thaat you can change all publisher and distributor and subscriber.
ofter that re-run your replication
Note:
here I'm LOGON with NT AUTHORITY\NETWORK SERVICE
and
my DATABASE is: Sudheer
Check your own what are LOGON with '????' and Database is '???' in your system!!
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