Active Directory (AD) is a major IT resource for many organizations. It makes sense to manage AD from the command line, especially when there is bulk data or scripting involved. PowerShell is a great tool for managing AD in this way, but what if you don't, won't, or can't use PowerShell?
Two handy command-line utilities that don't get the fanfare that PowerShell does, are called csvde and ldifde. These tools allow you to import, exort, or modify AD data from the command line.
These two tools ease the burden of migrating data between AD domains or importing data from non-AD LDAP directory services. They do this by allowing you to use standard plain text files (CSV and LDIF) to move AD data.
LDIF files are less common than CSV. Check out the companion article Understanding LDIF (LDAP Data Interchange Format) if you'd like to learn more about LDIF.
In this article, you will learn the power that each of these tools has!
What are CSVDE and LDIFDE?
Csvde and ldifde are a pair of tools designed to manage the import and export of Active Directory (AD) data to and from text files. CSVDE imports and exports from Comma Separated Values (CSV) files. Ldifde, on the other hand, imports and exports from LDAP Data Interchange Format (LDIF) files.
In this article, you'll learn many different actions you can take with these tools. Each one of these actions will be performed via one or more different parameters.I
One thing you will immediately notice if you work with both csvde and ldifde is that they have similar parameters. Each tool performs similar purposes but does it in a different way.
Below you will find a table that outlines each parameter and their purpose.
|-i||General||Turn on Import Mode (The default is Export)|
|-f filename||General||Input or Output filename|
|-s servername||General||The server to bind to (Default to DC of computer's domain)|
|-c FromDN ToDN||General||Replace occurrences of FromDN with ToDN. When using ldifde, if either FromDN or ToDN ends with #attributeName, the attribute value will be looked up in rootDSE and used to replace #attributeName. See the section Macro expansion in DNs.|
|-j path||General||Directory path for Log files|
|-t port||General||Port Number to be used for connection to AD. The default is 389. Use port 636 for SSL.|
|-u||General||Use Unicode format|
|-h||General||Enable Simple Authentication and Security Layer (SASL) layer signing and encryption|
|-?||General||Help. Note that the -? and -h parameters have different meanings, unlike some command line tools where -? and -h both invoke help for the command.|
|-d RootDN||Export||The root of the LDAP search (Default to Naming Context) - sometimes known as the SearchRoot. See Learning Active Directory and LDAP Filters in PowerShell for more details.|
|-r Filter||Export||LDAP search filter (Default to "(objectClass=*)"). See Learning Active Directory and LDAP Filters in PowerShell for more details.|
|-p SearchScope||Export||Search Scope (Base/OneLevel/Subtree). See Learning Active Directory and LDAP Filters in PowerShell for more details.|
|-l list||Export||List of attributes (comma separated) to look for in an LDAP search.|
|-o list||Export||List of attributes (comma separated) to omit from export.|
|-g||Export||Disable Paged Search.|
|-m||Export||Enable the SAM logic on export.|
|-n||Export||Do not export binary values.|
|-k||Import||The import will ignore Constraint Violation and Object Already Exists errors and continue importing.|
|-a UserDN [Password | *]||Credentials||Use Simple authentication|
|-b UserName Domain [Password | *]||Credentials||Security Support Provider Interface (SSPI) bind. This is the default authentication method using the logged in user.|
Distinguished Name Translation
With ldifde, you have the ability to export data from one domain and import into another. But what about domain-specific references like an AD object's distinguished name (DN)? Luckily, these tools provide a way to handle for such circumstances through a concept called DN translation.
DN translation allows you to "inject" a particular domain DN during import and export operations using the
-c parameter. When the
-c parameter is used in the form
-c FromDN ToDN , any occurrences of FromDN are swapped to ToDN.
In the following example, the distinguished name
DC=lab,DC=local is replaced by
> csvde -f export.csv -c DC=lab,DC=local DC=corp,DC=local
LDIFDE also supports the concept of macro expansion. Macro expansion is the ability to use a shortened name or macro to refer to some of the well-known naming contexts in LDAP. Ldifde supports the following macros:
|#defaultNamingContext||Default Naming Context|
|#rootDomainNamingContext||Root Domain Naming Context for the Forest|
|#schemaNamingContext||Schema Naming Context|
|#configurationNamingContext||Configuration Naming Context|
Perhaps you have an employee, Fiona Cortez, that you'd like to export from the corp.local domain and import into the lab.local domain. Fiona’s user object is exported to an LDIF file named fiona.ldf using the following command:
> ldifde -f fiona.ldif -r "samAccountName=Fiona.Cortez" Exporting directory to file fiona.ldif Searching for entries... Writing out entries. 1 entries exported
If you open up Fiona’s AD object record in the fiona.ldf file, it would look something like this:
dn: CN=Cortez Fiona,OU=All User Accounts,DC=corp,DC=local changetype: add accountExpires: 9223372036854775807 cn: Cortez Fiona description: Systems Analyst distinguishedName: CN=Cortez Fiona,OU=All User Accounts,DC=corp,DC=local dSCorePropagationData: 16010101000000.0Z givenName: Fiona instanceType: 4 mail: [email protected] name: Cortez Fiona objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=corp,DC=local objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user sAMAccountName: Fiona.Cortez sn: Cortez userAccountControl: 546
An attempt to import this record into the lab.local domain using
ldifde -i results in an error as shown below:
> ldifde -i -f fiona.ldf Importing directory from file "fiona.ldf" Loading entries. Add error on entry starting on line 1: Referral The server side error is: 0x202b A referral was returned from the server. The extended server error is: 0000202B: RefErr: DSID-031007F9, data 0, 1 access points ref 1: 'corp.local' 0 entries modified successfully. An error has occurred in the program
To get Fiona’s user object to import into the lab.local domain, change each occurrence of corp.local to lab.local for each distinguished names in the LDIF file. You could do this manually, but macro expansion can do this for you using the
#defaultNamingContext macro. The
#defaultNamingContext macro represents the default naming context of the AD domain.
The default naming context for an AD domain is the part of an object's DN. The DN is made up of domain components or DCs (not to be confused with domain controllers). For example, in the distinguished name
CN=Cortez Fiona,OU=All User Accounts,DC=corp,DC=local, the domain components are
DC=corp,DC=local. The default naming context for the corp.local domain is
The following command imports Fiona’s record successfully. In this case,
cn=lab,cn=local. All occurrences of
cn=corp,cn=local in distinguished names are changed to
> ldifde -i -f fiona.ldf -c "cn=corp,dc=local" "#defaultNamingContext"
Using macro expansion with the
-c parameter is only supported by ldifde and LDIF files. The same approach cannot be used with csvde and CSV files.
Even though both tools have similar parameters, ldifde diverges a bit by including a few parameters that csvde does not have. These parameters perform actions specific only to the ldifde tool.
|-w timeout||General||Terminate execution if the server takes longer than the specified number of seconds to respond to an operation (default = no timeout specified)|
|-x||Export||Include deleted objects (tombstones)|
|-1||Export||Retain only the important replPropertyMetadata|
|-y||Import||The import will use lazy commit for better performance (enabled by default)|
|-e||Import||The import will not use lazy commit|
|-q threads||Import||The import will use the specified number of threads (default is 1)|
|-z||Import||Continue importing irrespective of errors.|
|-x||Import||Enable tombstone reanimation support (passes deleted objects control with ldap modify requests)|
Working with LDIFDE and CSVDE
In the remainder of this article, you'll learn hands-on how to use these useful tools.
If you intend to follow along, be sure you have the following prerequisites met ahead of time:
- Windows 7 or higher OS
- Microsoft Excel or a similar spreadsheet program installed on your computer will help when viewing CSV files generated by csvde.
- Remote Server Administration Tools (RSAT)
Exporting AD Objects From the Current Domain
Perhaps you need to export information from AD. You can easily do this using the
-f parameter which allows you to specify a file.
The command below exports everything in the current AD domain to a file specified by the
> csvde -f export.csv > ldifde -f export.ldf
This could take a long time in a production environment and impact performance of AD.
A typical CSV export file for a whole domain would look like the below CSV when viewed in Excel.
Importing AD Objects Into the Current Domain
If you already have a CSV file containing AD objects, you can use the
-f parameter on either tool. Perhaps you're now importing AD information from the import.csv file exported earlier. To do this, use the
For an example, using the
-f parameters, you can impot everything that the import.csv file has in built above.
> csvde -i -f import.csv > ldifde -i -f import.ldf
Understanding How CSVDE Translates Data
Csvde changes some of the information returned by AD when you export it. It does this so that it can be stored in a plain text format like CSV. This behavior might catch you by surprise if you are modifying the data in Microsoft Excel, or the system you are importing it into is not Active Directory.
Let's have a look at a CSV export file pc.csv from the lab.local domain. This file was generated by csvde for the user Paul Cox. Using the
-r parameter to specify an LDAP filter picks out Paul by his
> csvde -r "samAccountName=Paul.Cox" -f pc.csv Exporting directory to file pc.csv Searching for entries... Writing out entries . Export Completed. Post-processing in progress... 1 entries exported
The structure of pc.csv can be examined by opening it in Excel or another spreadsheet program. It will look something like this:
Looking at the column headed
memberOf shows how csvde handles multi valued AD properties. You can see below that csvde separates values with a semicolon (";"). The semicolon is highlighted in the image below. It's quite hard to spot amongst all the commas.
Looking at the
objectGUID column in pc.csv shows how csvde handles AD properties that are not directly representable as text or numbers - the program exports a value prefixed by "X" and wrapped in single quotes.
Presenting the value in this way means that csvde has taken the value of
objectGUID and changed it to make it able storable in a plain-text format like CSV. When the file is imported by csvde the
objectGUID value will be converted before being sent to AD. There doesn’t appear to be any documentation about how these values are changed or changed back.
Below you’ll find a table of AD properties that are encoded and which objects in AD have that particular property.
|objectGUID||All AD objects have an objectGUID|
Exporting User Accounts
Maybe you need to export only user accounts. To make things more interesting, let's also assume you're not currently logged into a computer with access to query AD. You need to specify alternate credentials.
In the example below, the
-m parameter means that information that the program considers sensitive, such as
objectSid. These attributes are not exported. The
-r parameter sets the LDAP filter to use.
> csvde -m -f export.csv -a [email protected] [email protected]$$w0rdH3r3 -r "(objectCategory=user)" > ldifde -m -f export.ldf -a [email protected] [email protected]$$w0rdH3r3 -r "(objectCategory=user)"
A typical CSV export file containing user objects would look like this in Excel:
Exporting all Objects in an Organizational Unit (OU)
If you don't want to export all objects in AD, you can also only export those in a specific OU.
The following command exports all objects from an OU, including the OU object itself and any sub-OUs. A default LDAP filter of
"objectClass=*" (all objects) is used if we don't supply one using
-d parameter sets the starting point for the search in the directory tree. In this case, it is set to the OU that in which we are interested, as shown below.
> csvde -f ouexport.csv -d "OU=All User Accounts,DC=lab,DC=local" > ldifde -f ouexport.ldf -d "OU=All User Accounts,DC=lab,DC=local"
When you use csvde or ldifde to export AD object to a file, the objects in the file are listed in a particular order. This is the order that will be used when when the data is imported into another domain or LDAP service.
For example, the OUs are created before the user objects within the OUs. Additionally, linked attributes like manager are added after all of the users have been created. Below is an example LDIF file (snipped for brevity), showing the order of object creation and modification:
dn: OU=All User Accounts,DC=lab,DC=local changetype: add distinguishedName: OU=All User Accounts,DC=lab,DC=local ---SNIP--- dn: CN=Smith Brian,OU=All User Accounts,DC=lab,DC=local changetype: add distinguishedName: CN=Smith Brian,OU=All User Accounts,DC=lab,DC=local ---SNIP--- dn: OU=Professional Services,OU=All User Accounts,DC=lab,DC=local changetype: add distinguishedName: OU=Professional Services,OU=All User Accounts,DC=lab,DC=local ---SNIP--- dn: CN=Davis Bethany,OU=Professional Services,OU=All User Accounts,DC=lab,DC=local changetype: add distinguishedName: CN=Davis Bethany,OU=Professional Services,OU=All User Accounts,DC=l ab,DC=local ---SNIP--- dn: CN=Davis Bethany,OU=Professional Services,OU=All User Accounts,DC=lab,DC=local changetype: modify add: manager manager: CN=manager: CN=Smith Brian,OU=All User Accounts,DC=lab,DC=local -
Exporting Specific Attributes of User Accounts
There will be some situations where you don't need to export all of the information about a user using csvde or ldifde. Examples include the data for creation of physical phonebooks, or the export of user information for import into another, non-Active Directory system. -
This example uses the
-l parameter to allow the export of specific attributes of objects. The export file contains the Given Name, Surname, Telephone Number, and Email address of each user. These attributes attributes are specified via the
-l parameter .
> csvde -f export.csv -r "objectCategory=user" -l givenName,sn,telephoneNumber,mail > ldifde -f export.ldf -r "objectCategory=user" -l givenName,sn,telephoneNumber,mail
Modifying Active Directory Objects
While csvde and ldifde are both designed for bulk data import and export, ldifde can make changes to AD objects. As an example, Microsoft uses LDIF files to extend the AD schema. The LDIF file format is designed to support these actions.
There is no equivalent in CSV files used by csvde to the LDIF changetype. Csvde can only import or export AD objects.
Bear in mind that some of the attributes you export from AD cannot be written back to. These attributes are system generated, or are restricted to system access only. Examples include:
badPwdCount badPasswordTime lastLogoff lastLogon pwdLastSet primaryGroupID objectGUID objectSid logonCount sAMAccountType
The changetype lin is a key piece of information in an LDIF record that allows it to be used for different kinds of actions. The changetype line in an LDIF file sets the action that is going to happen to an object in AD specified by the DN line above the changetype, as shown in the example below.
dn: CN=Cox Paul,OU=All User Accounts,DC=lab,DC=local changetype: add
There a different kinds of changetype and these are summarized in the table below:
deleteoldrdn 0 | 1
Using the Add changetype
The Add changetype creates a new AD object. The values for attributes are supplied one per line for single valued attributes and on multiple lines for multi valued attributes. An add record looks like the example below (snipped for brevity).
Note that the second line (
changetype: add) identifies this as an add record.
dn: CN=Cox Paul,OU=All User Accounts,DC=lab,DC=local changetype: add objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: Cox Paul sn: Cox description: IT Manager givenName: Paul distinguishedName: CN=Cox Paul,OU=All User Accounts,DC=lab,DC=local ---SNIP---
Using the Delete changetype
The delete changetype removes an object from AD and is simple in structure. The DN is the only mandatory attribute required in the LDIF file, specifying the DN of the AD object to be deleted. This is followed by a changetype line of
changetype: delete, as shown below.
dn: OU=Legacy OU,DC=lab,DC=local changetype: delete
You can delete many kinds of objects using ldifde. You could easily destroy your AD installation using ldifde the wrong way. Be warned!
Using the Modify changetype
The modify changetype has add, delete, and replace operations that are applied to attributes of the selected AD object. Below is an example LDIF file showing how this can be used in practice. The example replaces Angelique's telephone number, adds her office location, and deletes her fax number.
dn: CN=Cortez Angelique,OU=All User Accounts,DC=lab,DC=local changetype: modify replace: telephonenumber telephonenumber: +44 1234 567890 - add: physicaldeliveryofficename physicaldeliveryofficename: Corner Office - # No one uses faxes, do they? delete: facsimiletelephonenumber -
Using the ModDN/ModRDN changetype
The moddn or modrdn changetype is used to rename or move an AD object in the directory tree.
Use the newsuperior value to set where the object will be moved to. The mandatory newrdn value sets the name of the object. The deleteoldrdn value determines if the old rdn is kept or replaced by the newrdn value. Omit the newsuperior value if the object should be renamed in place. Child objects of the object being moved are also moved.
An example LDIF file to move the Professional Services OU from under the Services OU is shown below.
dn: OU=Professional Services,OU=Services,DC=lab,DC=local changetype: modrdn newrdn: OU=Professional Services deleteoldrdn: 1 newsuperior: DC=lab,DC=local
Updating an Attribute
Let's explore how to update the value of an existing AD attribute using ldifde.-
In this example the
description attribute for a user is updated. First, the user's
description attribute is exported to an LDIF file to create a template to modify, as below. The
-l parameter specifies the attributes to be present in the LDIF file. The
-r parameter sets an LDAP filter used to determine the objects that ldifde returns.
> ldifde -r "samAccountName=Angelique.Cortez" -f ac.ldf -l description Exporting directory to file ac.ldf Searching for entries... Writing out entries. 1 entries exported The command has completed successfully
The resulting file ac.ldf, looks like below:
dn: CN=Cortez Angelique,OU=All User Accounts,DC=lab,DC=local changetype: add description: Compliance Guardian
To make this a modify record, the changetype is changed to modify and a replace line specifying the attribute to be modified is added. The description line is changed to the new value. Finally, a new line containing "-" on its own is added to mark the end of the change. The file looks like the example below when it is saved:
dn: CN=Cortez Angelique,OU=All User Accounts,DC=lab,DC=local changetype: modify replace: description description: General Manager -
Running ldifde with the
-i parameter imports the changes into AD, as seen below.
> ldifde -i -f ac.ldf Importing directory from file "ac.ldf" Loading entries.. 1 entry modified successfully. The command has completed successfully
Repeating the export step above and viewing
ac.ldf reveals that the change has taken place.
dn: CN=Cortez Angelique,OU=All User Accounts,DC=lab,DC=local changetype: add description: General Manager
Modifying Members of an AD Group
Let's explore how to modify the membership of an AD group using ldifde.-
In this example the membership of the group Professional Service Department is changed.
For example, export the group to an LDIF file called psd.ldf using the
-n switches. These switches remove security sensitive and binary attributes from the data that is returned. The command to achieve this is shown below.
> ldifde -r "cn=Professional Services Department" -f psd.ldf -m -n
The file psd.ldf is shown below (snipped for brevity).
dn: CN=Professional Services Department,OU=All Groups,DC=lab,DC=local changetype: add cn: Professional Services Department distinguishedName: CN=Professional Services Department,OU=All Groups,DC=carisbrookelabs,D ---SNIP--- dn: CN=Professional Services Department,OU=All Groups,DC=lab,DC=local changetype: modify add: member member: CN=Cox Paul,OU=All User Accounts,DC=lab,DC=local - dn: CN=Professional Services Department,OU=All Groups,DC=lab,DC=local changetype: modify add: member member: CN=Diaz Kristin,OU=Professional Services,OU=All User Accounts,DC=lab ,DC=local -
The order of entries in the psd.ldf means that the group is created first and then members are added. Note that the member attribute contains a DN, rather than a samAccountName, SID or commonname. That's how the attribute is stored in AD.
For this example, let's assume that the user Angelique Cortez needs to be added to the Professional Services group. Her distinguished name is
CN=Cortez Angelique,OU=All User Accounts,DC=lab,DC=local. The export file psd.ldf shows the LDIF format needed to add a user to a group. This consists of a changetype of modify, an add line, and a member line.
Don't forget to add the "-" on its own line to finish the modify record.
Following the example of the export file, the new LDIF file, which has been saved as
group.ldf, looks like this:
dn: CN=Professional Services Department,OU=All Groups,DC=lab,DC=local changetype: modify add: member member: CN=Cortez Angelique,OU=All User Accounts,DC=lab,DC=local -
The LDIF file is imported using the
-i parameter, as shown below.
> ldifde -i -f group.ldf
Assuming there are no errors, Angelique will have been successfully added to the group.
Resetting a User Password
Resetting a password using an LDIF file requires changing the user's
unicodePwd attribute. The new password must be wrapped in double quotes (NewPassword must be supplied as "NewPassword") and base64 encoded. The new password must also conform to any password policies applicable to the user, such as length or complexity. Failure to meet these requirements will cause the password change to fail.
In the example below, the user's password is changed and the
userAccountControl attribute's value is replaced with the value 512. This behavior enables the account.
LDIF files involving password changes must be imported over a secure connection. Use port 636 using the
-tparameter, or Simple Authentication and Security Layer (SASL) using
-h. Attempts to modify passwords over insecure connections will fail.
dn: CN=Cortez Angelique,OU=All User Accounts,DC=lab,DC=local changetype: modify replace: unicodePwd unicodePwd::IgBGAGwAeQBpAG4AZwBJAHMATQB5AFQAaABpAG4AZwAxACIA - replace: userAccountControl userAccountControl: 512 -
Adding a Photo to a User Account
The ldifde tool allows you set the
[jpegphoto](https://docs.microsoft.com/en-us/windows/win32/adschema/a-jpegphoto) attribute for a user by specifying a file name in the LDIF file. In the example below, the file specified is loaded into the
jpegphoto attribute. Note that the file path follows the file URI scheme, and that forward slashes are used.
dn: CN=Cortez Angelique,OU=All User Accounts,DC=lab,DC=local changetype: modify replace: jpegphoto jpegphoto: < file:///photos/angeliquephoto.jpg -
The content of the file is not checked in any way for invalid or malicious content before it is loaded. Be warned!
Although the csvde and ldifde tools can save you tons of time, things don't always go as expected. In this section, you'll find many pointers to help you deal with various issues you may come across.
Creating Logs for CSVDE and LDIFDE
-j parameter to create logs of the import or export. This parameter should point to a directory where the log files will be created. The logs themselves are plain text files, called
csv.log for csvde and
ldif.log for ldifde. The *.log files contain logs of all activity, whilst the *.err files only contain any errors.
For example, a failed csvde import generates a
csv.log file like this:
Connecting to "lab.local" Logging in as "[email protected]" using simple bind Importing directory from file "dc.csv" Loading entries2: CN=Cortez Angelique,OU=All User Accounts,DC=lab,DC=local Attribute 0) description: Team Leader Attribute 1) distinguishedName: CN=Cortez Angelique,OU=All User Accounts,DC=lab,DC=local Attribute 2) objectClass: userEntry already exists, entry skipped. 0 entries modified successfully. The command has completed successfully
The .err file for the same error looks like this:
Attribute 0) description: Team Leader Attribute 1) distinguishedName: CN=Cortez Angelique,OU=All User Accounts,DC=lab,DC=local Attribute 2) objectClass: user 2: Entry already exists, entry skipped.
If your LDIF file doesn't contain expected attributes when using the
-o switches, check the spelling on any attribute names that you wish to include or omit. Additionally, always check the spelling of server names, file names, etc. Any mistakes in these will also cause import or export failures.
“There is a syntax error in the input file”
This generic error identifies where in the LDIF or CSV file the import is failing:
Failed on line 3. The last token starts with 'n'.*
“A device attached to the system is not functioning”
This error is seen when using ldifde to change a user’s password. There are two possible causes.
Add error on entry starting on line 1: Unwilling To Perform The server side error is: 0x1f A device attached to the system is not functioning. The extended server error is: 0000001F: SvcErr: DSID-031A1254, problem 5003 (WILL_NOT_PERFORM), data 0
Cause 1 - Password incorrectly formatted
Ensure that you are replacing the unicodePwd attribute with a base64 value. The password must be a Unicode string wrapped in double quotes before base64 encoding. There are a number of approached you could use to base64 encode the password, including online services and command line tools. Here's how you could base64 encode a password using PowerShell.
PS51> [Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes('"PassWordInQuotes1"')) IgBQAGEAcwBzAFcAbwByAGQASQBuAFEAdQBvAHQAZQBzADEAIgA=
Cause 2 - Trying to set a password over an insecure connection
Another cause could be when you try to set a user's password, but don't use a secure connection.-
-t 636 (use port 636) or
-h (use SASL) parameters to secure your connection to AD. If not, password updates will fail.
“Errors on Line 2”
You will occasionally come across error message returned by csvde that start with "errors on line 2.". This usually means that the file format is incorrect.
This error could mean that incorrect attribute names have been used for column headings in a CSV file for example. Line 2 of a CSV file is the first data line after the headers. This error means that the import process has failed at the very start.
To illustrate this error, have a look at the following snippet from a CSV file. The columns for the the user's first and last name are headed firstName and *lastName (*instead of givenName and sn). The import will fail with an error on line 2 of No Such Attribute.
“Access to the attribute is not permitted because the attribute is owned by the Security Accounts Manager (SAM)”
Several AD attributes cannot be set via script. They are managed by AD itself - trying to modify one of these triggers this error.
Add error on line 2: Unwilling To Perform The server side error is "Access to the attribute is not permitted because the attribute is owned by the Security Accounts Manager (SAM)."
-m parameter when exporting to exclude the restricted attributes from the output file. Also, attributes that are backlinks to other attributes (such as
manager) cannot be set directly. Below is a (probably incomplete) list of attributes you can't set using csvde and ldifde:
objectGUID objectSid whenCreated whenChanged uSNCreated uSNChanged badpasswordTime lastLogoff lastLogon pwdLastSet lastLogonTimestamp dSCorePropagationData badPwdCount logonCount lockoutTime instanceType accountExpires objectCategory sAMAccountType memberOf manager primaryGroupID
“The specified account already exists”
CSVDE doesn't have the ability to update or recreate existing AD objects. If you try, you'll get the following error message.
Add error on line 2: Already Exists The server side error is "The specified account already exists."
“Illegal modify operation. Some aspect of the modification is not permitted”
Constraints within AD can prevent actions from taking place, for example trying to delete an OU when its isCriticalSystemObject attribute is set to True. Unfortunately, the error message is not specific about which change is not permitted.
The server side error is: 0x2077 Illegal modify operation. Some aspect of the modification is not permitted. The extended server error is: 00002077: SvcErr: DSID-031B0F19, problem 5003 (WILL_NOT_PERFORM), data 0
“Unable to update the password. The value provided for the new password does not meet the length, complexity, or history requirements of the domain”
The error message tells the story here. Ensure that any password you are trying to apply meets the requirements of the AD domain. See the Password Policy documentation on Microsoft Docs for more details on how these requirements are defined.
Add error on entry starting on line 1: Unwilling To Perform The server side error is: 0x52d Unable to update the password. The value provided for the new password does not meet the length, complexity, or history requirements of the domain. The extended server error is: 0000052D: SvcErr: DSID-031A1254, problem 5003 (WILL_NOT_PERFORM), data 0
“The parameter is incorrect”
The extended error part of the message gives a clue. In this case deleteoldrdn value needs to be set to 1 in the LDIF file.
Add error on entry starting on line 1: Unwilling To Perform The server side error is: 0x57 The parameter is incorrect. The extended server error is: 00000057: LdapErr: DSID-0C090E43, comment: Old RDN must be deleted, data 0, v3839
“The operation could not be performed because the object's parent is either uninstantiated or deleted”
This error means that the specified new location for a move operation does not exist. The newsuperior value in the LDIF file is likely wrong.
Add error on entry starting on line 1: Other The server side error is: 0x2089 The operation could not be performed because the object's parent is either uninstantiated or deleted. The extended server error is: 00002089: UpdErr: DSID-031B0DCE, problem 5012 (DIR_ERROR), data 2
“A referral was returned from the server”
The objects you are trying to import have DNs that don't match the domain you are trying to import into. Use the macro capability to fix this, or manually change the distinguished names to the correct value before importing.
Add error on entry starting on line 1: Referral The server side error is: 0x202b A referral was returned from the server. The extended server error is: 0000202B: RefErr: DSID-03100835, data 0, 1 access points
“Directory object not found”
This error occurs when you include a DN that does not exist in your import file. Has the object in question been deleted? Check for typos in the distinguished name.
Add error on entry starting on line 1: No Such Object The server side error is: 0x208d Directory object not found. The extended server error is: 0000208D: NameErr: DSID-03100241, problem 2001 (NO_OBJECT), data 0, best match of: 'DC=lab,DC=local'
“A required attribute is missing”
AD objects require certain mandatory attributes to be present before you can create them. This error reports that one of the attributes is missing. Unhelpfully, it doesn't say which one. To find out which attributes are mandatory for a particular object class, have a look at the AD schema documentation.
Add error on line 2: Constraint Violation The server side error is "A required attribute is missing."
“Unable to read the import file”
This error usually means that the file is not present in the specified location. Check the file path and spelling.
Unable to read the import file <filename>
“Error opening the output file”
This error could mean that the file is in use by another process. Make sure that the export file is not open in another program.
Error opening output file.
“The connection cannot be established. The error code is 8224”
Check that the server, domain, or forest name being used is correct and that network connectivity exists to the domain controller.
“SSPI "bind with supplied creds" returned 'Invalid Credentials' or Simple bind returned 'Invalid Credentials'”
This error means that the user name or password you are using to authenticate to AD is incorrect.
“Invalid Parameter: No Active Directory Domain Controller Available”
This error means that computer you are running csvde or ldifde on is cannot detect an AD domain. Specify a server using
-s (you'll probably need to specify credentials too, using the
- The LDAP Data Interchange Format (LDIF) - Technical Specification
- Learning Active Directory and LDAP Filters in PowerShell
Subscribe to Adam the Automator
Get the latest posts delivered right to your inbox