You really should consider restricted groups for the very last part of your question. It won't prevent them from elevating and adding their account, but it will remove their added account when the GP refreshes (90 minutes, or less if you change it for these machines).
I would also ask, do they need to run mmc at all for the tasks they are doing? If not, you could set it up with domain accounts that are local admins on those machines, and then block mmc from running using group policy on those accounts. You can also allow mmc, but set a list of allowed snap-ins and keep that one excluded. If it's a domain account, you could just create a domain group those "admin" accounts are members of, use that in your restricted groups policy, and apply only to the computers that need it. If you truly need local accounts (ie, they have to edit network settings when not connected), then you probably just want to stick with RG and not try blocking mmc as it would apply to all users that log on. From: [email protected] [mailto:[email protected]] On Behalf Of Freddy Grande Sent: Thursday, March 26, 2015 12:03 AM To: [email protected] Subject: [NTSysADM] RE: Local Administrators on computers Thanks for the prompt reply. I'll have a look at what the commercial solutions offer. I'm going to trial using Group Policy Preferences in the meantime rather than Restricted Groups as they're a bit more granular and I can use just one GPO to target different computers using Item-Level Targeting. I'll apply the password policy to the computers too, hadn't thought of that, like you said though, they can still get around this by opening up an elevated Computer Management console and resetting the user account password, right? At least you can do that as a Domain Admin to set your own domain account to a reused password or a weak password... How do the applications get around elevation? The users in question need to constantly install new software/tools to monitor different types of hardware provided by various vendors... it's quite a nightmare trying to maintain a whitelist for them. Funny you mention the elevation about the Browse window. 10 or so years ago I'd use that trick to launch an elevated Command Prompt from where I could launch games or Opera from my USB drive and browse unfiltered game sites at school :P Freddy From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Aakash Shah Sent: Thursday, 26 March 2015 4:13 PM To: [email protected]<mailto:[email protected]> Subject: [NTSysADM] RE: Local Administrators on computers Local accounts can be referenced in the Restricted Groups section in GP - just don't specify a prefix, i.e. rather than specifying something like "domain\user", just specify "localuser". I once did something similar for a small project where I created the local accounts with the same username, but with different passwords. This allowed me to target this account in policies. You can then use this to restrict other things like access from the network, RD access, etc. But it is not a foolproof solution and a knowledgeable user can get around this. To prevent weak passwords, set the password policy to apply to the computer object. So right now, if your password policy is only applying to the DCs, have it apply to either the OU with these computers, or the entire domain, and this will apply the settings to local accounts too. However, I would ask what the local admins rights are needed for? Since the time I worked on the project I referenced earlier, I have come across software solutions that can help with this. A free example is Sudowin<http://sourceforge.net/projects/sudowin/>, but the problem with it is that if you happen to allow a program that has a Browse window, the Browse window also opens elevated, and a knowledgeable user can use that to get into the computer. There is commercial software that can help: for a small unit that had some special requirements, we purchased AppSense Application Manager. The nice thing about many of these commercial products is that while they can allow an application to be elevated, you can still choose to prevent elevation from the Browse window. If you happen to look this up, look for "privilege management" solutions. -Aakash Shah From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Freddy Grande Sent: Wednesday, March 25, 2015 10:39 PM To: [email protected]<mailto:[email protected]> Subject: [NTSysADM] Local Administrators on computers How does everyone handle users needing local administrator rights? We have some field users that require local admin, at the moment their domain accounts have local administrator rights on their computers, however, this can be dangerous if they run everything as admin. I've been wanting to create local admin accounts on computers that require it, set a unique password to these and deny local/interactive logon so they are only to be used for elevation. Ideally all of this should be controlled through GPO or similar method to prevent users changing passwords to something weak. I'm not finding an easy way to refer to local accounts in GPO though so I'm thinking scripting is going to be the only way to go... any thoughts or ideas? Bonus: how would you prevent a user from launching an elevated Computer Management console and adding their domain user accounts to the Administrators group? Freddy
