Skip to content

Mask or encrypt sensitive data fields to protect user privacy.

389-DPC-002 - severity: high

Field Value
Control ID 389-DPC-002
Severity high
Type preventive
Owner IT Operations
Status authored
NIST 800-53 SC-28, AC-3
DISA SRG SRG-APP-000231, SRG-APP-000429

Rationale

Sensitive attributes such as national identifiers, PINs, or custom secret fields stored in the directory are exposed in plaintext on disk if attribute encryption is not enabled, meaning that anyone with direct access to the database files or backup media can read them without LDAP credentials - bypassing all protocol-level access controls entirely. An attacker who obtains a database file or backup archive gains all attribute values for every entry unless at-rest encryption is in place. Attribute encryption alone is insufficient: without read-deny ACIs, an authenticated LDAP client with a valid bind can still retrieve plaintext values through the protocol. Defense-in-depth therefore requires both layers - at-rest encryption ensures the database files and backups are opaque, while ACIs enforce least-privilege retrieval at the protocol level. NIST SP 800-53 SC-28 mandates protection of information at rest, and AC-3 requires enforcement of approved authorisations for information access.

Check

List the attributes currently configured for at-rest encryption on the target backend.

dsconf <instance> backend attr-encrypt --list <backend_name>

Remediation

Encrypt sensitive attributes at rest and deny read access to non-privileged users.

dsconf <instance> backend attr-encrypt --add-attr <sensitive_attribute> <backend_name>
# deny read of the sensitive attribute to ordinary users via an ACI:
ldapmodify -x -D "cn=Directory Manager" -W <<'EOF'
dn: <suffix>
changetype: modify
add: aci
aci: (targetattr="<sensitive_attribute>")(version 3.0; acl "deny-read-sensitive"; deny (read,search,compare) userdn="ldap:///anyone";)
EOF
dsctl <instance> restart

References

Implementation Notes

Attribute encryption requires TLS to be configured on the instance first, because the server uses its certificate's key material to wrap the per-attribute symmetric key. Enable encryption per-backend: each directory suffix has its own backend (e.g., userRoot), and --add-attr must be run against every backend that holds the sensitive data. Enabling encryption does not retroactively encrypt existing entries - existing values are encrypted only when the entry is next written; a full re-encryption requires exporting and re-importing the database or replicating from an already-encrypted replica (see 389-SH-001 for the export/import procedure). A server restart is required after modifying attribute encryption configuration. Note that encrypting an attribute does not prevent an authorized Directory Manager from reading it - the ACI shown in the fix command denies ldap:///anyone, which includes ordinary authenticated users but is overridden for the cn=Directory Manager root DN by its bypass privilege. Adjust the ACI target DN and subject as appropriate for your access model.