Microsoft
Microsoft
>>The GPO I set had a group designated as the password decrypter group, but that didn't seem to take affect.
>>Only after using the Powershell command to assign read and reset permissions to the group against the designated OUs was that permission actually assigned.
>>Is that by design?
The managed client device does not need either read or reset permissions in order to encrypt new passwords and store them in AD. (For the latter operation - ie storing passwords in AD - the device needs the Set-LapsADComputerSelfPermissions.)
The situation is different for password retrieval and decryption. For encrypted passwords there are two required authorization steps and both are completely separate. First the appropriate read permissions (Set-LapsADPasswordReadPermission) must be assigned in AD in order for an admin to query the password. In the case of an encrypted password, that only gets them halfway - once retrieved from AD, now they also need to be authorized to decrypt the password, and this is where the "authorized password decryptors" policy comes into effect. Password *reset* permissions should have nothing to do this.
It's possible to dream up odd authz configurations, for example imagine an admin who has decryption privileges on a given device's LAPS password(s), but who also lacks the AD read permissions to get the encrypted password blobs in the first place.
I tried to cover all of this and more in the Key concepts in Windows LAPS topic - scan down that page until you get to the sub-topic entitled "Password security" then read from there. And I'm still loving my utterly garish red-yellow-green security layer diagram that somehow got through editorial review lol. 🙂
Scott, lmk if anything is not clear, or if this doesn't fully explain the issues you are seeing.