Delegation in ASP.NET

[Dominick Baier]

I think i had a similar problem a while ago -

and i further thinks - yes - he is falling back to NTLM which makes delegation impossible...

when you turn on auditing for logon events you can see the Authentication Package that is used -

when using kerberos - the NEGOTIATE SSPI should be used - see if in the case you described the AuthPackage is NTLM to clarify this...



---
Dominick Baier - DevelopMentor
[url]http://www.leastprivilege.com[/url]

nntp://news.microsoft.com/microsoft.public.dotnet.framework.aspnet.security/<91175990-829B-44FD-BB4B-78BC757DEE78@microsoft.com>

Hi,

As the title suggests I have a question about delegation in ASP.NET.

We have an ASP.NET application running on a web server which requires
clients to authenticate via Windows Integrated authentication. We're running
in a Win2K native-mode domain and the clients are IE6 so we should be using
Kerberos to authenticate.

At some points the application needs to send an email on behalf of the
client; this it achieves by impersonating the remote user and using WebDAV to
talk to the exchange server running on the DC (which is a physically separate
box from the web server).

This is working in the main and the credentials appear to flow from the
browser, through the web-app to the exchange server.

However, it only hangs together with a certain set of *browser* settings :s

If the site is configured to live in a zone (e.g. Intranet or Trusted Sites
etc.) that has either of the "automatic logon..." options in the IE custom
security level dialog selected then all is well.

As soon as this isn't true and we manually enter the credentials when
prompted, we authenticate with the web-server OK, but then the ASP.NET app
can't authenicate with the exchange box on the client's behalf (its as if
we're back to impersonation rather than delegation).

We believe that we've all the accounts are correctly configured for
delegation (i.e. user accounts are *not* marked as sensitive, app account is
marked as trusted for delegation, machine account trusted for delegation).

Does anyone have any ideas about what this browser option is actually doing
that makes the whole thing work?

The application only supports windows integrated authentication so it can't
be "falling back" to basic - is it falling back to NTLM though?

Any help will be much appreciated.

cheers,
Matt


[microsoft.public.dotnet.framework.aspnet.security]

[Ken Schaefer]

Hi,

If the website is in the Internet security zone, Internet Explorer will not
use Kerberos (it will not attempt Kerberos authentication). Kerberos
authentication requires the browser to be able to access both the
webserver -and- the KDC (which are domain controllers in the Windows world),
and this typically isn't possible in an internet scenario. So, IE doesn't
attempt something that is most likely going to fail.

Solution? Add sites that use fully qualified domain names or IP addresses to
IE's Intranet zone. Also, ensure that you have an SPN registered for this
address.

Cheers
Ken

"matthewt" <matthewt@nospam.nospam> wrote in message
news:91175990-829B-44FD-BB4B-78BC757DEE78@microsoft.com...

> Hi,
>
> As the title suggests I have a question about delegation in ASP.NET.
>
> We have an ASP.NET application running on a web server which requires
> clients to authenticate via Windows Integrated authentication. We're
> running
> in a Win2K native-mode domain and the clients are IE6 so we should be
> using
> Kerberos to authenticate.
>
> At some points the application needs to send an email on behalf of the
> client; this it achieves by impersonating the remote user and using WebDAV
> to
> talk to the exchange server running on the DC (which is a physically
> separate
> box from the web server).
>
> This is working in the main and the credentials appear to flow from the
> browser, through the web-app to the exchange server.
>
> However, it only hangs together with a certain set of *browser* settings
> :s
>
> If the site is configured to live in a zone (e.g. Intranet or Trusted
> Sites
> etc.) that has either of the "automatic logon..." options in the IE custom
> security level dialog selected then all is well.
>
> As soon as this isn't true and we manually enter the credentials when
> prompted, we authenticate with the web-server OK, but then the ASP.NET app
> can't authenicate with the exchange box on the client's behalf (its as if
> we're back to impersonation rather than delegation).
>
> We believe that we've all the accounts are correctly configured for
> delegation (i.e. user accounts are *not* marked as sensitive, app account
> is
> marked as trusted for delegation, machine account trusted for delegation).
>
> Does anyone have any ideas about what this browser option is actually
> doing
> that makes the whole thing work?
>
> The application only supports windows integrated authentication so it
> can't
> be "falling back" to basic - is it falling back to NTLM though?
>
> Any help will be much appreciated.
>
> cheers,
> Matt
>

[Dominick Baier]

a while ago i wrote a little diagnostics web service to troubleshoot exactly this problem - ShowContextWebService

when you call it you have to pass in credentials (assuming you have disabled anonymous on the vdir) and if you want to impersonate.

you will get back info about : the process identity, the managed identity and the unmanaged thread identity..

get it from

[url]http://www.leastprivilege.com/PermaLink.aspx?guid=9b9d4122-352d-4b49-bb6a-861eaa87cf40[/url]



---
Dominick Baier - DevelopMentor
[url]http://www.leastprivilege.com[/url]

nntp://news.microsoft.com/microsoft.public.dotnet.framework.aspnet.security/<utJmyngmEHA.748@TK2MSFTNGP15.phx.gbl>

Hi,

If the website is in the Internet security zone, Internet Explorer will not
use Kerberos (it will not attempt Kerberos authentication). Kerberos
authentication requires the browser to be able to access both the
webserver -and- the KDC (which are domain controllers in the Windows world),
and this typically isn't possible in an internet scenario. So, IE doesn't
attempt something that is most likely going to fail.

Solution? Add sites that use fully qualified domain names or IP addresses to
IE's Intranet zone. Also, ensure that you have an SPN registered for this
address.

Cheers
Ken

"matthewt" <matthewt@nospam.nospam> wrote in message
news:91175990-829B-44FD-BB4B-78BC757DEE78@microsoft.com...

> Hi,
>
> As the title suggests I have a question about delegation in ASP.NET.
>
> We have an ASP.NET application running on a web server which requires
> clients to authenticate via Windows Integrated authentication. We're
> running
> in a Win2K native-mode domain and the clients are IE6 so we should be
> using
> Kerberos to authenticate.
>
> At some points the application needs to send an email on behalf of the
> client; this it achieves by impersonating the remote user and using WebDAV
> to
> talk to the exchange server running on the DC (which is a physically
> separate
> box from the web server).
>
> This is working in the main and the credentials appear to flow from the
> browser, through the web-app to the exchange server.
>
> However, it only hangs together with a certain set of *browser* settings
> :s
>
> If the site is configured to live in a zone (e.g. Intranet or Trusted
> Sites
> etc.) that has either of the "automatic logon..." options in the IE custom
> security level dialog selected then all is well.
>
> As soon as this isn't true and we manually enter the credentials when
> prompted, we authenticate with the web-server OK, but then the ASP.NET app
> can't authenicate with the exchange box on the client's behalf (its as if
> we're back to impersonation rather than delegation).
>
> We believe that we've all the accounts are correctly configured for
> delegation (i.e. user accounts are *not* marked as sensitive, app account
> is
> marked as trusted for delegation, machine account trusted for delegation).
>
> Does anyone have any ideas about what this browser option is actually
> doing
> that makes the whole thing work?
>
> The application only supports windows integrated authentication so it
> can't
> be "falling back" to basic - is it falling back to NTLM though?
>
> Any help will be much appreciated.
>
> cheers,
> Matt
>

[microsoft.public.dotnet.framework.aspnet.security]

[[MSFT]]

Hi Matt,

The logon and password are very sensitive data. In IE, there is no a
uniform option to control this. We have to adjust it per ZONE. Since your
application is only in a domain, I think you may consider set the intranet
zone to low security level on each computer. Can this work for you?

Luke

[[MSFT]]

Hi Matt,

The logon and password are very sensitive data. In IE, there is no a
uniform option to control this. We have to adjust it per ZONE. Since your
application is only in a domain, I think you may consider set the intranet
zone to low security level on each computer. Can this work for you?

Luke