I have a CTP of SSRS 2008 deployed to one of my servers. Today I built a couple of reports and from one of my systems, they all tested fine. However, this system, because it is a testing server, doesn't receive the Group Policy Object (GPO) controlling IE security settings that our standard systems do. Now the IE GPO contains what's necessary to do Windows integrated authentication against our Intranet-based web servers, to include Kerberos delegation. But for whatever reason, the systems which receive the GPO kept prompting users to log in.

One of the issues with troubleshooting is the fact that SSRS 2008 is no longer a web application under IIS. As a result, the places to look for logs, for security settings, and the like are all different. One thing that isn't is that since Windows authentication is involved, the audit failures should still be logged on against the Security event log for the OS. They were. I didn't see any Kerberos pre-authentication errors. The only errors I saw was when the domain/realm picked up the name of the server instead of the name of the Active Directory name. However, there weren't anywhere near the # of audit failures as people were getting prompted. It almost seemed like every time SSRS retrieved a new file (such as an image file) it forced a re-authentication.

Since I needed the reports out for others to use, I rebuilt the reports for SQL Server 2005. This, not surprisingly, meant I had to drop back to Business Intelligence Development Studio (BIDS) for SQL Server 2005. The Data Source was able to publish, but not the reports themselves. The reports were simple queries displayed in tabular form, so it took just minutes to rebuild them, but that wasn't something interesting to see... if BIDS for SQL Server 2008 could publish to a SSRS 2005 server just by switching the Reporting Services target. It wasn't. There may be a way to force it... but I'll wait until next week to look at that in more detail. I'll also troubleshoot what IE settings broke the authentication in SSRS 2008 but which don't break SSRS 2005.