Why you should remove local admin permissions

If you ever administrated a corporate domain environment, you will inevitably will have come across users who will have requested elevated access at some point in your career. While permitting someone to have local administrative rights does not immediately cause havoc across company systems and networks, it starts to open up a multitude of damaging possibilities such as malware infections, network intrusions and other illegal activities. These possibilities do not necessarily need direct user intervention to launch, as browsing the wrong website, clicking an email link or installing a well-known application can also be attack vectors.

Consider a seasoned IT user – this user might install a new version of a popular application, especially if the application is generally considered to be trusted. What if this new version might have been compromised  and now installs a persistent backdoor to the network? What if ransomware is launched from here, or the infection pivots across the network or even if the backdoor is being auctioned on the black market? Who is accountable?

So, the concept here is not to block all application installations in the company, but to proactively restrict who can install them. This is one of the ways we can achieve a key IT security concept known as Least Privilege.

The following is an excerpt from Microsoft’s Administrator Security Planning Guide:

Most security-related training courses and documentation discuss the implementation of a principle of least privilege, yet organizations rarely follow it. The principle is simple, and the impact of applying it correctly greatly increases your security and reduces your risk. The principle states that all users should log on with a user account that has the absolute minimum permissions necessary to complete the current task and nothing more. Doing so provides protection against malicious code, among other attacks. This principle applies to computers and the users of those computers.

What are local administrator permissions/rights?

Local admin permissions are privileges assigned to a user on a workstation that grants power to the user to practically do anything they want on the system. This includes installing any application, changing any setting, circumventing corporate security rules and bypassing IT administrative policies.

Reasoning behind prohibiting local administrative rights

• Protect the company’s public profile
• Protect the company’s data (including customer data or intellectual property)
• Protect the individual (who may have local admin rights)
• Protect IT systems and networks
• Prevent downtime or availability issues of data or corporate services
• Implement best practice procedures
• Implement consistent and efficient management of company systems
• Reduce corporate risk
• Reduce area of attack surface

Proactive approach to local administrator requests

It would be prudent to consider proactive approaches to tackle local administrator requests before they happen. This would infer that you should construct a Local Administrator Privileges Policy with all the constraints you require to secure your company’s systems and networks, and then getting executive approval/sign off. This will help protect you against any arbitrary and/or unnecessary local administrator requests and permit you to revisit older assigned permissions.

Reasons To Prohibit Local Admin Accounts

Legal compliance
While prohibiting local admin access may not be directly a legal compliance issue, it may become one if a user decides to install illegally obtained software leading to legal issues with the app vendors or unaware to the user where they install an application that launches some malware/spyware that eventually leads to data theft/public dumps of customer/client information or criminal acts operated via the infected machine. This could lead to the company suffering damaging negative public exposure or potential litigation actions against the company.

IT best practice
There is no single list of agreed best practices which is probably due to the varied nature of IT environments. However, one principle concept does exist in practically every security best practice – Least Privilege. Least Privilege is where you enforce the absolute minimum permissions required for the user to perform their role.This ensures that the users can complete their tasks without the possibility of compromising elements of systems or networks that the user should not have access to.

So, by removing local administrator privileges we are applying the principles of Least Privilege. There are of course exceptional circumstances where the user will require some degree of administrative control but I hope to cover that in the mitigation section below.

Efficient IT management
If the only applications that exist in the environment are installed by IT, then this means that the IT Department can control applications on their own white-listed basis. In this scenario, only pre-approved applications will be installed; approved applications are defined as such after undergoing sufficient testing on particular software versions. The scope of the testing will include system compatibility and security. This will ensure efficiency as trusted application updates can be pushed out via GPO (or similar) and IT can be safe in the knowledge that the applications in the wild have been tested.

Prohibit application installation
You never really know what the application you just installed is doing in the background. The free version of the zip file manager you just downloaded could have had its download location compromised and replaced with malicious version of the valid application, or it could be bundled with additional malicious apps in the installer or it could even have have deliberate backdoors in the application leading to instant system and/or corporate network access. Granted – if we are talking about open source software, you could download the open source code, recompile and then install but this is not necessarily the done thing in SMEs – after all, this will take a huge amount of resources, time, staff and skill to implement.

In an ideal world, the only applications that should be installed should be IT approved applications. The only true way to ensure that only these applications are installed is by involving IT in the process, preferably though an auditable helpdesk ticket system request. The scope of this scenario does not just apply to applications but also to plugins, addins, codecs, drivers and even fonts.

Prevent malicious code infecting systems or replicating through the corporate network
As touched on above, malicious code can arrive in a variety of ways; it can come as part of applications, bundled with application installers, in email/IM attachments or links, websites, and website advertisements.  Not all malicious code requires persistence (eg. ransomware) but the large majority will require some form of administrative control to persist in the affected system.

The idea here is to prevent malicious code from gaining a persistent foothold on the affected system. While there are absolutely exceptions to the rule, most malicious applications will get installed under the running user account. So, if the user account is a local administrator – then the malicious application can use these privileges to persist the infection so it can run its own code, infect the registry/file system, rootkit the machine, backdoor the system, stars on the next computer boot up, or so it can bind to other valid processes. Whereas, if the user is a regular user, then the malicious code is restricted the user space it is operating under. It is worth noting that there are privilege escalation techniques that can allow malicious code to bypass UAC but these are dependent on known system vulnerabilities (mitigated by updates), incorrect configuration (mitigated by staff training) or by zero day attacks (not easy to mitigate but can be considered uncommon if other security considerations are in place). Remember, anti-virus products will not have viral definitions in place to prevent zero-day attacks as none will exist.

Protect against disgruntled or technologically-unsure staff
Consider a disgruntled staff member who is with the company or even scheduled to leave the company at a future date, or consider an employee who is aware that using application X will permit the user to achieve objective Y but does not know which application download location is safe – what’s to stop the user from installing software that could:

• Use company network bandwidth illegally (eg. Torrent clients to download movies)
• Copy sensitive customer data from the network to a cloud provider (eg. Dropbox, Google Drive)
• Compromises the security of the system and/or the company network (eg. Resume building application that contains ransomware variant)
• Permit future remote access (eg. Teamviewer)
• Permit the user to play games or other technologies that will negatively affect the company network bandwidth

Potentially Valid Local Admin Scenarios

There may be some valid scenarios where users may require a higher degree of control to complete their role in the organisation. These scenarios will differ from company-to-company. Before granting access, time should be taken to understand why the users require this access; you should investigate to see if there are ways to resolve their request without needing to change user rights.

Potential scenarios include:

(a) Software developers may require some degree of administrative control to help deploy various solutions in helping them to build/debug software.

(b) Engineers in the field who may require administrative control over the computer’s network interfaces or system/config files – they may be in areas with no network access so remote support is not an option.

Local Administrator Account Alternatives & Mitigations

In some cases, you might have no choice but to consider alternatives. You may be over-ruled at executive level or there may be genuine business case scenarios where local administrative rights are to be granted.

Some options that could be provided as alternate solutions include:

• Offer fast helpdesk responses to users who require application installs/updates (once it meets your IT requirements) – this will promote helpdesk best practises and also encourage end-user participation.
• Ensure computers have all the required applications/printers pre-installed before issuing to end-user. This may require some discussion with their line manager first, but once a process is in place – this will become much easier over time.
• Investigate why the user requires elevated access and find a solution that works in the favour of both the user and IT – for example, if it is for continued usage of an application that requires UAC credentials then it might be worth considering a detailed investigation of that application to see if the UAC prompt can be circumvented. This can be done with tools such as Process Monitor and Process Explorer which can help identify files, processes and registry keys that cause the prompts.
• Create an alternate user account with strong passwords that has local admin rights on the machine but prohibit the user from logging into the account locally. So, if user223 needs administrative access, they use the ‘run as’ feature in Windows with their user223.admin account instead to authenticate the UAC prompt. The user would have to be aware of the risks and possibly undergo training beforehand.
• Create a supervisor account – similar to above, but this time, assign an alternate user account to a department supervisor who can authenticate UAC prompts to his department’s computers on request. The supervisor would have to be aware of the risks and possibly undergo training beforehand. The supervisor account would be separate to the supervisor’s normal account.
• Provide local administrative permissions but remove the computer’s access to the domain (possibly place on separate network if access to the network is not explicitly required).
• Provide a local VM environment with admin rights sandboxed from the main machine

Conclusion

The recommended approach with the IT Security concept ‘Least Privilege’ is to not permit elevated access and to prohibit allocating local administrator rights to end users. Why? Security, accountability and manageability. Exceptions may arise but these requests will need to be evaluated first. Prohibiting local administrative rights as a security control will need to be protected by company policy and have executive level approval. There are some great alternate options that could be offered as solutions to the requesting users which can help your corporate environment utilise safe practices.

Some useful resources and articles

Microsoft: Implementing Least-Privilege Administrative Models

Microsoft: The Administrator Accounts Security Planning Guide

Feedback

If you feel that you can add anything to the above article or recommend any changes, please include it in the comments below as discussion of these topics is healthy and will help out other users.