August 11, 2010 at 6:27 pm
I have upgraded our Reporting Services to SSRS 2008 on a Windows Server 2008 computer. The reports all have shared data sources that pull data from remote servers. Currently our production DBs are in SQL 2005. The upgrade plan has the development environment upgraded first and once all the kinks are worked out, the production environment will change. The upgrade is moving the databases from SQL Server 2005 on Windows Server 2003 to SQL Server 2008 on Windows Server 2008. (Enterprise editions all around.)
I am able to use windows authentication for the reports where the data is in SQL Server 2005 databases in both the default and named instances by having all of the proper SPNs registered.
In the new development edition, I can use windows authentication for reports that pull data from the default instance, but when I run a report against a database in a named instance an error is thrown. In the Report Manager browser window, I see the 'Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.' error message. When I check the application event log on the server where the named instance resides I see "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors. "
My research on “Token-based server access validation failed with an infrastructure error” all points to UAC issues and suggests either running SSMS as administrator or turning off UAC. Neither solution is appealing and actually neither solution works. I had our network administrator turn off the UAC on this computer and still got the error messages. The Reporting Services call isn’t using SSMS, so that solution is irrelevant. I can log into the named instance via SSMS both from my local workstation and via an RDC to the server. So I’m pretty convinced that it’s not a UAC issue. We’ve examined the SPNs and except for the actual letters used, they are the same as the SPNs that connect RS to our SQL 2005 data sources. And reports against the default instance work with Windows authentication. The reports against the named instance to render when stored credentials are used. But good grief! If I can use windows authentication with one instance, why can’t I use it with the other?
August 29, 2010 at 3:44 pm
Hmm, not had this issue and sounds very frustrating. This sounds like SPN/Kerberos related and I would keep looking at this area.
The fact it works on default and not named is odd, are the configs of each the same? Other than this then I would definitely say SPN/Kerberos as stored creds work a treat.
Steve.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply