Overview
Directory misconfigurations drive compromise risk: weak password policies, legacy crypto, unconstrained delegation, NTLMv1/LM, unsigned/unencrypted protocols, and over‑privileged Tier‑0 groups. Loxation’s AD Hardening provides a portable, policy‑driven method to detect and enforce secure configurations with strong guardrails and comprehensive auditability.
- Dry‑Run First: Generate capability‑aware diffs and enforcement plans without changes.
- Quorum Approvals: Apply only after MLS‑group quorum approvals within time windows.
- Staged Activation (Epochs): Schedule enforcement using not_before windows and rollback periods.
- MLS E2EE: Sensitive inventories, diffs, and plans delivered only to authorized admins; no plaintext in control‑plane or logs.
- Portable Policy Model: Unified controls across Microsoft AD, Samba, OpenLDAP, and FreeIPA with capability gating.
What You Get
- One workflow for multi‑directory hardening
- Least‑privilege service accounts and KMS MAC keys
- Full, versioned audit trails with policy fingerprints
- Automatic rollback within bounded windows
- No sensitive plaintext in messages, events or server logs
Core Capabilities
Control Families
- Password Policy Update: length, history, complexity, lockout (+ ppolicy on OpenLDAP; AD/Samba domain policy).
- Kerberos Cipher Policy: prefer AES256/AES128; disable RC4/DES/3DES; require preauth.
- NTLM Restriction: disable LM/NTLMv1; restrict NTLM usage (enforce/detect by provider).
- LDAP Security: require LDAPS/StartTLS; signing/channel binding; no cleartext binds.
- SMB Security: disable SMBv1; require signing; recommend encryption.
- Admin Tiering & Groups: enforce Tier‑0 allowlists; Protected Users; forbid generic service accounts.
- Delegation Controls: remove unconstrained delegation; set “sensitive & cannot be delegated”; migrate to constrained.
- Stale Account Controls: disable inactive; constrain interactive logon; gMSA guidance.
- Audit & Observability: action logs with policy hashes, versions, outcomes.
Security Properties
- Authorized Admins Only: MLS group membership + short‑lived jwt_proof (App Attest + TOTP + PoP).
- No Plaintext in Logs: Sensitive diffs/plans via MLS only; control‑plane carries non‑sensitive metadata.
- Immutable Audit: Versioned actions tied to policy_hash and action_id.
- Two‑Phase & Quorum: Dry‑run → notify → quorum approvals → apply within windows.
- Rollback Windows: Revert to previous state within bounded time.
Workflow
Dry‑Run → Approve → Apply
- Dry‑Run (policy_dry_run): Gateway discovers capabilities and reads current state via adapters; produces a diff_summary and enforcement_plan (MLS‑only to admins).
- Quorum Approval: Admins review MLS notifications and send service‑ack approvals; quorum counts enforced with deadlines.
- Apply (policy_apply): Gateway executes the plan atomically per adapter within the scheduled epoch (not_before); results recorded to the audit store.
- Rollback (policy_revert): Within the rollback window, revert to a prior policy_version_id (requires ack quorum by policy).
All sensitive outputs (inventory, diffs, enforcement plans) are delivered via MLS to authorized admin groups only.
Architecture
Components
- mls‑ad‑gateway (service member): orchestrates discovery, diff, apply, audit.
- mls‑ad‑admin (operator client): submits requests, reviews diffs, approves.
- mls‑ad‑monitor (observability): tracks outcomes and policy adherence.
- Adapters: microsoft, samba, openldap, freeipa (capability‑aware enforcement).
Policy & Governance
- Profiles: baseline, enterprise, strict — with provider‑specific capability mapping.
- Quorum & Timeouts: approvals, windows, and rollback governed by policy.
- Policy Fingerprints: canonical JSON with MAC (policy_hash) for idempotency and audit binding.
Security Model
- Authorization: MLS admin group membership + short‑lived jwt_proof (App Attest + TOTP + PoP) required for sensitive actions.
- Privacy: No sensitive topology or diffs in control‑plane events or logs — MLS only.
- Audit: Record action_type, action_id, directory_id, policy_version_id, diffs summary, approvals, and outcome.
Operator Experience
Typical Flow
- Choose directory scope and policy profile (e.g., “enterprise”).
- Run dry‑run to get MLS‑delivered diffs and plan.
- Schedule apply with not_before window; gather quorum approvals.
- Apply executes atomically per adapter within epoch; monitor results.
- Optionally revert within rollback window if needed.
Safety Valves
- require_dry_run_first = true by default
- block_if_capability_missing to avoid partial/unsupported enforcement
- Enforce maintenance windows via not_before scheduling
Detect vs Enforce
Controls degrade to detect/advisory when provider capability is absent (e.g., some Kerberos realm features on non‑AD KDCs). The gateway surfaces a capability matrix in dry‑run plans to make enforcement scope explicit.