Risks involved in setting up Kerberos authentication for WSS Reporting Services
We have an established Intranet based on WSS with two front ends and a database.
Currently all authentication is NTLM.
We have installed Reporting Services In Integration Mode.
RS works as long as the web front end that has RS installed on it handles the transactions.
If the front end without RS handles the request then we get an UNAUTHORIZED error.
In attempting to fix this problem, web searches etc. - have alluded to the problem being caused by the farm needing to perfrom 'double-hop' authentication - which cannot happen via NTLM.
So we need to configure the Intranet farm to accept Kerberos authentication.
I've found this helpful guide But it takes the stance that we are starting the farm from scratch.
So we need to know whether there are any risks involved in retroactively configuring Kerberos? Will NTLM carry on as before while and after we have carried out the steps to enable Kerberos?
Solution 1:
There is some risk to enabling Kerberos delegation in order to permit double-hops. Basically, you're allowing IIS to impersonate the user without the user actually entering any credentials again. In a Windows 2000 Active Directory environment, there is only what is known as unconstrained delegation. Basically, you can't restrict what's doing the delegation and to where it can delegate very well (as well as you would like). In those cases, Microsoft strongly recommends not using Kerberos delegation. If you're on Windows 2003 or 2008 Active Directory, you can and should use constrained delegation. This allows you get to rather specific with the delegation. In this case there is an increased risk, but usually the fact that you don't have users re-typing credentials or your using service accounts or SQL Server logins is worth the increased risk.
As far as whether or not NTLM will continue on, it depends. If Kerberos authentication can be established, it will be used. This includes in cases where it's returning an error (and you don't think it should be), such as if the SPNs are wrong, etc. It will only drop back to NTLM if Kerberos authentication cannot be used. With that said, Kerberos is the newer security protocol and has security features that NTLM does not including timestamp (preventing relay attacks), the ability for the client to verify the server's identity (which NTLM can't do), and the use of tickets which should reduce overall traffic for authentication to the DCs.
Solution 2:
We typically do retroactive SharePoint NTLM to Kerberos authentication changes as you're proposing. When we establish our SharePoint sites, it takes a couple of days for DNS changes to propagate, and getting our SPNs set on service accounts typically takes some time also.
So after our SPN's are set, we first create a small test site on the server running under the SP app pool. We turn on WIA and and put a single test page in it:
<%@ Page Language="C#" %>
<script runat="server" language="C#">
void Page_Load(object Sender,EventArgs E)
{
if (User.Identity.IsAuthenticated) {
lblIdentity.Text = User.Identity.Name;
} else {
lblIdentity.Text = "Anonymous";
}
lblImpersonation.Text =
System.Security.Principal.WindowsIdentity.GetCurrent().Name;
}
</script>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<TITLE>Test Application</TITLE>
</HEAD>
<BODY>
<FORM id="frmForm1" method="post" runat="server">
<HR width="100%" size="1">
<P>
<ASP:LABEL id="Label1" runat="server">Current Identity:
</ASP:LABEL>
<ASP:LABEL id="lblIdentity" runat="server">Label</ASP:LABEL>
</P>
<P>
<ASP:LABEL id="LABEL3" runat="server">Impersonated Identity:
</ASP:LABEL>
<ASP:LABEL id="lblImpersonation" runat="server">Label</ASP:LABEL></P>
<HR width="100%" size="1">
</FORM>
</BODY>
</HTML>
Browse to the page with Fiddler active, and determine if Kerberos works (Fiddler's authentication tab will tell you if you are using NTLM or Kerberos).
Once you know Kerberos works for your service account/server/URL, go ahead and make the change in SharePoint.