Delegatoin w/ Protocol transition in a Windows 2000 native domain


J

jesper.hvid

Hi,

Some background information first.

I have a root domain "rootdom.com" and two child domains
"c1.rootdom.com" and "c2.rootdom.com".

In the c1 domain I have an IIS 6 with an ASP.net application on it
that's running forms-based authentication as well as an Exchange 2003
frontend server running integrated authentication (integrated
authentication is the only box checked).

The ASP.NET application needs delegated access to the exchange
frontend-server by means impersonating the user who's logged in with
forms authentication and querying webdav with the user's credentials.

What I've done so far:
1. Created a domain user in the "rootdom.com"-domain called
"DelegationUser". This account is trusted for delegation. I don't have
the "Delegation" tab you get in a 2003-native domain since I'm running
2000-native on all domains.
2. Created service principal names for the "DelegationUser" user the
service principal names are: "aspnetserver" and
"aspnetserver.c1.rootdom.com"
3. Assigned "DelegationUser" to the ApplicationPool that's running the
ASP.NET application which included adding delegationuser to the
IIS_WPG group and granting the user the "Act as part of the operating
system" privelege on the ASP.NET server.
4. Turned off impersonation on the ASP.NET application
5. Used programmatic impersonation in the ASP.NET application where I
create a "new
WindowsIdentity(UPN_OF_USER_I_WANT_TO_IMPERSONATE).Impersonate()"
6. While impersonating I query the Exchange 2003-frontend server with
webdav.
7. End impersonation and revert to the application pool user which
runs the ASP.NEt application

Step 6 fails with a 401-error code while steps 1-5 seem to work just
fine. I've even checked the identity of the current thread while
impersonating, and I can see that it is in fact the user that I'm
impersonating. However, the identity is not being delegated to the
exchange 2003 server.

Things I've tried my self:
1. Trusting the computer accounts for the ASP.NET server and the
Exchange 2003 frontend server for delegation. However, this didn't
make any difference.
2. Looking in the IIS log "C:\Windows\System32\LogFiles" on the
Exchange 2003 server. Doing this I can see that the IIS is reading my
webdav queries as anonymous requests. This leads me to believe that
it's reverting to NTLM which isn't delegatable.
3. Looking in the event log of the c1.rootdom.com DC and I've seen no
failure audits. I presume that this is the DC that should be issuing
tickets for the aspnetserver?

I know the above scenario works with constrained delegation, since
I've done it in a 2003-native domain set up. But it SHOULD work in a
2000-native domain as well.

Any help?
 
Ad

Advertisements

J

jesper.hvid

Hi,

Some background information first.

I have a root domain "rootdom.com" and two child domains
"c1.rootdom.com" and "c2.rootdom.com".

In the c1 domain I have an IIS 6 with an ASP.net application on it
that's running forms-based authentication as well as an Exchange 2003
frontend server running integrated authentication (integrated
authentication is the only box checked).

The ASP.NET application needs delegated access to the exchange
frontend-server by means impersonating the user who's logged in with
forms authentication and querying webdav with the user's credentials.

What I've done so far:
1. Created a domain user in the "rootdom.com"-domain called
"DelegationUser". This account is trusted for delegation. I don't have
the "Delegation" tab you get in a 2003-native domain since I'm running
2000-native on all domains.
2. Created service principal names for the "DelegationUser" user the
service principal names are: "aspnetserver" and
"aspnetserver.c1.rootdom.com"
3. Assigned "DelegationUser" to the ApplicationPool that's running the
ASP.NET application which included adding delegationuser to the
IIS_WPG group and granting the user the "Act as part of the operating
system" privelege on the ASP.NET server.
4. Turned off impersonation on the ASP.NET application
5. Used programmatic impersonation in the ASP.NET application where I
create a "new
WindowsIdentity(UPN_OF_USER_I_WANT_TO_IMPERSONATE).Impersonate()"
6. While impersonating I query the Exchange 2003-frontend server with
webdav.
7. End impersonation and revert to the application pool user which
runs the ASP.NEt application

Step 6 fails with a 401-error code while steps 1-5 seem to work just
fine. I've even checked the identity of the current thread while
impersonating, and I can see that it is in fact the user that I'm
impersonating. However, the identity is not being delegated to the
exchange 2003 server.

Things I've tried my self:
1. Trusting the computer accounts for the ASP.NET server and the
Exchange 2003 frontend server for delegation. However, this didn't
make any difference.
2. Looking in the IIS log "C:\Windows\System32\LogFiles" on the
Exchange 2003 server. Doing this I can see that the IIS is reading my
webdav queries as anonymous requests. This leads me to believe that
it's reverting to NTLM which isn't delegatable.
3. Looking in the event log of the c1.rootdom.com DC and I've seen no
failure audits. I presume that this is the DC that should be issuing
tickets for the aspnetserver?

I know the above scenario works with constrained delegation, since
I've done it in a 2003-native domain set up. But it SHOULD work in a
2000-native domain as well.

Any help?

I've resolved the issue, and I figures out another problem :)

1) I had to change to Windows 2003-native functional mode since the
"protocol transition" part of the delegation only works with
constrained delegation
2) constrained delegation does not work at all in cross domain
scenarios. The frontend server will produce an HTTP 500 error because
it cannot talk kerberos to a backend server in another domain ¤#"%#¤%#
¤
%¤#%!

There's no way around this other than having frontend servers for each
unique child domain.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top