We have a similar situation. The alternate accounts we created are domain accounts. If you don’t use domain accounts, it will be more work because you’ll need to configure local Group Policy on every machine and hope that there are not domain ones that override the settings. Not only that, but they can use that admin account to change the local GP settings if they are savvy enough.
These are the measures that I’ve taken: - First make certain that UAC is on (default setting should be fine), or they won’t even be able to properly elevate - Create an admin account for each user and add it to a domain group - For the group that you created containing the admin accounts, deny logon interactively, over the network and via RDP. (In our case these are servers, which are VMs, and the users have no access to the console, so we didn’t have to deny logon interactively. I don’t think adding this will cause you any problems though.) - We found that one user was disabling UAC, adding his regular account to the Administrators group, etc. (He couldn’t figure out that we notice and can track down these things.) We had to take further action due to that, once we realized how untrustworthy at least one of these users could be: User Account Control Policy Setting User Account Control: Admin Approval Mode for the Built-in Administrator account: Disabled User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode: Prompt for consent for non-Windows binaries User Account Control: Detect application installations and prompt for elevation: Enabled Hide specified Control Panel items: Enabled Microsoft.UserAccounts Microsoft.ActionCenter Microsoft.DateAndTime Microsoft.DeviceManager Microsoft.NetworkAndSharingCenter Microsoft.System Microsoft.Troubleshooting Microsoft.WindowsFirewall Microsoft.WindowsUpdate Prevent access to registry editing tools: Enabled Disable regedit from running silently? Yes I would have liked to disable the Command Prompt and a few other things, but I figured they might be needed. Obviously, an advanced enough user can get around just about all of these settings, but it’s been working compared to what we had before. *From:* [email protected] [mailto: [email protected]] *On Behalf Of *Kish n Kepi *Sent:* Wednesday, March 30, 2016 8:21 AM *To:* [email protected] *Subject:* [NTSysADM] Local Administrative Privileges Hello All, I would like to give to my users, who do not have administrative privileges on their local Windows boxes, the ability to use other credentials with admin privileges so they install. So, it’s easy enough to create an admin account, however, I’d like to prevent people from actually using it to login into windows (thus bypassing my domain and its GPOs) and prevent creating a local profile (sort of like /sbin/nologin in /etc/passwd). Like this, I can restrict the use of the admin account to its intended purpose – allowing them to install, but making them jump through a hoop. Or is there a better way to lock down users but still allow them to install? Kish N Kepi
