Re: Windows authentication and UNC shares

From: Willy Denoyette [MVP] (willy.denoyette@pandora.be)
Date: 08/28/02 

From: "Willy Denoyette [MVP]" <willy.denoyette@pandora.be>
Date: Wed, 28 Aug 2002 22:11:26 +0200

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".

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.

Willy.

"Andrew Kemp" <ajwk@pell.uklinux.net> wrote in message news:slrnamq9ig.1bv.drew@onyx.pell.uklinux.net...
> Andrew Kemp wrote:
>
> > I am trying to achieve the following in an ASP.NET web application:
>
> [...]
>
> > 3. The application connects to a SQL Server database on a
> > different computer using integrated security and the same
> > database server account for all users
>
> [...]
>
> > In order to achieve (3) I have the userName in Machine.config's
> ><processModel> element set to an account with the "log on locally"
> > privilege, and impersonation with a specific username and password
> > enabled in Web.config.
>
> Oops -- I meant the "act as part of the operating system"
> privilege. Speaking of which...
>
> Somewhere in the ASP.NET documentation it gives this as one of two ways
> to enable impersonation of a specific account. It then goes on to say
> that Microsoft do not recommend it, but doesn't explain why not. Why is
> this a bad idea, and how is it different from the (presumably
> recommended?) second way of doing it which was to use "SYSTEM" as the
> userName in the <processModel> element?
>
> Thanks,
>
> --
> drew

Relevant Pages

  • Re: Impersonation and UNC network resources
    ... need the "Act as part of the operating system" privilege to call it under ... only the SYSTEM account has this. ... privilege to any account you want to, but be very careful about that as it ... Another option for you would be using impersonation with Kerberos delegation ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Impersonation using WindowsIdentity( upn ) ctor
    ... are using under the hood when you use the WindowsIdentity "UPN" ctor. ... the token returned by the API will either be an Impersonation ... Only accounts with with that privilege can create an ... only the SYSTEM account has ...
    (microsoft.public.dotnet.security)
  • Re: Impersonation using WindowsIdentity( upn ) ctor
    ... are using under the hood when you use the WindowsIdentity "UPN" ctor. ... the token returned by the API will either be an Impersonation ... Only accounts with with that privilege can create an ... only the SYSTEM account has ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Impersonation using WindowsIdentity( upn ) ctor
    ... Ok, now, what if I use the LogonUser API? ... the token returned by the API will either be an Impersonation ... Only accounts with with that privilege can create an ... By default, only the SYSTEM account ...
    (microsoft.public.dotnet.security)
  • Re: Impersonation using WindowsIdentity( upn ) ctor
    ... Ok, now, what if I use the LogonUser API? ... the token returned by the API will either be an Impersonation ... Only accounts with with that privilege can create an ... By default, only the SYSTEM account ...
    (microsoft.public.dotnet.framework.aspnet.security)