An interesting thread popped up on the newsgroups today involving a poster who was trying to prevent his LDAP client from doing client certificate authentication by using a feature in the LDAP API that allows you to supply a callback function that handles the client certificate selection process.  Unfortunately, the poster found what he thought was a memory leak.

The intrepid Joe Richards jumped in and with the help of the trusty MVP source access, his brain and a helpful MS employee, found the bug, reported it and created a workaround.  Nice job!  Joe goes into excruciating detail, so I won't add anything to his investigation.

The interesting thing for .NET developers is that this issue potentially affects users of System.DirectoryServices.Protocols (SDS.P).  SDS.P provides a direct wrapper around the leaking callback function in the LDAP API with the QueryClientCertificateDelegate method.  I did a a little Reflectoring and it looks to me like the workaround Joe suggested isn't implemented in SDS.P.

Thus, if you are using this callback, you could have the same memory leak.  The thing that really sucks is that Joe's workaround requires that you have a pointer in the allocated structure so that you can pass it into the appropriate deallocation function.  However, the .NET function prototype conveniently marshals all the data for you into an array of byte arrays, so you no longer have the pointer.  As such, you can't implement the workaround in .NET at all.

As such, in order to deal with this situation, you probably need to the QFE that Joe mentions (or perhaps a patch to SDS.P, although to my knowledge no such thing exists). 

I discussed this particular function's friend, VerifyServerCertificateCallback, in my posting describing how to check a domain controller certificate expiration date on its SSL/LDAP cert.  The QueryClientCertificateCallback is useful when you need to pick a specific client cert, or when you want to prevent the automatic Schannel layer for looking for a client certificate at all (which is what the original poster was doing).  The client certificate negotiation can be really slow and isn't really helpful in a lot of circumstances if you don't want to try to use client certificate authentication to bind with (which is another black hole of MS LDAP client documentation void best saved for another post).