Limit service accounts to required directory service access only.
389-IAM-003 - severity: medium
| Field | Value |
|---|---|
| Control ID | 389-IAM-003 |
| Severity | medium |
| Type | preventive |
| Owner | IT Operations |
| Status | authored |
| NIST 800-53 | AC-5, AC-6 |
| DISA SRG | SRG-APP-000033, SRG-APP-000340 |
Rationale¶
Service accounts used by applications - sync agents, monitoring tools, provisioning pipelines, LDAP-integrated services - frequently accumulate broader ACI grants than their function requires because tree-wide read or unconstrained write is simpler to configure than precise per-attribute, per-subtree scoping. This over-provisioning is a lateral-movement multiplier: if the application, its credentials, or its host is compromised, the attacker immediately inherits every permission in the service account's ACIs with no additional exploitation step needed. Constraining each service account to the specific attributes it reads, the specific subtrees it needs to traverse, and the specific operations (compare, read, write) it must perform reduces the blast radius of a service account compromise to a known and documented surface. Because service accounts often bind on automated schedules they can also mask anomalous activity if their broad permissions produce large result sets that look indistinguishable from normal operation. Least-privilege ACIs - expressed with explicit targetattr lists and scoped target subtree filters - also make it straightforward for reviewers to verify that the grant still matches the application's current function, supporting AC-5 (Separation of Duties) and AC-6 (Least Privilege) continuous compliance.
Check¶
Review all ACIs in the directory suffix and confirm no service account has broader access (write, manage, or tree-wide read) than its documented function requires.
ldapsearch -x -o ldif-wrap=no -D "cn=Directory Manager" -W -b <suffix> aci
Remediation¶
Replace broad ACIs with least-privilege ACIs scoped to the attributes/subtrees each service account needs.
# Review the aci values returned by the check, then tighten with ldapmodify, e.g.:
ldapmodify -D "cn=Directory Manager" -W -x <<'EOF'
dn: <subtree-dn>
changetype: modify
replace: aci
aci: (targetattr="cn || uid")(version 3.0; acl "svc-read"; allow (read,search,compare) userdn="ldap:///<service-account-dn>";)
EOF
References¶
Implementation Notes¶
Before modifying any ACI, test the change against a non-production replica or a test directory instance. A mistakenly broad deny can lock out legitimate access; a mistakenly narrow replace on the aci attribute will silently drop previously granted permissions for other principals sharing that entry.
Prefer targetattr with an explicit attribute list over targetattr="*", and use target to scope to a specific subtree rather than the root suffix. Document each service account's intended function alongside its ACI grant so that reviewers can verify scope without re-reading application code. Incorporate ACI review into your account-review cycle (see 389-IAM-004) so that service accounts whose applications have been decommissioned are caught and removed promptly.