The following is an overview of an article prepared by Mark Dasco and myself. The full article is around 4800 words and is attached to the end of this post. Basically, the article is a quite thorough description of how to implement Kerberos and the benefits Kerberos provides when implementing Microsoft BI solutions.
Table of Contents
1 Overview
2 The Double Hop
3 The NTLM Protocol
4 The Kerberos Protocol
5 Business Intelligence Case
6 Implementation
6.1 Considerations
6.2 Implementation
6.2.1 Getting Started
6.2.2 Configure Clients for Kerberos Authentication
6.2.3 Defining SPNs
6.2.4 Using Negotiation
6.2.5 Enable Impersonation and Delegation
6.3 Checking that it all works
7 Conclusion
Overview
When developing Microsoft Business Intelligence solutions we frequently need to rely on tight security integration between various tools. The NTLM protocol provides enough features for simple implementations, but when we need to provide enterprise-class solutions we invariably feel constrained by it. With Windows 2000 and later versions Microsoft provides an alternative security protocol – Kerberos, which addresses certain limitations of NTLM, provides improved security and better performance. The implementation of Kerberos could be fairly simple or very complex depending on the requirements. Configuring a few default server instances with no constraints on their services secured through Kerberos could be almost trivial, while for some more specific cases it could be a major cause of frustration.
As a base for this study we will examine a specific BI case – a digital dashboard, which involves all layers of the Microsoft BI stack:
- SQL Server 2005
- SQL Server Analysis Services
- SQL Server Reporting Services
- PerformancePoint 2007 Monitoring and Analytics for building a dashboard
- SharePoint Server as a organisational portal hosting the dashboard
Furthermore, each of the servers exists on two environments – Development and UAT. Also, we will show how we can implement Kerberos only between the services utilised by the servers, not affecting the rest of the domain and effectively isolating the implementation.
Typically, solutions not configured for Kerberos authentication and delegation fall back to the default NTLM authentication protocol. Whilst NTLM is completely transparent and very easy to use on a Windows domain, it falls short when we need to pass user credentials across a few server layers. This is commonly known as a double hop issue. If we depend solely on NTLM for user authentication, passing user names to servers on lower levels of our server topology involves including them in our connection strings or passing them programmatically, which is hardly the right choice for an enterprise-grade security framework.
On the other hand solutions which correctly implement Kerberos are advantaged with cross-server delegation and authentication, thus allowing the use of Integrated Windows Authentication throughout the whole solution. The ability to capture user credentials on any server is essential if we want to be able to secure and control access to each server independently and minimise the damage resulting from a potential security breach.
Download Full Article by Mark Dasco and Boyan Penev
Boyan Penev on Microsoft BI 