This is a live blogging post from the International SharePoint Conference London 2012. So don’t expect well-written proza here.
- 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
- 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!
- 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