Recognizing the problem
In most companies, there is a serious flaw that could compromise IT infrastructure easier than you think…
When you install a fresh copy of Windows 10, you probably noticed that the local Administrator account is disabled by default. Do you know why it is like that?
Maybe someone gave you the task to manage passwords for local accounts on domain computers using GPO, but you noticed that option is greyed out. Is it disabled by purpose? For the same reason?
Yes. It is.
People with bad intentions (at least for you), let us call them Hackers, found a significant flaw in the GPO password distribution process. Although Windows encrypted the distributed password, Microsoft released the encryption key in their technical documentation, so finding out the password was a child’s play.
Microsoft recognized this huge vulnerability and decided to disable the option to set a password in GPO, but if you already have and use this policy, it still works. You are just unable to change it anymore…
But why did Microsoft disabled the built-in administrator account by default?
Although the built-in administrator is disabled by default, it is still widely used in IT organizations.
How does this happen, and why?
Every computer in your company needs a local administrator account.
This local administrator account is mostly irrelevant to managing workstations and servers within an enterprise environment, because the right thing to do (which you probably already did) in the enterprise environment is to set up domain-level groups with restricted privileges under the local Administrators group, but… If your computer does not connect to any domain controller (for numerous reasons), or maybe your network is down, a local administrator account is necessary.
In that case, it will be used by administrators or technicians from the Help desk to access workstations and servers and resolve any issues.
Since administrators and Help desk technicians need to maintain many computers, it is easier and more convenient for them to have the same account and password on every one of them.
Also, most companies deploy Windows client OS on workstations for the first time as a copy of the Windows 10 image. Administrators often re-enable local administrators in Windows 10 because they need local access to their computers in the event of a disaster. If they configure their Windows 10 computers with an image where the local administrator account is enabled, then every computer provisioned via that image will have the same credentials.
In short, one password can be used to access every workstation.
For convenience and ease of use (more often than not), they have been given easily guessable passwords, and sometimes, that same password is used across large parts of the domain.
The fact that every computer in your network can be accessed with the same username and password is discoverable to a malicious user or attacker.
Using their local SAM account or tools such as mimikatz or impacket, an attacker or malicious user could discover their own local administrator password. Since many attackers know about this potential vulnerability, it will not take them long to try the password on every other computer in your network.
Infecting and compromising only one workstation, stealing that unique password is all they need to access everything. I mean EVERYTHING!
As things start to happen in front of your eyes, and you see the damage being done, you realize the true cost of having it easy…
The nightmare unfolds
That attack looks something like this:
- Attacker targets workstations simultaneously, all at once.
- User running as local admin compromised, attacker harvests credentials.
- Attacker starts “credentials crabwalk.”
- Attacker finds host with domain privileged credentials, steals them, and elevates privileges.
- Attacker owns the network. Now he can harvest whatever he wants.
- You realize that you can’t wake up from this nightmare…
Even if the local administrator is disabled for network operations and local administrators can be used only when accessing the local machine directly, it is still a significant security risk. Attackers will use this vulnerability for privilege escalation. They simply log in with any other account remotely and then “run as” the local administrator to gain administrative privileges.
Preventing this from happening. How hard can it be?
Keeping the local administrator account secure requires a lot of maintenance. It doesn’t matter which approach you take.
The system administrators must ensure that passwords are unique on every computer object, not to be too simple, obvious, or reused anywhere else. It also needs to be applied after deploying machines from a template or when you deploy them manually.
Backsliding is very easy and likely to happen.
Reusing the same passwords is so much easier from a maintenance perspective that people forget about the security angle.
Discovering the problematic computers is an issue on its own… If you have hundreds or thousands of computer objects in your organization, some might have weak, reused passwords, and some don’t. It is most likely the case since machines are probably deployed over a significant period in batches and by different people.
Here is how to avoid it.
The obvious way to avoid problems with the local administrator is to disable it entirely, but that leads you to other issues, in cases such as when the network becomes unavailable.
You could also create a unique password for every workstation/server. It may be a sisyphean task, especially if you have hundreds or thousands of computers.
Fortunately, Microsoft released a tool that will create random local administrator passwords using the GPO and then store them encrypted in Active Directory.
Hackers and malicious users can still steal credentials, but it would take a lot, A LOT more work to compromise workstations or servers.
Having it easy, but at the same time secure? It’s possible!
Here is an overview of the solution:
- Local admin passwords are stored encrypted in Active Directory.
- Computer accounts can only write passwords. They cannot read them (in case it gets compromised).
- The solution addresses only local accounts.
- Single installer contains:
- Group Policy Client Side Extension (CSE)
- ADM/ADMX templates for GPO management
- Powershell module
- Password Decryption Service (PDS)
- Fat client UI for reading/resetting passwords
The core of the LAPS solution is a GPO client-side extension (CSE) that performs the following tasks and can enforce the following actions during a GPO update:
- Checks whether the password of the local Administrator account has expired.
- Generates a new password when the old password is expired or required to be changed before expiration.
- Validates the new password against the password policy.
- Reports the password to Active Directory, storing it with a confidential attribute with the computer account in Active Directory.
- Reports the next expiration time for the password to Active Directory, storing it with an attribute with the computer account in Active Directory.
- Changes the password of the Administrator account.
The password then can be read from Active Directory by users who are allowed to do so. Eligible users can request a password change for a computer.
Installation
- On dedicated LAPS management server, install all available options presented in the install file:
- GPO extension, so computer objects could be managed by LAPS.
- Fat client UI to view passwords.
- Powershell module for completing and configuring the solution.
- GPO templates for configuring LAPS settings in AD GPO.
- PDS service.
AD preparation
Extending AD schema is required since the three new attributes are added:
- ms-MCS-AdmPwd (stores the built-in local administrator password in an encrypted way)
- ms-MCS-AdmPwdExpirationTime (stores the time to reset the password)
- ms-MCS-AdmPwdHistory (needed in case of restoring a backup)
It is executed with two commands (must be Schema Admin to run them) and my advice to you is to test AD replication and make sure it works without any issues before executing commands:
Import-module AdmPwd.PS – imports the modules for LAPS management.
Update-AdmPwdADSchema – extend the schema for the new attributes.
Delegation of permissions
Three roles need to be implemented:
Password Decryption Service role – has permission to interact with AD directly
Password Reader role – has permission to read admin passwords via PDS
Password Reset role – has permission to reset admin passwords via PDS
The best practice is to implement those roles by AD groups, so three types of groups need to be created and membership populated.
Service account permissions:
Managed machines access Active Directory using special well-known account SELF, so necessary permissions must be added to the SELF well-known account. It is required to update the password and expiration timestamp of its own built-in Administrator password on its own computer accounts in AD.
PowerShell cmdlet for granting permissions to the Password decryption service to read and write information to Active Directory:
Set-AdmPwdServiceAccountPermission –Identity <name of the OU to delegate permissions> -AllowedPrincipals <name of Password Decryption Group>
Self-permissions:
Managed machines access Active Directory using special well-known account SELF, so necessary permissions must be added to the SELF well-known account. It is required so the machine can update the password and expiration timestamp of its own built-in Administrator password on its own computer accounts in AD.
Set-AdmPwdComputerSelfPermission -Identity <name of the OU to delegate permissions>
User Rights to read passwords:
Add the extended permission Read Local Admin Password to the group that will be allowed to read the local administrator’s password for managed computers. It is done using PowerShell. You may need to run Import-module AdmPwd.PS if this is a new window.
Set-AdmPwdReadPasswordPermission -Identity <name of the OU to delegate permissions> – AllowedPrincipals <name of Password Readers Group>
User Rights to reset passwords:
Add the extended permission Reset Local Admin Password to the group that will be allowed to reset the local admin account’s password for managed computers. It is done using PowerShell. You may need to run Import-module AdmPwd.PS if this is a new window.
Set-AdmPwdResetPasswordPermission – Identity <name of the OU to delegate permissions> – AllowedPrincipals <name of Password Resetters Group>
PDS Server installation
PDS is responsible for creating and maintaining key pairs used for password encryption and decryption, communication with the Active Directory, auditing of requests of users for password reads/resets, and registration/maintenance of DNS SRV record used for discovery of service by clients.
Password Decryption Service is thus handling some interactions with AD infrastructure.
Computers do not directly read from Active Directory; they only directly write. Password Decryption Service maintains the decryption keys and is responsible for password reads, decrypts, and password resets.
Key pair
To store encrypted passwords in Active Directory, a key pair must be created. For security, only the Key Admin role can generate a new key pair. (By default, the Key Admin role is defined as an Enterprise Admin).
Keypairs are generated using PowerShell. Upon request to create keys, two files will be made in the configured location:
One file contains a public key, and it should be distributed to managed machines via GPO
One file contains a private key and is used by the Password Decryption machine(s)
New-AdmPwdKeyPair -KeySize <Keysize of 1024, 2048 or 4096>
Get-AdmPwdPublicKey
Keys are stored in C:\Program Files\AdmPwd\Svc\CryptoKeyStorage.
Group policy settings
Group Policy is used to enable the local admin password solution and to configure various settings.
For GPO maintenance, the ADMX template needs to be installed on the machine on which Group Policy Management Console (GPMC) is running.
In GPO UI, all configuration settings related to CSE configuration are located under “Computer configuration/Policies/Administrative Templates/AdmPwd/Managed Clients” path.
Following configuration values are supported:
Auditing
The Password Decryption Service (PDS) logs its activity into a dedicated Windows Event log.
Auditing for users who query for a computer’s local administrator password can be accomplished by reviewing the LAPS Service Event log located under Applications and Services Logs.
Client installation
Installing CSE does not initiate the management of the password. GPO settings must be enabled for password management.
For the GPO to be applied on Servers or Workstations and LAPS solution to work, each managed computer should be installed LAPS client.
These can be installed/updated/uninstalled on clients using various methods, including the software Installation feature of Group Policy, SCCM, login script, manual install, etc.
Using LAPS to retrieve password
To retrieve a computer object’s password, all you need to do is install “Fat client UI” on workstation you use to administer your infrastructure and select the computer object for which you need the local admin password retrieved.
Conclusion
As always, recognizing the problem is the first step in resolving it.
Ignoring it could have enormous, potentially unrecoverable consequences.
Security in IT is always about compromises. Searching for that thin line that separates ease of use, comfort, and improved security.
Luckily, Microsoft created the solution for a scenario described in this post, which favors ease of use in large organizations while equally improving its security.
People with bad intentions won’t be able to take advantage of you… At least, not that easily…