Microsoft
Microsoft
When using DPAPI in AD mode (which is what Windows LAPS password encryption is based on), the essential thing to remember is that the ability to decrypt a Windows LAPS password is dependent on whether or not the client's token contains the sid for the authorized password decryptor group.
>>Retroactively adding a user to the authorized password decryptor group immediately lets the user decrypt all current passwords + history
The "immediately" part sounds fishy, but otherwise yes this is by design. The user might need to logout and log back in again to refresh their token's group membership to include the sid for the authorized password decryptor group.
>>Removing the same user from the authorized password decryptor group does not revoke that decryption permission, all current passwords + history can still be decrypted by that user
The removal of the user from the authorized password decryptor group will only take final effect once the user's kerberos ticket expires and a new ticket is obtained that reflects the group membership change. Note that none of this is Windows LAPS-specific: as with any other AD group membership modification, the update process is not done in realtime across multiple machines.
>>After removing the user from the group, newly generated passwords can still be decrypted by that user (even after relog + reboot of all domain controllers in the forest).
Rebooting of domain controllers does not affect or speed up the process of revoking the user's ability to decrypt a given Windows LAPS password. Revocation depends on whether or not the user has the sid for the authorized password decryptor group in their token.
>>After a few days I generated a password again and only then it could not get decrypted anymore
I am guessing here, but pretty sure that what happened is that the user's kerb ticket\token expired, and after refreshing the user did not have access anymore.
A useful technique to be aware of when investigating this type of scenario is "whoami.exe /groups" - you can check the token of the current user to see if the sid for the authorized password decryptor group is present or not. Also you can run "klist.exe purge" which will force a kerb ticket refresh which is very useful after AD group membership change.
Let me know if this helps? I can add some comments to the docs to help others as well.
Jay