Friday, August 04, 2006

Fast Concurrent Binding in SDS.P

So, this is really a lesson learned about putting together a book and code samples.  Namely, refactoring your code just before the final cut is generally not a good idea.  Or perhaps I should say, refactoring your code and not thoroughly testing it is not a good idea.

In Chapter 12 of the book, we had a number of examples for how to perform authentication.  One of them was using System.DirectoryServices.Protocols (SDS.P).  The sample tried a number of techniques – first a secure SSL bind using Fast Concurrent Binding (FCB), then it tried either a secure SPNEGO bind or a Digest bind (if ADAM).  Well, initially these were all different samples.  I thought it might be nice to tie them all together a bit more comprehensively – hence the refactoring.  I figured that a bigger sample that did more in a practical manner was more useful than a few line snippets that showed each one.

Anyhow, what ended up happening is that I broke the FCB authentication during the refactoring.  Because of unforseen testing environment meltdown a week earlier I did not have the proper Win2k3 clients to test again (it used to work, really!).  So… I borked it because the FCB code never got tested again.

One of my Avanade co-workers was actually implementing something like this and asked why it was not working.  At first I chalked it up to an environment thing, but after a closer inspection I noticed what the issue was.  Namely, in my attempt to bring all the samples together I had attempted to reuse the same connection for authentication as the bootstrapping.  Well, you can’t do that with FCB – you have to enable it before you bind and cannot turn it off until you close the connection.

The good news is that it is a fairly simple fix and I have already refactored (yet again) to support it.  I will be posting that code in another week or so when I get back from vacation.  Then poor Joe gets to convert it yet again to VB.NET.  Mea Culpa…

Comments [2] August 4, 2006 Trackback  # Tracked by:
"Using Fast Concurrent Binding in SDS.P" (Joe Kaplan) [Trackback]

Tuesday, August 08, 2006 1:08:02 PM (Eastern Standard Time, UTC-05:00)
I love the book and the blog. Thank you!! Your book ranks in my top three (where the others are Inside Active Directory by seitsonen and kouti and my own book LDAP Directories Explained). :)

Anyhow, I'd like to share a couple tidbits I've gleaned in the SDS.P space since you don't spend much time on it in the book, and the blog seems to have a few extra gems in that area.

First, on the blog I've listed above as my homepage, there is a working copy of code that'll do an external SASL bind with a cert. I've specifically used it with a Windows client talking to an openldap server. See http://viewpoint.cac.washington.edu/blogs/winauth/Lists/Posts/Post.aspx?List=579f5597%2Dbcf9%2D4c73%2D9671%2D6f99b4e2e8db&ID=11&Source=http%3A%2F%2Fviewpoint%2Ecac%2Ewashington%2Eedu%2Fblogs%2Fwinauth%2FLists%2FPosts%2FAllPosts%2Easpx to go directly to the code snippet.

As an aside, speaking of external SASL bind, LDP.exe doesn't support it, even though it's in several of the LDAP standard RFCs, and LDP.exe claims to support SASL.

I also have a gotcha kinda thing for SDS.P timelimits. There are several places you can set a timeout value:
System.DirectoryServices.Protocols.LdapConnection.Timeout
System.DirectoryServices.Protocols.SearchRequest.Timeout

that don't affect the actual ldap query timeout at all.

Instead, you need to set it at:

System.DirectoryServices.Protocols.SearchResponse = System.DirectoryServices.Protocols.LdapConnection.SendRequest(System.DirectoryServices.Protocols.SearchRequest, system.timespan)

to affect the ldap query timeout. This is non-obvious and I'm sure will save someone time hunting it down.

Finally, I appreciate your comments on attribute range retrieval in the book. While the code is more or less the same as what's in MSDN, the comments are very useful. I've written a range retrival-aware method that mimics the .contains method so that I can test for the existence of a member before trying to add it to a group. I'm hoping to convince MS that they should add a method with this functionality to the framework--having a "broken" .contains method that doesn't work in all cases (and isn't documented that way specifically) is rather dangerous. I'd appreciate it if others would also ask MS for a fix along these lines. :)
Brian Arkills | barkillsAT NOSPAMcac dot washington dot edu
Tuesday, August 08, 2006 1:11:26 PM (Eastern Standard Time, UTC-05:00)
Oh ... one other thing ... do you know how to get ldp.exe to use attribute range retrieval? Using the same syntax doesn't seem to work ...

I suspect they've hard-coded the member behavior based on how they truncate the results after a few lines, even though they show that there are (at least) 1500 members.
Brian Arkills | barkillsAT NOSPAMcac dot washington dot edu
Comments are closed.