Restricting service accounts that have administrator privileges

Restricting service accounts that have administrator privileges
Secure Home | Search | About
Login Password
Register Now! Lost Password?
 General Computer Security    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content add this group's latest topics to your Google content
Subject Author Date
Restricting service accounts that have administrator privileges Matthew X. Economou 07-08-2007
Posted by Matthew X. Economou on July 8, 2007, 12:10 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
I have a service account with administrator rights that I would like
to restrict to just performing software installs. The account needs
to be able to copy files to the administrative shares on the target
computer (servers and workstations), then execute the setup program
via RPC. Once installed, the software will run as a service in the
LocalSystem security context.

How might I restrict the rights afforded to this service account? I
realize that remote software installation is sufficient to compromise
a computer, but I'd like to know if there's anything I can or should
do to restrict what this account can access. (I'm probably better off
using a different method for software distribution, but in this case,
I am using a network-based discovery program to find computers that
aren't running this service, and once discovered, the program pushes
the service out to them using this account.)

Best wishes,
Matthew

--
"Rogues are very keen in their profession, and know already much more
than we can teach them respecting their several kinds of roguery."
- A. C. Hobbs in _Locks and Safes_ (1853)

Posted by Roger Abell [MVP] on July 8, 2007, 2:26 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
Hi Matthew

I am thinking that there is pretty much nothing you can do.
Since the account does need access to an unpredictable set
of machines, and needs to be able to install there, unless you
can make the remote install happen without admin and without
the copy to admin share on install target it is pretty hard to see
how you can restrict the account used.
You could of course make some plain Domain User (not member
of Domain Admins) member of Administrators of all members of
the domain, and that would itself be a big plus (not using Domain
Admin account). But to be able to do this without Administrators
membership on the targets is really a matter of how the install
sets things up.

Roger

>I have a service account with administrator rights that I would like
> to restrict to just performing software installs. The account needs
> to be able to copy files to the administrative shares on the target
> computer (servers and workstations), then execute the setup program
> via RPC. Once installed, the software will run as a service in the
> LocalSystem security context.
>
> How might I restrict the rights afforded to this service account? I
> realize that remote software installation is sufficient to compromise
> a computer, but I'd like to know if there's anything I can or should
> do to restrict what this account can access. (I'm probably better off
> using a different method for software distribution, but in this case,
> I am using a network-based discovery program to find computers that
> aren't running this service, and once discovered, the program pushes
> the service out to them using this account.)
>
> Best wishes,
> Matthew
>
> --
> "Rogues are very keen in their profession, and know already much more
> than we can teach them respecting their several kinds of roguery."
> - A. C. Hobbs in _Locks and Safes_ (1853)



Posted by Matthew X. Economou on July 9, 2007, 10:48 am
If you were  Registered and logged in, you could reply and use other advanced thread options
>>>>> "Roger" == Roger Abell [MVP] <Roger> writes:

Roger> You could of course make some plain Domain User (not member
Roger> of Domain Admins) member of Administrators of all members
Roger> of the domain, and that would itself be a big plus (not
Roger> using Domain Admin account).

Thanks. I think that's a better idea than dropping this account into
"Domain Admins". I'll handle deployments to domain controllers
manually, since there's only a few of them relative to the rest of the
organization and since I'm keen to avoid granting administrative
rights to them. Besides, I've been meaning to implement restricted
groups for some time now, so this gives me additional incentive.

Best wishes,
Matthew

--
"Rogues are very keen in their profession, and know already much more
than we can teach them respecting their several kinds of roguery."
- A. C. Hobbs in _Locks and Safes_ (1853)

Posted by Roger Abell [MVP] on July 9, 2007, 9:44 pm
If you were  Registered and logged in, you could reply and use other advanced thread options

>>>>>> "Roger" == Roger Abell [MVP] <Roger> writes:
>
> Roger> You could of course make some plain Domain User (not member
> Roger> of Domain Admins) member of Administrators of all members
> Roger> of the domain, and that would itself be a big plus (not
> Roger> using Domain Admin account).
>
> Thanks. I think that's a better idea than dropping this account into
> "Domain Admins". I'll handle deployments to domain controllers
> manually, since there's only a few of them relative to the rest of the
> organization and since I'm keen to avoid granting administrative
> rights to them. Besides, I've been meaning to implement restricted
> groups for some time now, so this gives me additional incentive.
>

And, assuming all of your machines are post-NT4 and at current
service pack, then they will all support use of the Member-Of list
of a restricted group definition to add you custom domain group
to the local Administrators group without otherwise changing the
membership in those Administrators groups (since that membership
usually does need to vary some from machine to machine).
http://support.microsoft.com/kb/810076



Posted by Matthew X. Economou on July 10, 2007, 2:12 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
>>>>> "Roger" == Roger Abell [MVP] <Roger> writes:

Roger> ...they will all support use of the Member-Of list of a
Roger> restricted group definition to add you custom domain group
Roger> to the local Administrators group without otherwise
Roger> changing the membership in those Administrators groups

Oh, that's quite handy. I manage several organizations where our
standard security groups aren't always in the local Administrators
group. I considered writing a computer startup script that would make
the requisite changes, but I like this a lot more.

Best wishes,
Matthew

--
"Rogues are very keen in their profession, and know already much more
than we can teach them respecting their several kinds of roguery."
- A. C. Hobbs in _Locks and Safes_ (1853)

Similar ThreadsPosted
HPSBMA02385 SSRT080161 rev.1 - HP Service Manager (HPSM), Gain Extended Privileges November 12, 2008, 2:21 pm
HPSBUX02332 SSRT080056 rev.1 - HP-UX running Apache with PHP, Remote Denial of Service (DoS), Gain Extended Privileges May 6, 2008, 10:17 am
HPSBUX02332 SSRT080056 rev.2 - HP-UX Running Apache With PHP, Remote Denial of Service (DoS), Gain Extended Privileges May 19, 2008, 6:30 pm
HPSBUX02153 SSRT061181 rev.2 - HP-UX Running Firefox, Remote Unauthorized Access or Elevation of Privileges or Denial of Service (DoS) November 30, 2006, 3:15 pm
HPSBUX02153 SSRT061181 rev.3 - HP-UX Running Firefox, Remote Unauthorized Access or Elevation of Privileges or Denial of Service (DoS) March 6, 2007, 6:26 am
HPSBUX02156 SSRT061236 rev.2 - HP-UX Running Thunderbird, Remote Unauthorized Access or Elevation of Privileges or Denial of Service (DoS) March 21, 2007, 2:29 pm
HPSBUX02153 SSRT061181 rev.4 - HP-UX Running Firefox, Remote Unauthorized Access or Elevation of Privileges or Denial of Service (DoS) July 23, 2007, 10:16 am
HPSBUX02153 SSRT061181 rev.5 - HP-UX Running Firefox, Remote Unauthorized Access or Elevation of Privileges or Denial of Service (DoS) September 4, 2007, 10:21 am
HPSBUX02156 SSRT061236 rev.3 - HP-UX Running Thunderbird, Remote Unauthorized Access or Elevation of Privileges or Denial of Service (DoS) September 4, 2007, 10:23 am
HPSBUX02156 SSRT061236 rev.4 - HP-UX Running Thunderbird, Remote Unauthorized Access or Elevation of Privileges or Denial of Service (DoS) January 8, 2008, 7:59 am

The site map in XML format XML site map

Contact Us | Privacy Policy