3

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?

Improve this question

3 Answers 3

Reset to default
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.

Improve this answer
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>&nbsp;
        <ASP:LABEL id="lblIdentity" runat="server">Label</ASP:LABEL>
      </P>
      <P>
        <ASP:LABEL id="LABEL3" runat="server">Impersonated Identity:
          </ASP:LABEL>&nbsp;
        <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.

Improve this answer
0

Thanks to both responders - both gave some excellent advice.

I'd like to point out some additional tools that we discovered on the way, whilst configuring our farm for Kerberos:

DelegConfig V2( beta!):

  • By Brian Murphy-Booth We could not have done it with out this Download from his Blog You answer questions about the configuration you want and it provides where and why it will or wont work - even has testing facilities and if running under admin accounts can make the necessary changes for you.

Metabase Explorer

  • Many articles will tell you to use adsutil.vbs to set each site's NTAuthenticationProviders value. We found it much easier to use Metabase Explorer - especially as we had to set the value on virtual directories below the default site. It also reveals many many scary values in the metabase! Use with CAUTION! Part of the IIS 6.0 Resource Kit Tools
Improve this answer
1
  • DelegConfig rocks. I use MBE so much I forget that its not a standard tool.
    – Christopher_G_Lewis
    Jun 17, 2009 at 13:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .