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. Use 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.-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
orCRAM-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 mechanismSpecify 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, orDIGEST-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 tooff
, a schema modification removes all current values for an attribute and replaces them with the set of values in the replace operation. If set toon
, 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
or3
. The default is3
.-w passwd Use passwd as the password for simple, CRAM-MD5
, andDIGEST-MD5
authentication. The default is aNULL
string.-x sslFipsMode Specify FIPS mode for SSL/TLS protected connections. The supported FIPS modes are LEVEL1, LEVEL2, LEVEL3,
andOFF
. 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 toOFF
.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.
- A standard LDIF style that is defined by RFC 2849
- A non-standard "modify 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.
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". - The ldapadd command is equivalent to invoking the ldapmodify -a command.
- The ldapmodify and ldapadd utilities do not support base64 encoded distinguished names.
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
…
…
…
- A comment line is a line that begins with a number sign (
#
) in column 1. Comment lines are ignored. - 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.
- 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.
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. 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.
Here are some examples of valid input for the ldapmodify command using RFC 2849 LDIF style.
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
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
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
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
-
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
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
-
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
-
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
. 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
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
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
…
…
…
- A comment line is a line that begins with a number sign (
#
) in column 1. Comment lines are ignored. - 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.
Here are some examples of valid input for the ldapmodify command by using modify style.
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
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
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
registeredaddress
attribute value from the existing
entry.cn=Tim Doe, ou=Your Department, o=Your Company, c=US
-registeredaddress=tim@yourcompany.com
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.
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.
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 )
- 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 theModify Me
entry'smail
attribute with the valuemodme@MyCompany.com
, adds atitle
ofVice President
, adds the contents of the file/tmp/modme.jpeg
as thejpegPhoto
value, and completely removes thedescription
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
- 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. Theusercertificate
value is obtained from the binary data set USER.CERTDER.ldapadd -b -f /tmp/certuser
- 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
- 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
- Assume that
hostA
contains the referral object:
anddn: o=ABC,c=US ref: ldap://hostB:390/o=ABC,c=US objectclass: referral
hostB
contains the organization object:
and thedn: o=ABC,c=US o: ABC objectclass: organization telephoneNumber: 123-4567
/tmp/refmods
file has the following contents:
and thedn: o=ABC,c=US changetype: modify replace: ref ref: ldap://hostB:391/o=ABC,c=US -
/tmp/ABCmods
file has the following contents:dn: o=ABC,c=US changetype: modify add: telephoneNumber telephoneNumber: 123-1111 -
The following command replaces theref
attribute value of the referral objecto=ABC,c=US
inhostA
, changing the TCP port address in the URL from 390 to 391.ldapmodify -h hostA -r -M -f /tmp/refmods
The following command adds thetelephoneNumber
attribute value123-1111
too=ABC,c=US
inhostB
.ldapmodify -h hostB -p 391 -f /tmp/ABCmods
- 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 theattr1
attribute type definition by specifying theOBSOLETE
keyword in the definition, adds theattr2
attribute type definition and the associated IBM attribute type information, and modifies theoc1
object class definition by adding theattr2
attribute type as aMAY
attribute.ldapmodify -f /tmp/schemamods
- 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 namedu1
, with join authority and update UACC in the groupg1
. It is assumed that the z/OS LDAP support for RACF access suffix issysplex=sysplexa
and thatadmin1
has the RACF authority to make this update to RACF.ldapadd -D racfid=admin1,profiletype=user,sysplex=sysplexa -w passwd -f /tmp/newentry
- Assume that the /tmp/modentry file contains the following attributes.
Note: In the following LDIF, the
x
on thereplace: x
line is a placeholder for the attribute name and allows multiple attribute names and values to be replaced in a single operation.
The following command addsdn: racfid=u1,profiletype=user,sysplex=sysplexa changetype: modify replace: x racfattributes: OPERATIONS racfconnectgroupUACC: update
OPERATIONS
toracfattributes
and changes theracfconnectgroupUACC
value toupdate
.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.