I just had to say  it! Yes, I was frustrated.

Negotiate (through kerberos) on IIS sucks!
I love free speech, especially if something said is simply true (Joe Kaplan agreed with me)! Of course, this is not an excuse to be rude to MS employees :), but they never would improve things, if we don't ask for it right?

Why is Kerberos on IIS such a pain?
I need an Intranet site, running ASPX to utilize integrated security. That's nice. So, I don't have to maintain another user database (bleeh, not again). Secondly, for my AD solutions, I just needed full security based on AD, and (again) not my own security mechanism.
I hear you say: "What this fuzz about? It just works? Yes, it just works -as long as the credential on the current browser-IIS session- does not need to go any further than a page. For SQL Server, most developers, still would use standard security (and not pass-through authentication, which needs kerberos).
But for Exchange-, ADSI-, or Active Directory enabled pages, pages that -really do something- with Active Directory, IIS and Kerberos really need a professor (Joe Kaplan, but his fee is too high for me :) ) in Windows-kerberos-science.

Well, euh, it's easy, just 3 things to check!

there is

  1. AD (Active Directory) support (does AD trust IIS+host for delegation?)
  2. IIS - support (does IIS support Negotiate?)
  3. Browser support (do IE support Negotiate and integrated logon?)

And between the lines, you need to make sure (such as using setspn.exe) that it all is going to work. To get this done and configured, you'd better not be a third party intranet supplier!

Microsoft, please, fix this. I mean, make it more easy for us.

Let me just enumerate some knowledgebase articles that give some checklists. (See knowledge base articles below, note there are much more articles about this subject!)

For a script, yummy for you, you might not have found this script before, because I'm just good :). What it does, is checking (enabling) the IIS server delegation. Note, using it is for your own risk!
(ps: My setup scripts are preferable VBS because that just works without any version messup).

What it does is actually shown in the picture. It checks the middle option.
Delegation for IIS needed for Negotiate work.

update at 14 sep 2006: Some companies, have disabled netbios features and computer browsing. So they solely have DNS and AD, but this makes IIS fail to use negotiate as well. It just seems that IIS has a lot of legacy network component dependencies.

' this checks this IIS server, to be trusted

' otherwise, Negotiate (Wdigest) through kerberos will -not- work!

' if you don't like all protocols to be trusted, you should manually correct this property

'  for this IIS server.

Sub SetThisIISServerTrusted()

    Dim nt, ds, ldapHost, info, accInfo, dnMe


        ADS_NAME_TYPE_1779 = 1, ADS_UF_TRUSTED_FOR_DELEGATION = &H80000   


    Set nt = CreateObject("NameTranslate")

    Set info = CreateObject("WinNTSystemInfo")

    Set ds = GetObject("LDAP://rootDSE")

    ' the AD server that is serving us must be authorative enough

    ldapHost = ds.Get("dnsHostName")



   ' computer name is by definition the netbiosname plus a $

   nt.Set ADS_NAME_TYPE_NT4, info.DomainName + "\" + info.ComputerName + "$"


   dnMe = nt.Get(ADS_NAME_TYPE_1779)

   Set ds = GetObject("LDAP://" + dnMe)

   accInfo = ds.Get("userAccountControl")


   ds.Put "userAccountControl", accInfo

   On Error Resume Next


   If Err.Number > 0 Then

       WScript.Echo " Error at SetThisIISServerTrusted:" + Err.Description + ":" + Err.Source + ":" + Hex(Err.Number)

   End If

   On Error Goto 0

   Set ds = Nothing

End Sub


PRB: "Access Denied" Error Message When Using ServerXMLHTTP to Access an Authenticated Site

Enable negotiate on IE6

Troubleshoot IIS negiotiate 326985

Enable negotiate on IIS

Enable negotiate using XMLHttp