Hi All, I am very new to this forum and have limited technical knowledge of Windows (and Windows Security), so please bear with me. I have a Project Manager (PM) who is proposing to add users to the 'Local Administrator' group. The justification, risk and mitigation controls I have received are enclosed below. I am very uncomfortable with this proposal and would very much appreciate your response to the following question: Is there any way we can achieve all the outlined 'benefits' without adding users to the 'Local Admin' group. Further, please feel free to comment on any other aspects of the PMs proposal. Thank you very much in advance for your assistance. (from an educational institute) --------------------------------------------------------------- The recommended benefits for this change include the following: 1. To install non-standard hardware 2. Install non-standard, or personal software 3. To install printers at other sites (home conference sites etc) 4 Users can run poorly written software that requires Administrative access to operate. This change has disadvantages: 1. A virus or worm could cause increased damage if it is run be a user in the elevated privileges account. 2. Staff logging into a local workstation, will be able to take ownership of personal files on the local hard disk, and see potential private information, that they normal could no access. 3. Nefarious staff could delete event log data, in order to cover up suspect behaviour. 4. Staff could make multiple local accounts for third parties, who are not managed centrally. 5. Staff will be able to access other staffs backup Outlook .pst files which will be stored on the d: drive. To mitigate the risks involved in this reduction in security, the following changes to the desktop will be implemented. 1. Only allow users to be an Admin on the current workstation they are logged into, the will not have admin access across the network to other workstations or server s. 2. Use and enforce the use of User Account Control (UAC), this will pop up an approval window, anytime a user initiated action is trying to execute with administrative privileges, Further UAT will be configured to Auto escalate (or popup the window asking if the user wants to run as admin) a. Windows executables b. Fully signed programs, that are in the Program files sub directory c. Fully signed program installers All other types of applications will require the user to right click and specifically choose to run it as an Admin users. Until a user escalates, 3. Use folder redirecting, and encrypted client side caching, this means only the owner will be able to see unencrypted client side files. This will minimise the number of personal documents that users can see 4. The rights for local Admins to "manage auditing and security logs" will be removed via group policy, and allowed only by an approved central security group. 5. This cannot be mitigated 6. The right to take ownership of files or other objects, will be removed from the local administrator group It is recommended, that taking all the benefits, disadvantages and mitigations plan into consideration, that the board approve escalating the Staff accounts to be members of the local administrators group.

"recommended benefits for this change include the following:" 1) Tell your PM he/she is misguided. There is no Local Admin account required for installing hardware, installing the software & the drivers that the hardware might use though is a different question & to that end I would recommend having this done by using deployment tools or deployed through Domain GPO's rather than allowing for any odd user to perform ad-hoc drive & periphel changes to their system. If you want to allow (non technical) people to tinker with their hardware, have fun supporting it. If you're going to manage the system, you might as well have policies that ensure the consistency of the systems you're going to support. 2) I wouldn't advise allowing them to install anything they want, try to create a whitelist for approved applications & make them adhere to it. Software not on the whitelist cannot be installed & must be approved first. 3) Deploy printers using GPO's & I don't think there is a Local Admin requirement to assigning or setting up a shared network printer. 4) Running poorly written code = system instability = massive headaches. Go ahead, let them run alpa & beta code & when something doesn't work as advertised & they ask you to fix it & don't tell you it's beta have fun. Running beta code in a dev envirionment is one thing, allowing any and all users to install anything they want regardless of support, versioning, compatibility, etc. just sounds foolish. "This change has disadvantages:" 1) malware & viruses should be enough of a reason to not want to allow users to have Local Admin access. Seeing as you've mentioned using GPO's, you should be able to create security groups to control access so they can perform their normal tasks while not being a local admin. 2) Then don't share the systems between users. If you're going to share the systems between multiple users & don't want one of them to access the data of another, then no you don't want to allow one or both of them admin level acccess. 5) then move the Outlook.pst files (archive) to a network or server that the Local Admins don't have access to. Not really a great solution as they can be quite large, but in your situation you seem to allowing users to share systems which different users are having their local email stored. (sounds like a PCI violation waiting to happen...) "To mitigate the risks involved in this reduction in security, the following changes to the desktop will be implemented." 1) Allowing users to be members of the Local Admins would still allow them to install SW, thus potentially they could be the weakest link in your corporate network as they install SW which lets hackers gain access to their system & those on the corporate network. 2) UAC is NOT a security boundary. If you have a user which downloads and runs a virus UAC will likely promp them to open & execute the code, but it will not prevent them from running it. http://www.zdnet.com/blog/security/russinovich-malware-will-thrive-even-with-vistas-uac/175