Is it possible to force a w3wp process to always run under a specific
non-admin account when users are authenticated by different means?

What I have is two virtual directories: one with Windows authentication,
supporting a minimal set of internal Windows accounts, and one using
Anonymous authentication, supporting external web-based users authenticated
via a proprietary service. Both are configured to share the same application
pool.

One goal is to ensure that a number of DCOM connections made by the w3wp all
share the same instances of those DCOM servers (which have to be set to run
as 'Launching user'), and they run under the same account as w3wp. A second
goal is to limit the privileges of that "base" account, so that means it
can't be an admin.

It initially sounded easy: set the Identity for the application pool to be
the required account, and have all the threads call ImpersonateSelf.
However, this doesn't load the profile for that base account, and it isn't
loaded by default for the COM+ processes anyway. This then has bad knockon
effects, including for the DCOM servers. The catch-22 is that the non-admin
base account doesn't have permission to call LoadUserProfile.

Any guidance here would be really welcome

Tony Proctor

[ Post a follow-up to this message ]

Hi,

This can depend on what type of application you are using here...

ASP.NET applications run under w3wp.exe identity (for example) whereas ASP
applications impersonate authenticated user (by default).

Cheers
Ken


"Tony Proctor" <tony_proctor@aimtechnology_NoMoreSPAM_.com> wrote in message
news:OkgDs0APHHA.3544@TK2MSFTNGP03.phx.gbl...
> Is it possible to force a w3wp process to always run under a specific
> non-admin account when users are authenticated by different means?
>
> What I have is two virtual directories: one with Windows authentication,
> supporting a minimal set of internal Windows accounts, and one using
> Anonymous authentication, supporting external web-based users
> authenticated
> via a proprietary service. Both are configured to share the same
> application
> pool.
>
> One goal is to ensure that a number of DCOM connections made by the w3wp
> all
> share the same instances of those DCOM servers (which have to be set to
> run
> as 'Launching user'), and they run under the same account as w3wp. A
> second
> goal is to limit the privileges of that "base" account, so that means it
> can't be an admin.
>
> It initially sounded easy: set the Identity for the application pool to be
> the required account, and have all the threads call ImpersonateSelf.
> However, this doesn't load the profile for that base account, and it isn't
> loaded by default for the COM+ processes anyway. This then has bad knockon
> effects, including for the DCOM servers. The catch-22 is that the
> non-admin
> base account doesn't have permission to call LoadUserProfile.
>
> Any guidance here would be really welcome
>
>    Tony Proctor
>
>

[ Post a follow-up to this message ]

Is your problem:
1. Forcing w3wp.exe process to run code with a specific non-admin
account
2. Making the Application Pool Process Identity call LoadProfile on its
configured identity

Because #1 is possible to do but not with any built-in IIS features,
and #2 is not possible since IIS6 explicitly does not load the custom
user's Profile for scalability reasons.

Since you are trying to share a single DCOM server instance with
multiple users, can you consider making the DCOM server a standalone
singleton launched as the "launching user"? Is there a particular
reason that you must first map all users into one "launching user"
before invoking the DCOM servers?


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//


Tony Proctor wrote:
> Is it possible to force a w3wp process to always run under a specific
> non-admin account when users are authenticated by different means?
>
> What I have is two virtual directories: one with Windows authentication,
> supporting a minimal set of internal Windows accounts, and one using
> Anonymous authentication, supporting external web-based users authenticate
d
> via a proprietary service. Both are configured to share the same applicati
on
> pool.
>
> One goal is to ensure that a number of DCOM connections made by the w3wp a
ll
> share the same instances of those DCOM servers (which have to be set to ru
n
> as 'Launching user'), and they run under the same account as w3wp. A secon
d
> goal is to limit the privileges of that "base" account, so that means it
> can't be an admin.
>
> It initially sounded easy: set the Identity for the application pool to be
> the required account, and have all the threads call ImpersonateSelf.
> However, this doesn't load the profile for that base account, and it isn't
> loaded by default for the COM+ processes anyway. This then has bad knockon
> effects, including for the DCOM servers. The catch-22 is that the non-admi
n
> base account doesn't have permission to call LoadUserProfile.
>
> Any guidance here would be really welcome
>
>     Tony Proctor

[ Post a follow-up to this message ]

Thanks for replying David

This is an ASP-based application, although most of the code is in DLLs
loaded by the ASP page(s)

There may be multiple instances of this web application, each using a
distinct "base" account for their processing, which is why we are trying to
use 'launching user'. If we start putting an explicit Identity on the DCOM
servers then we are stuck with a single machine-wide instance rather than
separate application-wide instances (i.e.one per application). They are not
really "singletons" in the object sense. They are multi-threaded servers
that use shared memory across their threads, which is why each application
needs its own DCOM server process.

We managed to set the application pool Identity for a non-privileged
account, and used ImpersonateSelf to abandon the given impersonated token
and replace it with one for the "base" account. As I said though, the
profile for that "base" account isn't loaded by default, and you have to be
running under an admin account to call LoadUserprofile (even to load you own
profile, which seems odd). If someone is physically logged on under that
"base" account then things work, but that cannot be replied upon. Is there a
way to ensure the profile is pre-loaded for the configured Identity on the
application pool?

Tony Proctor


"David Wang" <w3.4you@gmail.com> wrote in message
news:1169359873.037310.32720@l53g2000cwa.googlegroups.com...
> Is your problem:
> 1. Forcing w3wp.exe process to run code with a specific non-admin
> account
> 2. Making the Application Pool Process Identity call LoadProfile on its
> configured identity
>
> Because #1 is possible to do but not with any built-in IIS features,
> and #2 is not possible since IIS6 explicitly does not load the custom
> user's Profile for scalability reasons.
>
> Since you are trying to share a single DCOM server instance with
> multiple users, can you consider making the DCOM server a standalone
> singleton launched as the "launching user"? Is there a particular
> reason that you must first map all users into one "launching user"
> before invoking the DCOM servers?
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>
>
> Tony Proctor wrote: 
authenticated[vbcol=seagreen] 
application[vbcol=seagreen] 
all[vbcol=seagreen] 
run[vbcol=seagreen] 
second[vbcol=seagreen] 
be[vbcol=seagreen] 
isn't[vbcol=seagreen] 
knockon[vbcol=seagreen] 
non-admin[vbcol=seagreen] 
>

[ Post a follow-up to this message ]

This does seem to be a hole in the system David, and I'm at a loss to find a
way around it. This non-privileged "base" account does not have privilege to
load it's own profile. It seems the rules for LoadUserProfile were tightened
up for XP SP2 too.

I know it's possible to have a separate privileged task/service that could
take care of loading the relevant profile, but this feels very messy, and --
worse still -- it would require hard-coding the passwords somewhere (e.g. in
the code). Is it legal to pass the relevant access tokens across process
boundaries in order to avoid such a task having to call LogonUser itself?

Tony Proctor

"David Wang" <w3.4you@gmail.com> wrote in message
news:1169359873.037310.32720@l53g2000cwa.googlegroups.com...
> Is your problem:
> 1. Forcing w3wp.exe process to run code with a specific non-admin
> account
> 2. Making the Application Pool Process Identity call LoadProfile on its
> configured identity
>
> Because #1 is possible to do but not with any built-in IIS features,
> and #2 is not possible since IIS6 explicitly does not load the custom
> user's Profile for scalability reasons.
>
> Since you are trying to share a single DCOM server instance with
> multiple users, can you consider making the DCOM server a standalone
> singleton launched as the "launching user"? Is there a particular
> reason that you must first map all users into one "launching user"
> before invoking the DCOM servers?
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>
>
> Tony Proctor wrote: 
authenticated[vbcol=seagreen] 
application[vbcol=seagreen] 
all[vbcol=seagreen] 
run[vbcol=seagreen] 
second[vbcol=seagreen] 
be[vbcol=seagreen] 
isn't[vbcol=seagreen] 
knockon[vbcol=seagreen] 
non-admin[vbcol=seagreen] 
>

[ Post a follow-up to this message ]