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.
Related
I wanted to read AWS Postgresql from within SQL Server, so
I created a system ODBC connection to Postgresql on the SQL Server machine, tested it, fine.
I then created a Linked Server to connect to postgresql.
In the Security tab (For a login not defined in the list above, connections will), I selected "Be made using the login's current security context".
When using this linked server while connected to SQL Server through windows authentication, it works fine.
If I connect to SQL Server using a SQL Server authenticated account, trying to access postgresql data through that same Linked Server fails authentication.
I fixed that by switching my security setting to "Be made using this security context" and giving the POSTGRESQL login/password (same that I gave at the ODBC level).
Question:
Without repeating the postgresql details at the Linked Server stage, why is it working with Window sauthentication account and not for SQL Server authenticated accounts?
Neither are relevant to Postgresql?...
I made it work but still confused...
I will have to guess a bit to help you, but I hope to give you enough context to understand what is happening so you can debug further.
When you connect to SQL Server using integrated authentication, the domain controller gives out a token to talk to SQL and this is used to authenticate your connection from your client to SQL Server's process. Underneath the covers, Windows can use either NTLM or Kerberos to do this handshake. You can read more about this here in this blog post:
NTLM vs. Kerberos Blog. This protocol choice matters when trying to use linked servers since it has to then authenticate to something else over the network.
At this point, it matters what credentials are used to run SQL Server (usually as a service in the services window to see). If you are running SQL as Local System or Network Service or something else defined by windows (instead of as a specific user on the network), it may or may not have permissions to talk out to your target remote server (whether it be postgres or something else). When you use Kerberos and enable delegation (which the domain admin needs to do), you can have the original integrated auth credentials "flow" over the linked server link to the next connection. NTLM does not do this. Therefore, the usual scenario is to create a map in the local SQL Server of what credentials to use when talking out to a remote linked server.
If you are talking to an ODBC driver, then you are likely using the msdasql (OLEDB to ODBC bridge) provider and then also having to go through its authentication stack. It has been too long for my memory as to whether it even supports integrated auth at all, much less delegation in Kerberos. However, you may be able to debug this problem further if you:
consider which account is running SQL
consider which mechanism is used to do integrated auth to sql and whether that would work with delegation
determine which credentials are used to make the outbound connection to your ODBC target. You should be able to debug much of this through the profiler mechanism as there is a distributed query/linked server set of events IIRC.
I can't speak to your postgres provider specifically, but this should give you some more tools to debug. Hope that helps you get one step further.
I have a situation where clients connecting to my webservice(that exists on another server) must access SQL Server databases and SSAS servers.
It must use the credentials of the client that is calling the service when accessing the SQL Servers and SSAS cubes.
For this to work I do
var winId = HttpContext.Current.User.Identity as WindowsIdentity;
var ctx = winId.Impersonate();
//Access Database/SSAS
ctx.Undo();
in my service which works fine when accessing SQL Server databases.
However when I access the SSAS servers I get
"The connection either timed out or was lost"
There are a number of posts like
http://denglishbi.wordpress.com/2009/03/31/windows-server-2008-kerberos-bug-%E2%80%93-transport-connection-issues-with-ssas-data/
http://sqlblogcasts.com/blogs/drjohn/archive/2009/03/28/kerberos-kills-large-mdx-queries-on-windows-server-2008-ssas.aspx
on this but I am using Windows Server 2008 R2
where my service lives so this should not be a problem as this bug should have been fixed by Microsoft.
Any information as to how to best diagnose this problem would be appreciated.
To clarify the SSAS servers do have SPNs. This was actually working at one point but has now stopped. Appears no sign of duplicate SPNs or anything.
What is interesting is it works intermittently on one SSAS server but seems to work all the time for the other.
They both have named SPNs as mentioned by this document
https://support.pyramidanalytics.com/entries/22056243-Configuring-Kerberos-Delegation-for-Named-Instances-of-SSAS-with-Active-Directory-and-additional-pro
My production environment is a load-balanced (and under heavy load) on a very large corporate Active Directory network. The following took a lot of testing to finally nail down settings that work.
I also run on Windows 2008 Server R2
My web services are in ASP.NET in IIS. For authentication I enabled "Windows Auth" and "ASP.NET Impersonation". Kernel mode is disabled and provider is "Negotiate:Kerboros"
SPNS and Trusted Delegation are setup for an AD account. My AD account looks like sys_myservice (sys_ is just a naming convention at my company)
The Application Pool identity is set to use the sys_myservice
After you make all these changes in your dev env, restart the entire server. For some odd reason this is always necessary when we bring on new servers and configure them.
With this setup my web services access SSAS, SQL Server, and more that use Windows Kerboros auth and all queries are performed correctly under the user's credentials.
The difference in my setup from yours is ASP.NET Impersonation is enabled at the IIS level. I had trouble doing the impersonation in code which is what you are trying to do. If you get code-level impersonation to work with your workflow I would be really interested in seeing you post an update.
Forgot to mention. My services are in a MVC application, I apply a global filter to all Action methods to force the application to authenticate all connections.
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
filters.Add(new System.Web.Mvc.AuthorizeAttribute());
}
and in my web.config system.web section
<authentication mode="Windows" />
<identity impersonate="true" />
I agree that the intermittently 'successful' SSAS instance is suspicious. I wonder if it's really using Kerberos all the time. Could be using a combination of negotiate/NTLM and Kerberos, with one auth method actually working and the other approaching failing. Might be worth another look at the SPN. This link might help: http://msdn.microsoft.com/en-us/library/dn194200.aspx
Did you try using Wireshark or any other Network Analysis tools to see anything red happening at that point of failure? Probably its better if you provide more troubleshooting observations from your end.
Also, does your web services has a Load balancer?
Regards,
Sasi.
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'm trying to configure Team Foundation Reporting but without any success.
The App Tier and the Data Tier are in separate servers.
I guess it's not a port/firewall problem, because I opened port 135, and I can see the established connection by using TCPView (from Sysinternals) whenever I click "Populate URLs" in the Reports tab in TFS Administration Console. I can also telnet servername 135 without any problems.
I also checked if WMI service is started in the Data-Tier. And for SQL Server Reporting Services. Also checked for RPC and RPC Locator in both servers. They're all started and automatic.
I also set tfs app user as admin in sql reporting services. Added all kinds of permissions to the tfs user in the Data-Tier server.
I set all user permissions in dcomcnfg.
Allowed all WMI namespaces permissions to the user. (Computer Management -> WMI Control)
Deactivated Windows Firewall in both servers temporarily.
No luck.
However, in the app-tier, when I click Computer Management -> Connect to another computer, and type the data-tier IP, i can't connect. I get the message "Computer xxx cannot be managed. The network path was not found". How is that ? Tried IP, name, and FQDN. I also tried browsing and selecting the computer. Nothing changed.
I'm lost, what could possibly be happening ?
Thanks in Advance!
i'm betting that you're having the double-hop issue. try having your system admin set an spn for the website on the sql server.
you also need the AD permission 'trust for delegation' on the AD Service Account, right?
do that and SetSpn with the service account, that should help I think that the SPN option was spot on
See this answer:
IIS to SQL Server kerberos auth issues
which links to an old but user-friendly troubleshooting web app called DelegConfig. It can try to run the SetSpn commands for you, at least giving you an idea of what they need to be.
I ran into SPN issues when using an externally-accessible URL (+SSL) everywhere.
I have couple of reports that I developed and are sitting on http//localhost/reports.
I have everything else set up, including Sql Server 2005 Config Tools. The reports run fine when I run them on my own machine, where IIS and Sql Server 2005 are both loaded. But they don't work when I try from other computers. I have the dir security to windows integrated security checked.
The error i get is -
An error has occurred during report processing. Cannot create a
connection to data source 'time_clock'. Login failed for user 'NT
AUTHORITY\ANONYMOUS LOGON'.
How do I make them available for remote users?
Is the reportserver and SQL server on the same box? If SSRS is on a different box and MSSQL is on your box, then you have to configure Kerberos for double hop authentication.
Check this link for help on configuring double hop authentcation.
Raj
SSRS machine authenticates the remote user, it impersonates him and it then tries to authenticate to the SQL machine. The SQL machine needs a proof that SSRS is who it claims it is (the remote user), but SSRS does not have the said proof (namely the password of the remote user), therefore authentication falls back to the anonymous logon.
To enable this scenario you need to enable and configure constrained delegation on the account running the SSRS. If constrained delegation is enabled and properly configured then the domain controller will vouch for the SSRS machine impersonated identity of the remote user and the SQL machine will authenticate it successfully.
In addition to turning Windows Authentication on, you need to turn Anonymous authentication off.