Re: Windows authentication and UNC shares
From: Andrew Kemp (andrew.kemp@dorsetsoftware.com)
Date: 08/29/02
- Next message: Dimitris Katsikas: "Re: Client Certificates"
- Previous message: Dan Greenberg: "Script Blocking Problem when creating new MS .Net Projects"
- In reply to: Willy Denoyette [MVP]: "Re: Windows authentication and UNC shares"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: andrew.kemp@dorsetsoftware.com (Andrew Kemp) Date: 29 Aug 2002 01:58:31 -0700
"Willy Denoyette [MVP]" <willy.denoyette@pandora.be> wrote in message
news:<OAs#c8sTCHA.2384@tkmsftngp10>...
> What you have in your web.config is: - identity impersonate="true",
> userName="xxxx", password="yyyyy" - Your machine.config file specifies an
> account "zzzz" which is part of the TCB (Trusted Computing Base)
>
> That means that your asp.net application (subject to this web.config) threads
> always use "xxxx" as principal identity. To access the UNC share,
> aspnet_wp.exe (the worker process for asp.net) uses the process id (well, his
> token), or when impersonating, the impersonation token, so, in your case
> always the token obtained for "xxxx".
There seems to be another account involved somewhere (and this is related to my
actual problem), namely the one used to connect the virtual directory to the
UNC share in IIS. This is the account that the various ServerVariables and
User.Identity identify the remote user as, despite the fact that he has gone
through Windows authentication.
Is there any way that I can determine the true identity of the authenticated
user? If as you say aspnet_wp isn't even using the account used to connect the
share when accessing it, it seems even stranger that it gives this as the
authenticated user name. The problem disappears (the user is correctly
identified) if the application is not accessed through a UNC share.
> Both, running asp.net with the identity of an account having TCB privileges
> or as SYSTEM, are dangerous options, as both have equally very high
> privileges to the system. Unfortunately, when running on NT4 or W2K, you need
> the TCB privilege (SYSTEM runs in the TCB by default) in order to impersonate
> an alternate principal (like you did), this requirement has been lifted as
> from XP on.
Thank you. Does this mean that the second option listed under
"Impersonate a Specific User for All the Requests of an ASP.NET Application"
in:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q306158
(i.e. running as SYSTEM) is just as not-recommended as the first (granting the
TCB privilege to ASPNET) or is there a reason why messing around with the
rights of ASPNET is particularly bad? In my case the <processModel> user has
been set to a different account entirely which has been granted the required
privilege -- would I be better using SYSTEM or are they both equally bad
solutions?
Thanks for your help,
-- drew
- Next message: Dimitris Katsikas: "Re: Client Certificates"
- Previous message: Dan Greenberg: "Script Blocking Problem when creating new MS .Net Projects"
- In reply to: Willy Denoyette [MVP]: "Re: Windows authentication and UNC shares"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
