CryptAcquireCertificatePrivateKey fails with CRYPT_E_NO_KEY_PROPERTY (0x8009200B ) when trying to obtain access to a user’s private key on machine’s after the user changes his password.

You create a key container on a machine for a specific user on the user’s profile.

You log off the user and login with the administrator account and forcibly change the user’s password.

Next time if you log on to the machine with the user account and the new password, and then try to access the user’s private key you see that CryptAcquireCertificatePrivateKey() fails with CRYPT_E_NO_KEY_PROPERTY.

The reason for this is DAPI (Data Protection API) and the way it works. For more specific details please refer to the KB article The section from this KB stated below mostly answers this issue.

Password Reset (Set)

In this method, an administrator forcibly resets a user password. A password reset is more complex than a password change. Because the administrator is not logged on as the user and does not have access to the user's old password, that old password cannot be used to decrypt the old master key and re-encrypt it with the new password.

In all cases of password resets, if the user's password is changed back to the last password before it was reset, access is restored to master key and, as a result, access is restored to all the confidential information it helps protect. This behavior occurs because master keys are never deleted, even when they cannot be decrypted. However, this may be an unreliable solution because you cannot expect the user to be able to always remember the old password. For example, the user's password may have been reset because the user forgot this password.

The way that DPAPI solves the password reset issue depends on the security environment where the user is authenticated.

If you have forcefully changed the password of an user account on a domain and you are still connected to the domain then CryptAcquireCertificatePrivateKey() should not fail.



Comments (0)

Skip to main content