[ad_1]
Editor’s note: This is a refresh of an older blog post on local admin privileges prior to the LAPS release. We’ve updated it with new best practice guidance.
When embarking on a project to remove administrator rights from users, it is important to understand all of the options available for modifying local group membership on your clients. If you have hundreds – or even thousands – of desktops, it is not feasible to do this manually. Fortunately, Microsoft provides two mechanisms in Group Policy to manage local group membership. The first is a Group Policy extension called Restricted Groups. Restricted Groups allows you to overwrite the existing local group with what you have configured in the Group Policy setting. The other option is within Group Policy Preferences. The Local Users and Groups extension allows you to modify the local group membership without overwriting the existing groups. In addition, or when a particular scenario is more complex than these allow, scripts can be used to address these.
Why remove administrator rights?
Before we get into the details, let’s discuss why you are removing admin rights in the first place. On the surface, it is as straight forward as saying, “Ah, users with unnecessary admin rights is bad, Jason”. This is a simple enough, and a quite accurate, statement. But if it were that easy it would already be done, and you wouldn’t need to be reading this post. More likely, a security initiative has prompted you to move to a least privilege model and/or better manage administrative accounts on endpoints.
The first step is discovery
The first step is understanding where administrative access exists. It will be good to have a baseline to refer to, and find any rogue or forgotten access. BeyondTrust offers a freeware tool called the PowerBroker Privilege Discovery and Reporting Tool (or DART for short) to get you started. DART will help reveal privileges not only on your Windows assets, but also for Mac, Linux and Unix throughout your organization.
Now that you have your baseline, let’s take a look at your options.
Restricted Groups
Restricted Groups can be configured by opening a GPO and navigating to the following location:
Computer Configuration/Policies/Windows Settings/Security Settings/Restricted Groups
If you create a Restricted Group for the Local Administrators group, the GPO will overwrite the existing local group membership and set the membership to whatever has been configured in the GPO. If a user adds himself to the local administrators group, the next time the policy refreshes, the local group membership will be reset back to what is defined in the Restricted Group.
Group Policy Preferences
Another option to manage local group membership is to use Group Policy Preferences (GPP). Group Policy Preferences was introduced in Windows Server 2008 after Microsoft acquired DesktopStandard Corp in 2006 (full disclosure: BeyondTrust was spun out of that transaction).
To configure Group Policy Preferences, simply open a GPO and maximize the Preferences, then maximize the Control Panel Settings.
When you right-click and create a new policy, you will have the option to add, remove or even modify local group membership. This method of managing local group membership provides more flexibility over Restricted Groups. In the example below, the policy will remove all members of the local administrators group and add the Domain Admins group back in.
Note: In previous versions of Preferences you could change the password for the Local Administrator. Due to security issues Microsoft deprecated this ability and since released LAPS – more on this later in this article.
Scripts
Sometimes it is not as simple as taking some objects out and putting others into the local administrators group as one or two policies. At times you may need to accommodate a varying amount of scenarios where Restricted Groups, or GP Preferences, won’t easily allow for. Using a script, though more complex, can manage group membership based on very unique settings.
What’s going to break if you do this? And how do you fix it?
Once you have decided on your strategy to technically remove admin rights, it is time to consider the things that will break when you actually take the administrator privileges away from users.
Typically, there will be several applications that your business relies on that will require administrator privileges to run. There will also be system tasks that users will no longer be able to run because they require administrator privileges. Finally, users will no longer be able to install most applications since they also require administrator privileges.
These are challenges all organizations will face when removing administrator privileges from end users, even in Windows 7 deployments. This is where PowerBroker for Windows comes to the rescue. PowerBroker for Windows can elevate these apps, tasks and installs, dynamically without any impact to the end users. You can even measure your progress with robust reporting capabilities that include automatic discovery of applications that require administrator privileges in your enterprise, but it also will show you how many user accounts have local administrator privileges, as shown below.
What about passwords?
At this point you have successfully managed which accounts have administrative rights and ensured users can still carry out their day to day operations without them. That leaves one more key item – passwords. Most, if not all, of you have a password age policy in place for your users, and sadly, many of them have that password written on a post-it in a vault, or under their keyboard, whichever is closer. While there isn’t much we can do to solve that problem, we can help you to properly manage enterprise, local and service account passwords that need to retain privileged access.
One option is LAPS. Microsoft released a product called Local Administrator Password Solution (LAPS) in 2015. LAPS can change the Local Administrator password for domain joined machines but it is quite limited, most notably…
1) LAPS requires an AD schema exchange. This may not be an issue for your company, but it is definitely a consideration.
2) You can only manage the Local Administrator, or a custom Admin account, BUT only on domain joined machines.
3) It goes without saying, but this only works for Windows systems. You will require additional tools for your Mac, Linux and Unix systems as well as other devices, (Routers, Phone Equipment, etc.)
A more complete solution is to use a product that can manage all accounts within your organization. PowerBroker Password Safe is used for this purpose. There are no schema changes to be made and isn’t limited by the operating system or domain membership. In addition, management, reporting and auditing is performed by the same central platform as the PowerBroker for Windows product mentioned above.
There are several mechanisms for removing admin rights from users. As you consider the right path for your organization, consider the steps and solutions above – these recommendations are built with an admin’s time in mind!
For more on how BeyondTrust can help, or to see a demo for PowerBroker for Windows or Password Safe, contact us today!
[ad_2]