RE: restricting permissions for services in Win2K

From: garberoa@WellsFargo.COM
Date: 02/20/02


From: garberoa@WellsFargo.COM
To: SecuredSite@hotmail.com
Date: Tue, 19 Feb 2002 20:59:33 -0700

Don Wolf wrote:

>The best, failsafe way to determine what rights an app or service requires
>is to simply start with "User" and test the functionality. If it works,
>then leave it at that. If not apply PU rights and so on.

Don,

While I concur with your recommendation of following the principle of least
privilege with regard to service account permissions, I find the suggested
application of the methodology to be a bit lacking. Adding an account to the
local Power Users group if it will not run as a member of the Users group is
painting with a pretty broad brush, and will probably not please internal
audit folks very much. I have far too often seen where this ends up: "It
wouldn't run unless we made it an administrator".

If the service will not function correctly as a member of the Users group,
*find out why* (check Sys/App event logs for error messages, check audit
logs for failures, run Filemon/Regmon & look for failures, consult the
vendor, etc.), then grant only the user rights & FS/Registry permissions
that are necessary to run the service.

If, after researching the issue, it has been determined that the service
will not run without a high level of privilege, you can:

a) Apply File System/Registry/System Object permissions around the account
(add account to another group, add the group with "No access" permission to
unnecessary resources).

b) See if you can get the vendor to change the software to reduce the level
of privilege required to run the service (as MS is doing with IIS 6).

c) Find a new vendor.

Best Regards,

Andrew Garberoglio, MCSE, CISSP
Wells Fargo Services, Internet Technology Services

"Let us prepare to grapple with the ineffable itself, and see if we may not
eff it after all"
-Douglas Adams

-----Original Message-----
From: Don Wolf [mailto:SecuredSite@hotmail.com]
Sent: Tuesday, February 19, 2002 3:11 PM
To: Focus on MicroSoft
Subject: Re: restricting permissions for services in Win2K

As for the service question, it is really simple. Create a new
Administrator(needs Admin) account for the Apache service to "run as". Then
simply disallow the ability for that account to login except as a service.
This would include removing the ability to "Access this computer from the
network", "Log on locally", "Log on as a batch job", etc. These settings
can be applied in the Local Security Setting console under the User Rights
Assignment folder.

The best, failsafe way to determine what rights an app or service requires
is to simply start with "User" and test the functionality. If it works,
then leave it at that. If not apply PU rights and so on.

___________________________________
 Don J. Wolf - Security Consultant
 SANS/GIAC, MCP, CCNA, ICSA
 SecuredSite Intrusion Specialists
 www.SecuredSite.org

----- Original Message -----
From: "Kevin Brown" <kbrownfox@home.com>
To: "Focus on MicroSoft" <focus-ms@securityfocus.com>
Sent: Tuesday, February 19, 2002 1:34 PM
Subject: restricting permissions for services in Win2K

> I have a question regarding the proper way to better lock down Win2K
> services. I know that IIS for example requires system level access to
run,
> and that can't be changed, or IIS won't work. But I should be able to
limit
> the privileges of other services running on my server. My question is how
> do I determine what minimum privileges are required for a given service to
> function properly? This way, if a service on my server is compromised, it
> won't give system level access to the "hacker".
>
> For example, I want to run Apache on my Win2K box. I install it, and now
it
> shows up as a service. I open the service, select the "Log On" tab. By
> default, "Local System Account" is selected. I want to change that so
> Apache doesn't have that level of control. First, do I create a new user,
> or do I use an existing one? If I need to create a new user, how do I
> determine which permissions to give Apache?
>
> My next question is do I need to ACL the Apache directory as well to
further
> lock down the application? If I need to, can I ACL it so only
> administrators, the Apache admin, and the Apache service can access those
> directories?
>
> Any insight into the proper way to do this would be greatly appreciated.
If
> I didn't explain myself clearly please let me know.
>
> Brownfox
>
>



Relevant Pages

  • Re: Prevent changes to Administrator password
    ... What I am trying to do is give Taz1972 some options to minimize the risk or make it harder for a lower-level DA to reset the password for the EA account. ... Restricted Admins group to mitigate against what you propose Deji. ... also need to make sure the DAs in question cannot elevate their rights to EA, ... > By adding the Deny Write Permissions ACE, ...
    (microsoft.public.windows.server.active_directory)
  • Re: Prevent changes to Administrator password
    ... What I am trying to do is give Taz1972 some options to minimize the risk or make it harder for a lower-level DA to reset the password for the EA account. ... * This posting is provided "AS IS" with no warranties and confers no rights! ... > By adding the Deny Write Permissions ACE, ... > permission to modify the ACL on AdminSDHolder. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Prevent changes to Administrator password
    ... * This posting is provided "AS IS" with no warranties and confers no rights! ... his/her account from the Restricted Admin group and clears the flag? ... > By adding the Deny Write Permissions ACE, ... > permission to modify the ACL on AdminSDHolder. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Error "The information store could not be opened." when openin
    ... Server without missing rights. ... I did grant additional permissions to %windir% as suggested in one of the ... account. ... OutlookSpy - Outlook, CDO ...
    (microsoft.public.win32.programmer.messaging)
  • Re: AD User Objects & Permission Inheritance
    ... I went ahead and granted the Account Operators built in group rights on the adminSDholder object according to what I want the OU admins to have. ... I went ahead and enabled inheritance on the> adminSDholder object to verify that this indeed was the cause and 60> minutes ... > later all user objects began to inherit permissions again. ...
    (microsoft.public.win2000.active_directory)