1

I have been thinking of implementing a new practice where local admin privileges are disabled entirely from all endpoints. For users who need to elevate privileges, they will have a separate admin account dedicated and restricted only to the local administration.

I am thinking about how the passwords will be managed. (Its a longshot but) Is there any way passwords can be centrally managed? E.G if a user forgot their password or needed to reset their password, can this be something done centrally via the AD by calling the helpdesk or would we just have to rely entirely on the users.

Also apart from the malware not being able to run automatically with admin privileges if a compromise occurs which is the primary reason I am implementing this, what other benefits would this provide? Is this even best practice?

TheGreyShadow
  • 43
  • 1
  • 7
  • Well not using Administrator as your main admin already decreases the chances of an malicious entity to successfully bruteforce you login imo – Sir Muffington Jan 27 '22 at 19:04

3 Answers3

3

There are several benefits to managing administrative accounts separately from regular user accounts.

  • Ordinary user activity, like email or web browsing, is done without special admin privileges, limiting the scope of an attack, and increasing the difficulty of exploiting an attack.
  • Logging in as an admin with a static password can leave hashes on a box that can be picked up by an attacker and reused in a “pass the hash” attack. If a domain admin logs on to a desktop box, and that box is later the victim of a phish, their credential hash may remain live until the password is changed! A checkout account with a rotating password invalidates those hashes as soon as the password is changed.
  • Checkout accounts give visibility and auditability to the use of elevated privileges. Letting a manager audit one specific account’s use can be done without granting full audit permissions to every account for that manager.
  • Checkout account systems can have their own authentication mechanisms, giving the ability to add multi-factor authentication (like TOTP) to older or closed systems that can’t otherwise support 2FA.

Most of these benefits can be derived by using a centralized tool to manage those accounts and passwords in your organization. There are several external products that can manage passwords dynamically; they have their pros and cons.

  • The enterprise licensed version of HashiCorp Vault has a module that can update the passwords, but it requires credentials with administrative access into AD to make those changes. They also have a RESTful API for conveniently accessing credentials programmatically from other systems. Their system is well suited to securely store passwords for automated systems such as CI/CD pipelines.

  • CyberArk Password Vault allows for timed credentials designed for "checkout accounts"; you check out a username/password from the vault and it automatically changes the AD password when the timer pops, or when the user checks the account back in. (I believe it can also lockout the account if something goes wrong.) You can also set it up so the user can reset their own checkout accounts. They have a "local agent" you can install that can remotely access credentials programmatically (for CI/CD use), but it's quite awkward to access and use. They're well suited to manual checkout of IDs for emergency use.

  • BeyondTrust Software offers Password Safe and DevOps Secrets Safe, which also fit similarly into those two problem spaces.

All these solutions provide ways for administrators to reset and revoke passwords, report on usage, etc. They're one way to control privileged access, and the audit trail can help your SOC identify the source of issues and incidents. And they all come with a price tag, so you can weigh that in the decision process, too.

John Deters
  • 33,650
  • 3
  • 57
  • 110
1

It is absolutely a good idea - you'll probably have an initial ramp of hatred from the users who were used to installing whatever they want, but once this dies down you'll be a lot more secure. You'll want a good way to push software (or let the helpdesk do it remotely) before you start this. You'll also want to make sure that people don't just swap to logging in using the admin account instead of their cached AD account. It might be an idea to let the few users that get an admin account have a separate admin account for themselves, and then add another helpdesk one with something like LAPS.

LAPS is a good way to keep all the local passwords secure and available (https://techcommunity.microsoft.com/t5/itops-talk-blog/step-by-step-guide-how-to-configure-microsoft-local/ba-p/2806185). I'm pretty sure I've seen a similar setup made with Hashicorp Vault. Maybe one of these will make things a bit easier for you.

0

We have had separate admin accounts for years that have more stringent password and access rules than a non-admin account. Recently, we implemented a PAM solution where our admin userids have to be checked in/out with a password that is only valid for that session and the session will timeout after a pre-defined period. Definitely inconvenient from an end-user perspective, but good security practice.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Tom
  • 11