6

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:
  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.

  • What is your use-case for to allow "authenticate / elevate administrative tasks for standard users" ? – gb5757870 Nov 14 '17 at 20:16
  • @gb5757870 If I've understood your question correctly, the standard stuff - installing an application, restarting a service, etc. – mythofechelon Nov 15 '17 at 8:41
2

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.

0
  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

  1. 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.

  2. 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.

  • 1
    Regarding #1: It's my understanding that "modern" (patched Windows 7 and newer) cached logons aren't vulnerable to theft of the credentials themselves but are vulnerable to pass-the-hash attacks and, therefore, lateral movement attacks. Regarding #2: Currently, we do use Microsoft LAPS but not for granting local administrative permissions or authenticating administrative actions (installing apps, etc), hence option #4. Regarding #3: Yes, domain users don't have local administrative permissions. So, you'd advise option #2? – mythofechelon Nov 15 '17 at 8:47
  • I belive that cached domain credentials are not vulnerable to pass-the-hash attackes. As I wrote earlier, modern versions of Windows do not store hash for cached credentials, it stores a verifier. This verifier can't be used to logon to any other computer. Cracking a password from the verifier is much more difficult task, than cracking a ntlmv2 hash , so if your passwords are strong enaugh it is not a problem. Yes, I recoment option#2. – Serg Kim Nov 15 '17 at 9:50
  • Okay. To ensure that the separate, administrative user accounts cannot be used as everyday ones, is it possible to restrict them so that they cannot logon but they can be used to authenticate UAC elevation? – mythofechelon Nov 16 '17 at 9:04
  • Domain credentials are stored in "reversable encryption" (cleartext) in memory, while local admin credentials are only stored as NTLM hashes. You can test for yourself by running mimikatz. – Daniel Grover Dec 15 '17 at 15:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.