LDAP Updates: Operation, Result and Uncertainty

1. Core mechanism

03.05 covered searching and 03.06 connection security. Now examine what counts as one operation when updating an entry. Schema validity, write permission and knowledge of the outcome are separate questions.

Interfaces and specifications

• Add creates an entry; required attributes and parent conditions must hold.
• Modify changes attributes of an existing entry. Its changes list forms one atomic operation.
• ModifyDN changes an RDN or permitted location; it is distinct from an ordinary attribute replacement.
• Delete removes an entry. Subsequent AD deleted-object and retention behavior is covered in 10.02.
• LDAPResult carries a standardized resultCode; diagnosticMessage is supplementary and can be empty.

Start with the operation target

You want to change Ece’s department. Modify fits an existing entry; Add is needed to create a missing entry. Similar forms can represent different operations. A DN identifies a location; a recreated entry at that name need not retain the old objectGUID.

The server evaluates the operation right on the target in addition to your authenticated identity. Schema defines valid structure; it does not grant permission. 05.05 develops the requested operation, target and right distinction.

One Modify versus two independent requests

One Modify can contain department=Finance and displayName=Ece A. The server processes the ordered list as one atomic operation: all changes succeed or none are applied. Schema conformity is required for the resulting entry, rather than every intermediate state.

A separate successful Add followed by a failed Modify does not undo the Add. Launching several requests with one application button does not turn them into a transaction. The application must represent that distinction accurately.

What do we know when the response disappears?

Distinguish a delivered rejection, a delivered success and no received response. In the last case, the server may have completed the update or may not have applied it. A disconnected transport does not distinguish those outcomes.

RFC 4511 §3.1 requires the client not to assume that an update succeeded or failed. Reconcile the entry, DC and operation context before deciding on a retry. A later read shows current state; if another writer intervened, it does not by itself establish the first operation’s history.

The boundary of success

A success from DC-A does not establish that DC-B sees the value or that an application has refreshed its cache. Those require separate observations. 10.07 shows which metadata accompanies replication.

5136 is a separate evidence channel, dependent on Directory Service Changes auditing and applicable SACL conditions. Its absence does not establish that no change occurred without checking generation and collection coverage.

State and data flow

1. The client prepares the target entry and a Modify list for two benign attributes.
2. The writable DC evaluates schema and authorization conditions for the target operation.
3. The single Modify list is applied or rejected as a whole.
4. LDAPResult can reach the client; a lost response leaves the client uncertain.
5. Read-back on the relevant entry and DC is a state observation taken at a separate time.
6. The other replica and audit record are evaluated independently under their own conditions.

2. Exploitation

Broken trust assumption

Assuming that a successful bind or visible entry also grants write permission.

Technical prerequisites

• An impact claim requires the relevant target, effective right and observed context.

Exploitation mechanism

Risk follows the effective target, attribute and right scope. A narrowly named role can have broader effective rights. Treating a missing response as certain failure can also cause unintended repeats; these risks occur at different boundaries.

A role name does not define its rights

A phone-update role name is a job description. Examine explicit and inherited rights on the relevant entries and attributes. Bound the impact accordingly; read or bind success does not imply domain-wide control.

Do not turn uncertainty into certain failure

A missing response is not a schema rejection. If an Add already applied, resending it does not necessarily restart a clean workflow. This example uses only benign department and displayName values.

3. Defense & Detection

Telemetry scope

• Correlate the response with the request messageID, object identity, DC and time interval. Do not substitute a later state or audit observation for the response.

Events and relevant fields

• Event records reflect their producer’s decision under applicable generation and collection conditions; they do not establish the entire access chain.

Preserve the scope of evidence

Correlate the response with the request messageID, object identity, DC and time interval. Do not substitute a later state or audit observation for the response.

Do not treat an absent event as negative evidence without generation and collection coverage. Verify new behavior at its responsible owner.

Detection logic · XPath

*[System[(EventID=5136)]]

Query assumptions

• This selects candidate events only in applicable Windows Security logs. The lesson JSON worksheet is not a Windows event.
• Correlate the response with the request messageID, object identity, DC and time interval. Do not substitute a later state or audit observation for the response.

False positives

• Legitimate changes, context/cache reuse or temporary connectivity issues can produce the same symptom; this selection does not classify an attack.

Hardening

• Limit write rights to needed entries and attributes; do not substitute role names for effective permissions.
• Keep missing responses marked unknown; reconcile with read-back and change history.
• Verify Directory Service Changes auditing, SACL and collection coverage together.

Read the examples

{
  "kind": "teaching-record",
  "synthetic": true,
  "scenario": "N01",
  "object": "CN=Ece,OU=People,DC=example,DC=test",
  "stableObjectIdentity": "toy-object-17",
  "operation": "Modify",
  "changes": [
    {
      "attribute": "department",
      "replace": "Finance"
    },
    {
      "attribute": "displayName",
      "replace": "Ece A."
    }
  ],
  "branches": [
    {
      "serverApplied": false,
      "clientResponse": "error: objectClassViolation (65)"
    },
    {
      "serverApplied": true,
      "clientResponse": "success (0)"
    },
    {
      "serverApplied": true,
      "clientResponse": null
    }
  ]
}

Two reality checks

Assumption: Two updates launched by one button must roll back together.

In fact: Atomicity within one Modify does not make separate Add and Modify requests transactional. Each request has its own result.

Assumption: The client timed out, so the update did not apply.

In fact: Response loss leaves the outcome uncertain. Server state, a received response and another DC’s view are distinct evidence.

Sources

• RFC 4511 — LDAP protocol
  §3; §4.6–4.9; Appendix A LDAPResult
• MS-ADTS Add processing specifics
  §3.1.1.5.2.4, objectGUID/objectSid and generated attributes
• MS-ADTS schema modifications
  §3.1.1.2.5 Schema Modifications