Forcing Single w3wp Identity

am 19.01.2007 22:02:44 von Tony Proctor

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

Re: Forcing Single w3wp Identity

am 20.01.2007 02:44:51 von Ken Schaefer

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

Re: Forcing Single w3wp Identity

am 20.01.2007 02:44:51 von Ken Schaefer

Re: Forcing Single w3wp Identity

am 21.01.2007 07:11:13 von David Wang

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

Re: Forcing Single w3wp Identity

am 21.01.2007 07:11:13 von David Wang

Re: Forcing Single w3wp Identity

am 21.01.2007 12:36:33 von Tony Proctor

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

Re: Forcing Single w3wp Identity

am 21.01.2007 12:36:33 von Tony Proctor

Re: Forcing Single w3wp Identity

am 24.01.2007 14:11:33 von Tony Proctor

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

Re: Forcing Single w3wp Identity

am 24.01.2007 14:11:33 von Tony Proctor

Re: Forcing Single w3wp Identity

am 02.02.2007 11:07:39 von David Wang

I think that the system looks fine - only that IIS should offer a
choice to load the user profile of the configurable Application Pool
Identity. IIS6 does not give this choice. IIS7 does.

I think it is fine for the non-privileged base account to not be able
to call LoadUserProfile because one user should not be able to load
any other user's profile, and it is useless for the user to load its
own profile because its process has already started running.

It is up to the LocalSystem process, like winlogon.exe at console
login, or WAS at w3wp.exe startup, to determine if the user's profile
should be loaded.

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

On Jan 24, 5:11 am, "Tony Proctor"
wrote:
> 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" 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:
> > > 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- Hide quoted text -
>
> - Show quoted text -