ldapmodify and ldapadd utilities

Purpose

The ldapmodify utility provides an interface to the ldap_modify() and ldap_add() APIs. The ldapadd command is implemented as a renamed version of ldapmodify. When invoked as ldapadd, the -a (add new entry) flag is turned on automatically.

The ldapmodify utility opens a connection to an LDAP server, binds, and modifies or adds entries. The entry information is read from standard input (or an input file that is redirected to standard input) or from file by using the -f option.

Format

ldapmodify | ldapadd [options]

Parameters

options
Table 1 shows the options that you can use for the ldapmodify and ldapadd utilities:
Table 1. ldapmodify and ldapadd options
Option Description
-? Print this text.
-a Add new entries. The default for ldapmodify is to modify existing entries. If invoked as ldapadd, this flag is always set.
-b Assume that any attribute values that start with a slash (/) are binary values that are contained in a file. The location of the binary file must be specified as a fully qualified z/OS® UNIX System Services file system or as a fully qualified data set name. If a data set name is specified, it must start with two slashes (//) and the name must have single quotation marks (') around it.
-c Continuous operation mode. Errors are reported, but ldapmodify continues with modifications. The return code from the utility is determined by the last modification. The default is to exit after reporting an error.

Start of changeUse this option when a single LDIF file or command has multiple operations on more than one entry. Modifies on the cn-schema will be considered a single operation. End of change
-d debugLevel Specify the level of debug messages to be created. The debug level is specified in the same fashion as the debug level for the LDAP server. See Table 1 for the possible decimal values for debugLevel. The default is no debug messages.
-D bindDN Use bindDN to bind to the LDAP directory. This option should be a string-represented DN. The default is a NULL string.

If the -S or -m option is equal to DIGEST-MD5 or CRAM-MD5, this option is the authorization DN that is used for making access checks. This directive is optional when used in this manner.
-f file Read the entry modification information from file instead of from standard input.

You can specify a partitioned or sequential data set for file on the -f option. See Specifying a value for a file name for more information.
-F Force application of all changes regardless of the contents of input lines that begin with replica: (by default, replica: lines are compared against the LDAP server host and port in use to decide if a replication log record should be applied).
-g realmName Specify the realm name to use when doing a DIGEST-MD5 bind. This option is required when multiple realms are passed from an LDAP server to a client as part of a DIGEST-MD5 challenge; otherwise, it is optional.
-h ldapHost Specify the host name or IP address on which the LDAP server is running. The default is the local host.
-k Send the Server Administration control with the operation request. The control requires a protocol level of 3 and its criticality is set to TRUE. There is no control value. This control enables a server that would normally refuse updates, such as a quiesced or replica server, to allow updates. See z/OS IBM Tivoli Directory Server Administration and Use for z/OS for additional information about this control.
-K keyFile Specify the name of the System SSL key database file, RACF® key ring, or PKCS #11 token. If this option is not specified, this utility looks for the presence of the SSL_KEYRING environment variable with an associated name.

If keyFile is specified as *TOKEN*/NAME, then System SSL uses the specified PKCS #11 token. Otherwise, System SSL uses a key database file or a RACF key ring. In this case, System SSL first assumes that keyFile is a key database file name and tries to locate the file. If keyFile is not a fully qualified z/OS UNIX System Services file name, the current directory is assumed to contain the key database file. The name cannot be a partitioned or sequential data set. If System SSL cannot locate the file, it then assumes that keyFile is a RACF key ring name.

See SSL/TLS information for LDAP client utilities for information about System SSL key databases, RACF key rings, and PKCS #11 tokens.

This option is ignored if -Z is not specified.
-L Send the Do Not Replicate control with the operation request. The control requires a protocol level of 3 and its criticality is set to TRUE. There is no control value. This control prevents the targeted server from sending replicated entries to the next tier of advanced replication servers. See z/OS IBM Tivoli Directory Server Administration and Use for z/OS for additional information about this control.
-m mechanism See the description of the -S option.
-M Manage referral objects as normal entries. This requires a protocol level of 3.
-n Show what would be done, but do not actually modify entries. Useful for debugging with -v.
-N keyFileDN Specify the label associated with the certificate in the System SSL key database, RACF key ring, or PKCS #11 token.

This option is ignored if -Z is not specified.
-p ldapPort Specify the TCP port where the LDAP server is listening. The default LDAP non-secure port is 389 and the default LDAP secure port is 636.
-P keyFilePW Specify either the key database file password or the file specification for a System SSL password stash file. When the stash file is used, it must be in the form file:// followed immediately (no blanks) by the file system file specification (for example, file:///etc/ldap/sslstashfile). The stash file must be a z/OS UNIX System Services file and cannot be a partitioned or sequential data set.

This option is ignored if -Z is not specified.
-r Replace existing values by default.
-R Do not automatically follow referrals.
-S mechanism
or
-m mechanism

Specify the bind method to use. You can use either -m or -S to indicate the bind method.

Specify GSSAPI to indicate that a Kerberos Version 5 bind is requested, EXTERNAL to indicate that a certificate (SASL external) bind is requested, CRAM-MD5 to indicate that a SASL Challenge Response Authentication Mechanism bind is requested, or DIGEST-MD5 to indicate that a SASL digest hash bind is requested.

The GSSAPI method requires a protocol level of 3 and the user must have a valid Kerberos Ticket Granting Ticket in their credentials cache by using the Kerberos kinit command-line utility.

The EXTERNAL method requires a protocol level of 3. You must also specify -Z, -K, and -P to use certificate bind. If there is no default certificate in the key database file, RACF key ring, or PKCS #11 token or a certificate other than the default must be used, use the -N option to specify the label of the certificate.

The CRAM-MD5 method requires a protocol level of 3. The -D or -U option must be specified.

The DIGEST-MD5 method requires a protocol level of 3. The -U option must be specified. Optionally, the -D option can be used to specify the authorization DN.

If -m or -S is not specified, a simple bind is performed.
-u on | off Specify whether the ldapmodify utility sends the SchemaReplaceByValueControl control to the server. This control indicates how a schema modify reacts to a replace modification. If set to off, a schema modification removes all current values for an attribute and replaces them with the set of values in the replace operation. If set to on, an attribute value is updated if some value in the replace operation has the same numeric object identifier as a value that exists in the schema attribute. An attribute value is added if the numeric object identifier in the replace operation does not exist in the schema attribute. No attribute values are removed.
-U userName Specify the user name for CRAM-MD5 or DIGEST-MD5 binds. The userName is a short name (for example, the uid attribute value) that is used to perform bind authentication.

This option is required if the -S or -m option is set to DIGEST-MD5.
-v Use verbose mode, with many diagnostics written to standard output.
-V version Specify the LDAP protocol level the client should use. The value for version can be 2 or 3. The default is 3.
-w passwd Use passwd as the password for simple, CRAM-MD5, and DIGEST-MD5 authentication. The default is a NULL string.
-x sslFipsMode Specify FIPS mode for SSL/TLS protected connections. The supported FIPS modes are LEVEL1, LEVEL2, LEVEL3, and OFF. When FIPS mode is enabled, it is more restrictive regarding cryptographic algorithms, protocols, and key sizes that can be supported. If this option is not specified, the FIPS mode is set to OFF.

This option is ignored if -Z is not specified.
-Z Use a secure connection to communicate with the LDAP server. Secure connections expect the communication to begin with the SSL/TLS handshake.

The -K keyFile option or equivalent environment variable is required when the -Z option is specified. The -P keyFilePW option is required when the -Z option is specified and the key file specifies a file system key database file. Unless you want to use the default certificate in the key database file, RACF key ring, or PKCS #11 token, use the -N option to specify the label of the certificate.

All other command-line inputs result in a syntax error message, after which the correct syntax is displayed. If the same option is specified multiple times or if both -m and -S are specified, the last value that is specified is used.

LDAP Data Interchange Format (LDIF)

LDAP Data Interchange Format (LDIF) is a standard text format for representing LDAP objects and LDAP updates (add, modify, delete, modify DN). Files containing LDIF records are used to transfer data between directory servers or used as input by LDAP utilities such as ldapadd and ldapmodify.

LDIF content records are used to represent LDAP directory content and consist of a line identifying the object, followed by optional lines containing controls, which are then followed by lines containing the attribute-value pairs for the object. This type of file is used by the ldapadd, ds2ldif, and ldif2ds utilities. See ds2ldif utility and ldif2ds utility in z/OS IBM Tivoli Directory Server Administration and Use for z/OS for more information about the ds2ldif and ldif2ds utilities.

LDIF change records are used to represent directory updates. These records consist of a line identifying the directory object, followed by lines describing the changes to the object. The changes include adding, deleting, renaming, or moving objects, and modifying existing objects.

The input styles for content and change records are:
  • A standard LDIF style that is defined by RFC 2849
  • A non-standard "modify style"
Use of the standard LDIF style is suggested; the non-standard style is documented later for use with older tools that produce or use that style.

Input styles

The ldapmodify and ldapadd commands accept two forms of input. The type of input is determined by the format of the first input line supplied to ldapmodify or ldapadd.

The first line of input to the ldapmodify or ldapadd command must denote the distinguished name of a directory entry to add or modify. This input line must be of the form:
    dn:distinguished_name
    
    or
    
    distinguished_name
where dn: is a literal string and distinguished_name is the distinguished name of the directory entry to modify (or add). If dn: is found, the input style is set to RFC 2849 LDIF style. If it is not found, the input style is set to "modify style".
Note:
  1. The ldapadd command is equivalent to invoking the ldapmodify -a command.
  2. The ldapmodify and ldapadd utilities do not support base64 encoded distinguished names.
RFC 2849 LDIF input

When using RFC 2849 LDIF input, attribute types and values are delimited by a single colon (:) or a double colon (::). Furthermore, individual changes to attribute values are delimited with a changetype: input line. The general form of input lines for RFC 2849 LDIF is:

change_record
<blank line>
change_record
…
…
…
In RFC 2849 LDIF input:
  1. A comment line is a line that begins with a number sign (#) in column 1. Comment lines are ignored.
  2. A continuation line is a line that begins with a space in column 1. The rest of the continuation line, starting in column 2, is appended to the previous line.
  3. Ensure that there are no extraneous spaces or characters at the end of a line. Even if not viewable in an editor, these characters are part of the modify input and can produce unexpected errors or unusable data.

An input file in RFC 2849 LDIF style consists of one or more change_record sets of lines that are separated by one or more blank lines. Each change_record has the following form:

dn:distinguished_name
[control:control_oid[true|false][::control_value]]
[changetype:{modify|add|modrdn|delete}]
{change_clause
…
…
…
}

A change_record consists of a line indicating the distinguished name of the entry directory to be modified, one or more optional lines indicating controls to be sent to the server on the modification, an optional line indicating the type of modification to be performed against the directory entry, and one or more change_clause sets of lines.

If one or more control: lines are present, the control_oid indicates the OID of the control, true or false may optionally be specified to indicate the criticality of the control (defaults to false if not specified), and an optional control_value can be specified. The control_value is expected to be in base64 format. This format is an encoding that represents every three binary bytes with four text characters. See the base64encode() function in /usr/lpp/ldap/examples/line64.c for an implementation of base64 encoding.

The control lines in the RFC 2849 LDIF input style provide a way to apply certain controls to an individual entry rather than using a command-line option. For example, the -M, -L, and -k command-line options send the controls that you want for all entries in the RFC 2849 LDIF input style. Any acceptable server control can be specified on the control lines. If the same control is specified multiple times for an entry, the client sends multiple controls for the entry to the server. This can occur if the control is specified using a command-line option and on a control line for the entry, or on multiple control lines for the entry.

If the changetype: line is omitted, the change type is assumed to be modify unless the command invocation was ldapmodify -a or ldapadd, in which case the changetype is assumed to be add.

When the change type is modify, each change_clause is defined as a set of lines of the form:

add:x
{attrtype}{sep}{value}
…
…
…
-

or

replace:x
{attrtype}{sep}{value}
…
…
…
-

or

delete:{attrtype}
[{attrtype}{sep}{value}]
⋮
-

or

{attrtype}{sep}{value}
⋮

Specifying replace replaces all existing values for the attribute with the specified set of attribute values except when modifying a schema entry by using the -u option with SchemaReplaceByValueControl enabled. (See the description of the -u option in Table 1.) Specifying add adds to the existing set of attribute values. Specifying delete without any attribute-value pair records removes all the values for the specified attribute. Specifying delete followed by one or more attribute-value pair records removes only those values specified in the attribute-value pair records.

If an add:x, replace:x, or delete:attrtype line (a change indicator) is specified, a line containing a hyphen (-) is expected as a closing delimiter for the changes. Attribute-value pairs are expected on the input lines that are found between the change indicator and hyphen line. If the change indicator line is omitted, the change is assumed to be add for the attribute values specified. However, if the -r option is specified on ldapmodify, the change_clause is assumed to be replace. The separator, sep, can be either a single colon (:) or a double colon (::). A single colon (:) is used as a separator when value contains printable characters while a double colon (::) is used as a separator when value contains non-printable characters or begins with a space. Any white space characters between the separator and the attribute value are ignored. If a double colon is used as the separator, the input is expected to be in base64-encoded format. This format is an encoding that represents every three binary bytes with four text characters. See the base64encode() function in /usr/lpp/ldap/examples/line64.c for an implementation of this encoding.

Multiple attribute values are specified by using multiple {attrtype}{sep}{value} specifications.

Note: RFC 2849 indicates that LDIF file parsers should support the file:// URL format on a value to indicate that the contents of the referenced file are to be included verbatim in the integrated input of the LDIF file. However, the z/OS LDAP client LDIF parser does not support this specification. Also, the z/OS LDAP client LDIF parser does not support language or syntax tags on attrtype.
When the change type is add, each change_clause is defined as a set of lines of the form:
{attrtype}{sep}{value}

As with change type of modify, the separator, sep, can be either a single colon (:) or a double colon (::). A single colon (:) is used as a separator when value contains printable characters while a double colon (::) is used as a separator when value contains non-printable characters or begins with a space. Any white space characters between the separator and the attribute value are ignored. Attribute values can be continued across multiple lines by using a single space character as the first character of the next line of input. If a double colon is used as the separator, the input is expected to be in base64-encoded format.

When the change type is modrdn, each change_clause is defined as a set of lines of the form:

newrdn:value
deleteoldrdn:{0|1}

These are the parameters that you can specify on a modify RDN LDAP operation. The value for the newrdn setting is the new RDN to be used when performing the modify RDN operation. Specify 0 for the value of the deleteoldrdn setting to save the attribute in the old RDN and specify 1 to remove the attribute values in the old RDN. You cannot use ldapmodify to move an entry under a new superior DN, instead, use ldapmodrdn utility with the -s option.

When the change type is delete, no change_clause is specified.

RFC 2849 LDIF style examples

Here are some examples of valid input for the ldapmodify command using RFC 2849 LDIF style.

Adding a new entry
The following example adds a new entry into the directory using name cn=Tim Doe, ou=Your Department, o=Your Company, c=US, assuming ldapadd or ldapmodify -a is invoked:
dn:cn=Tim Doe, ou=Your Department, o=Your Company, c=US
changetype:add
cn: Tim Doe
sn: Doe
objectclass: organizationalperson
objectclass: person
objectclass: top
The following example sends the Server Administration Control (OID 1.3.18.0.2.10.15) and the Do Not Replicate Control (OID 1.3.18.0.2.10.23) and adds a new entry into the directory by using name cn=Tim Doe, ou=Your Department, o=Your Company, c=US, assuming ldapadd or ldapmodify -a is invoked:
dn:cn=Tim Doe, ou=Your Department, o=Your Company, c=US
control: 1.3.18.0.2.10.15
control: 1.3.18.0.2.10.23
changetype:add
cn: Tim Doe
sn: Doe
objectclass: organizationalperson
objectclass: person
objectclass: top
The following example adds a new entry that contains a binary user certificate that is base64-encoded in the userCertificate attribute into the directory by using name cn=John Doe, ou=Your Department, o=Your Company, c=US, assuming ldapadd or ldapmodify -a is invoked:
dn: cn=John Doe, ou=Your Department, o=Your Company, c=US
changetype:add
cn: John Doe
sn: Doe
usercertificate:: MIICNjCCAZ+gAwIBAgIBADANBgkqhkiG9w0BAQUFADAvMQswCQYDVQQGEwJ
 1czEMMAoGA1UEChMDaWJtMRIwEAYDVQQDEwlyMTNzZXJ2ZXIwHhcNMTAwNjE1MDQwMDAwWhcNMjE
 wMTAxMDM1OTU5WjAvMQswCQYDVQQGEwJ1czEMMAoGA1UEChMDaWJtMRIwEAYDVQQDEwlyMTNzZXJ
 2ZXIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMVgV8f3IAZEZ5/h3R2Iy7h4LSHbhsj4diH
 iHPIpTRtqJD5d42z2Z4gG9oUzqfYLyZSPoAVlDwVbufZVVvBeiDo7Bgm+1nj4/YYWCpnCkETmriB
 bVDJBoaF8W9xxHs38F6LVuJniDMp0VT9lDcqH3RNWgIcDqKurQm2uTHNDs6OtAgMBAAGjYjBgMD8
 GCWCGSAGG+EIBDQQyFjBHZW5lcmF0ZWQgYnkgdGhlIFNlY3VyaXR5IFNlcnZlciBmb3Igei9PUyA
 oUkFDRikwHQYDVR0OBBYEFLSjexfulLGxaf4xDvXV4Qhocv/JMA0GCSqGSIb3DQEBBQUAA4GBAIz
 fNvc3kWSINsVNexPANbUG9i7SR/79B++pBszHwlKsDqCcB/Sa45yIIxni6cCnLFAoKQO76wFXAnC
 Y4QDAxxukBdkiBjus0dQ4vfUDU2b5w+7F8mnvzNuHqvqBhk5DaMPbctcBl2E8lJkn3OwAk6VU+b5
 F6YJ3NT6y6SNDVk2q
objectclass: inetOrgPerson
objectclass: person
objectclass: top
Adding attribute types
The following example sends the Server Administration Control (OID 1.3.18.0.2.10.15) and adds two new attribute types to the existing entry. Note the registeredaddress attribute is assigned two values:
dn:cn=Tim Doe, ou=Your Department, o=Your Company, c=US
control: 1.3.18.0.2.10.15
changetype:modify
add:x
telephonenumber: 888 555 1234
registeredaddress: td@yourcompany.com
registeredaddress: ttd@yourcompany.com
-
Changing the entry name
The following example changes the name of the existing entry to cn=Tim Tom Doe, ou=Your Department, o=Your Company, c=US. The old RDN, cn=Tim Doe, is retained as an additional attribute value of the cn attribute. The new RDN, cn=Tim Tom Doe, is added automatically by the LDAP server to the values of the cn attribute in the entry:
dn: cn=Tim Doe, ou=Your Department, o=Your Company, c=US
changetype:modrdn
newrdn: cn=Tim Tom Doe
deleteoldrdn: 0
Replacing attribute values
The following example replaces the attribute values for the telephonenumber and registeredaddress attributes with the specified attribute values.
dn: cn=Tim Tom Doe, ou=Your Department, o=Your Company, c=US
changetype:modify
replace:x
telephonenumber: 888 555 4321
registeredaddress: tim@yourcompany.com
registeredaddress: timtd@yourcompany.com
-
Deleting and adding attributes
The following example deletes the telephonenumber attribute, deletes a single registeredaddress attribute value, and adds a description attribute:
dn:cn=Tim Tom Doe, ou=Your Department, o=Your Company, c=US
changetype:modify
add:x
description: This is a very long attribute
  value that is continued on a second line.
   Note the spacing at the beginning of the
  continued lines in order to signify that
  the line is continued.
-
delete: telephonenumber
-
delete: registeredaddress 
registeredaddress: tim@yourcompany.com
-
Modifying multiple entries
The following example adds the postalCode attribute and replaces the description attribute in the directory entry with name cn=Tim Tom Doe, ou=Your Department, o=Your Company, c=US and adds a new directory entry with name cn=Ken Smith, ou=Your Department, o=Your Company, c=US.
Note: A line containing only a dash is used to separate different types of changes within an entry and a blank line (a line containing no characters) is used to separate the changes to different entries. 
dn: cn=Tim Tom Doe, ou=Your Department, o=Your Company, c=US
changetype: modify
add: x
postalcode: 12345
-
replace: x
description: This is a short description.
-

dn: cn=Ken Smith, ou=Your Department, o=Your Company, c=US
changetype: add
cn: Ken Smith
sn: Smith
objectclass: organizationalperson
Deleting an entry
The following example deletes the directory entry with name cn=Tim Tom Doe, ou=Your Department, o=Your Company, c=US:
dn:cn=Tim Tom Doe, ou=Your Department, o=Your Company, c=US
changetype:delete
Modify style

The "modify style" of input to the ldapmodify or ldapadd commands is not as flexible as the RFC 2849 LDIF style. However, it is sometimes easier to use than the LDIF style.

When using modify style input, attribute types and values are delimited by an equal sign (=). The general form of input lines for modify style is:

change_record
<blank line>
change_record
…
…
…
In modify style input:
  1. A comment line is a line that begins with a number sign (#) in column 1. Comment lines are ignored.
  2. A line can be continued by specifying a backslash (\) as the last character of the line. If a line is continued, the backslash character is removed and the succeeding line is appended directly after the character preceding the backslash character.

An input file in modify style consists of one or more change_record sets of lines separated by a single blank line. Each change_record has the following form:

distinguished_name
[+|-]{attrtype} = {value_line1[\
value_line2[\
…value_lineN]]}
…
…
…

Therefore, a change_record consists of a line indicating the distinguished name of the directory entry to be modified along with one or more attribute modification lines. Each attribute modification line consists of an optional add or delete indicator (+ or -), an attribute type, and an attribute value. If a plus sign (+) is specified, the modification type is set to add. If a hyphen (-) is specified, the modification type is set to delete. For a delete modification, the equal sign (=) and value should be omitted to remove an entire attribute. If the add or delete indicator is not specified, the modification type is set to add unless the -r option is used, in which case the modification type is set to replace. Any leading or trailing white space characters are removed from attribute values. If trailing white space characters are required for attribute values, the RFC 2849 LDIF style of input must be used. The new-line character at the end of the input line is not retained as part of the attribute value.

Multiple attribute values are specified by using multiple attrtype=value specifications.

Modify style examples

Here are some examples of valid input for the ldapmodify command by using modify style.

Adding a new entry
The following example adds a new entry into the directory by using name cn=Tim Doe, ou=Your Department, o=Your Company, c=US:
cn=Tim Doe, ou=Your Department, o=Your Company, c=US
cn=Tim Doe
sn=Doe
objectclass=organizationalperson
objectclass=person
objectclass=top
Adding a new attribute type

The following example adds two new attribute types to the existing entry. Note the registeredaddress attribute is assigned two values:

cn=Tim Doe, ou=Your Department, o=Your Company, c=US
+telephonenumber=888 555 1234
+registeredaddress=td@yourcompany.com
+registeredaddress=ttd@yourcompany.com
Replacing attribute values
Assuming that the command invocation was:
ldapmodify -r …
The following example replaces the attribute values for the telephonenumber and registeredaddress attributes with the specified attribute values. If the -r command-line option was not specified, the attribute values are added to the existing set of attribute values.
cn=Tim Doe, ou=Your Department, o=Your Company, c=US
telephonenumber=888 555 4321
registeredaddress: tim@yourcompany.com
registeredaddress: timtd@yourcompany.com
Deleting an attribute type
The following example deletes a single registeredaddress attribute value from the existing entry.
cn=Tim Doe, ou=Your Department, o=Your Company, c=US
-registeredaddress=tim@yourcompany.com
Adding an attribute
The following example adds a description attribute. The description attribute value spans multiple lines:
cn=Tim Doe, ou=Your Department, o=Your Company, c=US
+description=This is a very long attribute \
value that is continued on a second line.  \
Note the backslash at the end of the line to \
be continued in order to signify that \
the line is continued.
Changing the numeric object identifier:

A special input file is required to change the numeric object identifier (OID) of an attribute or an object class in the z/OS LDAP server schema. This input file must contain a delete of the existing attribute or object class (with the old OID) followed by an add of the new version of the attribute or object class (with the new OID). The value for NAME within the attribute or object class must be identical in the delete and add modifications. When using the z/OS IBM® Tivoli® Directory Server, noncritical values (such as DESC) can be changed in the new version but critical values (such as the SYNTAX or the MUST and MAY lists) must be the same as in the existing attribute or object class. The deletion and addition must be the only modifications that are made to the schema in that operation.

For example, to change the OID for the userHomeAddr attribute from 1.3.21.7777 to 2.5.44.3.9999 in the schema, the input file for ldapmodify should contain: 
cn=schema
-attributetypes=( 1.3.21.7777 NAME 'userHomeAddr' DESC 'The home address' \ 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications )
+attributetypes=( 2.5.44.3.9999 NAME 'userHomeAddr' DESC 'The home address' \ 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications )
Examples
Following are some ldapmodify and ldapadd examples. It might be necessary to supply a bindDN and passwd for modify to be allowed.
  1. Assume that the /tmp/entrymods file exists and has the following contents:
    dn: cn=Modify Me, o=My Company, c=US
changetype: modify
replace: mail
mail: modme@MyCompany.com
-
add: title
title: Vice President
-
add: jpegPhoto
jpegPhoto: /tmp/modme.jpeg
-
delete: description
-
    The following command replaces the contents of the Modify Me entry's mail attribute with the value modme@MyCompany.com, adds a title of Vice President, adds the contents of the file /tmp/modme.jpeg as the jpegPhoto value, and completely removes the description attribute.
    ldapmodify -b -r -f /tmp/entrymods
    The same modifications can be performed by using the older ldapmodify input format: 
    cn=Modify Me, o=My Company, c=US
mail=modme@MyCompany.com
+title=Vice President
+jpegPhoto=/tmp/modme.jpeg
-description
  2. Assume that the /tmp/certuser file exists and has the following contents:
    dn: cn=Karen Smith, o=My Company, c=US
objectclass: inetorgperson
cn: Karen Smith
sn: Smith
userpassword: secret
usercertificate: //'USER.CERTDER'
    The following command adds a new entry for Karen Smith by using the values from the /tmp/certuser file. The usercertificate value is obtained from the binary data set USER.CERTDER.
    ldapadd -b -f /tmp/certuser
  3. Assume that the /tmp/newentry file exists and has the following contents: 
    dn: cn=Joe Smith, o=My Company, c=US
objectClass: person
cn: Joseph Smith
cn: Joe Smith
sn: Smith
title: Manager
mail: jsmith@jsmith.MyCompany.com
uid: jsmith
    The following command adds a new entry for Joe Smith by using the values from the /tmp/newentry file. 
    ldapadd -f /tmp/newentry
  4. Assume that the /tmp/newentry file exists and has the following contents: 
    dn: cn=Joe Smith, o=My Company, c=US
changetype: delete
    The following command removes Joe Smith's entry. 
    ldapmodify -f /tmp/newentry
  5. Assume that hostA contains the referral object: 
    dn: o=ABC,c=US
ref: ldap://hostB:390/o=ABC,c=US
objectclass: referral
    and hostB contains the organization object: 
    dn: o=ABC,c=US
o: ABC
objectclass: organization
telephoneNumber: 123-4567
    and the /tmp/refmods file has the following contents: 
    dn: o=ABC,c=US
changetype: modify
replace: ref
ref: ldap://hostB:391/o=ABC,c=US
-
    and the /tmp/ABCmods file has the following contents: 
    dn: o=ABC,c=US
changetype: modify
add: telephoneNumber
telephoneNumber: 123-1111
-
    The following command replaces the ref attribute value of the referral object o=ABC,c=US in hostA, changing the TCP port address in the URL from 390 to 391. 
    ldapmodify -h hostA -r -M -f /tmp/refmods
    The following command adds the telephoneNumber attribute value 123-1111 to o=ABC,c=US in hostB. 
    ldapmodify -h hostB -p 391 -f /tmp/ABCmods
  6. Assume that the /tmp/schemamods file exists and has the following contents: 
    dn: cn=schema
-attributetypes=( 1.2.1 NAME 'attr1' DESC 'attribute type' \
  EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+attributetypes=( 1.2.1 NAME 'attr1' DESC 'attribute type - obsoleted' OBSOLETE \
  EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+attributetypes=( 1.2.2 NAME 'attr2' DESC 'new attribute type' \
  EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+ibmattributetypes=( 1.2.2 ACCESS-CLASS normal )
-objectclasses=( 4.5.6 NAME 'oc1' DESC 'sample object class' STRUCTURAL MUST ( cn ) )
+objectclasses=( 4.5.6 NAME 'oc1' DESC 'sample object class' STRUCTURAL MUST ( cn ) MAY ( attr2 ) )
    The following command obsoletes the attr1 attribute type definition by specifying the OBSOLETE keyword in the definition, adds the attr2 attribute type definition and the associated IBM attribute type information, and modifies the oc1 object class definition by adding the attr2 attribute type as a MAY attribute.
    ldapmodify -f /tmp/schemamods
  7. Assume that the /tmp/newentry file exists and has the following contents: 
    dn: racfid=u1,profiletype=user,sysplex=sysplexa 
objectclass: racfuser 
objectclass: racfbasecommon
racfid: u1
racfdefaultgroup: racfid=g1,profiletype=group,sysplex=sysplexa
racfconnectgroupUACC: read
racfconnectgroupauthority: join
    The following command creates a RACF user named u1, with join authority and update UACC in the group g1. It is assumed that the z/OS LDAP support for RACF access suffix is sysplex=sysplexa and that admin1 has the RACF authority to make this update to RACF.
    ldapadd -D racfid=admin1,profiletype=user,sysplex=sysplexa -w passwd -f /tmp/newentry
  8. Assume that the /tmp/modentry file contains the following attributes.
    Note: In the following LDIF, the x on the replace: x line is a placeholder for the attribute name and allows multiple attribute names and values to be replaced in a single operation.
    dn: racfid=u1,profiletype=user,sysplex=sysplexa
changetype: modify
replace: x
racfattributes: OPERATIONS
racfconnectgroupUACC: update
    The following command adds OPERATIONS to racfattributes and changes the racfconnectgroupUACC value to update.
    ldapmodify -D racfid=admin1,profiletype=user,sysplex=sysplexa -w passwd -f /tmp/modentry

Notes

The LDAP_DEBUG environment variable can be used to set the debug level. For more information about specifying the debug level by using keywords, decimal, hexadecimal, and plus and minus syntax, see Enabling tracing.

You can specify an LDAP URL for ldapHost on the -h option. See ldap_init() for more information.

For information about SSL/TLS, see SSL/TLS information for LDAP client utilities.

Diagnostics

Exit status is 0 if no errors occur. Errors result in a nonzero exit status and a diagnostic message being written to standard error.