Kerberos On 2010

Question

I stumbled on this article http://technet.microsoft.com/en-us/library/gg502606.aspx and checked our sites using the Kerberos Authentication Tester (http://blog.michelbarneveld.nl/michel/archive/2009/12/05/kerberos-authentication-tester.aspx) and discovered that we are not using Kerberos although we thought we were.....it comes back as NTLM.

From the article I am thinking we may fall into this bug and need to do the first work around....

We are running 2 W2K8 (non-R2) WFE's

We have 10 web applications.

They all run under the same domain account.

They all point to the same host on non-standard port

sharepoint-site:1234

sharepoint-site:1789

sharepoint-site:7839

etc....

All of the dns entries point to the same load balanced address of the WFE's (2 servers)

app-a.website = 111.12.123.12

app-b.website = 111.12.123.12

app-c.website  = 111.12.123.12

In IIS 7 for each site we map incoming requests on port 80 to the appropriate app pool.

IIS Binding on App Pool A =  Type: http  host name: app-a.website  port: 80  IP: *

IIS Binding on App Pool B =  Type: http  host name: app-b.website  port: 80  IP: *

IIS Binding on App Pool C =  Type: http  host name: app-c.website  port: 80  IP: *

I am looking for how we can get kerberos to work in our environment.

Answer 1

A Question... Are you considering Kerb just because or is there a business need?   If you really don't need it I'd recommend sticking with NTLM because of the issues Kerb can bring into play.

More Info:
http://www.microsoft.com/downloads/en/confirmation.aspx?FamilyID=1a794fb5-77d0-475c-8738-ea04d3de1147&displaylang=en

Other Links

http://blogs.technet.com/b/askds/archive/2008/05/29/kerberos-authentication-problems-service-principal-name-spn-issues-part-1.aspx

http://blogs.technet.com/b/askds/archive/2008/06/09/kerberos-authentication-problems-service-principal-name-spn-issues-part-2.aspx

---

Kris Wagner, MVP, MCITP, MCTS Twitter @sharepointkris Blog: http://www.sharepointkris.com/blog

Answer 2

We did it (or thoght we did it since it apparently isn't working) to support search and web service accesses coming through the front-end load balancer (Netscaler) that sits in front of the WFE's.  When we enabled kerberose our search crawl began working.  So we thought we were done and everything was fine.

I just stumbled across today that the user authentication is falling back to NTLM and is not using Kerberos and wanted to see if we can pursue getting it working within our environment the way it should work.

Answer 3

I've heard of needing an additional config for the Netscaler... Is that a possible route?

Check out this thread ie Kerb and Netscaler.

---

Kris Wagner, MVP, MCITP, MCTS Twitter @sharepointkris Blog: http://www.sharepointkris.com/blog

Answer 4

Thanks Kris.... was there to be a link to the thread you mention?  Not seeing it.

Answer 5

We did resolve this....  when setting up the SPN's the non-ported address was not inlcuded in the definitions.  we had the ported address and the fqn but not the unported address.  Adding the non-ported address to the SPN definition resolved the issue.

Example. 

We had:

sharepoint-site:1234
full-name.sharepoint-site.com:1234

We missed:

sharepoint-site
full-name.sharepoint-site.com