Kerberos failing from ISAPI Extension in Active Directory domain

[Jason Viers]

I'm having some problems with Kerberos authentication from an ISAPI
Extension in an Active Directory domain.

Background:
-----------------------------------
I have two machines, A and B in a test domain. A is the domain
controller, both are Win2003.

Active Directory is all set up, I have a Virtual Directory on IIS on A
that has anonymous disabled and allows "Integrated Windows
Authentication", and I can fetch it from B with IE and Kerberos
authentication operates successfully, as viewed by a packet sniffer.
All is well.


ISAPI & WinHttp:
--------------------------
I've written an ISAPI Extension that uses WinHttp to fetch a remote URL,
and it's set to use "Negotiate" authentication in hopes that it will
propagate the Kerberos authentication. I've created a SPN for HTTP/B,
and I've set "trust this computer for delegation" on B.

If I perform a web request from A to the IIS Extension on B (which will
then attempt to fetch the VDir on A), I can see the browser performing
Kerberos authentication to B's ISAPI Extension, and then B performing
NTLM authentication to A's VDir, which fails. All the information in
the NTLM request seem to be ok (user/domain/etc).

I'm not sure why B isn't trying to use Kerberos authentication when the
request is coming from A. Is there some additional permission necessary
beyond "Trust this machine for delegation"?

Jason

P.S. I noticed if I perform the request on *B* to B's extension, then
the WinHttp request to A performs kerberos authentication, but the
server returns my favorite cryptic kerberos error, "Message Stream
Modified". Still no idea on how to resolve it though.

[Wade A. Hilmo [MS]]

Hi Jason,

There are 3 completely independent technologies in play here: ISAPI,
WinHttp, and Kerberos. And of the 3, ISAPI is pretty much inconsequential.
In your scenario, WinHttp and Kerberos need to be properly set up for this
to work.

The place to start on this would be to make sure that Kerberos is properly
set up on both machines A and B. Unfortunately, I don't know of a forum I
can send you to where you are likely to get an answer. And I don't have
anything set up in my office to set it up for myself (which I would need to
do to walk you through it.)

If you can send me a piece of mail, I can do some checking to see if I can
find a concise answer. Please mention in the subject that this is in
response to this Usenet thread.

Note that this is a spare time effort for me, and it's largely unrelated to
my product (IIS). I can't guarantee that I can get a response that solves
the problem, but I want to run it by some folks.

Thank you,
-Wade A. Hilmo,
-Microsoft

Post by Jason Viers
I'm having some problems with Kerberos authentication from an ISAPI
Extension in an Active Directory domain.
-----------------------------------
I have two machines, A and B in a test domain. A is the domain
controller, both are Win2003.
Active Directory is all set up, I have a Virtual Directory on IIS on A
that has anonymous disabled and allows "Integrated Windows
Authentication", and I can fetch it from B with IE and Kerberos
authentication operates successfully, as viewed by a packet sniffer.
All is well.
--------------------------
I've written an ISAPI Extension that uses WinHttp to fetch a remote URL,
and it's set to use "Negotiate" authentication in hopes that it will
propagate the Kerberos authentication. I've created a SPN for HTTP/B,
and I've set "trust this computer for delegation" on B.
If I perform a web request from A to the IIS Extension on B (which will
then attempt to fetch the VDir on A), I can see the browser performing
Kerberos authentication to B's ISAPI Extension, and then B performing
NTLM authentication to A's VDir, which fails. All the information in
the NTLM request seem to be ok (user/domain/etc).
I'm not sure why B isn't trying to use Kerberos authentication when the
request is coming from A. Is there some additional permission necessary
beyond "Trust this machine for delegation"?
Jason
P.S. I noticed if I perform the request on *B* to B's extension, then
the WinHttp request to A performs kerberos authentication, but the
server returns my favorite cryptic kerberos error, "Message Stream
Modified". Still no idea on how to resolve it though.

[Jason Viers]

Couple of updates on the problem:

The "Using NTLM instead of kerberos" error seems to have gone away;
there was a duplicate, incorrect spn for HTTP/machineB registered to
HTTP/machineC in addition to HTTP/machineB for machineB. Removed that
and restarted, and now MachineB's WinHttp request is always attempting
to do kerberos with the domain controller machineA.

The problem is that it's still getting the "message stream modified"
kerberos error over the wire. I enabled kerberos logging on the server
& client. There are *NO* errors on the virtualDir server, and the
winhttp machine has "log #1" mentioned below.

The server DOES show valid logon records for the request, but I believe
this is because machineB requests the kerberos ticket before sending the
kerberos'd HTTP request. The logs for that are included as log #2, #3,
and #4.

Any ideas what could cause this?

Thanks
Jason

Log #1, appears on winhttp machine:
------------------------------------
Event Type: Error
Event Source: Kerberos
Event Category: None
Event ID: 3
Date: 8/7/2007
Time: 5:20:02 PM
User: N/A
Computer: machineB
Description:
A Kerberos Error Message was received:
on logon session
Client Time:
Server Time: 21:20:2.0000 8/7/2007 Z
Error Code: 0xd KDC_ERR_BADOPTION
Extended Error: 0xc00000bb KLIN(0)
Client Realm:
Client Name:
Server Realm: mydomain.com
Server Name: host/machineB.mydomain.com
Target Name: host/***@mydomain.com
Error Text:
File: 9
Line: ae0
Error Data is in record data.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 30 15 a1 03 02 01 03 a2 0.¡....¢
0008: 0e 04 0c bb 00 00 c0 00 ...»..À.
0010: 00 00 00 03 00 00 00 .......


Log #2,3,4: successful login audits on the DC
---------------------------------------------
Event Type: Success Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 552
Date: 8/7/2007
Time: 5:35:50 PM
User: mydomain\Administrator
Computer: machineB
Description:
Logon attempt using explicit credentials:
Logged on user:
User Name: Administrator
Domain: mydomain
Logon ID: (0x0,0x1E40A)
Logon GUID: {427e0b8b-fa47-9f1d-2bd9-af1c9f479966}
User whose credentials were used:
Target User Name: administrator
Target Domain: mydomain.com
Target Logon GUID: {056c9832-62f6-ed36-fbe7-9e69f8709ae4}

Target Server Name: machineA
Target Server Info: HTTP/machineA
Caller Process ID: 444
Source Network Address: -
Source Port: -


For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.


Event Type: Success Audit
Event Source: Security
Event Category: Account Logon
Event ID: 673
Date: 8/7/2007
Time: 5:35:50 PM
User: NT AUTHORITY\SYSTEM
Computer: machineB
Description:
Service Ticket Request:
User Name: ***@mydomain.com
User Domain: mydomain.com
Service Name: machineA$
Service ID: mydomain\machineA$
Ticket Options: 0x40810000
Ticket Encryption Type: 0x17
Client Address: 127.0.0.1
Failure Code: -
Logon GUID: {72631daf-2eb3-a410-137a-f2966b4bbbcc}
Transited Services: -


For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.


Event Type: Success Audit
Event Source: Security
Event Category: Account Logon
Event ID: 672
Date: 8/7/2007
Time: 5:35:50 PM
User: NT AUTHORITY\SYSTEM
Computer: machineB
Description:
Authentication Ticket Request:
User Name: Administrator
Supplied Realm Name: mydomain
User ID: mydomain\Administrator
Service Name: krbtgt
Service ID: mydomain\krbtgt
Ticket Options: 0x40810010
Result Code: -
Ticket Encryption Type: 0x17
Pre-Authentication Type: 2
Client Address: 127.0.0.1
Certificate Issuer Name:
Certificate Serial Number:
Certificate Thumbprint:


For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

Post by Wade A. Hilmo [MS]
Hi Jason,
There are 3 completely independent technologies in play here: ISAPI,
WinHttp, and Kerberos. And of the 3, ISAPI is pretty much inconsequential.
In your scenario, WinHttp and Kerberos need to be properly set up for this
to work.
The place to start on this would be to make sure that Kerberos is properly
set up on both machines A and B. Unfortunately, I don't know of a forum I
can send you to where you are likely to get an answer. And I don't have
anything set up in my office to set it up for myself (which I would need to
do to walk you through it.)
If you can send me a piece of mail, I can do some checking to see if I can
find a concise answer. Please mention in the subject that this is in
response to this Usenet thread.
Note that this is a spare time effort for me, and it's largely unrelated to
my product (IIS). I can't guarantee that I can get a response that solves
the problem, but I want to run it by some folks.
Thank you,
-Wade A. Hilmo,
-Microsoft

Post by Jason Viers
I'm having some problems with Kerberos authentication from an ISAPI
Extension in an Active Directory domain.
-----------------------------------
I have two machines, A and B in a test domain. A is the domain
controller, both are Win2003.
Active Directory is all set up, I have a Virtual Directory on IIS on A
that has anonymous disabled and allows "Integrated Windows
Authentication", and I can fetch it from B with IE and Kerberos
authentication operates successfully, as viewed by a packet sniffer.
All is well.
--------------------------
I've written an ISAPI Extension that uses WinHttp to fetch a remote URL,
and it's set to use "Negotiate" authentication in hopes that it will
propagate the Kerberos authentication. I've created a SPN for HTTP/B,
and I've set "trust this computer for delegation" on B.
If I perform a web request from A to the IIS Extension on B (which will
then attempt to fetch the VDir on A), I can see the browser performing
Kerberos authentication to B's ISAPI Extension, and then B performing
NTLM authentication to A's VDir, which fails. All the information in
the NTLM request seem to be ok (user/domain/etc).
I'm not sure why B isn't trying to use Kerberos authentication when the
request is coming from A. Is there some additional permission necessary
beyond "Trust this machine for delegation"?
Jason
P.S. I noticed if I perform the request on *B* to B's extension, then
the WinHttp request to A performs kerberos authentication, but the
server returns my favorite cryptic kerberos error, "Message Stream
Modified". Still no idea on how to resolve it though.

[Jason Viers]

Problem has been solved, thanks all for the troubleshooting help. The
problem was twofold, both on my part.

--------------------------------------------
The "Message Stream Modified" kerberos errors were caused by improper
manual setting of the "Authorization" header.

This ISAPI code is functioning as a proxy, which includes passing along
headers from the original request. The "Authorization" header was being
set with WinHttpAddRequestHeaders along with WinHttp's own authorization
attempts, causing them to be concatenated into one long Authorization
header.

There was code in place to prevent "Authorization" from being passed
along in this manner, but of course there was a typo that prevented it
from detecting "Authorization" properly. Fixed it, Authorization header
was suddenly half the length, and now it works.

---------------------------------------
The "Propagating NTLM instead of Kerberos after Kerberos auth" was a
problem with how IE was authenticating with IIS.

I was not aware that, when connecting to an IIS that is using Integrated
Authentication, there is an underlying difference between "connecting
with IE and entering user credentials" vs "adding the site to local
internet and passing credentials automatically". I saw Kerberos auth
between IE & IIS in both cases, and I liked being able to enter
different users for testing with the former, so I was using it.

Now I've discovered that it makes all the difference; when added to
local sites, kerberos will be properly delegate and propagated through
WinHttp, where as when credentials are entered manually, there are not.


Follow-up question - When in the Authenticated ISAPI and using WinHttp,
is there any way to detect these two situations? I can examine the
"Authorization" header to detect NTLM vs. Kerberos easily, but a quick
glance didn't show any difference between the Kerberos-that-becomes-NTLM
vs. the Kerberos-that-becomes-Kerberos. I'd like to be able to raise an
error in the former situation rather than just getting "access denied"
for anything.


Thanks
jason

[S. Pidgorny <MVP>]

Your objective is pass-through authentication: client - A -B. The A must be
trusted for delegation?
--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-

* http://sl.mvps.org * http://msmvps.com/blogs/sp *

Post by Jason Viers
I'm having some problems with Kerberos authentication from an ISAPI
Extension in an Active Directory domain.
-----------------------------------
I have two machines, A and B in a test domain. A is the domain
controller, both are Win2003.
Active Directory is all set up, I have a Virtual Directory on IIS on A
that has anonymous disabled and allows "Integrated Windows
Authentication", and I can fetch it from B with IE and Kerberos
authentication operates successfully, as viewed by a packet sniffer.
All is well.
--------------------------
I've written an ISAPI Extension that uses WinHttp to fetch a remote URL,
and it's set to use "Negotiate" authentication in hopes that it will
propagate the Kerberos authentication. I've created a SPN for HTTP/B, and
I've set "trust this computer for delegation" on B.
If I perform a web request from A to the IIS Extension on B (which will
then attempt to fetch the VDir on A), I can see the browser performing
Kerberos authentication to B's ISAPI Extension, and then B performing NTLM
authentication to A's VDir, which fails. All the information in the NTLM
request seem to be ok (user/domain/etc).
I'm not sure why B isn't trying to use Kerberos authentication when the
request is coming from A. Is there some additional permission necessary
beyond "Trust this machine for delegation"?
Jason
P.S. I noticed if I perform the request on *B* to B's extension, then the
WinHttp request to A performs kerberos authentication, but the server
returns my favorite cryptic kerberos error, "Message Stream Modified".
Still no idea on how to resolve it though.

[Jason Viers]

Post by S. Pidgorny <MVP>
Your objective is pass-through authentication: client - A -B. The A must be
trusted for delegation?

Yes, pass-through authentication is the goal. It's really A->B->A,
where A->B works but the second B->A doesn't. Machine A (the domain
controller) is trusted for delegation by default, which I've left.

Jason