Disabling Local Administrator Accounts

What Is It? When an operating system is installed on a computer, whether a server, tablet, laptop, or desktop, it is installed with local administrator privileges. The installer sets a strong administrator password (we hope!) and maintains control of that system with this knowledge. Often, the computer is then joined to a domain using domain level credentials and maintained at that level going forward. Often, the local administrator account remains unchanged and just as often the end user either has access to this account or their domain account has local administrator privileges.

With this level of control, it is not hard to see how the local administrator account can be exploited and abused, intentionally or not. Local users could modify settings, install programs, and indulge all kinds of shenanigans. Others in possession of this password can enact a grocery list of nastiness as long as your arm. When you consider that tens, hundreds, or thousands of systems across the enterprise can have the exact same user name and password for the administrator account, the pulse quickens, and the breathing becomes quite shallow.

The administrator account is power and while your user base may not have domain level privileges, they have more than enough capabilities to become problematic, especially if they have just enough knowledge to be dangerous. It doesn’t take a lot to understand that one can quickly Google “how to (insert random task here)” and quickly create a realm of havoc.

Not all users have malicious intent, or even the desire to do anything out of the norm, but it’s always better to mitigate something going off the rails.

Where Do I Start? Very quickly figure out if users have local administrator privileges on their workstations and how they can access it. Is their domain account part of the local administrators’ group? Do they have a separate account with admin privileges when they need to run a program with elevated rights? Perhaps they just have the administrator user name and password itself?

Do you use the same local administrator password across the enterprise? Have you renamed the local administrator account to something less obvious? Is there any chance that password is used on domain or enterprise administrator accounts? It’s time to take serious stock of the situation. Do you use logging and auditing for use of privileged accounts? Do you use generic administrator accounts? Do service accounts use the local administrator account or at least the same password as the administrator account? I think you’re starting to catch on to where I’m going with this.

With this information in hand, next find out if there are any policies or procedures that govern the use of administrator accounts and whether they align with the reality you face with them. If no policy exists, it’s probably a good time to define one and have it supported by management, especially if you are now faced with the prospect of revoking local admin access. By the same token, figure out exactly who should have local admin access and just as importantly, why. Anyone that has local admin access to a computer should have a clearly defined reason, and not just because they’re at the upper levels of the organisation, or “just because” either.

A current inventory, clearly defined policy, and a complete understanding of how your local administrator accounts are used is essential before making any changes. Again, if you need help, ask. Disabling local administrator accounts completely may not be the be-all and end-all, but it needs to be considered.

How do I make It Work? Depending if you are dealing with domain or stand-alone computers, your approach will be a bit different. If it’s stand alone, and you don’t have a password, configure one ASAP. Use a secure password (what constitutes “secure” varies from person to person and there are different trains of thought, but that’s a debate for another day). If you have the default administrator name (such as “administrator”) I’d recommend changing it. Don’t give any more ammunition to anyone trying to compromise you than they already have. Also try to avoid using the administrator account for daily tasks or having your user account as part of the local admins group. Try to limit the damage possible, even if it’s self-inflicted by forcing you to elevate your privileges temporarily to execute something. It’s not an absolute fix, but it may help mitigate against accidental clicks of “things” and “stuff” happening.

For the rest of us, it gets tough, because we’re probably all on company-owned and controlled domains. Really, in this type of environment, the average user should not have either local administrator rights or have their regular user account in the local administrators’ group. I’ve heard many arguments for and against this before, so I’ll avoid the debate and offer this up as a suggestion. If you absolutely need administrator privileges, be sure to use a separate account for this purpose and do not use the privileged account for anything other than explicit admin tasks. I’d also suggest limiting this to very few selected, authorised individuals…. not everyone needs this ability. Bonus point: don’t allow anything to be executed from the “Downloads” folder, even as administrator.

Change the local administrator name from the default if you can. If I’m testing the security of a computer, this is often the first thing I go looking for and try to log in as. If you do change it, don’t make it something obvious. Changing from “administrator” to “companyadmin” isn’t much help. Part two to this endeavour is to not use the same password for all local admin accounts. If I know that you use “company admin” and the same password on ALL computers, I’m going to have a field day! Yes, I know, this is tricky, but even Microsoft provides a program called “Local Administrator Password Solution (LAPS)” to help. I’d suggest looking into it.

Once you have your inventory, underpinned by management-supported policy and a plan of action, run it through change control, get it approved, and start enforcing it. I’d also strongly suggest enabling auditing of all success and failures of administrator accounts and feeding these logs into a SIEM or your logging platform of choice.

Of course, if you can get away with it, just disable the local admin accounts completely, but this may be too much of an uphill battle. I’d like to think the domain administrators can look after all aspects, but we may end up accidentally sharing too much detail if a domain admin thoughtlessly hands over those credentials to and end user who just needs to install their whizbang software. Planning is critical.

Pitfalls? Political battles await those who attempt to revoke administrator privileges from end user that currently have it. Even if they don’t use the privileges, there will always be an argument “they might” and “just in case”. If those users are higher on the ladder, be prepared for it to be a bit more difficult. We all must realise we’re not trying to hinder anyone or pick on anybody, but secure the overall environment. It takes only one vulnerability to be exploited the right way to have a domino effect. Think of a huge dam on a river. Its surface area may be hundreds or thousands of square meters, but a small leak just a few centimetres wide can quickly compromise the whole structure. Access to one computer with compromised administrator privileges can go sideways in a real hurry, especially where the account may be trusted and not raise any red flags when it is accessed.

Ghosts in the Machine? Generic accounts should always be avoided because you likely want to keep track of exactly who is doing what with regards to administrator accounts. People come and go, roles come and go, and services and servers come and go, so try to clean up old accounts or the ghosts of administrator’s past may come back to haunt you. Better still, make account management a strict part of any on-boarding and off-boarding processes!

Anything Missing? Remember to think of any non-Windows local admin accounts as well, including those on other platforms like Linux and local administrator accounts on networking equipment. Use of TACACS or RADIUS to a domain account is strongly advised, but in that case, maintain a local admin account for the time when you cannot access the domain to get authenticated.

Oh yes. Consider investing in a good quality password management system. There are lots of them available!

Disclaimer: The thoughts and opinions presented on this blog are my own and not those of any associated third party.  The content is provided for general information, educational, and entertainment purposes and does not constitute legal advice or recommendations; it must not be relied upon as such.  Appropriate legal advice should be obtained in actual situations.  All images, unless otherwise credited, are licensed through ShutterStock

Views: 10

Join the Discussion ...

You need to be a member of CISO Platform to join the discussion!

Join CISO Platform

© 2020   Created by CISO Platform.   Powered by

Badges  |  Report an Issue  |  Privacy Policy  |  Terms of Service