Microsoft KB Archive/286799

{|
 * width="100%"|

PRB: Private Key Operations May Fail on Windows NT 4.0

 * }

Q286799

-

The information in this article applies to:


 * Microsoft Win32 Application Programming Interface (API), included with:
 * the operating system: Microsoft Windows NT 4.0

-

SYMPTOMS
Private key operations, such as the CryptSignMessage, CryptSignHash, CryptImportKey, and CryptDecrypt APIs, may fail on Windows NT 4.0 in situations in which machine keys are used and the calls are made in a security context other than the interactive logged on user. These symptoms are seen even though CryptAcquireContext is called successfully.

NOTE: This is not a problem on Windows 2000.

CAUSE
The problem lies in the &quot;Protected Storage&quot; service. CryptoAPI uses protected storage to store and access the public/private key pair.

When a thread creating a machine key runs under a user account with a loaded profile, only user accounts with loaded profiles can access the private machine key. For example, if the interactive user creates a machine key, the IUSR cannot use the private key unless IUSR's profile is loaded. This behavior contradicts the reason for creating a machine key.

RESOLUTION
There are two possible ways to avoid this problem:


 * The best solution is to make sure that the user account that creates the key does not have a loaded profile.
 * If the application is accessing an existing machine key (in other words, you don't have control of the key creation), you can load the user's profile programmatically before calling any crypto APIs. The LoadUserProfile API can be used to accomplish this. LoadUserProfile requires administrative privileges. Therefore, writing a Windows NT service to load the user's profile is the best approach.

MORE INFORMATION
Machine keys are created by a call to CryptAcquireContext with the CRYPT_MACHNE_KEYSET|CRYPT_NEWKEYSET flags followed by a call to CryptGenKey with the AT_KEYEXCHANGE or AT_SIGNATURE flag.