6.9. Using Syntax Validation

With syntax validation, the Directory Server checks that the value of an attribute follows the rules of the syntax given in the definition for that attribute. For example, syntax validation will confirm that a new telephoneNumber attribute actually has a valid telephone number for its value.

6.9.1. About Syntax Validation

As with schema checking, validation reviews any directory modification and rejects changes that violate the syntax. Additional settings can be optionally configured so that syntax validation can log warning messages about syntax violations and then either reject the modification or allow the modification process to succeed.
This feature validates all attribute syntaxes, with the exception of binary syntaxes (which cannot be verified) and non-standard syntaxes, which do not have a defined required format. The syntaxes are validated against RFC 4514.

6.9.2. Syntax Validation and Other Directory Server Operations

Syntax validation is mainly relevant for standard LDAP operations like creating entries (add) or editing attributes (modify). Validating attribute syntax can impact other Directory Server operations, however.
Database Encryption
For normal LDAP operations, an attribute is encrypted just before the value is written to the database. This means That encryption occurs after the attribute syntax is validated.
Encrypted databases (as described in Section 2.2.3, “Configuring Attribute Encryption”) can be exported and imported. Normally, it is strongly recommended that these export and import operations are done with the -E flag with db2ldif and ldif2db, which allows syntax validation to occur just fine for the import operation. However, if the encrypted database is exported without using the -E flag (which is not supported), then an LDIF with encrypted values is created. When this LDIF is then imported, the encrypted attributes cannot be validated, a warning is logged, and attribute validation is skipped in the imported entry.
There may be differences in the allowed or enforced syntaxes for attributes in Windows Active Directory entries and Red Hat Directory Server entries. In that case, the Active Directory values could not be properly synced over because syntax validation enforces the RFC standards in the Directory Server entries.
If the Directory Server 8.2 instance is a supplier which replicates its changes to a consumer, then there is no issue with using syntax validation. However, if the supplier in replication is an older version of Directory Server or has syntax validation disabled, then syntax validation should not be used on the 8.2 consumer because the Directory Server 8.2 consumer may reject attribute values that the master allows.

6.9.3. Enabling or Disabling Syntax Validation

Syntax validation is configured by the nsslapd-syntaxcheck attribute. The value of this attribute is either on or off (by default, this is on). To change the syntax validation, modify this attribute using ldapmodify or by editing the dse.ldif file directly.
/usr/lib64/mozldap/ldapmodify -D "cn=directory manager" -w secret -p 389

dn: cn=config
changetype: modify
replace: nsslapd-syntaxcheck
nsslapd-syntaxcheck: off


If syntax validation is disabled, then run the syntax-validate.pl script to audit existing attribute values before re-enabling syntax validation. See Section 6.9.6, “Validating the Syntax of Existing Attribute Values”.

6.9.4. Enabling Strict Syntax Validation for DNs

When syntax validation is enabled, DNs are validated against RFC 4514, as are other attribte syntaxes. However, DN syntax validation is enabled separately because the strictness of later standards can invalidate old-style DNs, and therefore directory trees.
Syntax validation checks DNs against section 3 in RFC 4514.
The value of this attribute is either on or off (by default, this is off). To change the syntax validation, modify this attribute using ldapmodify or by editing the dse.ldif file directly.
/usr/lib64/mozldap/ldapmodify -D "cn=directory manager" -w secret -p 389
dn: cn=config
changetype: modify
replace: nsslapd-dn-validate-strict
nsslapd-dn-validate-strict: on
If strict DN validation is enabled and a DN value does not conform to the required syntax, then the operation fails with LDAP result code 34, INVALID_DN_SYNTAX.


If a DN contains a nested DN, then the syntax validation checks not only the DN, but it looks up and normalizes the nested DN as well. This can affect performance in some situations, because a single validation can result in multiple lookup and normalization operations.
To disable checking on the nested DNs, turn off the nsslapd-normalize-nested-dn attribute. The primary DN will be validated and normalized as expected.

6.9.5. Enabling Syntax Validation Warnings (Logging)

By default, syntax validation rejects any add or modify operations where an attribute value violates the required syntax. However, the violation itself is not recorded to the errors log by default. The nsslapd-syntaxlogging attribute enables error logging for any syntax violations.


Syntax violations discovered by the syntax validation script and task are logged in the Directory Server error log.
If nsslapd-syntaxlogging and nsslapd-syntaxcheck are both enabled, then any invalid attribute modification is rejected and the message written to the log. If nsslapd-syntaxlogging is enabled but nsslapd-syntaxcheck is disabled, then the operation is allowed to succeed, but the warning message is still written to the error log.
The value of this attribute is either on or off (by default, this is off). To enable syntax validation logging, edit the attribute using ldapmodify or by editing the dse.ldif file directly.
/usr/lib64/mozldap/ldapmodify -D "cn=directory manager" -w secret -p 389

dn: cn=config
changetype: modify
replace: nsslapd-syntaxlogging
nsslapd-syntaxlogging: on

6.9.6. Validating the Syntax of Existing Attribute Values

Syntax validation checks every modification to attributes to make sure that the new value has the required syntax for that attribute type. However, syntax validation only audits changes to attribute values, such as when an attribute is added or modified. It does not validate the syntax of existing attribute values.
Validation of existing attribute values can be done with the syntax validation script. This script checks entries under a specified subtree (in the -b option) and, optionally, only entries which match a specified filter (in the -f option). For example:
/usr/lib64/dirsrv/instance_name/syntax-validate.pl -D "cn=directory manager" -w secret -b "ou=people,dc=example,dc=com" -f "objectclass=inetorgperson)"
Any syntax violations in existing attribute values can be identified and corrected through this script.


If syntax validation is disabled or if a server is migrated, then there may be data in the server which does not conform to attribute syntax requirements. The syntax validation script can be run to evaluate those existing attribute values before enabling syntax validation.
Alternately, a task can be launched to initiate syntax validation, specifying the required base DN and, optionally, LDAP search filter.
/usr/lib64/mozldap/ldapmodify -a -D "cn=directory manager" -w secret -p 389 -h server.example.com

dn: cn=example, cn=syntax validation,cn=tasks,cn=config
objectclass: extensibleObject
basedn: ou=people,dc=example,dc=com
filter: "(objectclass=inetorgperson)"