Editing Lightweight Directory Access Protocol (section)

===Modify===
The MODIFY operation is used by LDAP clients to request that the LDAP server make changes to existing entries.<ref>[http://tools.ietf.org/html/rfc4511#section-4.6 Modify Section of RFC4511]</ref> Attempts to modify entries that do not exist will fail. MODIFY requests are subject  to access controls as implemented by the server.

The MODIFY operation requires that the distinguished name (DN) of the entry be specified, and a sequence of changes. Each change in the sequence must be one of:
* add (add a new value, which must not already exist in the attribute)
* delete (delete an existing value)
* replace (replace an existing value with a new value)

[[LDIF]] example of adding a value to an attribute:

<syntaxhighlight lang="ldif">
dn: dc=example,dc=com
changetype: modify
add: cn
cn: the-new-cn-value-to-be-added
-
</syntaxhighlight>

To replace the value of an existing attribute, use the <code>replace</code> keyword. If the attribute is multi-valued, the client must specify the value of the attribute to update.

To delete an attribute from an entry, use the keyword <code>delete</code> and the changetype designator <code>modify</code>. If the attribute is multi-valued, the client must specify the value of the attribute to delete.

There is also a Modify-Increment extension<ref>{{cite IETF|title=LDAP Modify-Increment Extension|rfc=4525|first=K.|last=Zeilenga}}</ref> which allows an incrementable attribute value to be incremented by a specified amount. The following example using LDIF increments <code>employeeNumber</code> by <code>5</code>:

<syntaxhighlight lang="ldif">
dn: uid=user.0,ou=people,dc=example,dc=com
changetype: modify
increment: employeeNumber
employeeNumber: 5
-
</syntaxhighlight>

When LDAP servers are in a replicated topology, LDAP clients should consider using the post-read control to verify updates instead of a search after an update.<ref>{{Cite IETF|title = Lightweight Directory Access Protocol (LDAP) Read Entry Controls|rfc = 4527|publisher = [[IETF]]|last = Zeilenga|first = K.}}</ref> The post-read control is designed so that applications need not issue a search request after an update – it is bad form to retrieve an entry for the sole purpose of checking that an update worked because of the replication [[eventual consistency]] model. An LDAP client should not assume that it connects to the same directory server for each request because architects may have placed load-balancers or LDAP proxies or both between LDAP clients and servers.