Eric Fleischman's WebLog

I'll think of a clever title one day. Today's not that day. Tomorrow's not looking good either.

Finding the lost&found container in S.DS.P...or anything that isn't ADSI really

Finding the lost&found container in S.DS.P...or anything that isn't ADSI really

  • Comments 2
  • Likes

I found myself writing a piece of C# which would go hunt for objects in lost&found today. This is a pretty straight forward task….find that container, pop in to it and search away. I usually do this by looking at the lost&found well known GUID (which is GUID_LOSTANDFOUND_CONTAINER_W in the platform SDK) then just crafting the search by hand.

 

Anyway, I was feeling particularly lazy today so I went to take a quick look at MSDN and just use their sample. Much to my surprise the only examples I could find did this via ADSI and talked about “binding to well-known objects using WKGUID.” (I’ve NEVER been a fan of the use of terms there…I don’t like how we say “binding to an object” in ADSI as that is a somewhat unnatural construct given what’s really going on under the hood. Further, it makes moving to wldap32/S.DS.P/etc. harder as the terms are different. If only I ruled the world.....) Given this, I figured I’d paste some sample code here.

 

First, the LDAP work itself. To do a search for L&F, you want to craft a search as follows:

            Base DN: <WKGUID=GUID_LOSTANDFOUND_CONTAINER_W,dc=someNC,dc=com>

            Search filter: (objectclass=*)

            Search scope: Base

To dissect that baseDN some…..WKGUID means “well known GUID”, instead of the string I pasted in italics (GUID_LOSTANDFOUND_CONTAINER_W) you would of course want to actually use the GUID there, and then after the comma you put the DN of the naming context you wish to search (for example, dc=mydomain,dc=com).

 

So here’s a quick and dirty piece of C# written against System.DirectoryServices.Protocols APIs that would get this DN for you. Please note that this is sample code so you really want to robustify it some before actually putting this in an application, and clean up the little foreach I have there just because I’m being lazy. ;)

 

            string lAndFBaseDN = String.Format("<WKGUID={0},{1}>", GlobalVars.GUID_LOSTANDFOUND_CONTAINER_W, myNCDN);

            string[] attrList = {"dn"};

            string searchFilter = “(objectclass=*)”

            SearchRequest sr = new SearchRequest(lAndFBaseDN,searchFilter,SearchScope.Base,attrList);

            SearchResponse searchResponse = (SearchResponse)myLdapConnection.SendRequest(sr);

            if (searchResponse.Entries.Count == 0)

            {

                // Must be no l&f container in the target dn (like, target not an NC for example)

            }

            Debug.Assert(searchResponse.Entries.Count == 1, "More than one L&F container found. This is weird.");

            // If there is more than one, we just return the first. But there should not be.

            foreach (SearchResultEntry sre in searchResponse.Entries)

            {

                return sre.DistinguishedName;

            }

 

I think it goes w/o saying but you can apply similar logic to other well known GUIDs. I just picked l&f as it was convenient. ;)

Comments
  • "Robustify" - I think I found a new term... ;)

  • I reserve the right to make up any word or set of words needed to get my point across. English is just so limiting... ;)

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment