Securely granting local administrative permissions

Question

I’ve been researching the best method of securely granting local administrative permissions but I’m really struggling to reconcile the security, operational, and cost implications.

I’ve devised a few options:

1. Create a domain security group (PC Admins), add the required domain user accounts, and use Group Policy to add the domain security group to the local security group Administrators:
   • Pros:
     • Centrally-managed.
     • Auditable.
     • Free.
   • Cons:
     • Vulnerable to credential theft and lateral movement attacks.
2. Option #1 but using separate domain user accounts (<original username>.admin):
   • Pros: Same as #1
   • Cons: Same as #1. Authenticating a UAC prompt creates a logon cache which can be exploited.
3. Option #1 but disabling cached logons:
   • Pros:
     • Centrally-managed.
     • Auditable.
     • Free.
     • Not as vulnerable to credential theft and lateral movement attacks in that there are no logon caches to exploit but credentials can still be captured via other means (keyloggers, etc).
   • Cons:
     • Users will be unable to logon if there’s a problem with the domain, there's a problem with network connectivity, their PC is offsite, etc.
4. Deploy Microsoft LAPS and issue users with the unique, local administrator credentials:
   • Pros:
     • Centrally-managed.
     • Not vulnerable to credential theft and lateral movement attacks.
     • Free.
   • Cons:
     • Non-auditable.
     • The default administrative user account is an easy target.
5. Add the required domain user accounts to the local security group Administrators:
   • Pros:
     • Auditable (to an extent).
     • Not as vulnerable to credential theft and lateral movement attacks.
     • Free.
   • Cons:
     • Not centrally managed.
6. Implement MFA:
   • Pros:
     • Centrally-managed.
     • Auditable.
   • Cons:
     • Not free.
     • Still vulnerable to credential theft and lateral movement attacks (according to https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/implementing-least-privilege-administrative-models).
7. Implement a system that uses TOTPs and/or only temporarily grants administrative permissions as-and-when needed:
   • Pros:
     • Centrally-managed.
     • Auditable.
     • Not vulnerable to credential theft and lateral movement attacks?
   • Cons:
     • Not free.

Is there a general best practice?

I can't help but get the feeling that there is no one correct technological answer and that these risks are mitigated by simply trying to ensure that no one can or will (1) use an administrative user acount on a day-to-day basis or (2) run malware.

Answer 1

Use protected users

When a user logs on to a Windows machine with the NTLM protocol, his hash is stored in memory in the LSASS process. An attacker can dump this memory to steal these credentials.

To overcome this problem, a good solution is forcing Kerberos authentication for administrators and banning the plaintext credentials. You can do this with a mechanism called protected users.

/!\ You will need Windows Server 2012 R2 to create the Protected Users security group and hosts must run Windows 8.1 or later to provide client-side restrictions for Protected Users.

When an account is a protected user's member:

• default credential delegation and Windows Digest (plaintext credentials) are not cached even when the Allow delegating default credentials policy is enabled
• NTLM hash is not cached
• Kerberos configuration is improved
• Sign-on offline (the cached logon verifier) is not created

Your first option is the good one

Create a domain security group (PC Admins), add the required domain user accounts, and use Group Policy to add the domain security group to the local security group Administrators.

That's exactly what you have to do. And your PC Admins group will be a member of Protected Users group.

Bad options

Deploy Microsoft LAPS

LAPS automatically manages the rid 500 (local administrator) password on domain joined computers, so the password is:

• unique on each managed computer
• randomly generated
• stored in existing AD infrastructure

However, local administrator accounts should not be used to administrate computers over the network. In an Active Directory, these accounts must be considered as backup accounts, in case of loss of network connection. So LAPS does not fit your needs.

Moreover, it is vulnerable to credential theft but not lateral movement attacks.

Implement a system that uses TOTPs and/or only temporarily grants administrative permissions as-and-when needed

For same reasons as MFA, it is still vulnerable to credential theft and lateral movement attacks.

Answer 2

1. As far as I know cached logons for domain account are not vulnerable to credential theft and lateral movement attacks.

Security of cached domain credentials The term cached credentials does not accurately describe how Windows caches logon information for domain logons. In Windows 2000 and in later versions of Windows, the username and password are not cached. Instead, the system stores an encrypted verifier of the password. This verifier is a salted MD4 hash that is computed two times. The double computation effectively makes the verifier a hash of the hash of the user password. This behavior is unlike the behavior of Microsoft Windows NT 4.0 and earlier versions of Windows NT.

http://support.microsoft.com/kb/913485

2. But you still need a way to manage local administrators accounts. You can either disable them or use LAPS. Using the same local admin password on all computers is vulnerable to credential theft and lateral movement attacks.

3. From my point of view - your domain users should not have local admin privs. IT staff should have special accounts which are in local administators group. Local administrators accounts should have different passwords.