Extracting Active Directory info quickly and easily with LDIFDE

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!

LDIF is actually a standard interface for LDAP (RFC 2849 which can be found at here ). LDIF describes Directory and Directory entries in text format. Simply put, you can extract object and attribute data from the directory and have it output in simple text format, as well as using it to read a simple text file to create objects in the directory. Microsoft provided LDIFDE.exe as a command line tool, native to all server versions of Windows 2000, 2003, etc. While it is not native to Windows XP, you can simply copy the ldifde.exe file from a server to an XP workstation and it will work. It uses common LDAP syntax and structure to export from or import data into Active Directory. Since it is a standard, it can also be used to move objects such as users, groups, etc. between LDAP directories.

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:

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). This is an interesting command...

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT Microsoft Active Directory Scripting Scripting domain controller installations: A must for Server Core Introducing Active Directory to Windows PowerShell Simple WMI tricks for AD administrators Active Directory LDAP scripting made simple Scripting School: Connect scripts to remote computers Taking computer names as arguments Using WSH Controller Connect scripts to remote computers: Summary Reading computer names from Active Directory Reading computer names from a file Microsoft Active Directory Tools and Troubleshooting How to find and remove lingering objects in Active Directory DNS troubleshooting best practices Generating a DNS health check in Windows Debugging Windows client logon delays: Narrowing the scope Troubleshooting poor Windows logon performance in Active Directory environments New Operations Manager 2007 feature allows for automated agent deployments Taming the LSASS.exe process for Active Directory performance and security Active Directory FAQs Troubleshooting Active Directory database errors Troubleshooting a cross-forest trust in Active Directory Active Directory Administration How to find and remove lingering objects in Active Directory Utilizing Active Directory snapshots in Windows Server 2008 Creating Windows taskpad views for Active Directory management When to add new domains to your Windows environment Debugging Windows client logon delays: Narrowing the scope Using Active Directory to manage Macs in a Windows environment Troubleshooting poor Windows logon performance in Active Directory environments Common Active Directory security oversights Scripting domain controller installations: A must for Server Core Taming the LSASS.exe process for Active Directory performance and security

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

. 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: 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: Note 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.

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.