- New Features in Windows Server 2003
- Limitations of Classic NT Security
- Directory Service Components
- Brief History of Directory Services
- 500 Overview
- LDAP Information Model
- LDAP Namespace Structure
- Active Directory Namespace Structure
- Active Directory Schema
- Active Directory Support Files
- Active Directory Utilities
- Bulk Imports and Exports
- Moving Forward
This chapter is from the book
This chapter is from the book
This chapter is from the book
Bulk Imports and Exports
You may find yourself in a situation where you want to dump information out of Active Directory into a flat file for searching. Or you may need to create large numbers of objects and you want to simplify your work by importing information from a flat file. A standard Windows domain controller has a couple of utilities that help with this kind of bulk object processing. First, we need to take a look at the format for exchanging LDAP information.
LDAP Data Interchange Format (LDIF)
RFC 2849, “The LDAP Data Interchange Format (LDIF)—Technical Specification” defines a standard structure for exchanging LDAP information. The following example shows the LDIF format for the attributes of the Administrator account in the Company.com domain:
dn: CN=Administrator,CN=Users,DC=company,DC=com memberOf: CN=Group Policy Admins,CN=Users,DC=company,DC=com memberOf: CN=Enterprise Admins,CN=Users,DC=company,DC=com memberOf: CN=Schema Admins,CN=Users,DC=company,DC=com memberOf: CN=Administrators,CN=Builtin,DC=company,DC=com memberOf: CN=Domain Admins,CN=Users,DC=company,DC=com accountExpires: 9223372036854775807 adminCount: 1 badPasswordTime: 125693193676075896 badPwdCount: 0 codePage: 0 cn: Administrator countryCode: 0 description: Built-in account for administering the computer/domain isCriticalSystemObject: TRUE lastLogoff: 0 lastLogon: 125693891796993128 logonCount: 109 distinguishedName: CN=Administrator,CN=Users,DC=company,DC=com objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=company,DC=com objectClass: user objectGUID:: gLgtb/ju0hGcKADAT1NqTQ== objectSid:: AQUAAAAAAAUVAAAAoF4uDLI/DAf7Cwgn9AEAAA== primaryGroupID: 513 pwdLastSet: 125681556744344992 name: Administrator sAMAccountName: Administrator sAMAccountType: 805306368 userAccountControl: 66048 uSNChanged: 1532 uSNCreated: 1410 whenChanged: 19990410040835.0Z whenCreated: 19990410034956.0Z
There are a few items of note with this example:
-
LDIF files use simple ASCII characters. If you have high-order Unicode values in some of the attributes, they might not survive the translation.
-
Long integers that represent time and dates will be represented in decimal format and, as such, will not survive reimport. These items are discarded and created afresh when an entry is imported and a new object created.
-
Octet strings are converted to Base64 format. This is indicated by a double-colon after the attribute name. ObjectGUID is an example. These values withstand a reimport. For the most part, though, this syntax is used for values that are unique for an object so the imported values would be ignored.
-
The attributes conform to the Active Directory schema for the forest where they were obtained. Attempting to import these values into a foreign directory service can result in compatibility issues. At the very least, you'll need to change the distinguished names, because it is unlikely that the foreign directory service would use the same namespace.
The LDIF standard includes several command verbs that are used to determine what to do with a particular record. These verbs permit adding, modifying, replacing, or deleting an entire object or individual attributes of an object. They also permit modifying the directory schema. Active Directory permits LDIF to add and modify object classes and attributes, but it does not permit them be deleted. After a class or attribute has been added to the schema, it's there to stay.
LDIF and Active Directory Schema Upgrades
Lest you think that LDIF is one of those obscure programmer toys that reasonable system administrators should avoid like it was oozing with plague, consider this: When you upgrade the first Windows 2000 domain controller in a domain to Windows Server 2003, new objects are added and old objects modified to support changes in the new operating system version. In addition, the Active Directory schema must be modified to support the new features in Windows Server 2003. How does Microsoft install these schema updates? With LDIF files, that's how.
Check the Windows Server 2003 CD in the \I386 folder. Look for a series of files with an LDF extension. These contain the LDIF entries that modify Active Directory contents and the schema. The CD includes an uncompressed executable called Schupgr.exe. This executable loads the changes from the LDF files into Active Directory.
One last feature of this upgrade method is important to note. The last step in each LDF file modifies an attribute of the Schema container called ObjectVersion. This is how Windows keeps track of the LDF files applied by Windows updates. Installing Windows Server 2003 upgrades the schema to version number 30. Installing Exchange also modifies the schema but does not change the schema version number.
LDIFDE
A Windows domain controller comes with a command-line tool for importing and exporting LDIF files, LDIFDE. Run ldifde with no switches to get a list of parameters.
LDIFDE simplifies importing and exporting large numbers of records to and from Active Directory, but it also comes in handy for making quick checks of directory entries without opening up a pesky MMC snap-in. Use the –f con switch to direct the output to the console. For example:
-
To know the group membership of a user, use Ldifde –d cn=username,cn=Users, dc=company,dc=com –f con.
-
To check the entries in a trusted domain, use Ldifde –s alb-dc-01.office.company.com –d dc=Office,dc=Company,dc=com –f con.
-
To find all the printers in an organizational unit, use Ldifde –d ou=Phoenix, dc=Company,dc=com –r "(objectclass=printers)" –f con.
You can use LDIFDE to dump a file of information about a user and then modify the settings and the username and import that file as a new user. To do this, use the -m option to remove the SAM-specific information from the dump file.
You can also use LDIFDE to modify attributes of existing objects, but you need to know a little trick. After you've created an LDIF file consisting of entries you want to modify, you must put a dash on the first blank line at the end of the entries and then a blank line after that. Here's an example showing how to change the Description attribute for a user named Avguser:
dn: CN=avguser,OU=Phoenix,DC=company,DC=com changetype: modify replace: Description Description: Wazula -
Without that dash, you'll get an error similar to the following:
Failed on line 4. The last token starts with 'W'. The change-modify entry is missing the terminator '-'.
CSVDE
Working with the LDIF format can get a little tedious because it sorts attributes vertically rather than horizontally. If you prefer a more standard spreadsheet layout, use the CSVDE utility. The switches for CSVDE are the same as for LDIFDE.
Here's an example of using CSVDE. Let's say you are the administrator for a school district and you want to add 5000 new students into Active Directory. Your student list may be in a mainframe or AS400 application or a UNIX application of one form or another or a SQL database. You can write a little JCL (Job Control Language) routine or do a quick SQL query to output the student list to a delimited file. Import the delimited file into a spreadsheet and massage it until you get the required data for Active Directory. (Do a csvde -f output.ldf to see the column headings and data types.) Then use csvde -i to import the spreadsheet contents into Active Directory.
Reimporting LDIF Dumps
If you do an LDIFDE or CSVDE export, many of the attributes for user and group objects are owned by the system and cannot be reimported. Here's a trick. Run the export with the –m switch. This enables SAM Logic, which is another way of saying that the export skips the attributes that are owned by the system. This gives you a template to use when building your import files or spreadsheets.
Other LDAP Tools
Because Active Directory is an RFC-compliant implementation of LDAP, you can use virtually any LDAP tool for browsing objects and collecting information. Here are a few sources of LDAP tools and related information:
-
OpenLDAP (www.openldap.org) . If you are an open source kind of person, you should take a look at the latest wares from that community. These toolkits are not for the fainthearted, and there are no compiled packages to play with, but it's worth a peek if you want to build your own administration tools to replace those clumsy MMC snap-ins.
-
Novell (www.novell.com/products/nds/ldap.html). NetWare 5 boogies on IP and so does NDS. Novell is putting lots of calories into doing the “Internet thing” right. Also take a look at developer.novell.com for LDAP and X.500 tools that might be useful in a mixed network.