| Roger Abell [MVP] 2007-04-17, 1:18 am |
| Prior to IIS 5 instead of Iusr_ and Iwam_ I could define a machine
local group, used for no grants whatsoever, and make the accounts
used to replace Iusr_ and Iwam_ members of this no-grant local
group and of it alone. Interactive not a member of Users, so the
run token of the accounts were totally without grants except to the
content served, and it worked. I was happy. That fit with the model
I was used to with non-Windows web servers, and the runtime account
was clearly and well constrained.
Of course, one cannot do that now (nor in IIS 5 ;-( ).
I still attempt to make sure that the runtime accounts are
as least privileged as possible and yet do what they need.
The practice of solving problems by granting admin is symptomatic
of either an intractable problem or a problem of insufficient staff skill
and/or time. They should solve the problem, rather than covering it up
by creating a larger (potential, future) problem.
If it worked previously with a Users member account, then it should
still be able to do so. If it cannot then one should find out why and
get that part rearchitected. IIS has been good in not having security
vulnerabilities, but the quality of what it is hosting is beyond the control
of IIS. If the applications provided by the IIS server get subverted, then
the account used is made available. The most limited account is what
one should provision in order to defensively configure the server so
that it mitigates impacts in the event that a risk factor gets actualized.
Roger Abell
--
Microsoft MVP (Windows Server, Security)
<Paulaner> wrote in message
news:lsu623hegv5tv144v6r4i50fgoqhsdjhr1@
4ax.com...
>
> We have a web application that uses asp pages and javascript to
> display information to users. We want the data to be secure, so the
> login page will redirect http:// users from port 80 to https:// on
> port 443. We prompt for a username a password, then use an isapi
> filter to authenticate them with our database.
>
> The service team got a report about some trouble with this website, so
> they changed the anonymous account logon from IUSR_computername to a
> local user account in the administrators group. This has fixed their
> problem, but I am concerned that they just opened a security hole.
>
> The only reference to this issue I can fine in technet is this
> comment: "If you use an account other than IUSR_computername for
> anonymous access, choose the rights you assign to it very carefully. "
> from http://msdn2.microsoft.com/en-us/library/ms951775.aspx
>
> Can anyone point me to some documentation that says "don't do this",
> or give me some sufficient ammunition to convince them to undo this
> action and appropriately repair the root cause of their issue?
|