These both sound like double-hop delegation issues. The fact that it works
when you specify specific credentials in your impersonate tag but doesn't
work when you use Window Integrated Authentication (WIA) and try to access
resources on a different machine than the IIS box suggests this. The
impersonation token that WIA creates cannot hop to another machine on the
network (like your file server or AD) unless Kerberos delegation has been
enabled and working.
I'd suggest you read up on that first and then come back here if you can't
get it to work or need a different approach.
http://support.microsoft.com/default.aspx?scid=kb;en-us;810572
You'll find even more links with a little searching.
Cheers,
Joe K.
>I have been fighting with impersonation for quite sometime now and now
>matter what I have tried it just won't work.
[quoted text clipped - 111 lines]
>
> James Pemberton
James Pemberton - 25 Oct 2004 21:08 GMT
Thanks for the site.
I've read quite a bit about delegates, but I have one more question. Do you
have to setup your entire network, hardware and users, to utilize
delegation? Or can you just set up those users or servers that you think
will need to access information remotely?
"Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote
> These both sound like double-hop delegation issues. The fact that it
> works when you specify specific credentials in your impersonate tag but
[quoted text clipped - 130 lines]
>>
>> James Pemberton
Joe Kaplan \(MVP - ADSI\) - 25 Oct 2004 22:06 GMT
I'm not a great expert on delegation, but you can enable delegation on a per
user basis in AD. The other trick you have to be careful with is that
delegation requires Kerberos, so you need to make sure your authentication
is Kerberos end to end. If it fails over to NTLM, then delegation will
suddenly break. Sometimes this will manifest itself as intermittent
problems, where the user fails on one workstation, but works on another or a
different network.
Joe K.
> Thanks for the site.
>
[quoted text clipped - 138 lines]
>>>
>>> James Pemberton
Ken Schaefer - 26 Oct 2004 05:39 GMT
In addition to Joe's comments, the following document is quite useful in
getting these things setup:
Troubleshooting Kerberos Errors
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/secu
rity/tkerberr.mspx
It covers Kerberos and delegation basics, common scenarios and
troubleshooting tips and tools.
Cheers
Ken
"Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote
> I'm not a great expert on delegation, but you can enable delegation on a
> per user basis in AD. The other trick you have to be careful with is that
[quoted text clipped - 149 lines]
>>>>
>>>> James Pemberton
James Pemberton - 26 Oct 2004 17:57 GMT
I actually did get this to work, without using delegation on the users and
hardware in AD, using the example from:
http://support.microsoft.com/default.aspx?scid=kb;en-us;306158
Hopefully one last question though. I am currently hardcoding the user
name, password, and domain into the code and really don't like doing that.
I know I can retrieve the domain and username from the
WindowsIdentity.Getcurrent.Name, but is there anyway to exacting the users
password without having them type it in on a logon screen?
Thanks
"Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote
> These both sound like double-hop delegation issues. The fact that it
> works when you specify specific credentials in your impersonate tag but
[quoted text clipped - 130 lines]
>>
>> James Pemberton
Joe Kaplan \(MVP - ADSI\) - 26 Oct 2004 18:14 GMT
The only way to get a plain text password is to either use forms
authentication or use Basic authentication. With Windows Integrated
authentication, the plain password is never sent to the IIS server, only a
hash, so you can't get it. This is why IIS creates an impersonation token
and you end up in your double-hop/delegation problem to begin with.
So basically, you can't have it both ways. You either prompt for the
password somehow or use delegation.
If you have 2003 AD, you might also be able to use what is called Kerberos
S4U. Essentially, this allows you to specify a machine as trusted and allow
it to create a token for the user given only their userPrincipalName. There
is a good article on this here:
http://msdn.microsoft.com/msdnmag/issues/03/04/SecurityBriefs/default.aspx
Joe K.
>I actually did get this to work, without using delegation on the users and
>hardware in AD, using the example from:
[quoted text clipped - 143 lines]
>>>
>>> James Pemberton