I'd have to check, but I think that even if they tried to reset the local password to a weak password, that the policies will still apply, but I'd have to test it to be sure.
The commercial solutions have an option to allow specific users/groups to pretty much run anything you want either from a specific publisher (preferred), path, etc. Most of these solutions can force the user to indicate a reason as to why they needed the software for documentation purposes. However, I don't have much experience with this aspect, but I recall reading about it when I was looking into it. These solutions bypasses UAC so the user just gets to run the program. But I agree with Espi that you should try to avoid granting full admin access if possible. If that isn't possible, perhaps using a VM or something like Deep Freeze with isolated network access with restricted ingress and egress rules may potentially limit damage. -Aakash Shah 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
