 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Windows Server Forum / Windows Server 2003 / Security / July 2007Restricting service accounts that have administrator privileges
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  Signature"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 >I have a service account with administrator rights that I would like > to restrict to just performing software installs. The account needs [quoted text clipped - 14 lines] > Best wishes, > Matthew >>>>> "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 Signature"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) >>>>>> "Roger" == Roger Abell [MVP] <Roger> writes: > [quoted text clipped - 9 lines] > 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 >>>>> "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 Signature"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. SignatureSvyatoslav Pidgorny, MS MVP - Security, MCSE -= F1 is the key =- * http://sl.mvps.org * http://msmvps.com/blogs/sp * >I have a service account with administrator rights that I would like > to restrict to just performing software installs. The account needs [quoted text clipped - 14 lines] > Best wishes, > Matthew >>>>> "SP" == "S Pidgorny <MVP>" <slavickp@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 Signature"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. >>>>>> "SP" == "S Pidgorny <MVP>" <slavickp@yahoo.com> writes: > [quoted text clipped - 6 lines] > Best wishes, > Matthew >>>>> "SP" == "S Pidgorny <MVP>" <slavickp@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-3 76115c066bf1033.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 Signature"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) 1. It is relevant. Connect from the network is for accessing CIFS resources and IPC$. It is relevant - you can restrict that so only admins can access remotely. That is the default for terminal services but not for CIFS. 2. Yes. SignatureSvyatoslav Pidgorny, MS MVP - Security, MCSE -= F1 is the key =- * http://sl.mvps.org * http://msmvps.com/blogs/sp * >>>>>> "SP" == "S Pidgorny <MVP>" <slavickp@yahoo.com> writes: > [quoted text clipped - 22 lines] > Best wishes, > Matthew HI Mathew, Did you want to restrict the service accounts, or determine a character of service account that works (make them admin on their machine) ? The inital segment of posts clarified how to do what you were trying to make work, which restricted services to accounts with admin rights on the target systems. Highly likely only some few of the privs covered by admin are needed. It is convenient to use a svcacct group to carry the grants on the target systems, and the service accts bear the character of that group in place of admin. Roger >I have a service account with administrator rights that I would like > to restrict to just performing software installs. The account needs [quoted text clipped - 14 lines] > Best wishes, > Matthew |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2010 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.