One of my favorite softies, Eric Fleischman, is doing some S.DS.P programming these days.  He demonstrates a useful technique, which is how to do WKGUID searches to find well-known objects in AD or ADAM.  For those not familiar with this, AD and ADAM have a set of "well-known" objects that the directory always contains and applications may need to find to do reasonable things.  However, the names of these objects may be internationalized, so it may not be possible to find them by name across different implementations of the directory.  By referencing them by the "well-known" GUID, a published value, you can always find them.

One of the things we didn't do in our book was provide matching S.DS.P samples for most of the techniques.  In fact, we barely covered it at all.  I still have some regrets about this, although I also think we probably did the right thing.  If the book had been 800 pages due to all the extra samples, that would have been tough.  I do think there might be a place to supplement the material with online materials at some point.  I'm not sure another print tome dedicated to the subject would ever sell very well as the audience is probably limited and likely needs the material less than than the audience we originally wrote the book for (I could be wrong about this).  The internal debate continues...

One of the things that Eric does hit on is the somewhat sad state of affairs of the MSDN DS API documentation.  The S.DS.P docs are especially heinous, as they include almost NO samples and even have some stuff documented as wrong or misleading.  For example, the documentation for the DistinguishedName property on the SearchRequest class doesn't even succeed in identifying that as the search BASE of the search, instead calling it the "object to search for".  If it wasn't for the fact that there is no other obvious choice, an experienced LDAP programmer might not even understand what it is doing!

Additionally, the SDK docs for the directories themselves (AD and ADAM) are still mostly written for the unmanaged VB or C++ programmers with little attention to the managed code devs (although ADAM is much better about that).  However, you won't find a single S.DS.P sample in any of that.  It is as if the API didn't exist.  The managed code docs are also spread out between the .NET SDK and the Directory Services SDK, so it is hard to know where to look to get help.

There are two things missing here. 

• The S.DS.P docs are just embarassing and must be improved.  I'll give it some more time. 
• The overall DS API documentation lacks strategy and makes the platform harder to consume than it needs to be.  Sure, that helps drive sales of our book, but trust me, we didn't write it to make money.

On the bright side, there is a lot of low hanging fruit available here. :)

Ok, so I've bought a new house, sold my old one, moved and have my life returning to its typical state of order.  Baseball season ended tonight (congrats to the Cards; I couldn't really get into it though), I have broadband and the weather is starting to lend itself towards staying inside.  As such, it is time to start blogging again and getting back into some technology. 

For anyone who may have ever subscribed to this humble sign post and was not impressed by the quantity of content forthcoming, I will now try to ratchet things back up.

On my mind these days are still ADFS and Identity Federation in general (which we are getting close to deploying at the mothership now), directory programming (as usual), crypto and application-level authorization approaches (a la AzMan).  Let's see what I can come up with.  :)

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).