Kerberos Configuration Manager updated for Reporting Services
Back in may, we released the Kerberos Configuration Manager tool to help with diagnosing and correcting Kerberos related issues for SQL Server. Today, I’m happy to announce that version 2 of this tool has been released and has been updated for Reporting Services. A lot of work went into this tool to get us to this point and the team that worked on it was awesome! You can download it from the following link:
Microsoft® Kerberos Configuration Manager for SQL Server®
https://www.microsoft.com/en-us/download/details.aspx?id=39046
Here is a look at what versions of Reporting Services are supported with this release of the
SQL RS Version Native Mode SharePoint Integrated Mode 2005 No support in v.2 No support in v.2 2008 Supported Supported 2008 R2 Supported Supported 2012 Supported No support in v.2
The tool does not add a shortcut to the Start Menu, so you will need to go to the directory of which it is installed to. By default, this is C:\Program Files\Microsoft\Kerberos Configuration Manager for SQL Server. There are a couple of things here that are pretty neat. First is that you can decide whether to include SQL Server and Reporting Services instances in the list. This comes in handy if you have several of both on the same server and you just care about one or the other. Great for Dev and Test environments!
We will also show you the Mode of the Report Server that we discovered. Native or SharePoint.
Common Problems
Unauthorized
If you see the “Unauthorized” message under status, this just means that you didn’t start the tool with Admin rights. Be sure to launch the tool with Admin rights. The tool will not prompt automatically.
Kerberos not enabled
If you see the “Kerberos not enabled” message under status, this means that the rsreportserver.config doesn’t not have either RSWindowsNegotiate or RSWindowsKerberos in the Authentication Types.
If you do want to use Kerberos with Reporting Services, which I’m assuming you do if you got this far, you will need to modify the rsreportserver.config to get past this.
For more information on this, check out one of my previous blogs on setting up Kerberos with Reporting Services. It covers this.
Logging
If you happen to encounter something that I didn’t highlight above, you may be able to find additional information. Each time you run the tool, we will create a log file. The default location for this is the following: C:\Users\<user>\AppData\Roaming\Microsoft\KerberosConfigMgr.
The details of the log file will be flushed when you close the program. So, if it is blank, just close the tool and the log should populate. You may also find some details in the Event Log under the Source “Kerberos Configuration Manager”. If we encounter an error, it should be logged in the Application Event Log as well as the tool’s log file.
Limitations
There are a few limitations that you will run into. I wanted to walk through those so you are aware.
SharePoint Integrated Mode with RS 2012
Unfortunately this does not cover SharePoint Integrated mode with RS 2012. This is true regardless of whether it is SharePoint 2010 or SharePoint 2012. The reason for this was that it was a completely different approach with regards to discovery. We still want to get this in as it is important, but for now it is not.
Reporting Services 2005
For 2005, we had to make the same call as with SharePoint Integrated with RS 2012. RS 2005 is a different architecture and would have caused us extra work to get the discovery in. As such, we opted to not include RS 2005 with this tool. Unfortunately, I don’t believe this will make it into the tool.
Multiple Domains
Right now, the tool will only work in a single domain scenario. So, if you have the service installed in Domain A, but want to use a Service Account from Domain B, we won’t be able to discover and correct the issue appropriately. As long as the machine the instance is in and the Service Account are in the same domain, you should be good to go. This is true for Reporting Services and the SQL Server discovery.
Delegation
We will discover the Delegation settings for the service account itself, but that is the extent of the Delegation checks that this tool will make for Reporting Services. To determine if delegation is indeed configured correctly, we would need to crack all of the Data Sources. This means not just the shared data sources, but any embedded data source within the RDL files. That part did not make the cut for v2, but it is something we would like to include down the road.
I hope that you find this tool useful! I’ll also point you back to an older blog post I created regarding my Kerberos Checklist to help you understand the different areas to consider when tracking down Kerberos issues. As you can probably gather from this point, there is more that we want to do with this tool, so we aren’t done yet! Stay tuned for future updates!
Adam W. Saxton | Microsoft SQL Server Escalation Services
https://twitter.com/awsaxton