In my previous article, we talked about using LDIFDE to export data from Active Directory, and learned some basic command syntax to get the results we want. Of course that's a good start, but now we need to figure out how to perform skilled surgery to knife through the mounds of objects and attributes to get exactly what you need. The way to do that, of course, is to understand how LDAP search filters work. Understanding the basic principles makes it easy to formulate whatever search you want.
In order to set the stage for the search, you need to define the "scope" of the search. There are three scope options as indicated in Figure 1. They are, Base, One Level, and Subtree. The scope defines the extent of the search from the RootDN. Think of the RootDN as the starting point in the directory for your search.
Figure 1
Note in Figure 1 that the BASE is OU=USA,DC=Corp,DC=COM. If you set the search scope to BASE, the search only takes place at the OU object (not objects below). The scope option in LDIFDE is –p. The following LDIFDE command performs a base level search at the Engineering OU:
C:\>ldifde -f search.ldf -s corp-dc2 -d ou=Engineering,dc=corp,dc=net -p bas
Connecting to "corp-dc2"
Logging in as current user using SSPI
Exporting directory to file search.ldf
Searching for entries...
Writing out entries.
1 entries exported
The result is shown in the search.ldf output file:
dn: ou=Engineering,dc=corp,dc=net
changetype: add
objectClass: top
objectClass: organizationalUnit
ou: Engineering
distinguishedName: OU=Engineering,DC=Corp,DC=net
objectCategory:
CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=Corp,DC=net
While I didn't list all the boring attributes, note that this search only returned one object -- the OU object.
The One Level scope, as noted in Figure 1, searches one level in the tree below the RootDN. Thus changing the LDIFDE example above using the –p One Level option returns the following result:
C:\>ldifde -f search.ldf -s corp-dc2 -d ou=Engineering,dc=corp,dc=net -p onelevel
Connecting to "corp-dc2"
Logging in as current user using SSPI
Exporting directory to file search.ldf
Searching for entries...
Writing out entries..............
100 entries exported
Of course the search.ldf file contains objects in the Engineering OU such as:
dn: CN=EngUser1,OU=Engineering,DC=Corp,DC=net
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: EngUser1
distinguishedName: CN=EngUser1,OU=Engineering,DC=Corp,DC=net
dn: CN=EngUser10,OU=Engineering,DC=Corp,DC=net
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: EngUser10
distinguishedName: CN=EngUser10,OU=Engineering,DC=Corp,DC=net
…and so forth.
The final scope is Subtree. Subtree, as we can see in Figure 1, searches from the RootDN to the end of that branch of the tree. In our example, this scope would include all the objects in the Engineering OU as well as any child OUs and their subordinate objects.
C:\>ldifde -f search.ldf -s corp-dc2 -d ou=Engineering,dc=corp,dc=net -p subtree
Connecting to "corp-dc2"
Logging in as current user using SSPI
Exporting directory to file search.ldf
Searching for entries...
Writing out entries........
115 entries exported
The output below, with the attributes trimmed for brevity, lists the child OU Staff under Engineering, and the Hourly and Professional OUs under Staff, as well as Users in each:
dn: OU=Engineering,DC=Corp,DC=net
dn: OU=Staff,OU=Engineering,DC=Corp,DC=net
dn: OU=Hourly,OU=Staff,OU=Engineering,DC=Corp,DC=net
dn: CN=EngUser15,OU=Hourly,OU=Staff,OU=Engineering,DC=Corp,DC=net
dn: OU=Professional,OU=Staff,OU=Engineering,DC=Corp,DC=net
dn: CN=EngUser18,OU=Professional,OU=Staff,OU=Engineering,DC=Corp,DC=net
dn: CN=EngUser14,OU=Staff,OU=Engineering,DC=Corp,DC=net
Note that in the previous example we used the –p subtree search. Actually "subtree" is the default search scope. So the previous LDIFDE example would return the same results if it were entered like this:
C:\>ldifde -f search.ldf -s corp-dc2 -d ou=Engineering,dc=corp,dc=net
Now we are ready for the object class filters. Suppose that we want to get a list of all users in the Engineering OU. We know that there are computer, group, and printer objects in that OU but we just want the users. Using the LDIFDE commands we have learned to this point, the searches would return all users, groups, printers in the OU -- much more than we want. The LDIFDE option –r specifies an object filter. The default filter is all object classes – (objectClass=*). Thus, all the previous searches we have done have used the default object filter. They could have been specified with the –r filter like this:
C:\>ldifde -f search.ldf -s corp-dc2 -d ou=Engineering,dc=corp,dc=net –r "(objectClass=*)"
Note the –r option has the option enclosed in quotes. Note that the LDIFDE online help shows an example of this option.
It should be somewhat obvious that simply plugging in the word User for the * in the search filter will give us the users:
C:\>ldifde -f search.ldf -s corp-dc2 -d ou=Engineering,dc=corp,dc=net –r "(objectClass=user)"
Likewise you could insert any object class in the filter specification -- such as computer, printer, group, etc. Of course you may not have all the objectClass names memorized, so you need to find a list somewhere of all possible objectClass names. This is easily obtained either via the ADSIEdit tool (available in the Windows Support Tools on any Windows Server CD), or the Schema Manager snap-in (built in but you have to find it).
Figure 2 shows how we expanded the Schema folder, then the CN=Schema, CN=Configuration, DC=Corp, DC=Net folder exposes all classes and attributes. I sorted on the CLASS column in the right pane which separates the classes from the attributes. In the screen shot here, you can see the User class highlighted. Notice that other common classes you might be interested in include Server, Site, Site Link, etc.
Figure 2
If you want to use the Schema Manager, you first must have Schema Operators privilege. It isn't exposed by default for security reasons. All you need to do is to register the dll:
Regsvr32 schmmgmt.dll
Then you can open an MMC and add the snap-in "Active Directory Schema" snap-in.
In the next installment, I will go into more detail on how to further filter your search by restricting the search to a certain attribute value. For instance, if you want all users whose surname begins with the letter M. In addition, we can limit the return to list only certain attributes, such as getting a list of all your users and list only their street addresses and postal codes.
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers.
