Directory Programming .NET

Is one method faster or better than the other for binding to ADAM objects?

Ex:
LDAP://myserver:myport/CN=object1,OU=objectGroup,DC=example,DC=com
vs
LDAP://myserver:myport/<GUID=someguid>

I know that the GUID never changes, whereas a DN can (from moving for example), but the objects that we add to our ADAM are never going to move around. We are currently wondering how to store references to the ADAM objects in our web pages, and we are not sure if it is better/faster to use the DN or the objectGUID.

I actually don't know which is faster although I would not be surprised if the GUID was.  If you need to store external references to directory objects, you should always use the GUID when possible because it is a strong, immutable key.  To me, that's the key to the answer.

I second what joe is saying.  I wrote an app once that stored the DN and we ran into all sorts of problems later because people got re-organized in the domain so their DN changed.  In our case, if a user left the company, they got moved to a different OU for a period of time before we deleted their account.  It was in 2001 or 2, so there was a lot of layoffs going on after the .com bust and I found my app crashing pretty quickly.

I coverted it to using the GUID and the problem was solved.  There is one gotcha however.  You cannot use the .Parent with the GUID syntax.  You would need to change the path back to the DN (base search on DN) to get access to that.

---

Ryan Dunn
Extemporaneous Mumblings
The .NET Developer's Guide to Directory Services Programming

dunnry I am not sure what you mean by "you cannot use the .Parent". I performed the following and the result was correct:
            string strGuid;
            using (SDS.DirectoryEntry entry = new SDS.DirectoryEntry("LDAP://localhost:10636/OU=Connections,OU=Gator,OU=Program Data,DC=example,DC=com", "admin", "admin", SDS.AuthenticationTypes.SecureSocketsLayer))
            {
                object o = entry.NativeObject;
                strGuid = entry.NativeGuid;
                using (SDS.DirectoryEntry par = entry.Parent)
                {
                    string strName = par.Name;//Correct name is shown.
                }
            }
            using (SDS.DirectoryEntry entry2 = new SDS.DirectoryEntry("LDAP://localhost:10636/<GUID=" + strGuid + ">", "admin", "admin", SDS.AuthenticationTypes.SecureSocketsLayer))
            {
                object o = entry2.NativeObject;
                using (SDS.DirectoryEntry par2 = entry2.Parent)
                {
                    string strName = par2.Name;//Correct name is shown.
                }
            }

Fascinating.  It didn't used to work that way.  It would actually bomb out on you with a COMException.  Granted, I haven't looked at this in awhile, so I have no idea when they fixed it.  It must have been fixed in the ADSI stack as this has nothing to do with .NET actually.

If you check the MSDN docs, they still actually list that limitation.  The reason it was a limitation was pretty simple - they were using the underlying IADs object.  Here is the code for .Parent for instance:

public DirectoryEntry Parent
{
    get
    {
        this.Bind();
        return new DirectoryEntry(this.adsObject.Parent, this.UsePropertyCache, this.GetUsername(), this.GetPassword(), this.AuthenticationType);
    }
}
 
Notice that they are using 'adsObject' here and calling the .Parent on it.

Now, refer to the documentation and the relevant part:

When binding using the object GUID, some IADs and IADsContainer methods and properties are not supported. The following IADs properties are not supported by objects obtained by binding using the object GUID:

ADsPath
Name
Parent
The following IADsContainer methods are not supported by objects obtained by binding using the object GUID:

GetObject
Create
Delete
CopyHere
MoveHere
To use these methods and properties after binding to an object using the object GUID, use the IADs.Get method to retrieve the object distinguished name and then use the distinguished name to bind to the object again.

I would be interested in knowing if the .Rename and .MoveTo functionality works now as well.  This syntax used to not work with those (as documented).

Anyhow, good to know.

---

Ryan Dunn
Extemporaneous Mumblings
The .NET Developer's Guide to Directory Services Programming

A quick check on my last thoughts show that indeed, MoveTo now works as well (which means Rename works).  Fun facts...

---

Ryan Dunn
Extemporaneous Mumblings
The .NET Developer's Guide to Directory Services Programming

This may also be an ADSI/Windows OS capability change and have nothing to do with .NET, so the answer as to whether or not this might or might not work could depend simply on the OS version.

I seem to remember having to code around this a long time ago to accomodate this in Win2K and then seeing it get fixed later in 2K3, but I don't really know the details or if the fix was ever back ported.

Someone on the product team will likely know.  :)

Yep, you might have missed it, but it is definitely a change in ADSI and not .NET.  Sometimes this is a change in ADSI capabilities via OS and SP level, and other times it is an update to ADSI that gets pushed to all platforms as a bug fix.  No idea which one it was.  I will ask out of curiosity and also get them to fix the MSDN pages.

---

Ryan Dunn
Extemporaneous Mumblings
The .NET Developer's Guide to Directory Services Programming

Hmm, joe's comments about this being an OS specific fix makes me cringe. OS bugs are hard to detect and cause no end of headaches for the tech support group. Our application will make much use of the .Parent property, so if using the GUID method is questionable, we'll stick with the DN for now. Thanks again guys.

Unless you plan to run your code on older Win2K systems, I wouldn't worry about this too much.  Some of this experience comes from 5 or 6 years ago.  :)

That said, you can do what you want.  However, I still recommend you don't store DNs externally.  Use the GUID as an external key.