Binding to Active Directory Objects
Before continuing with this scenario, you must understand how objects are named in Active Directory. A simple analogy for understanding the object naming system can be made by looking at how files are named within a file system. Each file has a name and a path. The file name must be unique among siblings. Consider the following example: "c:\public\specs\adsi25.doc". In this case, the file name is "adsi25.doc" and the file path is "c:\public\specs\adsi25.doc".
Objects in Active Directory are named in a similar manner. Every object has an object name or relative distinguished name (RDN), and an object path or distinguished name (DN). The RDN or object name has two parts: the attribute ID and the value itself. For example, "DC=Fabrikam". DC is an RDN attribute ID and stands for domain component, and Fabrikam is the value of the attribute. In this scenario, the distinguished name of the Fabrikam domain object is "DC=Fabrikam,DC=Com". A DN is composed of multiple RDNs.
In ADSI, the binding string is called the ADsPath. The ADsPath contains the service provider moniker, which identifies the type of service that is being used, followed by the distinguished name of the object. LDAP or WinNT are examples of service provider monikers. So an ADsPath looks like the following:
Now, you can bind to the domain object as follows:
When you run this code example, ADSI uses the DN to determine which ADSI objects to bind to. When ADSI has bound to these objects, you can access all methods available on those objects. For example, the previous code example binds to IADs and IADsContainer. You can now use methods on those interfaces such as Get, Put, Create, Delete, MoveHere, and so on.
When you have a domain object, you can print some of its attributes: