As mature as Active Directory is, it still amazes me how many admins I talk to who have no idea how to write simple LDIFDE.exe commands to gather data for routine operations. My next few articles will give you some simple instructions on how to take advantage of this tool to gather Active Directory data without using those painful UIs -- even for the scripting impaired!
O.K. -- so now you know the boring stuff -- let's look at a few simple commands. Note that just by typing LDIFDE at a command prompt on a server, the help file will be output. The LDIFDE command contains several basic components:
LDIFDE -i import (default option is export)Examples
-f (file name) name of import or export file)
-s (server name) name of server to bind to for the operation
-d (Ldap path) Distinguished name for the path to the object(s) desired
-r (ldap object filter) Filter the results using common ldap filters
-l (ldap attribute filter) lists attributes to be returned on the object in the object filter.
Here are some basic examples you can cut your teeth on.
This first command will dump the entire AD into a file called ADdump.ldf. Note that since export is the default, we don't have to give it an export option. The -f option directs the output to ADdump.ldf and the -s option binds to the domain controller ATL-DC01 for the operation. If the -s option is missing it will bind to the DC you are executing the command from (assuming you are on a DC).
LDIFDE –f ADdump.ldf –s ATL-DC01This is an interesting command. Since users have read access to the directory, any user can put LDIFDE.exe on his or her workstation and dump the entire AD into a text file. This seems like a bit of a security hole -- especially if you store private data like Social Security numbers, Employee Badge Numbers, etc. that could be exposed with the dump of the user objects. There is no way around this as users must have read privileges. As one Admin put it, "At some point, you have to trust the users."
Obviously, you don't want to dump the entire AD and then sort through piles of data to find what you are looking for. LDIFDE uses common LDAP filters to narrow the search. Here are a few examples of how you can use the LDAP filters.
Suppose you want to get the attributes of all users in the Americas OU in the Corp.net domain. Using the -d and the -r command options described previously, the command would look like this:
Ldifde –f users.ldf –s hpqnet-dc4 –d "OU=USA, dc=corp,dc=net" –r "(objectClass=user)"Note that for the -d option, the LDAP path is the distinguished name (DN) for the OU. The -r option defines the objectClass. In this case, we just want Users. This would dump all attributes of all users. The data returned from one user would look similar to this:
dn: CN=Gary Olsen,OU=Americas,DC=Corp,DC=NetNote the values of the objectGUID, objectSid, pwdLastSet, and AccountExpires attributes are unintelligible. There is some data that has to be reformatted via a script to get the right data. This will be discussed in a future article.
cn: Gary Olsen
displayName: Gary Olsen
distinguishedName: CN=Gary Olsen,CN=Users, ,DC=Company,DC=com
name: Gary Olsen
This article has given you some basics. You could use the same sample command and replace the User objectClass with Computer, or any other valid objectClass. There are also ways to filter certain attributes, such as returning only the street address, or perhaps return only users with a surname beginning with "A". These advanced operations require a bit more digging into LDAP search syntax. In the next few articles, I will give you a brief tutorial on LDAP searches and how to implement them in LDIFDE commands.
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.
This was first published in May 2006