Implementing Kerberos and using claims based Web Applications Part 1

2 minutes read

This is a live blogging post from the International SharePoint Conference London 2012. So don’t expect well-written proza here.

Session by Spencer Harbar & Todd Carter

Introduction

  • Around the Kerberos topic there is a proliferation of misinformation
  • Kerberos is not dead in the claims world!
  • Windows claims is still windows authn, so possibly kerberos is involved
  • claims makes cross org/product boundary authn simpler
  • but be aware of the many functional constraints when using claims (powerpivot, ppoint, upa)
  • saml claims is even worse on the functional constraints
  • many external systems don’t support it, eg sql server
  • next wave of MS products will probably also support claims

Why kerberos

  • security: inter server comm, end user authn, security policies
  • performance: reduce impact on infra, multi domain scenarios
  • functionality: delegation

NTLM vs Kerberos

  • NTLM doesn’t scale, doesn’t perform and sends a shared secret over the wire
  • With Kerberos your IIS server does not have to talk to the domain controller! So less stress on your domain infra.
  • Performance increase for your farm is possible, but not guaranteed,  mainly due to reduced authn roundtrips & impact on dc’s
  • Benefits mainly increase with user/resource domain scenario’s
  • Many myths around this: “Kerberos makes SharePoint faster”, “one DC for every four WFE’s”
  • Assess the impact on your domain infrastructure before deployment (perfmon)
  • For standard sessions (5 min, MS Usage Profile) NTLM can be faster than Kerberos (requests/sec, page response times)
  • Longer sessions (20 mins e.g.) will benefit from Kerberos
  • IIS7 with Kerberos requires client to reauthenticate for every request
  • Configure IIS to persist non NTLM connections (authPersistNonNTLM)
  • KB 954873 is correct, SP docs are wrong!

Configuration

  • Where: SQL communications (not necessary but useful), web apps, service apps (for delegation scenario’s)
  • DNS: CNAMES are bad, always use A records with Kerberos
  • Implement service accounts for application pool identities
  • Kerberos authn is not the same as delegation, make sure authn works before doing delegation
  • Kerberos autn is only creating the right SPN’s and configuring the webapp for Kerberos. That’s it.

Creating service principal names

  • SPN notation is critical PROTOCOL/HOST:PORT
  • Windows treats SPN’s as case insensitive
  • best practice is to create both netbios & fqdn spn
  • port is not required with default HTTP ports