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