Partager via


3.1.1.2.5 Schema Modifications

This section documents the special behavior of schema objects with respect to LDAP Add, Modify, Modify DN, and Delete requests.

Only the DC that owns the Schema Master FSMO role performs originating updates of objects in the schema NC, as specified in section 3.1.1.1.11.

All transactions that perform originating updates to objects in the schema NC are serialized, even if the updates do not appear to conflict and thus do not seem to require serialization.

Many attributes of attributeSchema and classSchema objects are system-only, as specified in sections 3.1.1.2.3 and 3.1.1.2.4. An LDAP Modify request that attempts to modify a system-only attribute (except as specified in section 3.1.1.5.3.2) fails with error constraintViolation / ERROR_DS_CANT_MOD_SYSTEM_ONLY.

A Delete of an attributeSchema or classSchema object fails, with error unwillingToPerform / ERROR_DS_CANT_DELETE.

An attempt to add any object other than a schema object in the schema NC fails with the error unwillingToPerform / ERROR_DS_CANT_CREATE_UNDER_SCHEMA.

There is no constraint on the amount of time between when an object in the schema NC is successfully added or modified and when the DC enforces the updated schema. Therefore, it is possible that there is a period of time during which the schema enforced by the DC does not reflect the schema represented by the objects in the schema NC. Although the protocol places no boundary or requirements on the length of this time period, it is recommended that implementations minimize the length of this time period to improve the usability of the directory for clients.

The server MUST guarantee that all successful schema modifications are eventually enforced.