Eliminating Local Administrative User Access Requirements

Tracing the Evolution of User Access

Back in the Windows 95/98 days, Windows had no file system security, and users always had full control of their systems. With the advent of Windows NT/XP, granular access controls and limited user accounts (LUA) were introduced to enhance security. While LUA's were available, there were many limitations and the default was for users to be administrators of their machines. As a local administrator, users can make any system change they wish, such as install or remove programs, and enable and disable services (such as anti-virus). With the onslaught of viruses and other forms of malware, this is a dangerous problem. If a user with local admin rights happens across a"bad thing" on the Internet, or clicks the wrong link in an email, code executes and it's game over.

Microsoft has always provided guidelines to software authors for how programs should read and write to the system, and which areas of the system were off limits to LUA's. These guidelines were often ignored, with programmers relying on the assumption that users would have complete control of their system. Everything"Just Worked" and attempts to run as a limited user were typically abandoned due to usability issues. Failure of the software to work for a limited user account is a serious bug that compromises system security, stability, and manageability.

The Role of Microsoft: Enhancing User Experience and Application Compatibility

Beginning with Windows Vista, and continuing on through all subsequent OS releases, Microsoft has improved the experience when running as a limited user by allowing the user to easily"elevate" their privileges when they want to change certain settings or install software. Additionally, programmers started wising up and writing software that worked properly when ran with LUA's. You're unlikely to find a piece of modern software that requires a user to be a full administrator.

Common Hurdles: Overcoming Resistance to Change

We still encounter organizations that have a large number of users that are local administrators of their systems. The typical reasons are"we use an old program that requires it" or"the software vendor says they won't support us if users aren't local admins."

The Essence of Remediation: Steps Towards Eliminating Administrative Access

Fixing this issue will result in a substantially better security posture for your organization. It is one of the most important things you can do to provide protection from the bad guys, bar none.

Determining the Reason for Admin Rights

Resources. Maybe you know you need to fix this, but just haven't had the time or technical ability to accomplish this task. There's been no sense of urgency, because everything's working and you don't want to break anything. Make it a priority and dedicate the resources. Unless you commit, you will never get this project completed.

Testing Admin Access Requirements

Test it. If you have a program that you believe requires users to be a local admin, have you recently tested it to see if it works running on a LUA? The program may have required it at one time, but was subsequently updated to remove the need. It's also possible that the benefits that Microsoft brought with User Account Control (UAC), such as Registry Virtualization, also may have mitigated the issue without any other changes.

Clarifying Vendor Specifications

Ask the vendor. Check to see if the vendor still requires local admin access. Maybe they fixed this problem with an updated version you weren't aware of. If the vendor says running as a local administrator is still a requirement, make sure to voice your extreme displeasure at them requiring you to put your organization at risk. There is no excuse for this behavior in 2016 and beyond. Consider voting with your dollars when practical.

Confronting Organizational Politics

Politics. Sometimes, users have local admin access because someone thinks they or their group shouldn't be subject to"restrictive" security policies, or other equally nonsensical reason. While there is no technical fix for this, tackling this roadblock requires management buy in and a strong leader to enforce this policy where there is resistance. All security policies, such as removing local administrative access, should apply equally across the organization to all users regardless of title and position - yes, this includes the IT team. Doing anything otherwise puts your organization at a greater risk of having a really bad day.

Remediation

Eliminating local admin access in your environment is always doable, it just requires patience, determination, a decent understanding of Active Directory, and the right set of tools. In the below example, we will surgically modify permissions on objects. It should be noted that using these techniques can introduce the risk of privilege escalation, though the risk level is low in relation to the user running with local admin rights.

Request a Quote

Tools you need:

• Process Monitor  - aka Procmon from Windows Sysinternals - https://learn.microsoft.com/en-us/sysinternals/downloads/procmon
• Group Policy Management Console (GPMC)  - Built into Windows.
• Two user accounts  - One LUA user with no admin access (normaluserin our examples), and one administrator level user (administrator in our examples).

Test Steps:

1. On a system with the affected program, log in as a LUA user - i.e. not a member of the Local Administrators Group of that system.
2. Determine the file name and path of the application you want to work without local admin rights. In our example, the application is SuperLendingSuite.exe. The application lives in the protected C:\Program Files\SuperLendingSuite folder.
3. Start Process Monitor. You'll need to elevate your permissions with an admin account to run Procmon.

   

4. In the Process Monitor window, click the filter icon. The Process Monitor Filter window will open.

   

5. Configure the filter's Process Name with the name of the application to watch, and click Add, Apply, and OK.
6. Let's limit the output to only"ACCESS DENIED" results.
7. Now, when we runSuperLendingSuite.exe, we will see exactly what the program is trying to read/write to that's being denied.

   

8. The program is trying to modify SuperLendingSuite.inf, but users don't have write access to the folder C:\Program Files\SuperLendingSuite, nor the file SuperLendingSuite.inf if it exists. It's also trying to write to a restricted area of the Registry, HKLM\Software.

Now that we know what the program is doing, it's time to work on the fix.

Setting up the Test Environment and Creating Group Policy to Address the Problem

Implementing a Test Environment: Creating an Effective Group Policy

Open Active Directory Users and Computers, most commonly found on your domain controller in"Control Panel\All Control Panel Items\Administrative Tools."

1. Create a"Test" Organizational Unit (OU), and move a system you would like to test into it. 

   

Open Group Policy Management, in"Control Panel\All Control Panel Items\Administrative Tools."

1. Create a new Group Policy Object for the"Test" OU.

   

   

2. Right Click and Edit the newly created"Test Fix Local Admin" group policy.
3. Navigate to Computer Configuration\Policies\Windows Settings\File System, right click and select"Add File."

   

4. Once you click OK, the Security dialogue box will display. As an example, we are going to add the"Normal User" test account we created, but you can also use Security Groups to make this setting available groups of people.

   

5. Once you add the user or Security Group, you will set the permissions. Read and Execute, List Folder Contents, and Read are pre-checked"Allow", you will want to also allow Write and then click"Apply", then"OK".

   

6. The"Add Object Dialogue box will display, and the default selection is typically the best.

   

7. Let's fix the registry access issue. Navigate to Computer Configuration\Policies\Windows Settings\Registry, right click and select"Add Key".

   

8. Once you click OK, the Security dialogue box will display. As with the File path above, we are going to add the"Normal User" test account we created. Remember, you can also use Security Groups to make this setting available to groups of people too.

   

9. Once you add the user or Security Group, you will set the permissions. Read is pre-check"Allow", you will want to also allow Full Control and then click"Apply","OK."

   

10. The"Add Object" Dialogue box will display, and the default selection is typically the best.

    

11. The"Test Fix Local Admin" Group Policy Object is now configured, and you can close the object to save it.

    

The Verification Process: Ensuring Changes Are Working

Test!

You now have a system ready to test with this new Group Policy Object. Log back into this machine with the LUA account and update Group Policy by opening a command prompt and issuing the gpupdate /force command. You may be required to log off, or restart once Group Policy updates. Once this is complete, repeat Test Steps 1-8 again to confirm that everything is working as you configured. If everything works as it should, you would then apply these settings to all affected users, and remove those users from the Local Administrators groups on their machines.

Introducing LUA Buglight: A Tool for Identifying LUA Issues

LUA Buglight

LUA Buglight is a tool written by a Microsoft employee that can help identify LUA issues with programs. While it can automate some of the above testing, be aware that is also comes back with some information that isn't necessarily relevant to the LUA issue you may be experiencing. That being said, it may be helpful to you, so check it out.

• LUA Buglight 2.3, with support for Windows 8.1 and Windows 10: http://blogs.msdn.com/b/aaron_margosis/archive/2015/07/01/lua-buglight-2-3-with-support-for-windows-8-1-and-windows-10.aspx

Further Reading: Expanding Your Knowledge on LUA Bugs

• What is a “LUA Bug”? (And what isn’t a LUA bug?): https://learn.microsoft.com/en-us/archive/blogs/aaron_margosis/fixing-lua-bugs-part-i
• Problems of Privilege: Find and Fix LUA Bugs (2006): https://learn.microsoft.com/en-us/previous-versions/technet-magazine/cc160944(v=msdn.10)?redirectedfrom=MSDN
• Registry Virtualization: https://learn.microsoft.com/en-us/windows/win32/sysinfo/registry-virtualization?redirectedfrom=MSDN

  Download Blog

Authored By: David Matt