MAY. 19, 2017 | THE FRONT LINE

Last time, we discussed the importance and impact of User Rights Assignments on your network.  When coupled with a solid delegation model and group policy settings such as Restricted Groups, they can create a strong defensive posture for your network.  In this entry, I want to address the problem of local administrative accounts and Microsoft’s budget-friendly solution known as Local Administrator Password Solution (LAPS).

Local accounts on workstations have been and continue to be a huge chink in the armor of most networks, mostly because there is no native or simple way to manage them once a workstation has been deployed in the live environment.  A few of the complications that involve local accounts in an enterprise include:

  • No native solution exists to rotate the passwords of local accounts.
    • The Group Policy Preferences settings have been compromised, and attackers can pull the clear text passwords from the group policy.
    • Scripting solutions will not work as there is no absolutely secure and sustainable way to have passwords report back to a central location for administrators to retrieve later.
      • SOAPBOX: Scripts are not solutions. They are only tools to aid your solutions.
    • Scripts that use pseudo random logic mixed with static environmental attributes to create passwords will only slow down attackers, not stop them.
  • No native solution exists to remove all custom-made local accounts.
  • Administrators tend to apply the same password to local administrator accounts when building workstations prior to setting them up in the environment, and they rarely follow up to change these passwords.

Local accounts within a network can be very scary if not properly managed as adversaries use local accounts to move laterally between systems.  When moving between systems whose local accounts share a password, the adversary can bypass some of your defenses as no domain authentication is required. If local accounts are not properly administered, then network defenders will leave a glaring hole in their defensive strategy.  Unfortunately, there is no easy, cost-effective way of managing these local accounts while maintaining security.  As such, I recommend purchasing a management platform. My recommendation, while not an easy or budget-friendly one, is a secure solution.

There are existing solutions to centrally manage local accounts within your domain.  This approach will require deploying the solution within your network and dealing with the costs and limitations of the chosen solution.  What you gain, though, is a central location that can manage your system’s local accounts, log administrative actions taken against those systems, and properly secure local passwords.  In my opinion, acquiring a local account management platform is the best solution for the problems listed above.  Of course, not every company has thousands or tens of thousands of dollars extra to purchase these platforms, and as a stopgap for those in this situation, Microsoft has created the LAPS program that you can deploy for free.

Before I start talking about LAPS, let me give you two disclaimers.  First, I do not advocate using LAPS over any fully-developed, third-party solution.  LAPS is free, but there are a number of limitations that come with it.  Second, this is not a deployment guide but rather a list of the pros and cons of LAPS. (You can find a deployment guide here1) Microsoft created this program to help ease the burden of local administrative password management, and I want to make sure that you are informed before deciding which solution to deploy.

Now, what does LAPS do? LAPS automatically manages the local administrative account on a system by rotating its passwords.  It creates a randomly-generated password that gets uploaded to a machine’s active directory object, and only authorized accounts can view the password of the local account.  The process to deploy LAPS is fairly painless, and the solution is easy to manage once it is deployed to the domain.  Here are some of the things that LAPS will do for your domain:

  • It allows for passwords to be 8 to 64 characters in length.
  • It allows for passwords to be 1 to 365 days old.
  • Passwords can be made up of the following characters:
    • Capitalized letters
    • Capitalized and lowercased letters
    • Capitalized letters, lowercased letters, and numbers
    • Capitalized letters, lowercased letters, numbers, and special characters
  • Settings for the clients are managed through group policies.
  • Clients can apply new passwords as soon as group policies are reapplied to the machine.
  • Passwords are stored in active directory under a confidential attribute (only those with granted permissions can read the passwords).
  • It can target accounts with custom names or accounts that are not the built-in administrator.

With some of the benefits listed, here are some of the limitations of LAPS:

  • It will only protect one account on the client at a time.  If you have more than one local account on your workstation, you must choose which one you wish to secure.
  • The workstations must install LAPS.  This requires the program to be pushed either through a patching solution or by a group policy configuration to reach all the end points.
  • If a machine does not update its password, there are no native queries or alerts that will notify administrators of non-compliance. An administrator would have to use PowerShell tools to list all noncompliant accounts.
  • There is no centralized log of who updates a password and when.  Administrators can still rotate the passwords on the local machine without the active directory being aware of the changes.
  • Some of the administration of LAPS is through PowerShell commands which are not natively installed on every machine.
  • The password uploaded in active directory is not encrypted.

Clearly, LAPS does not provide a complete answer to managing local accounts on a system.  To increase security, you would have to pair it with other stopgap options, such as a script that deletes unneeded local users on workstations.  However, deploying LAPS is better than having no solution or an extremely unsecure solution.  To me, ignoring this option is like refusing to drive your old car because it doesn’t have air conditioning or power steering. Is it an ideal solution? No.  Will it get you from Point A to Point B until you can acquire a different car? Yes, as long as Point B is within city limits.  Sometimes, you can’t purchase all the necessary defensive solutions for the network for one reason or another.  In those instances, LAPS can provide some protection to your local accounts rather than letting all the weaknesses remain as holes in the wall of your domain.

While this post focuses on workstations, the principles discussed here can be applied to servers as well.  (LAPS is easier to apply to workstations as they are easier to standardize.  Servers require a little bit more planning.)

Note: I would not recommend running LAPS on a domain controller as it will change the domain’s administrator’s account instead of the true local administrator account (the DSRM account).

Stop by next time to learn about critical logs occurring in your domain that can assist you in detecting lateral movement, credential abuse, or abnormal user behavior.

Until next time!

  1. https://gallery.technet.microsoft.com/Step-by-Step-Deploy-Local-7c9ef772