Protocol Transition and Constrained Delegation

External Since: Aug 17, 2007 Posts: 1

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

External Since: Aug 23, 2003 Posts: 3041

"Gavin Dell" <Gavin Dell.RemoveThis@discussions.microsoft.com> 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
>