Require MFA for all privileged accounts.
389-IAM-002 - severity: high
| Field | Value |
|---|---|
| Control ID | 389-IAM-002 |
| Severity | high |
| Type | preventive |
| Owner | IT Operations |
| Status | authored |
| NIST 800-53 | IA-2(1), IA-2(2) |
| DISA SRG | SRG-APP-000149, SRG-APP-000150 |
Rationale¶
389 Directory Server has no native multi-factor authentication capability. Simple bind validates only a stored password; there is no built-in TOTP, OTP, push notification, or hardware-token support for directory binds. This means that a single stolen or phished credential is entirely sufficient to bind as a privileged account and gain the full access it carries. Privileged accounts are the primary targets of credential-theft campaigns, and directory super-users represent an especially high-value target because a successful bind yields read access to all stored passwords, PII, and group memberships across the directory. MFA must therefore be enforced externally by delegating privileged authentication to SASL/GSSAPI backed by a Kerberos realm or IdP that requires MFA for admin principals, or by configuring the PAM Pass-Through Auth plugin to route privileged binds through a PAM stack with an MFA module (e.g., pam_oath, pam_duo, or SSSD joined to an MFA IdP). Without one of these integrations, this control cannot be satisfied, and the deployment remains vulnerable to password-only credential attacks. IA-2(1) and IA-2(2) mandate MFA for privileged network access; this external-delegation approach is the only viable implementation path for 389DS.
Check¶
Verify privileged binds are delegated to an MFA-capable mechanism (SASL/GSSAPI or PAM pass-through), not simple password bind.
dsconf <instance> plugin list | grep -i 'pam\|pass'
# confirm the configured external auth (Kerberos/PAM) enforces MFA for admin principals
Remediation¶
Delegate privileged authentication to an MFA-capable backend (PAM pass-through to an MFA PAM stack, or SASL/GSSAPI to an MFA IdP).
# 389DS has no native MFA. Enable PAM pass-through auth and point it at a PAM
# stack that enforces MFA for admin accounts (verify the exact subcommand with
# `dsconf <instance> plugin --help`):
dsconf <instance> plugin pam-pass-through-auth show
# then configure the PAM service/stack (pam_oath, pam_duo, SSSD+IdP) and map admin users to it
References¶
Implementation Notes¶
Because MFA is external to 389DS, this control requires organisational integration work beyond a single dsconf command. The pam-pass-through-auth plugin subcommand name can vary between 389DS package versions; confirm the exact name for your installation with dsconf <instance> plugin --help before scripting it.
Document which IdP or PAM stack enforces MFA, which admin principals are covered, and which bind DNs are excluded (e.g., cn=Directory Manager cannot itself be delegated to PAM - see 389-IAM-001 for its separate controls). For SASL/GSSAPI, ensure that the Kerberos KDC policy requires pre-authentication and that admin service principals are issued only with step-up or MFA policies enabled. Regularly audit which accounts are still permitted to use simple bind and treat any active simple-bind admin account as a gap against this control.