Re: The pest of Impersonation
- From: Cliff <Junk@xxxxxxxxxxxxx>
- Date: Wed, 26 Sep 2007 02:43:13 -0700
On 26 Sep, 05:42, "Joe Kaplan"
<joseph.e.kap...@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
A few things here. It sounds like either your AD is Win2K or is still and
2K functional level, as your description makes it sound like the only option
available for delegation is "trusted for delegation". With a 2K3 native
forest, you can also do protocol transition and constrained delegation and
the delegation tab in ADUC has more options.
So, assuming you only have "trusted for delegation" available, that requires
Kerberos auth for the both the front end web app as well as your target
backend system. If you were able to enable protocol transition ("trusted to
delegate with any protocol" in ADUC), then you could have the front end web
app authenticate using NTLM, Basic or Digest in addition to Kerberos.
You'll need to run the app pool as Network Service (preferred) or Local
System in order for the machine account's credentials to be used on the
network. Since that's where you applied the delegation, it is important for
that account to be used.
So, given all that, the first thing you need to do is ensure that you are
getting Kerberos authentication in the front end web app, not NTLM. Turn
off Digest. You can't use it in this scenario, so it is best that your
server doesn't even advertise it as an option. To determine whether you are
getting Kerberos auth, the best way is to enable auditing for both success
and failure of logon events in your local security policy and look at the
details of the authentication events that are logged when you sign in via
the browser. If those say NTLMSSP instead of Kerberos, then you aren't
getting Kerberos auth in the web app and you have to fix that. Reading the
TechNet docs on troubleshooting Kerberos auth is essential.
Once you get Kerb auth on the front end, then you need to also ensure you
get Kerb auth on the backend. After that, you can delegate using
impersonation of the authenticated user in the web app.
Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"http://www.directoryprogramming.net
--
hi. Thanks for that, I've given the server the "trusted for
Delegation" right in AD and given it a re-boot, but still no avail...
for reference: The site is set as Integrated and Digest authentication
The Application Pool has been tried under Local Service, Network
Service and Local System
The web.config file is set to <Authentication Mode="Windows"/> and
<identity impersonate="true"/>
Many thanks!
Cliff.- Hide quoted text -
- Show quoted text -
WOW...there's alot there and I'll certainly give that a go.
We are Windows 2003 Native tho, I didn't mention the other options as
I thought I'd start with the simplest option which is just "Trusted
for Delegation".
Thanks again for your help...I'll post back when I've completed those
steps.
Cliff.
.
- Follow-Ups:
- Re: The pest of Impersonation
- From: Cliff
- Re: The pest of Impersonation
- References:
- The pest of Impersonation
- From: Cliff
- Re: The pest of Impersonation
- From: Joe Kaplan
- Re: The pest of Impersonation
- From: Cliff
- Re: The pest of Impersonation
- From: Joe Kaplan
- The pest of Impersonation
- Prev by Date: Re: The pest of Impersonation
- Next by Date: login control blues
- Previous by thread: Re: The pest of Impersonation
- Next by thread: Re: The pest of Impersonation
- Index(es):
Relevant Pages
|
|