This event may occur when you install SEP 11.x on Microsoft Server with Domain Controller. They solution from Symantec is:
1. Go to Start -> Programs -> Administrative Tools -> Local Security Policy.
2. Expand Local Policies.
3. Open Audit Policy.
4. In the right pane, open "Audit Process Tracking"
5. Uncheck "Failure" then click "Apply”.
See the link to “Symantec Support Document ID: 2008070209482648” for details on this issue.
As per Microsoft: "A program used the CryptUnprotectData function to read data encrypted by Data Protection API (DPAPI). The name of the encrypted data is provided in the event message, but because this name is determined by the program that originally created the encrypted data, it might not be recognizable. This event is logged for informational purposes only". See MSW2KDB
for more details.
Failure code 0x8009000B, Data Description: pws or Data Description: Export Flag:
From a newsgroup post: "The problem seems to be related to Protected Storage and password, OS security feature. Have you performed an administrative password reset or change password?
On Windows XP, Protected Storage uses the user's password exclusively to encrypt user data, such as RSA private keys for current user key container. Whenever the user password is changed, Protected Storage subsystem is automatically notified of this event, and is supplied with both the old and new passwords. This allows Protected Storage to decrypt all of its master keys with the old password, and re-encrypt them using the new password.
Prior to Windows XP, a machine secret was used by Protected Storage to encrypt the master RSA keys rather than the user password exclusively. Using a machine secret made Protected Storage more robust, but the user data could be accessed by anyone with local administrative access to the
If you use the standard change password mechanism by entering the old and new passwords, everything will work fine. If you performed an administrative password reset, the old password is not available, and so access to the master keys is lost. This is by design in Windows XP. In this
scenario, CryptAcquireContext() API will fail with NTE_BAD_KEYSET (80090016), even if the key container already exists and the caller has permissions to open the key container."
Failure code 0x2 - no info
Failure code 0x8009000B, Data Description: Enterprise Credential Set - no info