As an InfoSec consultant I had confronted and I am sure that many of you might have faced the question from your clients or within your organization that “‘to provide’ or ‘not to provide’ Local Admin privileges to users”.
Indeed, it is a tough question to answer and even tougher to convince anyone to take a certain approach in this regard. Reason being, I feel, it is impossible to get away with any one approach. Again in my view, if given a chance, I would prefer to go with the approach of not providing administrative privileges, unless I have been provided with enough personnel, technology and time to handle the mess created by this action.
In this brief, I am not considering various or different ways of requests being made by users and their power or political tactics for getting local admin privileges on their systems. Also, I will not discuss the operations part of handling the same. Instead, I would stick to the adverse aspects of providing admin privileges to users and the solution I can think of.
Let me explain you what makes me to go with this kind of approach.
First of all let’s see what the issues, risks are and associated impacts of providing the local admin privileges to users.
Issues
- Because of their inherent permissions, the admin accounts on computers are both the most useful and the most dangerous accounts that exist on them.
- In some situations admin privileges are necessary to perform certain activities which cannot be achieved with normal user privileges.
- Some users demand IT staff to provide the admin access, they even sometimes threaten, that they can not carry on their activities with out admin access.
- In some cases some users in higher positions or roles would be provided with admin privileges by their IT Staff to delight them, though the senior executives does not need that kind of privileged access.
- Users who are granted with administrative access might inadvertently cause problems because they fail to understand the ramifications of configuration changes.
Risks
Now, coming to some of the risk areas and associated impacts that I can foresee;
- With admin privileges users will have full access to system files, so there is a possibility of been effected by virus or spyware/malware and that spreading to the entire network.
- When users, log on to a system as an administrator and unknowingly visit a harmful or malicious website, this action might result in downloading malicious software like Trojans and key loggers to their machine. This can go unnoticed, which in turn may spread to the entire network.
- If users login with admin privileges, malicious codes, among other things, can reformat the hard disk drive, delete files, install backdoors, Trojans, steal information and create a new user account with administrative privileges.
- Users can install unauthorized software on their machines which results in licensing issues and software piracy.
- Users with malicious intent, with admin privileges can steal the hashes (encrypted passwords present in the system) of other users who has logged on to their system or has account created on their system. It is also possible that, if lucky, they might get the hash of Domain Admin. Just imagine the magnitude of resultant risk of this particular act.
- In some organizations it is a practice that all the systems in the LAN will have a common password for local admin account. In this scenario, if a user can get the hash of his/her system, he/she can access any system in the LAN. The worst is, if the organization also has a practice of adding domain admin to the local admin group.
Above mentioned risks justifies, why I have chosen the second approach of not providing admin access to users. In fact, I have mentioned only a few. I am sure that you guys have some more to add to the list.
Ok, let’s assume that, we were not able to convince the requestor in taking the second approach. So, unfortunately, it is our job to provide a solution, if he/she chooses to go with the first approach.
One of the solutions that I could think of is as mentioned below. I request others who read this post to come up with their thoughts.
Solution
Create two ID’s for the user, first being the normal domain user ID with which users performs his/her day to day activities. Second, privileged ID with local admin privileges.
Normal ID should be used for users’ day to day activities and should comply with organizations security policy or standard. The privileged ID, which is also another normal ID with different name, would be provided with ‘Local Admin Privileges’ on users system and should be used for those activities which requires privileged access.
IT Staff, by applying policies, should not allow users to use their privileged ID on any system other than their own. Continuous monitoring of the usage of the privileged ID should be made. IT Staff should maintain the up to date inventory of the issued privileged ID’s.
Approval and Agreement
- Before providing the approval, IT or Security staff needs to vet the request thoroughly, if possible advise users with alternative solution that may not require the privileged access.
- User needs to get the approval from their senior executives, at least 3-4 levels above him/her and also from IT Security team.
- The privileged access should never be provided for unlimited period. There should always be a start and end date for the usage of the ID.
- User requesting for privileged ID must sign a contract stating that he will not misuse it. At a minimum, the below mentioned points should be a part of the contract.
- User should not use the privileged ID to perform his day to day activities like checking email and browsing internet.
- User should be notified that, a minimal technical help or support on his/her system will be provided, in case the system is down or malfunctioning, tech support shall not spend more than 20-30 minutes on the system, if not rectified by then, system shall be formatted.User should be notified that, all his activities will be monitored closely.
- User should attend a short training on Do’s and Do not’s of using privileged ID.
The above mentioned clauses and stringent approval process acts as deterrent control on users.
#1 by razdan khan on January 6th, 2009
Quote
Excellent writeup.If I may add one suggestion on regulating the local admin privileges..
In case the user requires local admin privileges to running an application,the same can be done by creating a shortcut for the program to be run with Runas Command.
Syntax being : Runas /netonly /user:domain\testuser c:\windows\system32\mmc.exe from the command line or the Runas prompt from the GUI.
Further if a service requires to be started with admin privileges,the option is always there in the services.msc menu under the logon tab.
#2 by Twinkle on December 7th, 2011
Quote
This is very true. I like the arguments given for both the issues and risks. But for most companies and their networks, I believe that the issues are nothing compared to the risks. Limiting admin access is advisable.