| Downloads |
|---|
| 41832.zip |
Within every Active Directory (AD) domain, several special containers serve as the default location for certain types of objects. This feature is useful because it permits applications to default to a particular container if you don't specify a container when creating or searching for that type of object. You're probably familiar with some of these containers—for example, the cn=Computers container is for computer objects, and the cn=Users container is for user and group objects.
You can use VBScript to bind to the cn=Computers container:
Set objComputers = GetObject _
("LDAP://cn=Computers," & _
"dc=rallencorp,dc=com")
This line of code works fine, unless you want to use an organizational unit (OU) to store computer objects. In that case, this code doesn't work. To address this problem, Microsoft supports (in Windows Server 2003 and Windows 2000) another type of binding in AD called a Well-Known GUID (WKGUID) binding. Instead of specifying cn=Computers, you can use a GUID that maps to that container. For example, the WKGUID of the default cn=Computers container is aa312825768811d1aded00c04fd8d5cd. To make your GetObject call resilient to such name changes, you can use the following line of code:
Set objComputers = GetObject _
("LDAP://<WKGUID=aa31282" & _
"5768811d1aded00c04fd8d5cd," & _
"dc=rallencorp,dc=com>")
The only differences are that the container name is replaced with WKGUID=aa312825768811d1aded00c04fd8d5cd and the full path of the object is surrounded by caret brackets. Let's take a look at how to use WKGUID binding and how to change the default WKBIND containers in Windows 2003.
A list of WKGUIDs resides in the wellKnownObjects attribute of the domainDNS object for a domain (e.g., dc=rallencorp,dc=com). The wellKnownObjects attribute is multivalued and uses DNWithBinary syntax. For example, Figure 1 shows what that attribute contains in my rallencorp.com domain. You can use the Ldp tool (part of the Windows Support Tools) to view the attribute for your domain. The format of each value is straightforward:
B:NumberofBytes:GUID: DistinguishedName
Each value contains four elements separated by colons. The first element is the letter B, followed by the number of bytes, which is 32. These two elements will be the same for every value. The third element is the GUID that you would use as part of a WKGUID binding. The fourth element is the distinguished name (DN) to which the GUID maps.
The only item that will always look different from Figure 1 in your domain is the DN. Another potential difference depends on whether you're running Windows 2003 or Win2K: The second and third values are new in Windows 2003 domains.
The code in Listing 1 demonstrates how you can connect to the default Computers container by knowing only the target domain's Fully Qualified Domain Name (FQDN). To make this code work in your domain, change rallencorp.com at callout A in Listing 1 to the name of your domain. The code at callout B sets a constant for the WKGUID that represents the default Computers container. (Another way to get the WKGUIDs is to look them up in the ntdsapi.h file, which is available in the Microsoft Platform Software Development Kit—SDK. You can download the SDK from http://www.microsoft.com/msdownload/platformsdk/sdkupdate.) The code at callout C binds first to the RootDSE entry, then binds to the default Computers container and prints the DN of that container.
WKGUID binding is a nice feature, but Win2K doesn't support the modification of any of the mappings. In Win2K, you're pretty much stuck with the default containers. Because the default containers aren't OUs, you can't apply Group Policy to them. For this reason (among others), most AD administrators don't use the default Computers container as the primary computer account repository or the default Users container to store user and group objects. If you use another location to store computer objects, changing the default Computers container makes sense. Windows 2003 lets you change them.
Listing 2, page 16, contains the code to change the default Computers container. To make the code work in your domain, customize the values for the two variables at callout A in Listing 2. Set the strNewComputersParent variable to the relative DN of the Computers container you want to set as the default, and set the strDomain variable to the target domain's FQDN.
The code at callout B sets up a few constants. The COMPUTER_WKGUID constant is set to the first three elements of the value that represents the default Computers container in the wellKnownObjects attribute. The code uses the other two constants when it calls the PutEx method. At callout C, objects are instantiated for the RootDSE container at the root of the domain (as specified in the defaultNamingContext attribute of the RootDSE entry) and the current default Computers container.
At callout D, the code changes the default Computers container. The first instance of the PutEx call deletes the current default container in the wellKnownObjects attribute. The second instance of the PutEx call adds the new default container that you specified at callout A. Next, the SetInfo method commits the changes. AD requires the container you set to be valid. (You can't delete the value without setting a new value.) Also, the DN of the new container must already exist.
To change the two well-known containers that I've discussed in this article (cn=Users and cn=Computers), you can also use Windows 2003 tools. The Redircmp command lets you change the default Computers container. The command takes a single parameter, which is the container to set as the default—for example,
Redircmp "ou=RallenCorp" & _ Computers,dc=rallencorp," & _ "dc=com"
You can similarly use the Redirusr command to modify the default Users container. Both of these tools are provided as part of the Windows 2003 installation. For more information about using the Redircmp and Redirusr tools, see the Microsoft article "Redirecting the Users and Computers Containers in Windows Server 2003 Domains" (http://support.microsoft.com/?kbid=324949).
