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.

 

[James Steele]

Hi Zeng,

You can learn how to create custom accounts to run ASP.NET at the following
link.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secmod/html/secmod15.asp

Good luck!

 

[Kevin Spencer]

Somebody's going to find a whole bunch of old posts exactly like yours,
thanks to cross-posting! ;-)

If you own the server, the simplest way is to edit the machine.config file
in your .Net config folder, and change the ProcessModel section to use
"SYSTEM" instead of "MACHINE".

--
HTH,

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

 

[Guest]

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

 

[Juan T. Llibre]

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.

 

[Kevin Spencer]

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

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]

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 :

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

 

[Kevin Spencer]

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

 

[Guest]

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]

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.

 

[Guest]

April 6, 2005

I'll repeat what I said in my first post... Sorry for my abruptness!


Joseph MCAD

 

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

 

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

 

[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

 

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

 

[Kevin Spencer]

I feel luckier with every post...

--
;-),

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

 

[Gerry Hickman]

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]

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.

 

[Kevin Spencer]

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

http://support.microsoft.com/default.aspx?scid=kb;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.

 

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

;-)