389DS SRG Baseline: A Machine-Consumable Hardening Catalog for 389 Directory Server

Mon, 25 May 2026 00:00:00 GMT

389 Directory Server is one of the most widely deployed LDAP implementations in Linux environments. It underpins identity infrastructure across Red Hat, CentOS, Rocky Linux, and Fedora deployments. If you run Linux at any scale, there is a reasonable chance directory services are somewhere in your stack.

The hardening guidance for it is scattered. The DISA STIG for 389DS was withdrawn. The official documentation covers configuration but not security posture. If you want to harden a production 389DS instance against NIST 800-53 or DISA SRG requirements today, you are assembling that picture from multiple sources and hoping nothing falls through.

I started working on this problem about two years ago. At the time, I expected someone else would publish something before I got far enough to make it worth releasing. Nobody did. The gap that existed then still exists now, so I pulled the project out of storage, rebuilt it properly, and decided to push it forward.

389DS SRG Baseline is the result.

What It Is

43 security controls for 389 Directory Server, organized across 9 domains: network security, logging and monitoring, configuration management, system hardening, identity and access management, data protection, incident response, backup and recovery, and access control.

Each control is a single markdown file. The file has two parts: a structured YAML frontmatter block and a human-readable rationale section. The frontmatter is the source of truth. It contains the control ID and title, severity rating, control type, framework mappings to NIST 800-53 and DISA SRG, a concrete check command, and a fix command that remediates the finding.

A sample check looks like this:

check:
  summary: "Confirm security (TLS) is enabled and the minimum protocol is TLS 1.2."
  command: |
    dsconf <instance> security get | grep -Ei 'security|tls-protocol-min'
  expected: "Security is enabled and the minimum TLS protocol is TLS1.2 or higher."
fix:
  summary: "Enable security and set the minimum TLS protocol version to 1.2."
  command: |
    dsconf <instance> security set --tls-protocol-min=TLS1.2
    dsconf <instance> security enable
    dsctl <instance> restart

The documentation site renders from this frontmatter automatically. Future phases will generate Bash audit scripts, Ansible roles, and OpenSCAP XCCDF content from the same source without re-authoring anything.

RHDS and Red Hat Identity Management

If you run Red Hat Directory Server or Red Hat Identity Management, this baseline applies to you too.

RHDS is the enterprise distribution of 389DS. The same codebase, the same dsconf tooling, the same configuration surface. The controls in this baseline map directly. Red Hat IDM goes a layer further, wrapping 389DS with FreeIPA, Kerberos, and Dogtag certificate services, but the directory server at its core is still 389DS and the hardening requirements for that layer are the same. If you are running IDM in a NIST 800-53 or SRG-adjacent environment, this baseline covers the directory component of that stack.

What It Is Not

This is not a certified STIG. It is not an official DISA SRG. The commands were written from 389DS and Red Hat documentation and the dsconf source, but they have not been validated against a live 389 Directory Server. No control has had an independent review. Every control carries an authored status, not reviewed.

We are being explicit about this because the alternative is shipping something that looks authoritative before it has earned that. Run every command in a non-production environment first. Confirm attribute names against your specific 389DS version. The alpha warning on the site is not boilerplate.

Testing and Getting Involved

Validation testing begins shortly. The path to a 1.0 runs through testing every command against a live server and getting each control independently reviewed. Neither of those is a one-person job.

If you run 389DS, RHDS, or Red Hat IDM in production, that experience is exactly what this project needs. Validating a control means running the check command against a real instance, confirming the expected output matches what you see, and reporting back. If you find a command that is wrong, a severity rating that does not match your environment, or a control that is missing entirely, that is a contribution worth making.

Issues and pull requests are open at github.com/Hexaxia-Labs/389ds-srg-baseline. The control schema and contribution guide are in the repo. If you want to get involved before you are ready to open a PR, open an issue and start a conversation.

Roadmap

The structure is built around a single source of truth by design. Everything that follows generates from the same control files:

Phase 2: Bash audit script (checks) and Ansible role (remediation) derived from the frontmatter
Phase 3: OpenSCAP XCCDF and OVAL content, scannable with oscap
Phase 4: Contribution to ComplianceAsCode/content, blocked on a license decision (GPL-3.0 today, ComplianceAsCode is BSD-3-Clause)

Get It

Docs: labs.hexaxia.tech/389ds-srg-baseline

Source: github.com/Hexaxia-Labs/389ds-srg-baseline

GPL-3.0. Contributions welcome via GitHub issues and pull requests.

Hexaxia Labs: What This Is and Why It Exists

Mon, 25 May 2026 00:00:00 GMT

Hexaxia is a group of companies. Hexaxia Technologies does managed IT, infrastructure, and security consulting. Hexaxia AI runs AI transformation engagements and builds AI infrastructure products. Hexaxia Media handles the creative and media side of the group.

Each division does different work. Some of it is client-specific. Some of it is not.

Labs is where the second kind lives.

When a division builds something general enough to be useful outside its own operation, it goes here. Not because we are trying to build a community or grow a following, but because keeping useful tools private when they solve a problem anyone could have is a waste. We work in real infrastructure and real production environments. Things get built. The ones worth sharing, we share.

HexOps

The first project was HexOps, a developer operations dashboard that came out of managing too many local projects at once. The specific problem: a CVE drops and you have 15 projects that need patching. The manual path is cd into each one, run the audit, update, commit, repeat, and hope you did not miss one. HexOps handles it from a single interface.

It scans every project for vulnerabilities and outdated packages concurrently, patches them in batch, and runs a post-patch audit to confirm the advisories are actually gone. It handles transitive dependency issues with automatic override detection, flags collateral downgrades across other projects when a patch lands, and gives you an escalation path when a patch cannot land cleanly: force-override, force-major bump, or accept-risk with an expiry date. There is also a code security scanner with 16 grep-based rules covering hardcoded secrets, command injection, weak crypto, and common misconfigurations.

v0.13.0, MIT license.

HexCMS and HexCMS Studio

HexCMS is a git-based headless CMS currently in development. Content lives in your repository as markdown files with frontmatter. No database, no vendor lock-in, no SaaS subscription.

HexCMS Studio is the visual editor that runs alongside it and is already released. It runs locally on your machine with direct filesystem access. You get WYSIWYG editing via TipTap and raw markdown mode, a frontmatter editor, live preview, git integration that lets you stage, commit, push, and pull without leaving the UI, and multi-repository support so you can manage content across several projects from one interface. Multiple themes: light, dark, midnight, and sepia.

HexCMS Studio is v0.2.0, MIT license. HexCMS is AGPL-3.0.

389DS SRG Baseline

389DS SRG Baseline came from Hexaxia Technologies' infrastructure work. 389 Directory Server is widely deployed in Linux environments and there is no good public hardening baseline for it. So we wrote one.

43 controls across 9 domains: network security, logging and monitoring, configuration management, system hardening, identity and access management, data protection, incident response, backup and recovery, and access control. Each control is a markdown file with structured YAML frontmatter containing a check command, a fix command, framework mappings to NIST 800-53 and DISA SRG, and an in-depth rationale. The frontmatter is the single source of truth: the documentation site renders from it today and future phases will generate Bash audit scripts, Ansible roles, and OpenSCAP XCCDF content from the same files without re-authoring.

It is v0.1.0-alpha. The commands have not been validated on a live server and no control has had an independent review. We are saying that plainly because the alternative is shipping something that looks authoritative and is not. GPL-3.0, contributions welcome.

More will come from across the group as work produces them. This blog is where we write about what we are building, the decisions behind it, and what did not go as expected. No release theater. Just the work.