This KB article mentions an issue where signing or encrypting information may result in a network IO call to a Domain Controller.

Apparently the RSACryptoServiceProvider's SignData and VerifyData looks up the OID in AD, but the purpose of this call eludes me.

What could be the possible security benefit of this? I'd like to learn more about it.


When you call SignData() or VerifyData(), you must specify which hash function to use (because signatures operate on hashed messages). Moreover, with RSA specifically as described by PKCS#1, the hash value is encapsulated inside a structure which contains the object identifier (OID) of the hash function. The invoked method must thus map the provided hash function specification (which can be a string) to the corresponding OID, and, in the Active Directory, this must go through the AD server (the AD server is a kind of gatekeeper for such mappings).

When the calling code runs as a local account, the AD server may refuse to respond, hence the delay.

This is a misfeature of the .NET implementation: for hash functions specifically, the code should know of the OID of the hash functions it implements (there are not so many) and should not need to talk to the AD server for that (these OID are "well-known" and standardized, they cannot change at the whim of an AD administrator).

  • So I guess that means that OIDs are stored in AD somewhere for this to work? Is there any legitimate reason for this feature? – goodguys_activate Aug 22 '12 at 14:40
  • I suppose that the OID are not really in the AD, but the code in .NET first tries a generic conversion method which looks in the AD. After all, when the delay occurs, the AD refuses to respond, but the signature generation or verification still succeeds. – Tom Leek Aug 22 '12 at 21:49

Isn't the AD acting as a Certificate Authority:

013e3928 794f8a95 mscorlib_ni!System.Security.Cryptography.X509Certificates.X509Utils.OidToAlgId(System.String)+0x15


        // Verify the data using the signature.  Pass a new instance of SHA1CryptoServiceProvider
        // to specify the use of SHA1 for hashing.
        return RSAalg.VerifyData(DataToVerify, new SHA1CryptoServiceProvider(), SignedData);
  • Are you saying that you debugged VerifyData to see the call to AD? I'm not sure if a CA even needs to be present to make the API connect to AD (RSA can make its own keys). Does the call still exist when the CA is moved to a non DC? – goodguys_activate Jul 23 '12 at 14:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.