I was lucky enough to attend DEC again this year and was even more lucky to have been asked to speak due to an unfortunate last minute cancellation.  This year, I presented on a variation of the same type of stuff that Ryan and I presented on at DEC 2006.  This year, I had to fly solo as Ryan could not attend.  :(

Here's what we did differently this time around:

• No PowerShell (DEC already had 2 PowerShell sessions, so why bother?)
• Focus on some new Longhorn LDAP and AD features (Fine Grained Password Policy)
• A "slideware" overview of what's coming in .NET 3.5 "Orcas" with the new System.DirectoryServices.AccountManagement namespace (formerly known as the Principal API).

I'd like to thank all of those who attended.  I hope you enjoyed the talk and hope that some of you got free books.  I apologize if I could not accomodate all of you.  :(  Thanks to the Addison-Wesley marketing team for providing the books for your enjoyment.

For those of you interested in the Snippet Compiler tool I used in my demos, you can find it here.

The slides and code for the demos are attached and I did get around to converting them to VB for all of you VB people (I'm a VB.NET guy too; I really don't know why I coded all the demos in C# :)). 

Note that my application of the "in chain" matching rule turns out to be incorrect usage.  Don't do it like that!  Read more here.  I feel silly.

Note that if you are confused about which API to use, S.DS or S.DS.P, I discussed that in some detail here.  There is really no right answer, but hopefully that helps. 

To ask us any specific questions about LDAP programming, please use the book's discussion forum.  This is the only place that Ryan and I both use together.

As always, DEC is a treat and I really enjoyed all the conversations and interaction and am happy to see ADFS gaining a little traction.  Now, about that hot chicken...

Microsoft has added a new LDAP feature to AD in Windows 2003 SP2 and Longhorn server called the LDAP_MATCHING_RULE_IN_CHAIN.  Essentially, it is an extension filter type that allows you to search withing the content of a distinguished name-syntax attribute and do matching throughout the entire chain of linked values instead of just within the immediate values.  The docs are here and the syntax looks like this:

(memberOf:1.2.840.113556.1.4.1941:=CN=some group,CN=xxxx,DC=xxxx,DC=xxxx)

I showed some examples of this in my talk at DEC where I used some searches with and without the extension filter type to show traversal of some nested group membership.

Ryan also wrote about this a while ago and discovered that while useful, this technique is very slow for expanding group membership and it seems to be much faster to just use recursive searches.

As it turns out, the problem is that we were trying to use this feature incorrectly.  The "In Chain" filter type should NOT be used for transitive link expansion!  It is intended to be used for matching only.  Perhaps that's why they called it LDAP_MATCHING_RULE_IN_CHAIN.  :)

As such, you should really only use it in a base level query.  If you use the filter shown above in a base level query, it will still tell you if the object that is used as the search root is a member of the specified group anywhere in the nesting chain, but it will perform fine.  If you use it for anything else, you are asking for trouble. 

Now, when will we get some sort of transitive link expansion widget that actually works well for this purpose?