2

I've deployed MS LAPS to manage local admin passwords and all is working fine, except that non-privileged users are able to access the local admin password, in both Powershell and LAPS UI.

Running the command below shows me that in addition to the intended groups, BUILTIN\Users can also read the password. (This command is the same that the LAPS_OperationalGuide suggests, but I piped results to a ForEach and Out-File so that output was not truncated.)

    Find-AdmPwdExtendedRights -Identity 'All Computers' | `
     ForEach-Object -Begin $null -Process {$_.ObjectDN}, {$_.ExtendedRightHolders} -End $null |`
      Out-File C:\Temp\WTF.txt

mydomain\Domain Users group is a member of BUILTIN\Users (which is normal), so maybe this is where the problem is coming from...? Regardless, I cannot find a way to remove the AdmPwd permission from BUILTIN\Users or from mydomain\Domain Users. I've stepped through every single account listed in ADSIEdit\AllComputers\Properties\Security\Advanced but no user or group has the AdmPwd permission, except those that should. Did same in ADUC with same result.

Can someone please tell me how to remove the AdmPwd permission from BUILTIN\Users? There is a Set-AdmPwdExtendedRights cmdlet, but no Remove-AdmPwdExtendedRights cmdlet. Failing that, can someone tell me how to find where the permission is coming from?

Before folks start asking, yes, I have closely followed the LAPS_OperationGuide, have run all the Powershell cmdlets, have gone to ADSI Edit and removed "All Extended Rights", and have given rights to my two intended groups. Everything about LAPS is working properly except for the BUILTIN\Users problem.

bahnjee
  • 21
  • 1

2 Answers2

0

Your issue has nothing to do with your implementation of LAPS. We noticed the same problem with regular domain users being able to read LAPS passwords. The issue was caused by misconfigured permissions or privilege creep on AD computer objects. The solution was to audit all computer objects by script and reset inheritance to remove any custom permissions on new objects. One major reason for this issue was discovered to be caused by administrators giving domain users permission to join a computer to the domain when creating the computer object. This permission stayed with the object and was enough to let them read the LAPS password after the computer was joined to the domain.

twconnell
  • 764
  • 4
  • 12
  • 1
    Thanks much, @twconnell. Sounds highly likely our root cause is similar. Years ago, a loose-cannon of an admin removed default user rights (add up to 10 PCs to domain) and probably screwed the pooch in the process. I know it's a big ask (especially coming from a newbie to the forum), but if you could provide said script or any other tools/advice, I would be forever in your dept. EDIT: I would be forever in your debt, not dept. Though I imagine we do both work in the same dept (IT). :) – bahnjee Apr 19 '21 at 18:41
  • Sound's like you'd fit in well with our dept ;) but unfortunately the script I referred to is proprietary and focused on other use cases specific to our environment. I'd suggest you look into leveraging Powershell to reset inheritance on computer objects. There's several examples of this on the web such as https://www.mowasay.com/2019/08/fix-active-directory-broken-security-inheritance-problem-or-protected-acl/ – twconnell Apr 23 '21 at 15:47
0

Thanks to Semicolon over at Spiceworks.com, I found the solution. https://community.spiceworks.com/topic/2314503-laps-problem-still?page=1#entry-9150359

TL;DR: When looking at Properties > Security > Advanced of the relevant computer OU, and then the offending MyDomain\Users entry, I did not notice that the list of Permissions/Properties was scrollable. There are a ton of settings in there that I wasn't seeing. The Users entry did not have All Extended Rights, but did have Read mcs-McS-AdmPwd. Wasn't able to uncheck the box (would just re-check itself after OK), so I removed the entry entirely. Problem solved. Thanks to all that contributed.

bahnjee
  • 21
  • 1