| Paulaner 2007-04-17, 1:20 pm |
| Good advice. Thanks.
This issue is symptomatic of service people that are measured on how
fast they can repair a problem, but not how well it is repaired. I'm
going to try and find out how this 'workaround' got approved, and make
a arduous training process to teach them the importance of proper
process. :} (evil grin).
On Mon, 16 Apr 2007 22:34:15 -0700, "Roger Abell [MVP]"
<mvpNoSpam@asu.edu> wrote:
>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
|