TL;DR:
This outlines one method to allow helpdesk personnel to perform administrative tasks on domain workstations without exposing domain credentials. This idea is only applicable if you are already utilizing MS LAPS on your domain. This is just an idea for those who are paranoid of Mimikatz style attacks.
I borrowed the core idea from https://docs.microsoft.com/en-us/archive/blogs/secguide/remote-use-of-local-accounts-laps-changes-everything and implemented it in the lab.
Background:
What if we could prevent privileged user credential theft from a compromised workstation by not having any privileged user ever log in to it with a domain account in the first place?
It turns out there is a way. It is up to the sysadmin, and their management to decide if this idea would work for them, but I believe it is worth outlining. This method is for those organizations who have an entry level help desk staff who support the end user’s needs mostly by setting up, managing, and fixing their workstations. These staff require the rights in AD to create & delete computer accounts and exercise local admin privileges on the workstations. They do not however need access to the servers, user accounts, or any rights in AD outside the workstation OU.
What if we left these staff as lowly Domain Users, delegated them rights to the OU containing the workstations, and had them access the workstations directly as the local admin account to perform any required maintenance?
LAPS changes everything:
I know what you are immediately thinking; this sounds like a terrible idea. However since 2015 LAPS has made this possible without creating a security nightmare. The Local Admin Password Solution (LAPS) gives sysadmins an easy, automated way to randomize the local admin password on each and every domain workstation and change it on a set schedule. Using LAPS no two workstations have the same local admin password. This goes a long way in holding up an attacker who has managed to compromise one workstation.
Combine this with having only the user who works on that computer daily being the only domain account that ever accesses that workstation and there are no credentials to steal.
Please note; this solution is only an even halfway decent idea if you are already using LAPS on the domain workstations.
Prep the GPOs to allow local admin access remotely:
First there are three changes required to the default Windows baseline:
Windows Settings\Security Settings\Local Policies\User Rights Assignment\Deny access to this computer from the network = set to empty
Windows Settings\Security Settings\Local Policies\User Rights Assignment\Deny log on through RDP = set to empty
The last GPO is:
Administrative Templates\MS Security Guide (*)\Apply UAC restrictions to local accounts on network logon = set to Disabled
This requires updating the Central Store with SecGuide.admx from Microsoft. We discussed how to update the Central Store in the writeup on mitigating suspicious macros, but to recap just copy/paste the *.admx & *.adml to
\\test.local\SYSVOL\test.local\Policies\PolicyDefinitions
And wait for the changes to sync to the DCs. Once that happens you will see the GPMC pulling from it.
We can then make the final GPO change:
This allows the local admin of a workstation to RDP into that workstation, among other remote access methods.
Giving the helpdesk staff control of the workstations & their OU:
Next we need to setup privileges for the helpdesk staff so they can do their job and maintain the domain workstations. First we will give them permissions over the OU containing said workstations and give them access to LAPS:
Note the ‘All extended rights’ permission above. This AD privilege can be dangerous if not handled correctly. It gives the holder the ability to read the AD attribute ms-Mcs-AdmPwd of workstations in that OU. That is whoever has that right can pull the LAPS passwords for the workstations. ‘Full Control’ of course also allows this.
By default only Domain Admins can pull LAPS passwords.
We can verify these changes and ensure that no unauthorized groups or users have access by running this query:
Find-AdmPwdExtendedRights -Identity “ou=clients,dc=test,dc=local”
Validate the setup:
We will logon to TestClientII as helpdesk staff, pull the LAPS password for TestClient, then RDP to TestClient as the local admin of that workstation as though we were going to install an approved above baseline application for the user:
Get-AdmPwdPassword TestClientmstsc /w:1024 /h:800 /v:TestClient
If the helpdesk staff are forgetful and try to RDP under their domain account instead of the local admin of that system then no harm no foul. It just won’t work.
Dameware:
This method also works with Dameware, which is a nice feature if the helpdesk only needs to show a user how to do something such as clear everyone else’s certs out of certmgr.msc, ensure their cert is published to the GAL, etc. It is also handy if the ticket is a quick fix and there is no reason to log the user off.
The helpdesk can simply pull the local admin password and then copy/paste into Dameware.
A benefit to this method is that Dameware accurately shows the end user who connected to their workstation by domain account, local account used, and what workstation the domain user is coming from.
If the helpdesk staff are forgetful and attempt to connect using their domain account it will simply fail.
Security benefit:
This method prevents credential theft, because, well what is cached for an attacker to grab? The local admin of that workstation? They already have that if they are able to run Mimikatz or a similar tool, and thanks to LAPS that password or hash will not get them access to any other system.
The attacker can’t get the hash of the helpdesk staff because they never logged in to the user’s workstation as themself. They cannot, their account does not have access. Their domain account can really only create/delete computer accounts and pull LAPS passwords.
Cons:
There is little accountability for any errors or unauthorized changes made to workstations by the local admin account. However we already have this problem if we make the helpdesk staff Domain Admins since Domain Admins can pull the LAPS passwords by default. Additionally we can setup auditing of who accesses the LAPS passwords by:
Set-AdmPwdAuditing -OrgUnit “ou=clients,dc=test,dc=local” -AuditedPrincipals:Everyone
Additionally the helpdesk staff may complain about the required process of pulling the local admin to any workstation they need to work on. It is easier to simply connect as a privileged domain user. That’s a decision for management and the age old ease of use versus security fight.
Wrapping up:
Lastly we will change the local admin password on the workstation:
Reset-AdmPwdPassword TestClientIIIInvoke-GPUpdate TestClientIII
Or if you like to be thorough then just reset all the workstations at once:
$computers = Get-ADComputer -Filter * -SearchBase “ou=clients,dc=test,dc=local”$computers | ForEachObject -Process {Reset-AdmPwdPassword -Computer $_.name}$computers | ForEachObject -Process {Invoke-GPUpdate -Computer $_.name -RandomDelayInMinutes 0 -Force}
Of course we could also just set a GPO to change it daily:
30 is the default, but there’s really no reason why it could not be 1.
One last important note:
In the training for your helpdesk staff stress that they should only query LAPS in PowerShell. This can be done via
Get-AdmPwdPassword TestClientIf they have the AdmPwd.PS module loaded on their workstation (‘Install-Module -Name AdmPwd.PS’). If not, as long as they have the rights in AD they can:
Get-ADComputer TestClient -Properties ms-Mcs-AdmPwdOf if they want to attempt to impress their co-worker:
Get-ADComputer TestClient -Properties * | Select-Object SamAccountName, ms-Mcs-AdmPwdIf your helpdesk staff get into the habit of using the Active Directory User & Computers (ADUC) GUI tool to pull LAPS passwords you may open yourself up to the risk of a MITM.
Conclusion:
This is all just an idea to prevent the credential theft of a domain user who has elevated rights, aka a Privileged User. It assumes compromise of a domain workstation, possibly multiple ones. If you read this far and think it’s a dumb idea, then great, it’s not for you. I thought it was worth trying out and outlining how to setup. If anyone finds this helpful or just an interesting idea that is worth exploring then that is great too.
References:
https://petri.com/use-a-local-administrator-account-for-remote-administration
https://petri.com/auditing-access-to-laps-passwords-in-active-directory
https://www.parallels.com/blogs/ras/mstsc-commands-alternatives/
https://blog.nowmicro.com/2018/02/28/configuring-laps-part-1-configuring-active-directory/
https://4sysops.com/archives/part-2-faqs-for-microsoft-local-administrator-password-solution-laps/
https://activedirectorypro.com/update-group-policy-remote-computers/
