How to run aspnet with system account

[Zeng]

Hi,

I'm running ClrProfiler for the first time to profile my web app, and it
keeps getting stuck at this msg box: "Waiting for Asp.net to start common
language runtime - this is the time to load your test page." even after I
launched my app and aspnet_wp.exe is running.

Do you know what I need to do to fix it? I also found some old post, a
person mentioned that I need to make sure I need to
run my aspnet with system account instead. Do you know how to do this
account switching?

Thanks for your comment and advice.

[Joseph MCAD]

April 6, 2005

I'll repeat what I said in my first post... Sorry for my abruptness! :-)
Joseph MCAD


"Kevin Spencer" wrote:

Well, darn, Joseph. How lucky we've been, considering the "lack of security"
on our system. In all the time it's run, we've had no problems, attacks,
down-time, viruses, trojan horses, or anything else, for several years now.

Thanks for making me feel so lucky!

Of course, there's always the possibility that we ARE security experts, but
thankfully, you have made us realize that it's all been pure luck. I guess
I'll just have to take the MCAD course to become one.

--
;-),

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"Joseph MCAD" <Jo********@dis cussions.micros oft.com> wrote in message
news:D6******** *************** ***********@mic rosoft.com...

April 6, 2005

No security expert would ever agree with you + no security expert
would
say that you are security oriented with that frame of mind and lack of
knowledge. Even if you only run your own code on your servers, developers
STILL make mistakes! If you had a simple program that connected to your
database with the SYSTEM account and it had one bug, the attacker could
launch a SQL Injection attack and do everything from, corrupting the
registery, stealing data, take files, delete audit logs, release your IP
address, knock the server offline, and do damage that could result in not
beening able to boot and therefore render the computer unrecoverable
without
changing physical pieces such as the harddrive. If you don't run web
services, I bet you haven't disabled the Documentation protocol either. I
also think that you haven't blocked .Net remoting and .rem and .soap
requests. I can't even begin to give examples of what my happen. If all
of
your customer information was taken, then deleted, then audit logs
cleared,
and then damaged all of your web servers, your company's reputation would
be
permanently destroyed unless you work for a giganticly gigantic company
such
as Microsoft. With the way you have been able to run your programs as
SYSTEM,
I can already believe that you work for a small business and have no
security
experts on your team. (that is besides maybe yourself) I strongly
recommend
that you begin to switch back to least privilege...... ..
Joseph MCAD

"Kevin Spencer" wrote:

Hi Juan,

Sorry about the poor choice of words. You were correct. It wasn't
"self-contradictory" other than the fact that you started out by
seemingly
agreeing with Joseph, who made a blanket statement. You qualified your
statement, which actually indicated that you only PARTIALLY agreed with
Joseph.

Blanket statements are almost always incorrect. Note that I didn't make a
blanket statement there! Blanket statements are only useful to lazy
people
or people that don't have the time to research the reality behind them.

Telling people that you CAN safely run ASP.Net under the System account
under the right circumstances is not likely to get anyone in trouble.
Note
that I didn't RECOMMEND it. If people misunderstand, they aren't
listening
diligently, and are therefore responsible for their own actions.

I don't like to hide the truth from people in the fear that they will
misunderstand it. Misunderstandin g is not truth. It is a lie that someone
tells themself. What I said was perfectly true. What Joseph said was
implerfectly true. What you said was perfectly true.

The account under which ASP.Net runs is configurable, and includes
"System."
Don't tell me that Microsoft made a mistake, by allowing people to do
something they should NEVER do! ;-)

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"Juan T. Llibre" <no***********@ nowhere.com> wrote in message
news:uq******** ******@tk2msftn gp13.phx.gbl...
> re:
>> Hang on a minute guys. This is self-contradictory:
>
> No, it is not.
>
> re:
>> In other words, it is either too dangerous to run it in as the System
>> account, or it is USUALLY too dangerous to run it as the System
>> account.
>> Which one is true?
>
> You're the one making *that* distinction.
>
> What I stated is :
>>> The *only* reason to change the account used for ASP.NET
>>> ( from SYSTEM to ASPNET, and now to Network Service ),
>>> was to be able to run ASP.NET in a less-dangerous security context.
>
> re:
>> The reason I ask is that we run it as System, and have for years. Why?
>> Because it is our servers, and nobody else's.
>
> If you feel comfortable with that, feel free.
>
> But, please, don't issue a recommendation to
> "run ASP.NET under the System account".
>
> That's liable to get a lot of people into trouble.
>
> Getting away from having to use an account with excessive privileges
> is the reason why, first, the ASP.NET account was changed from
> System to ASPNET and then, later, to Network Service, when
> even ASPNET was considered to have too many privileges.
>
> That's almost as bad as running a server logged in as "Administrator" .
>
>
>
>
>
> Juan T. Llibre
> ASP.NET MVP
> http://asp.net.do/foros/
> Foros de ASP.NET en Español
> Ven, y hablemos de ASP.NET...
> =============== =======
>
> "Kevin Spencer" <ke***@DIESPAMM ERSDIEtakempis. com> wrote in message
> news:eH******** *****@tk2msftng p13.phx.gbl...
>> Hang on a minute guys. This is self-contradictory:
>>
>>>> It is too dangerous to run it as SYSTEM!
>>
>>> The *only* reason to change the account used for ASP.NET
>>> ( from SYSTEM to ASPNET, and now to Network Service ),
>>> was to be able to run ASP.NET in a less-dangerous security context.
>>
>> In other words, it is either too dangerous to run it in as the System
>> account, or it is USUALLY too dangerous to run it as the System
>> account.
>> Which one is true?
>>
>> The reason I ask is that we run it as System, and have for years. Why?
>> Because it is our servers, and nobody else's. We are not a hosting
>> service. And I am in charge of the software that goes on it.
>>
>> Most executable applications run under the System account.
>>
>> --
>> HTH,
>>
>> Kevin Spencer
>> Microsoft MVP
>> .Net Developer
>> What You Seek Is What You Get.
>>
>> "Juan T. Llibre" <no***********@ nowhere.com> wrote in message
>> news:ey******** *****@TK2MSFTNG P10.phx.gbl...
>>> re:
>>>>I can't emphasize this enough!
>>>
>>> Neither can I.
>>>
>>> The *only* reason to change the account used for ASP.NET
>>> ( from SYSTEM to ASPNET, and now to Network Service ),
>>> was to be able to run ASP.NET in a less-dangerous security context.
>>>
>>> It's amazing to see that this is being deliberately reverted.
>>>
>>> re:
>>>>Sorry for my abruptness. :-)
>>>
>>> I thought you restrained yourself admirably! :-)
>>>
>>> For developers to deliberately, or maybe unknowingly,
>>> expose themselves to security risks after a product's
>>> security configuration was changed to protect them,
>>> requires a good rap on the knuckles.
>>>
>>>
>>>
>>>
>>> Juan T. Llibre
>>> ASP.NET MVP
>>> http://asp.net.do/foros/
>>> Foros de ASP.NET en Español
>>> Ven, y hablemos de ASP.NET...
>>> =============== =======
>>>
>>> "Joseph MCAD" <Jo********@dis cussions.micros oft.com> wrote in message
>>> news:3C******** *************** ***********@mic rosoft.com...
>>>>
>>>> April 5, 2005
>>>>
>>>> It is too dangerous to run it as SYSTEM! I am a Microsoft
>>>> Certified
>>>> Application Developer and one of the topics I happen to be certified
>>>> in
>>>> is
>>>> Web Applications and Security. I am not familiar with ClrProfiler,
>>>> but
>>>> I
>>>> HEAVILY am in doubt that it requires the System. I think that the
>>>> old
>>>> post
>>>> was just doing a "quick fix". I am sure that if you were having
>>>> almost
>>>> any
>>>> problem on your computer, it would be fixed by using the System
>>>> account. For
>>>> this reason, I doubt that the person was really knowing what was
>>>> required. I
>>>> strongly encourage you to research further, or disconnect the
>>>> computer
>>>> from
>>>> the internet and from any intranet whose computers connect to the
>>>> internet.
>>>> Then immediately switch back to ASPNET as soon as you are done. I
>>>> can't
>>>> emphasize this enough! Sorry for my abruptness. :-) Good luck!
>>>>
>>>>
>>>> Joseph MCAD
>>>>
>>>>
>>>>
>>>> "Zeng" wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm running ClrProfiler for the first time to profile my web app,
>>>>> and
>>>>> it
>>>>> keeps getting stuck at this msg box: "Waiting for Asp.net to start
>>>>> common
>>>>> language runtime - this is the time to load your test page." even
>>>>> after I
>>>>> launched my app and aspnet_wp.exe is running.
>>>>>
>>>>> Do you know what I need to do to fix it? I also found some old
>>>>> post, a
>>>>> person mentioned that I need to make sure I need to
>>>>> run my aspnet with system account instead. Do you know how to do
>>>>> this
>>>>> account switching?
>>>>>
>>>>> Thanks for your comment and advice.
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>
>
>

[Joe Kaplan \(MVP - ADSI\)]

Wasn't the original point of this to run CLR Profiler on your ASP.NET app?
If that is the case, you do need your worker process to have much higher
privileges than the standard ASPNET or NETWORK SERVICE account. This is due
to the nature of the profiler (requires debug privileges or something; can't
remember details).

In this case, you have two choices. You can either configure a new worker
process identity with the required privileges and set it up for ASPNET or
you can just switch to SYSTEM. SYSTEM is what MS mentions to try in their
documentation as it is the path of least resistance.

I don't think anyone would argue that running ASP.NET in production under
SYSTEM is a very bad idea from a security perspective. However, we are just
talking about doing some code profiling here. The CLR Profiler will make
your web application so slow that you would never consider running it in
production anyway (seconds per request, not the other way around), so I
don't see an issue here. Just change it back when you are done profiling.

Joe K.

"Kevin Spencer" <ke***@DIESPAMM ERSDIEtakempis. com> wrote in message
news:eH******** *****@tk2msftng p13.phx.gbl...

Hang on a minute guys. This is self-contradictory:

It is too dangerous to run it as SYSTEM!

The *only* reason to change the account used for ASP.NET
( from SYSTEM to ASPNET, and now to Network Service ),
was to be able to run ASP.NET in a less-dangerous security context.

In other words, it is either too dangerous to run it in as the System
account, or it is USUALLY too dangerous to run it as the System account.
Which one is true?

The reason I ask is that we run it as System, and have for years. Why?
Because it is our servers, and nobody else's. We are not a hosting
service. And I am in charge of the software that goes on it.

Most executable applications run under the System account.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
What You Seek Is What You Get.

"Juan T. Llibre" <no***********@ nowhere.com> wrote in message
news:ey******** *****@TK2MSFTNG P10.phx.gbl...

re:

I can't emphasize this enough!

Neither can I.

The *only* reason to change the account used for ASP.NET
( from SYSTEM to ASPNET, and now to Network Service ),
was to be able to run ASP.NET in a less-dangerous security context.

It's amazing to see that this is being deliberately reverted.

re:

Sorry for my abruptness. :-)

I thought you restrained yourself admirably! :-)

For developers to deliberately, or maybe unknowingly,
expose themselves to security risks after a product's
security configuration was changed to protect them,
requires a good rap on the knuckles.


Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
=============== =======

"Joseph MCAD" <Jo********@dis cussions.micros oft.com> wrote in message
news:3C******** *************** ***********@mic rosoft.com...

April 5, 2005

It is too dangerous to run it as SYSTEM! I am a Microsoft Certified
Application Developer and one of the topics I happen to be certified in
is
Web Applications and Security. I am not familiar with ClrProfiler, but I
HEAVILY am in doubt that it requires the System. I think that the old
post
was just doing a "quick fix". I am sure that if you were having almost
any
problem on your computer, it would be fixed by using the System account.
For
this reason, I doubt that the person was really knowing what was
required. I
strongly encourage you to research further, or disconnect the computer
from
the internet and from any intranet whose computers connect to the
internet.
Then immediately switch back to ASPNET as soon as you are done. I can't
emphasize this enough! Sorry for my abruptness. :-) Good luck!
Joseph MCAD

"Zeng" wrote:

Hi,

I'm running ClrProfiler for the first time to profile my web app, and
it
keeps getting stuck at this msg box: "Waiting for Asp.net to start
common
language runtime - this is the time to load your test page." even after
I
launched my app and aspnet_wp.exe is running.

Do you know what I need to do to fix it? I also found some old post, a
person mentioned that I need to make sure I need to
run my aspnet with system account instead. Do you know how to do this
account switching?

Thanks for your comment and advice.

[Gerry Hickman]

Hi Kevin,

Well, darn, Joseph. How lucky we've been, considering the "lack of security"

You both seem to missing the most important factor here; whether your
IIS is "world facing" or not?

You have to remember that IIS (and web servers in general) are designed
to be able to serve pages on the world-wide-web (the www).

If your IIS server is world facing, you would be a fool to run as SYSTEM
regardless of what has (or has not) happened so far.

If your IIS is only accessible from within your organization, then it
really comes down to what your users may (or may not) do, but even then
it's not a good idea because any new virus designed to target IIS
brought in by a user from email or a laptop would be able to take
control of your internal IIS server.

--
Gerry Hickman (London UK)

[Joseph MCAD]

April 6, 2005

Don't forget about disgruntled employees! In very large corporations you
will definitely face threats from the inside. Same threats, same server,
just coming from a different direction.
Joseph MCAD

"Gerry Hickman" <ge********@yah oo.co.uk> wrote in message
news:uL******** ******@TK2MSFTN GP12.phx.gbl...

Hi Kevin,

Well, darn, Joseph. How lucky we've been, considering the "lack of
security"

You both seem to missing the most important factor here; whether your IIS
is "world facing" or not?

You have to remember that IIS (and web servers in general) are designed to
be able to serve pages on the world-wide-web (the www).

If your IIS server is world facing, you would be a fool to run as SYSTEM
regardless of what has (or has not) happened so far.

If your IIS is only accessible from within your organization, then it
really comes down to what your users may (or may not) do, but even then
it's not a good idea because any new virus designed to target IIS brought
in by a user from email or a laptop would be able to take control of your
internal IIS server.

--
Gerry Hickman (London UK)

[Kevin Spencer]

Well, darn Gerry. Now I feel REALLY lucky! Our server has been world facing
for years. And despite all that, no problems! Not that we don't get
attacked. Just lucky I suppose...

--
;-),

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"Gerry Hickman" <ge********@yah oo.co.uk> wrote in message
news:uL******** ******@TK2MSFTN GP12.phx.gbl...

Hi Kevin,

Well, darn, Joseph. How lucky we've been, considering the "lack of
security"

You both seem to missing the most important factor here; whether your IIS
is "world facing" or not?

You have to remember that IIS (and web servers in general) are designed to
be able to serve pages on the world-wide-web (the www).

If your IIS server is world facing, you would be a fool to run as SYSTEM
regardless of what has (or has not) happened so far.

If your IIS is only accessible from within your organization, then it
really comes down to what your users may (or may not) do, but even then
it's not a good idea because any new virus designed to target IIS brought
in by a user from email or a laptop would be able to take control of your
internal IIS server.

--
Gerry Hickman (London UK)

[Kevin Spencer]

I feel luckier with every post...

--
;-),

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"Joseph MCAD" <an*******@disc ussions.microso ft.com> wrote in message
news:Ob******** ******@TK2MSFTN GP10.phx.gbl...

April 6, 2005

Don't forget about disgruntled employees! In very large corporations
you will definitely face threats from the inside. Same threats, same
server, just coming from a different direction.
Joseph MCAD

"Gerry Hickman" <ge********@yah oo.co.uk> wrote in message
news:uL******** ******@TK2MSFTN GP12.phx.gbl...

Hi Kevin,

Well, darn, Joseph. How lucky we've been, considering the "lack of
security"

You both seem to missing the most important factor here; whether your IIS
is "world facing" or not?

You have to remember that IIS (and web servers in general) are designed
to be able to serve pages on the world-wide-web (the www).

If your IIS server is world facing, you would be a fool to run as SYSTEM
regardless of what has (or has not) happened so far.

If your IIS is only accessible from within your organization, then it
really comes down to what your users may (or may not) do, but even then
it's not a good idea because any new virus designed to target IIS brought
in by a user from email or a laptop would be able to take control of your
internal IIS server.

--
Gerry Hickman (London UK)

[Gerry Hickman]

Joseph MCAD wrote:

Don't forget about disgruntled employees! In very large corporations you
will definitely face threats from the inside. Same threats, same server,
just coming from a different direction.

I agree, that's why I said it wasn't a good idea.

--
Gerry Hickman (London UK)

[Gerry Hickman]

Hi Kevin,

Well, darn Gerry. Now I feel REALLY lucky! Our server has been world facing
for years. And despite all that, no problems! Not that we don't get
attacked. Just lucky I suppose...

That's good news, but in many corporations it would be a sackable
offence. It's equivalent to deliberately implementing weak security.

Actually, I'm not even sure I understand you. Are you saying your
running the ASP.NET worker process as SYSTEM, or something else? If it's
the ASP.NET worker process, it does not make any sense to me to run it
as SYSTEM. How did you achieve this? Did you use the machine.config file??

Here's an extract from the official docs:

Do Not Run ASP.NET as SYSTEM

Do not use the SYSTEM account to run ASP.NET and do not grant the
ASP.NET process account the "Act as part of the operating system" user
right. Doing so defeats the principle of least privilege and increases
the damage that can be done by an attacker who is able to execute code
using the Web application's process security context.
--
Gerry Hickman (London UK)

[Kevin Spencer]

The "official docs" eh? Is this an "official doc?"

http://support.microsoft.com/default...b;en-us;317012

The problem with following instructions without understanding the whys and
wherefores of those instructions is that, when one encounters an "exception"
situation, one has only the instructions one has read to rely on. It is far
better to understand the whys and wherefores that spawned those
instructions, and the context in which they were given, or you might wind up
in a church where they don't allow you to wear short sleeves!

--
;-),

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"Gerry Hickman" <ge********@yah oo.co.uk> wrote in message
news:eR******** ******@TK2MSFTN GP14.phx.gbl...

Hi Kevin,

Well, darn Gerry. Now I feel REALLY lucky! Our server has been world
facing for years. And despite all that, no problems! Not that we don't
get attacked. Just lucky I suppose...

That's good news, but in many corporations it would be a sackable offence.
It's equivalent to deliberately implementing weak security.

Actually, I'm not even sure I understand you. Are you saying your running
the ASP.NET worker process as SYSTEM, or something else? If it's the
ASP.NET worker process, it does not make any sense to me to run it as
SYSTEM. How did you achieve this? Did you use the machine.config file??

Here's an extract from the official docs:

Do Not Run ASP.NET as SYSTEM

Do not use the SYSTEM account to run ASP.NET and do not grant the ASP.NET
process account the "Act as part of the operating system" user right.
Doing so defeats the principle of least privilege and increases the damage
that can be done by an attacker who is able to execute code using the Web
application's process security context.
--
Gerry Hickman (London UK)

[Juan T. Llibre]

Aargh!

This thread is getting to be worse than the VB vs. C# thread.

While, certainly, you *can* use system, *recommending* that
it be used might open a can of worms for some poor developer
who won't understand why, all of a sudden, nothing works
because somebody screwed up royally trying out a procedure,
or because the system was hacked, or because the system was
maliciously used by a disgruntled employee.

Since we're getting down to citing Microsoft documents as a bible,
here's another "official doc" :

http://support.microsoft.com/kb/315158/

To work around this problem, use one of the following methods:

1. Create a weak account that has the correct permissions, and then
configure the <processModel > section of the Machine.config file to use
that account.

2. Set the userName attribute to SYSTEM in the <processModel >
section of the Machine.config file.

3. Configure the <processModel > section of the
Machine.config file to use an administrator account.

Note : *Allowing ASP.NET applications to run as SYSTEM or an
administrator account has serious security implications.*

*Therefore, Microsoft recommends that you use the first workaround.*

( Asterisks added by me... )

Granted, that section specifically refers to domain controllers,
because of the inherent danger in opening your domain to a
potential attack, which would net the attacker control over your
whole domain.

In the case of a box which only serves as a web server instead of a
domain controller, you'd only be giving up control over your *web server*
to a hacker, a dumb programmer, or a disgruntled employee.

Lucky you!

;-)

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
=============== =======

"Kevin Spencer" <ke***@DIESPAMM ERSDIEtakempis. com> wrote in message
news:%2******** ********@TK2MSF TNGP15.phx.gbl. ..

The "official docs" eh? Is this an "official doc?"

http://support.microsoft.com/default...b;en-us;317012

The problem with following instructions without understanding the whys and
wherefores of those instructions is that, when one encounters an
"exception" situation, one has only the instructions one has read to rely
on. It is far better to understand the whys and wherefores that spawned
those instructions, and the context in which they were given, or you might
wind up in a church where they don't allow you to wear short sleeves!

--
;-),

Kevin Spencer
Microsoft MVP
.Net Developer
What You Seek Is What You Get.

"Gerry Hickman" <ge********@yah oo.co.uk> wrote in message
news:eR******** ******@TK2MSFTN GP14.phx.gbl...

Hi Kevin,

Well, darn Gerry. Now I feel REALLY lucky! Our server has been world
facing for years. And despite all that, no problems! Not that we don't
get attacked. Just lucky I suppose...

That's good news, but in many corporations it would be a sackable
offence. It's equivalent to deliberately implementing weak security.

Actually, I'm not even sure I understand you. Are you saying your running
the ASP.NET worker process as SYSTEM, or something else? If it's the
ASP.NET worker process, it does not make any sense to me to run it as
SYSTEM. How did you achieve this? Did you use the machine.config file??

Here's an extract from the official docs:

Do Not Run ASP.NET as SYSTEM

Do not use the SYSTEM account to run ASP.NET and do not grant the ASP.NET
process account the "Act as part of the operating system" user right.
Doing so defeats the principle of least privilege and increases the
damage that can be done by an attacker who is able to execute code using
the Web application's process security context.
--
Gerry Hickman (London UK)