Home / server / Questions / 1144499
Accepted
David Trevor
Asked: 2023-09-26 23:01:05 +0800 CST

New LAPS - Authorized password decryptor not updating permissions as expected

  • 772
  1. Created a new group DOMAIN\LapsAdmins. Currently empty.
  2. Configured GPO Configure Authorized password decryptors to point to my group DOMAIN\LapsAdmins
  3. Forced server1 to create a new encrypted password for the local Administrator account
  4. Get-LapsADPassword server1 -AsPlainText -IncludeHistory

As expected, my user DOMAIN\dtrevor cannot decrypt the password.

  1. Added DOMAIN\dtrevor to group DOMAIN\LapsAdmins
  2. Logoff and logon with user DOMAIN\dtrevor
  3. Get-LapsADPassword server1 -AsPlainText -IncludeHistory

As expected, my user DOMAIN\dtrevor can decrypt and view all passwords, both the current password and the whole password history

  1. Removed DOMAIN\dtrevor from group DOMAIN\LapsAdmins
  2. Logoff and logon with user DOMAIN\dtrevor
  3. Ran gpupdate /force on server1
  4. Forced server1 to create a new encrypted password for the local Administrator account
  5. Get-LapsADPassword server1 -AsPlainText -IncludeHistory

Unexpectedly, my user DOMAIN\dtrevor can still decrypt and view all passwords, including the freshly generated one and also including the whole password history. Why?

windows

1 Answers

  1. Best Answer

    This question was answered by Jay Simmons of Microsoft in the official blog post about the new LAPS. The answer is in the comment section on page 7.

    The behavior mentioned in the question is due to the caching mechanism of DPAPI.

    You are likely seeing this behavior due to DPAPI's default behavior which caches decryption keys retrieved from AD. Try this:

    1. Remove the user from the authorized decryptor group

    2. Flush the user's kerb tickets (klist purge) (or logoff\logon again)

    3. Delete all cached DPAPI\KDS keys from the user's local profile directory (look for a hidden directory in the profile, I believe it's something like "AppData\Local\Microsoft\Crypto\KdsKey").

    4. Re-run the password decryption attempt - it should now fail.

    This means that as long as the cached key persists on the local machine, the user may decrypt old passwords still. In practice, this does not seem like a big deal because when you want to revoke access you would also remove the ACL from the AD fields, so the user cannot access the encrypted value in the first place.

    • 0