|
|
Our Hot Pick: Rising Antivirus 2006 - Certified by TUV & Checkmark! Get 10% discount by entering this coupon code: ONDISCOUNT10
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)
|
|
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
"Matthew X. Economou" <xenophon+usenet[ at ]irtnog.org> wrote in message
news:uvecuoozk.fsf[ at ]irtnog.org...
[Quoted Text] >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)
|
|
The rights you looking for:
* Connect to computer from network
* Install software
It's not full admin. From the description, that is not required.
--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-
* http://sl.mvps.org * http://msmvps.com/blogs/sp *
"Matthew X. Economou" <xenophon+usenet[ at ]irtnog.org> wrote in message
news:uvecuoozk.fsf[ at ]irtnog.org...
[Quoted Text] >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)
|
|
|
[Quoted Text] >>>>> "SP" == "S Pidgorny <MVP>" <slavickp[ at ]yahoo.com> writes:
SP> Connect to computer from network
Is this sufficient to connect via the administrative shares (i.e.,
C$)? That's this program's only method of access to the target
computers.
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)
|
|
Yes, that is sufficient, but from what you said previously
that is not the only way as the install also gets triggered.
"Matthew X. Economou" <xenophon+usenet[ at ]irtnog.org> wrote in message
news:u4pkenr8s.fsf[ at ]irtnog.org...
[Quoted Text] >>>>>> "SP" == "S Pidgorny <MVP>" <slavickp[ at ]yahoo.com> writes:
>
> SP> Connect to computer from network
>
> Is this sufficient to connect via the administrative shares (i.e.,
> C$)? That's this program's only method of access to the target
> computers.
>
> 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)
|
|
|
[Quoted Text] >>>>> "SP" == "S Pidgorny <MVP>" <slavickp[ at ]yahoo.com> writes:
SP> Connect to computer from network
How is this right relevant? According to Microsoft
(http://technet2.microsoft.com/windowsserver/en/library/f9c9ddb9-a7bf-4b1f-a0e3-376115c066bf1033.mspx),
"EVERYONE" (or "AUTHENTICATED USERS" at least) has this right by
default. I don't see how assigning this right to my service account
will grant any additional access to member computers.
SP> Install software
I'm not familiar with the "install software" user right, and I don't
see it listed in the policy editor. Is this some amalgamation of
existing rights? From what I can tell, one must be at least a member
of "Server Operators" or "Power Users" in order to be able to copy
files into %ProgramFiles%, and one must be a member of
"Administrators" in order to access the administrative shares. (I
haven't had time to analyze the permissions necessary to register
executables with the Service Control Manager, although I assume it
requires administrator rights.)
Thanks anyway.
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)
|
|
|
[Quoted Text] >>>>> "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)
|
|
"Matthew X. Economou" <xenophon+usenet[ at ]irtnog.org> wrote in message
news:utzsdmy4e.fsf[ at ]irtnog.org...
[Quoted Text] >>>>>> "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
|
|
|
[Quoted Text] >>>>> "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)
|
|
|