Watch out for two-hop delegation in scaled-out solutions
Last month, I talked about the licensing model for the “Scale Out” Reporting Services model. It is expensive. Well, this month I am building a proof-of-concept for a customer. Luckily, we can use the Developer edition until we go into production. I feel much more comfortable dealing with technical issues versus licensing issues. Let’s take a look… I built a web farm using two web servers running ASP.NET and IIS. On the back-end I installed two database servers running SQL Server. The idea was to use NLB on the front-end for load balancing and Database Mirroring on the back-end for data protection and failover. I thought I would be security conscious and install only using a domain user account that had local admin rights instead of the Domain Admin. This had some consequences as we will see later. I installed SQL Server according to the Books Online article “Configuring Reporting Services for Scale-Out Deployment” http://msdn.microsoft.com/en-us/library/ms156453.aspx I installed a files-only install of SSRS on the web servers then used SSRS Configuration Manager to actually configure the web farm with 2 front-end Reporting servers pointing to the same ReportServer database on the back-end. All set up went well. When I came to test out Report Manager, I hit security issues. The first one was simple. The Developer Edition of SQL Server is not set up for Remote connections by default so I had to enable TCP/IP in the SQL Configuration Manager for the Database Servers. The next issue was more involved. I was getting an error trying to connect to SQL Server through Report Manager. At this point I actually had no reports built at all. I was just testing access to SSRS through this architecture. The error was interesting “NT AUTHORITY/ANONYMOUS LOGON” – failed to connect to Database. I checked that everything was set up using Windows Integrated Security and that the default service accounts were in place and granted appropriate permissions as part of the SSRS install. All looked good. It turns out that I was trying to implement “double-hop” authentication using Kerberos but that Delegation in Active Directory was not set up correctly. So the system gave up on Kerberos and tried NTLM anonymous access. Hence the error. If I had installed everything using the Domain Admin account, the install would have set up delegation correctly for me behind the scenes. The issue was uncovered by an interesting document on the MSDN Forum for Reporting Services: http://social.msdn.microsoft.com/forums/en-US/sqlreportingservices/thread/3266f4ac-51f7-4534-b5f0-eda19a86d9d6/ The actual document that helped me most was buried deep in that post about Microsoft Dynamics CRM “Microsoft CRM 3.0: Additional Setup Tasks Required if Reporting Services Is Installed on Different Server”. This outlined the different scenarios and solutions. Even though I was not using CRM, the document was definitive in its advice. Cut a long story short, I was able to set up the correct SPNs (ServicePrincipalNames) on the service account and Trusted Delegations on the Computers to make the proof of concept work. If only I had installed using the Domain Admin account, I could have bypassed this whole thing. But, as I tell my students, if everything works, you don’t learn as much! Put it down to experience. cheers Brian Licensing for Scale Out Reporting Services solution: http://www.networkworld.com/community/node/43349
