Use attribute-based access control (ABAC) for granular user permissions.
389-IAM-005 - severity: medium
| Field | Value |
|---|---|
| Control ID | 389-IAM-005 |
| Severity | medium |
| Type | preventive |
| Owner | IT Operations |
| Status | authored |
| NIST 800-53 | AC-3, AC-24 |
| DISA SRG | SRG-APP-000033 |
Rationale¶
ACI grants expressed as hard-coded lists of bind DNs become silently incorrect as an organisation evolves: users change roles, teams are restructured, accounts are renamed or moved, and service accounts are retired - but DN enumerations in ACIs do not update automatically. This drift means that access control decisions diverge from intended policy without any administrator noticing, creating both over-permission (former role members retaining access) and under-permission (new role members blocked). Attribute- and role-based ACIs using targetattr, targetfilter, groupdn, and roledn tie access decisions to directory attributes and group membership, so permissions automatically stay correct as entries change without requiring manual ACI maintenance after every organisational update. This approach also makes each ACI's intent legible to compliance reviewers: a groupdn rule expressing "members of the eng-managers group may read entries with department=Engineering" is self-documenting in a way that a list of twenty bind DNs is not. Attribute-based access control satisfies AC-3 (Access Enforcement) by ensuring that access rules are evaluated dynamically against current state, and AC-24 (Access Control Decisions) by keeping authorisation policy centralised and coherent rather than distributed across brittle per-DN grants.
Check¶
Review ACIs in the directory suffix and confirm that access rules use targetattr and targetfilter expressions rather than hard-coded per-DN grants.
ldapsearch -x -o ldif-wrap=no -D "cn=Directory Manager" -W -b <suffix> aci
Remediation¶
Express authorization with attribute/filter-based ACIs (targetattr/targetfilter) rather than DN enumeration.
# Implement targetfilter-based ACIs so access follows attributes/roles, e.g.:
ldapmodify -D "cn=Directory Manager" -W -x <<'EOF'
dn: <subtree-dn>
changetype: modify
replace: aci
aci: (targetattr="*")(targetfilter="(department=Engineering)")(version 3.0; acl "eng-managers"; allow (read,search) groupdn="ldap:///cn=eng-managers,<suffix>";)
EOF
References¶
Implementation Notes¶
targetfilter is evaluated per matching entry during a search, which adds overhead on large result sets or broad subtree searches. Measure query latency against representative data volumes before deploying filters on high-traffic attributes. For best maintainability, combine targetfilter with groupdn or roledn so that adding a user to a group automatically grants (or revokes) the corresponding access, rather than embedding attribute values directly in the ACI string.
Test each new ACI in isolation against a non-production directory before deploying to production; an incorrect filter silently admits or denies access without returning an error to the bind client. Document the intended semantics of each ACI (which role/team, what operation, why) alongside the rule text, and include ACI review in the account-lifecycle audit process described in 389-IAM-004.