David_Trevor ,
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.
I am not on the DPAPI team so I don't know the whole background story of why their design is this way. I will talk to that team and see if we can make some improvements in this area. If nothing else, it would be much better if Windows LAPS decryption keys were never cached locally. That would be a perf hit in that each decryption operation would require a new round-trip call to the DC, but that's trivial in a Windows LAPS password scenario.
thx,
Jay