How to export users and groups from Active Directory with ldifde

Compare the number of user, group and computer objects in the LDIF file with the number returned by an LDAP query run against the same domain, using the same filter you used for the export. Count entries by objectClass, not by total lines, because a single user record spans many lines. A count that is lower than the source usually means the export filter excluded objects, such as a base DN that stopped short of a child OU, or a filter that required an attribute some objects lack. A count that is higher often means the query picked up objects of a class you did not intend to move, such as contacts or service accounts. Record both numbers in your migration log so the comparison can be repeated after any re-export.

Pick a sample of groups, including several that contain other groups, and compare their member lists in the export against a direct query of the source. Nested membership is the usual point of failure: a group that holds another group can show fewer effective members in the target if the nested group was exported without its own member entries or if the target does not resolve nesting the way Active Directory does. Check that each member DN in the export points to an object that is also in the file. Dangling references usually mean an object was excluded by the filter or sits outside the exported base DN. Decide before the move whether nesting will be flattened or preserved, because the target directory handles it differently.

Verify the attributes the target system and its consumers actually need, not every attribute the export contains. Typical examples are userPrincipalName, mail, department and the on-premises identifiers, such as sAMAccountName and the attributes used to link objects to other systems. For each attribute, check that the value is present on the same share of users you expect and that it matches the source for a sample of accounts. Blank values usually mean the attribute was not included in the export attribute list, or it is set only on some account types. Also confirm that you omitted AD-only attributes with the -m option as planned, and that no attribute you need was removed by an -o exclusion.

Multi-valued attributes store several values under one name, and LDIF represents each value on its own line. Check that every value appears, that none were collapsed into one, and that the order and separators match what the target expects. Some attributes, such as proxyAddresses or otherMailbox-style lists, carry type prefixes that the target may reject or interpret differently. memberOf is computed by Active Directory from group membership and is not a value you should import as-is, so verify membership through the group entries instead. If a multi-valued attribute is truncated or merged, the usual cause is a line-folding or encoding issue in the export, which you can find by counting values per object on a sample of records.

Open the file in a UTF-8 aware editor and search for a set of accounts with accented or non-Latin names, then compare their displayed values with the source in the Active Directory console or an LDAP query. Garbled characters such as doubled or replaced letters indicate the file was read or saved with the wrong encoding somewhere in the pipeline, not that the directory is wrong. Also check that LDIF values containing special characters or leading spaces were base64 encoded, since the import will fail or silently change them otherwise. Fix encoding at the export and transfer step and re-run the export before you import, so the target never holds a partial copy of names.

Decide whether disabled and expired accounts move at all, then verify that the export matches that decision. Disabled accounts are represented by a flag in userAccountControl, and expiry is held in accountExpires, so check that these attributes are present for accounts you intend to keep and that the target can read them. Counting active and disabled users separately on both sides shows whether the export filter treated them as you intended. Most teams migrate only active accounts and archive the rest, so confirm the policy with the business owners and record the count of skipped accounts. Remember that the export does not carry passwords, so every migrated account will need a credential reset or a secure password transfer method on the target.

The export itself is a short command run against the directory, so the effort lies in the preparation and checking around it. Four factors drive it: the number of objects and how many OUs they sit in, the depth of group nesting, how much attribute cleanup the target system needs, and how many target systems receive the data. Each target adds its own attribute mapping and its own verification pass. Attribute cleanup is often the largest share, because ldifde can omit listed attributes with -o and AD-only attributes with -m, but someone must still decide which attributes the new directory needs. Ask the implementation partner to split the estimate into discovery, export filters, mapping, verification and sign-off so each driver is visible.

Yes, a Windows administrator with directory read rights can run ldifde from a domain controller or a host with the AD DS or AD LDS tools installed. The export is the default mode of the tool, so basic exports need no special product. The harder part is knowing what to export and what to leave out: group nesting, filters that match the right OUs, service accounts, disabled users and attributes that Samba AD or FreeIPA will not accept. Teams that have done directory work before usually manage the export. Teams without that experience often need outside help for the mapping and the verification, which is where mistakes tend to surface after cutover.

No fixed duration applies, because the length depends on the drivers of the work rather than the export command itself. Duration grows with the object count, the number of OUs and nested groups to reconcile, the number of attributes that need mapping, and how many rounds of test imports the target needs. Delays usually come from the business, not the tooling: waiting for group owners to confirm memberships, or for a change window to be booked. Ask for a schedule that lists each stage, its owner and the checkpoint that closes it, and confirm which stages a test environment must complete before production work begins.

The business must name an owner for each group that will be migrated, because someone has to confirm that membership is still correct before it is moved. It also has to decide how users will authenticate after the move, since ldifde does not export password hashes and users will need a reset or another documented path. Finally, it must agree on change windows for the cutover and for any rollback. Without these decisions, the technical export can be correct and the migration still stalls. Record each decision in writing with a named approver before the export runs.

No. An ldifde export holds user, group and attribute data in LDIF files, but it is not a full domain backup. It does not capture the domain controller state, SYSVOL contents, Group Policy objects, DNS zones, or the directory's own recovery data needed to restore a domain. Keep your existing Windows system state and DC backups running until the migration is complete and retired. For what a complete backup and restore plan requires, read the backup questions on the sibling migration pages before relying on any export as a safety net.

Ask for a fixed scope written out in advance, with the list of OUs and groups to export, the target systems covered, and the attributes to be omitted or mapped. The quote should show deliverables for each stage: export filters, the mapping document, test imports, verification results and the sign-off record. Ask which parts are one-time work, such as the mapping and cutover, and which recur, such as support or upgrades after go-live. Confirm who performs the checks against the source directory, what evidence is delivered, and which assumptions about the business decisions would change the price or timeline.