Protocol Transition and Constrained Delegation

Hi all,

We are using IIS 6.0 on Windows Server 2003 R2 to host both various ASP.NET
2.0 applications and a third party BI application (Cognos). At this point
the Domain Controller is also the Web Server. Cognos supports both Kerberos
and Active Directory and provides an ISAPI Extension which is installed in
IIS and manages the downstream hand-off to the back-end processes. The
ASP.NET applications are deployed in the normal manner and the Authentication
Method is set identically for all virtual directories.

The configuration works successfully for SSO between ASP.NET 2.0 and Cognos
using Integrated Windows Authentication in IE6. What does not work
successfully is when I switch the Authentication Method over to Basic in IIS.
According to Cognos support, the Kerberos token is not being translated in
IIS properly and hence is not recognised by the ISAPI gateway with the result
the I get prompted to authenticate by the Cognos ISAPI gateway even though I
have already authenticated using the Basic scheme.

I have to assume that I have made a mistake somewhere with the
configuration, however I cannot seem to spot it. To remove permissions
issues at this point I have set IIS6 to use LocalSystem as the Identity for
the worker pool, and have allowed the machine to delegate to all listed
services on itself using any protocol. SPNs also seem to be correct - I
have HTTP and the usual ones for the machine itself.

At this point I cannot see where the problem lies and will greatly
appreciate any assistance in resolving this.

Many thanks in advance.

Gavin

Re: Protocol Transition and Constrained Delegation

"Gavin Dell" wrote in message
news:A256D29E-D272-4B67-A243-9835B1E25151@microsoft.com...
> Hi all,
>
> We are using IIS 6.0 on Windows Server 2003 R2 to host both various
> ASP.NET
> 2.0 applications and a third party BI application (Cognos). At this
> point
> the Domain Controller is also the Web Server. Cognos supports both
> Kerberos
> and Active Directory and provides an ISAPI Extension which is installed in
> IIS and manages the downstream hand-off to the back-end processes. The
> ASP.NET applications are deployed in the normal manner and the
> Authentication
> Method is set identically for all virtual directories.
>
> The configuration works successfully for SSO between ASP.NET 2.0 and
> Cognos
> using Integrated Windows Authentication in IE6. What does not work
> successfully is when I switch the Authentication Method over to Basic in
> IIS.
> According to Cognos support, the Kerberos token is not being translated
> in
> IIS properly and hence is not recognised by the ISAPI gateway with the
> result
> the I get prompted to authenticate by the Cognos ISAPI gateway even though
> I
> have already authenticated using the Basic scheme.

This doesn't make a lot of sense here.

Client ----> IIS is using Basic authentication correct? If so, there is no
Kerberos token for the Cognos ISAPI filter to see. The ISAPI filter would
only see the Authorization HTTP headers with Basic auth details.

Perhaps you can explain in more detail, how all these different bits and
pieces work, so we can see exactly where Kerberos is supposed to kick in,
and where the protocol transition is supposed to take place.

Personally, i don't think this is a bug in IIS as suggested by Cognos - I've
seen plenty of Kerberos setups that work just fine on IIS. IIS itself does
not handle the Kerberos or Protocol transition work - that is all handled by
lsass.exe and ksecdd.sys etc (i.e. the Windows security subsystems).

More on protocol transition and IIS:
http://www.adopenstatic.com/cs/blogs/ken/archive/2007/07/18/ 8460.aspx

Cheers
Ken



>
> I have to assume that I have made a mistake somewhere with the
> configuration, however I cannot seem to spot it. To remove permissions
> issues at this point I have set IIS6 to use LocalSystem as the Identity
> for
> the worker pool, and have allowed the machine to delegate to all listed
> services on itself using any protocol. SPNs also seem to be correct - I
> have HTTP and the usual ones for the machine itself.
>
> At this point I cannot see where the problem lies and will greatly
> appreciate any assistance in resolving this.
>
> Many thanks in advance.
>
> Gavin
>

Re: Protocol Transition and Constrained Delegation

Hi Ken,

Thank you for your prompt response. I am also not inclined to think that
there is a bug in IIS 6.0 regarding this. I am sure it is simply a
misunderstanding of protocol transition on my part. Thank you for the link,
I have reread your blog which I must say is definitely one of the clearest
resources I have found on Protocol Transition and Constrained Delegation.

I am using Kerberos within the system architecture in order to facilitate
SSO through the tiers, specifically through to SQL Server 2005 and Analysis
Services from the Web Server tier, which is IIS6. Since the Web Server tier
will be Internet facing, the users of the system will need to authenticate
using some form of authentication protocol other than Kerberos (and then
transition to Kerberos), and my reading of various articles has led me to
believe that IIS can perform a protocol transition to Kerberos with
appropriate configuration on the server. So an effective scenario like this:

Basic Kerberos
Client --------> IIS 6 ---------> Backend System
^
|
Transition

The difference between the illustration above and what I am currently
working with is that in my scenario all applications are currently running on
the same server (ie there is no Backend System).

Services for User to Self (S4U2S) was the Kerberos service I expected to
allow this transition. I expected IIS to perform the protocol transition in
the process of handling the request through to the ISAPI Extension (the
Cognos gateway in this case) - effectively replacing the process level
authentication token with the Kerberos equivalent for the user - but I
suspect that the transition does not occur at this point.

The ISAPI Extension requires a Kerberos token in order to perform the SSO
and the only authentication option I have for the users, is Basic, so any
idea on getting this to work would be greatly appreciated.

I hope that this makes more sense.

Thanks again.

Gavin




"Ken Schaefer" wrote:

>
> "Gavin Dell" wrote in message
> news:A256D29E-D272-4B67-A243-9835B1E25151@microsoft.com...
> > Hi all,
> >
> > We are using IIS 6.0 on Windows Server 2003 R2 to host both various
> > ASP.NET
> > 2.0 applications and a third party BI application (Cognos). At this
> > point
> > the Domain Controller is also the Web Server. Cognos supports both
> > Kerberos
> > and Active Directory and provides an ISAPI Extension which is installed in
> > IIS and manages the downstream hand-off to the back-end processes. The
> > ASP.NET applications are deployed in the normal manner and the
> > Authentication
> > Method is set identically for all virtual directories.
> >
> > The configuration works successfully for SSO between ASP.NET 2.0 and
> > Cognos
> > using Integrated Windows Authentication in IE6. What does not work
> > successfully is when I switch the Authentication Method over to Basic in
> > IIS.
> > According to Cognos support, the Kerberos token is not being translated
> > in
> > IIS properly and hence is not recognised by the ISAPI gateway with the
> > result
> > the I get prompted to authenticate by the Cognos ISAPI gateway even though
> > I
> > have already authenticated using the Basic scheme.
>
> This doesn't make a lot of sense here.
>
> Client ----> IIS is using Basic authentication correct? If so, there is no
> Kerberos token for the Cognos ISAPI filter to see. The ISAPI filter would
> only see the Authorization HTTP headers with Basic auth details.
>
> Perhaps you can explain in more detail, how all these different bits and
> pieces work, so we can see exactly where Kerberos is supposed to kick in,
> and where the protocol transition is supposed to take place.
>
> Personally, i don't think this is a bug in IIS as suggested by Cognos - I've
> seen plenty of Kerberos setups that work just fine on IIS. IIS itself does
> not handle the Kerberos or Protocol transition work - that is all handled by
> lsass.exe and ksecdd.sys etc (i.e. the Windows security subsystems).
>
> More on protocol transition and IIS:
> http://www.adopenstatic.com/cs/blogs/ken/archive/2007/07/18/ 8460.aspx
>
> Cheers
> Ken
>
>
>
> >
> > I have to assume that I have made a mistake somewhere with the
> > configuration, however I cannot seem to spot it. To remove permissions
> > issues at this point I have set IIS6 to use LocalSystem as the Identity
> > for
> > the worker pool, and have allowed the machine to delegate to all listed
> > services on itself using any protocol. SPNs also seem to be correct - I
> > have HTTP and the usual ones for the machine itself.
> >
> > At this point I cannot see where the problem lies and will greatly
> > appreciate any assistance in resolving this.
> >
> > Many thanks in advance.
> >
> > Gavin
> >
>
>

Re: Protocol Transition and Constrained Delegation

Hi,

I suspect that your ISAPI filter is kicking in too early in the process. It
is probably seeing the HTTP request that comes from the client, and not the
end security token that IIS sees later on. But I don't have enough knowledge
of the Cognos ISAPI filter to comment - you probably need to get some more
details on how their ISAPI filter works from them.

You could put ISA Server or something in between the client and the web
server (or even run it on the webserver). ISA Server can do the protocol
transition for you, so that there's a Kerberos token delivered to the
webserver.

Cheers
Ken


"Gavin Dell" wrote in message
news:D9B317B7-C427-4211-8FA5-A11D6A22EB3A@microsoft.com...
> Hi Ken,
>
> Thank you for your prompt response. I am also not inclined to think that
> there is a bug in IIS 6.0 regarding this. I am sure it is simply a
> misunderstanding of protocol transition on my part. Thank you for the
> link,
> I have reread your blog which I must say is definitely one of the clearest
> resources I have found on Protocol Transition and Constrained Delegation.
>
> I am using Kerberos within the system architecture in order to facilitate
> SSO through the tiers, specifically through to SQL Server 2005 and
> Analysis
> Services from the Web Server tier, which is IIS6. Since the Web Server
> tier
> will be Internet facing, the users of the system will need to authenticate
> using some form of authentication protocol other than Kerberos (and then
> transition to Kerberos), and my reading of various articles has led me to
> believe that IIS can perform a protocol transition to Kerberos with
> appropriate configuration on the server. So an effective scenario like
> this:
>
> Basic Kerberos
> Client --------> IIS 6 ---------> Backend System
> ^
> |
> Transition
>
> The difference between the illustration above and what I am currently
> working with is that in my scenario all applications are currently running
> on
> the same server (ie there is no Backend System).
>
> Services for User to Self (S4U2S) was the Kerberos service I expected to
> allow this transition. I expected IIS to perform the protocol transition
> in
> the process of handling the request through to the ISAPI Extension (the
> Cognos gateway in this case) - effectively replacing the process level
> authentication token with the Kerberos equivalent for the user - but I
> suspect that the transition does not occur at this point.
>
> The ISAPI Extension requires a Kerberos token in order to perform the SSO
> and the only authentication option I have for the users, is Basic, so any
> idea on getting this to work would be greatly appreciated.
>
> I hope that this makes more sense.
>
> Thanks again.
>
> Gavin
>
>
>
>
> "Ken Schaefer" wrote:
>
>>
>> "Gavin Dell" wrote in message
>> news:A256D29E-D272-4B67-A243-9835B1E25151@microsoft.com...
>> > Hi all,
>> >
>> > We are using IIS 6.0 on Windows Server 2003 R2 to host both various
>> > ASP.NET
>> > 2.0 applications and a third party BI application (Cognos). At this
>> > point
>> > the Domain Controller is also the Web Server. Cognos supports both
>> > Kerberos
>> > and Active Directory and provides an ISAPI Extension which is installed
>> > in
>> > IIS and manages the downstream hand-off to the back-end processes.
>> > The
>> > ASP.NET applications are deployed in the normal manner and the
>> > Authentication
>> > Method is set identically for all virtual directories.
>> >
>> > The configuration works successfully for SSO between ASP.NET 2.0 and
>> > Cognos
>> > using Integrated Windows Authentication in IE6. What does not work
>> > successfully is when I switch the Authentication Method over to Basic
>> > in
>> > IIS.
>> > According to Cognos support, the Kerberos token is not being
>> > translated
>> > in
>> > IIS properly and hence is not recognised by the ISAPI gateway with the
>> > result
>> > the I get prompted to authenticate by the Cognos ISAPI gateway even
>> > though
>> > I
>> > have already authenticated using the Basic scheme.
>>
>> This doesn't make a lot of sense here.
>>
>> Client ----> IIS is using Basic authentication correct? If so, there is
>> no
>> Kerberos token for the Cognos ISAPI filter to see. The ISAPI filter would
>> only see the Authorization HTTP headers with Basic auth details.
>>
>> Perhaps you can explain in more detail, how all these different bits and
>> pieces work, so we can see exactly where Kerberos is supposed to kick in,
>> and where the protocol transition is supposed to take place.
>>
>> Personally, i don't think this is a bug in IIS as suggested by Cognos -
>> I've
>> seen plenty of Kerberos setups that work just fine on IIS. IIS itself
>> does
>> not handle the Kerberos or Protocol transition work - that is all handled
>> by
>> lsass.exe and ksecdd.sys etc (i.e. the Windows security subsystems).
>>
>> More on protocol transition and IIS:
>> http://www.adopenstatic.com/cs/blogs/ken/archive/2007/07/18/ 8460.aspx
>>
>> Cheers
>> Ken
>>
>>
>>
>> >
>> > I have to assume that I have made a mistake somewhere with the
>> > configuration, however I cannot seem to spot it. To remove
>> > permissions
>> > issues at this point I have set IIS6 to use LocalSystem as the Identity
>> > for
>> > the worker pool, and have allowed the machine to delegate to all listed
>> > services on itself using any protocol. SPNs also seem to be correct -
>> > I
>> > have HTTP and the usual ones for the machine itself.
>> >
>> > At this point I cannot see where the problem lies and will greatly
>> > appreciate any assistance in resolving this.
>> >
>> > Many thanks in advance.
>> >
>> > Gavin
>> >
>>
>>