1

I am having a problem with Kerberos working on SharePoint. Also note that I am a developer not a network guy so if I use the wrong terms I apologize but I hope my intent is clear.

We have two web front ends aliased to a single name say "SPPortal" and the web front ends themselves are "WFE1" and "WFE2". In my development I need to be able to perform double hops across servers.

The following is the result of how I address the server:

http:/ /spportal - fail (NTLM)

http:/ /wfe1 - success

http:/ /wfe2 - success

http:/ /sportal.fully.qualified.com - fail (NTLM)

http:/ /wfe1.fully.qualified.com - success

http:/ /wfe2.fully.qualified.com - success

(http:// in front of all the above, since I'm a new user I can only post the protocol once in a post)

Anyone have any ideas on why the alias will not work? This is SP 2007 running on Win2k3. Not a domain server, AD is on a separate machine and afaik all patches are up to date with cumulative updates.

Edit: Here is what we are seeing in Fiddler for the Auth

On the web front ends (http:/WFE1,http:/WFE2) themselves, this is the behavior we are expecting for all requests: 

401 

No Proxy-Authenticate Header is present.

WWW-Authenticate Header is present: Negotiate

WWW-Authenticate Header is present: NTLM

Then 

302

No Proxy-Authenticate Header is present.

WWW-Authenticate Header (Negotiate) appears to be a Kerberos reply:
A1 81 A0 30 81 etc...

When connecting to the alias (http:/spportal), this is not the behavior we expect or want:

401

No Proxy-Authenticate Header is present.

WWW-Authenticate Header is present: Negotiate

WWW-Authenticate Header is present: NTLM

Then

401

No Proxy-Authenticate Header is present.

WWW-Authenticate Header is present: Negotiate
4E 54 4C 4D 53 53 50 00 02 00 00 00 0C 00 0C 00  NTLMSSP.........
38 00 0 etc..

-[NTLM Type2: Challenge]------------------------------
Provider: NTLMSSP
Type: 2
OS Version: 5.2:3790
Flags:  0xa2898205
    Unicode supported in security buffer.
    Request server's authentication realm included in Type2 reply.
    NTLM authentication.
    Negotiate Always Sign.
    Negotiate NTLM2 Key.
    Target Information block provided for use in calculation of the NTLMv2 response.
    Supports 56-bit encryption.
    Supports 128-bit encryption.
Challenge: DE 02 etc...

Then

302

No Proxy-Authenticate Header is present.

No WWW-Authenticate Header is present.
Junx
  • 111
  • 4
  • How do you know it is a Kerberos error? Post some error message that point you in this direction. Describe what you are trying to do, what you expect, and what actually happens. – dunxd Sep 27 '10 at 10:26
  • In fiddler I can see that we get a Kerberos reply when not using the alias. The response that I get when using the alias is NTLM. I will add more details to the question. – Junx Sep 27 '10 at 12:02
  • Could you clarify what you mean by "alias", because using DNS aliasses is not going to work with Kerberos. Also, did you configure alternate access mappings in SharePoint? Host headers in IIS? Created service principal names (SPN's)? – Thomas Vochten Oct 04 '10 at 11:12

0 Answers0