Vielleicht koennen die folgenden Erklaerungen von Scott Guthrie (von
dotnet.framework.aspnet) helfen. Sie sind in jedem Fall sehr
interessant:
------------------------------------------------------------------------
----
There was one important security change between ASP.NET Beta2 and RTM
that
you should watch out for when upgrading to the final bits.
Specifically, the default Windows Account under which the ASP.NET worker
process executes was changed from running as "LocalSystem" in Beta2 to
instead run under a more restricted "ASPNET" account (which we
automatically
create during install).
Making this change reduces the capabilities of code running within
ASP.NET.
Specifically, it means that .aspx files no longer run with local
administrative permissions. The helps improve the overall security of
the
system by eliminating the ability of a remote hacker to exploit any
security
holes on the server and then execute code under an administrator
identity to
maliciously hack the system.
What this change also means, though, is that because ASP.NET code is now
running with reduced permissions on the system, administrators will now
need
to explicitly grant the ASPNET account security ACLs to use certain
Windows
features.
If appropriate ACLs are not set when attempting to use a resource, an
"access denied" exception will most likely be thrown at runtime (in some
shape or form depending upon the feature you are attempting to use).
Whenever you see one of these types of errors when running on the RTM
bits,
the first thing you should investigate is what resource that page or
code
was trying to execute -- and then whether the "ASPNET" account has ACL
permissions to use that resource and perform those operations. If the
ASPNET
account doesn't have access -- then you'll need to either grant the
ASPNET
account access to it, or alternatively modify the account the ASP.NET
worker
process runs under (for example: by changing back to LocalSystem). Note
that
you can change the account used within the <processModel> section of the
machine.config file.
The most common case where you will probably find that you now need to
grant
ACLs is with file-system disk access. Two scenarios to explicitly watch
out
for:
All File System Write Scenarios
--------------------------------
By default the ASPNET account only has access to read files from disk --
and
not to write to it. If you have a file (for example an XML text file)
that
you are writing to from an ASP.NET application, then you will need to
make
sure to grant the "ASPNET" account write access to either the individual
file, or the directory it is in. To do this, simply right-click the file
or
folder using the file-system explorer, click the security tab within it,
select or add the "ASPNET" account from the users list, and then click
the
appropriate checkboxes below to grant write access for the account.
Some File System Read Scenarios
--------------------------------
By default the ASPNET account does have access to read the disk
(especially
for everything under Inetpub). However, on some servers that have been
locked down prior to installing ASP.NET, you might find that an
administrator has denied read access to all but a chosen few users. In
this
case you will probably see an error (possibly a "access denied" or "file
change notification monitor failed to start") the first time you hit an
ASP.NET page on a newly installed system. This is because ASP.NET isn't
able
to read from the disk of your web directory to either open/execute a
.aspx
page -- or ev�{�w�� ]�
�XC/
���en to examine the web.config file.
To fix this, simply right-click the Inetpub directory (or whatever your
web
root directory is) using the file-explorer, click the security tab
within
it, select or add the "ASPNET" account from the users lists, and then
click
the appropriate checkboxes below to grant read access for the account.
Note that every web directory higher than your application root will
also
need read access for the ASPNET account (this is a gotcha to watch out
for).
So for example, if you have a "foo" application on your server:
"http://localhost/foo"; -- you need to make sure that the "foo"
application
directory has read permissions for the ASPNET account, as well as the
"Inetpub" directory (which is the logical parent directory of the
application) as well. We've seen a few (albeit rare) situations where
admins
have locked down the Inetpub directory -- and these can potentially lead
to
confusing error messages if you forget to check these security ACLs when
deploying your application.
Some other scenarios to watch out for
--------------------------------
A few other scenarios that will now require explict ACL permissions to
be
set in ASP.NET RTM (but didn't in beta2):
-- Creating new EventLog categories dynamically
-- Creating new PerfMon categories dynamically
-- Sending email using the NT SMTPMail Service
-- Using WMI (System.Management)
-- Registering COM+ components (System.EnterpriseServices)
-- Reading the Registry or IIS Metabase
-- Reading Active Directory (with System.DirectoryServices)
We will shortly be posting a whitepaper that walks through how to
perform
each of the above steps. We will post a link to it from
http://www.asp.net.
Thanks,
Scott
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Christoph
Wille
Sent: Thursday, January 17, 2002 1:53 AM
To: aspDEdotnet
Subject: [aspdedotnet] Re: Authentication
>wie sehen die ACLs auf die ASPX-Seite aus?
�hmm, wie ich schrieb: lokaler Administrator full control, sonst
niemand,
keine Inheritance.
>Da ASP.NET jetzt bunter ASPNET Account l�uft sollte man das mal
�berpr�fen ...
ich habe dem ASPNET Account auch schon "act as part of the operating
system" gegeben, sowie das processModel auf SYSTEM umgestellt - nichts
hat
geholfen.
Chris
| [aspdedotnet] als [email protected] subscribed
| http://www.dotnetgerman.com/archiv/aspdedotnet/ = Listenarchiv
| Sie k�nnen sich unter folgender URL an- und abmelden:
| http://www.dotnetgerman.com/listen/aspDEdotnet.asp
