On 9 Jan., 17:53, bruce barker <brucebar...@discussions.microsoft.com>
wrote:
> you are on the correct track. most likely you are not creating a primary
> token to impersonate, so its only valid for local resources, not network. you
> need to use DuplicateToken to create a primary token, that you can then use
> to impersonate.
>
> // note: air code
> // save current identity
>
> WindowsIdenity oldId = WindowsIdentity.Current;
>
> // impersonate desired id
>
> IntPtr token = IntPtr.Zero;
> IntPtr tokenDuplicate = IntPtr.Zero;
> LogonUser(userName, domain, password, 3, 0, ref token);
> DuplicateToken(token, 2, ref tokenDuplicate);
> (new WindowsIdentity(tokenDuplicate)).Impersonate();
>
> // do code here
> .....
>
> // restore identity
>
> oldId.Impersonate();
> CloseHandle(token);
> CloseHandle(tokenDuplicate);
>
> note: because asp.net is thread agile (can change threads during
> processing), this code should be done in one method (asp.net callback).
>
> -- bruce (sqlwork.com)
>
> "jesper.h...@gmail.com" wrote:
> > 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) on the Exchange 2003 /exchange
> > vdir.
>
> > The ASP.NET application needs delegated access to the exchange
> > frontend-server by means of impersonating the user who's logged on
> > with forms authentication and querying webdav with the user's domain
> > 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.
|
Similar Threads
