FreeIPA for CIS Controls account and access management

How FreeIPA helps with CIS Controls account and access management

If you run an IG2 or IG3 enterprise, you need to show that accounts are managed from one central place (Safeguard 5.6) and that access control to your enterprise assets is run centrally from a directory or single sign-on provider (Safeguard 6.7), where the asset supports it. FreeIPA can serve as that central directory for Linux and UNIX estates, combining 389 Directory Server for users, groups, hosts and policies with an MIT Kerberos KDC for single sign-on. Safeguard 6.5, which requires multi-factor authentication for every account with administrative access, applies from IG1, so it matters even for smaller organizations. FreeIPA supports HOTP and TOTP tokens, including hardware tokens, for that purpose, but only on assets that can authenticate against it. Confirm with your own asset inventory which Linux systems, appliances and service-provider-managed assets can actually join FreeIPA, because the CIS wording limits each safeguard to assets that support it.

Before you build anything, confirm two prerequisites. The CIS Controls Assessment Specification lists the enterprise asset inventory (Safeguard 1.1) and the software inventory (Safeguard 2.1) as inputs for measuring both 5.6 and 6.7, so your FreeIPA host records and access rules should trace back to those inventories. Plan the DNS naming for the IPA domain early, because clients and the Kerberos realm depend on it. DeployOpen plans, configures and documents the FreeIPA side, and prepares the evidence an assessor will ask for, such as account lifecycle records and access rule exports. DeployOpen does not issue audit reports or certifications. Independent assessors make that judgment, so ask them early which evidence format they accept.

Treat the CIS Controls as a measurement framework rather than a checklist to pass. The Assessment Specification describes what to measure, not how, so the way you show central management is your design decision. Agree with your assessor which report proves 5.6 (for example, a complete account list reconciled against HR or the asset inventory), which proves 6.7 (for example, host-based access rules applied through FreeIPA), and which proves 6.5 (for example, OTP enrollment for every administrator). Ask whether they need evidence from the current FreeIPA release line, and check the CIS Controls Navigator if you need to map the same controls to another framework you already report against.

Which FreeIPA capabilities map to Safeguards 5.6, 6.7 and 6.5

This table pairs each CIS Controls v8.1 safeguard in scope with the FreeIPA capability that addresses it and the configuration the deployment needs. Read each row as a starting point for the evidence your assessor will ask for, and confirm support for each asset in your environment, because the requirement applies only where the asset supports the control. The main takeaway is that FreeIPA covers the central directory and MFA parts well for Linux estates, while non-Linux and vendor-managed assets need separate confirmation.

Safeguard and classification	FreeIPA capability	Configuration needed
5.6 Centralize account management (Users asset class, Govern function, IG2 and IG3, not IG1)	Identity directory: 389 Directory Server stores users, groups, hosts and policies in one multi-master directory	Create all Linux and service accounts in IPA, enroll hosts with SSSD, disable local accounts that duplicate central identities, and set a documented provisioning and removal process
6.7 Centralize access control (Users asset class, Protect function, IG2 and IG3, not IG1)	Host-based access control (HBAC) and sudo rules applied from the central directory	Define HBAC rules per host group, map privileged access to sudo rules, remove default allow-all rules, and export rule lists as evidence
6.5 MFA for administrative access (Users asset class, Protect function, all IGs including IG1)	OTP tokens (HOTP and TOTP, including YubiKey hardware tokens) and RADIUS proxying to an existing server	Enroll OTP tokens for every administrative account, enforce OTP on the relevant authentication path, and confirm which admin paths (console, SSH, web UI, vendor-managed systems) actually prompt for a second factor
Prerequisite for 5.6 and 6.7: Safeguards 1.1 (asset inventory) and 2.1 (software inventory)	Host enrollment and group records give a starting list of enrolled systems for comparison	Reconcile the IPA host list against your asset inventory and flag any Linux system that authenticates outside IPA
Evidence for 5.6 and 6.7	Exportable user, group, host and HBAC/sudo rule listings from the IPA command line and web UI	Schedule dated exports, keep change history for rules, and record who approved each change
Where support is limited	Non-Linux assets, appliances and vendor-managed services may not authenticate against IPA	Record each asset as supported, partly supported or excluded, with the reason, since CIS applies each safeguard only where the asset supports it

How each safeguard is built in FreeIPA

Safeguard 5.6 asks for accounts to be managed from one central place. In FreeIPA, that place is the identity store built on 389 Directory Server, a multi-master LDAPv3 directory that holds users, groups, hosts and policies. Every Linux client enrolled through SSSD resolves accounts from this directory, so one record drives login, group membership and host access across the estate. The design work is deciding who is allowed to create, change and disable those records, and how your joiner, mover and leaver steps feed them.

Single directory of record: Users and groups live in IPA rather than in local /etc/passwd files on each host, so a disable action in one place takes effect everywhere the host is enrolled.
Account lifecycle settings: Decide account expiry, inactivity handling and the groups that grant baseline access before the first user is loaded.
Staged or preserved accounts: Choose whether new accounts are created as staged and activated by an administrator, which gives you a review step in the provisioning flow.
Replica topology: Plan replicas per site so that account changes replicate to every server that authenticates clients.
Client-side process: Your HR or ticketing process must still trigger the create, change and disable actions, and your team must review group membership and remove accounts that no longer have an owner.

Before you rely on this tab, confirm with your own environment that every host and service account is either in IPA or documented as an exception.

Safeguard 6.7 asks for access control to every enterprise asset to be run centrally from a directory or SSO provider, where the asset supports it. In FreeIPA, central access control uses host-based access control (HBAC) rules to decide which users may log in to which hosts and services, and sudo rules to decide which privileged commands they may run. Kerberos provides single sign-on for supported services, so the same identity and policy apply across the estate instead of being copied to each machine.

HBAC rules by host group: Group hosts by function, such as database, web or bastion, and attach HBAC rules to those groups rather than to individual machines.
Sudo rules as central policy: Define privileged commands once in IPA and scope them to user and host groups, instead of editing /etc/sudoers on each system.
Default deny decisions: Confirm how your team treats hosts with no matching HBAC rule, and test that outcome before go-live.
Assets FreeIPA cannot cover: Network devices, appliances and some cloud consoles may not support Kerberos or LDAP, so record them as exceptions and show how their access is controlled.
Client-side process: Your team must still approve who receives each role or group, review rules on a schedule, and retire rules tied to decommissioned hosts.

Check which assets in your inventory support central authentication, since the safeguard applies only where they do.

Configuring FreeIPA to meet the account and access safeguards

This sequence takes a FreeIPA deployment from measurement groundwork to a running identity service where accounts are central, host access is policy-driven, administrators must use a second factor and the evidence is retained. Each step ends with a check you can record for an assessor.

Confirm asset and software inventories first
Before building anything, the team confirms that the enterprise asset inventory (Safeguard 1.1) and the software inventory (Safeguard 2.1) exist and are current. The CIS Controls Assessment Specification lists both as prerequisites for measuring Safeguards 5.6 and 6.7, because they supply the data the measurement needs. Owners of the Linux hosts, service accounts and applications that will authenticate against FreeIPA should be named here. Done means you can produce a list of every host and application that will be enrolled, with an owner for each.
Deploy FreeIPA replicas per the recommendations
The platform team installs FreeIPA servers on dedicated machines, following the FreeIPA deployment recommendations. Those recommendations advise at least two to three replicas in each datacenter, no more than four replication agreements per replica, and at least two DNS servers in each client's resolv.conf. Where certificate or DNS services are used, at least one replica per datacenter should run them. Done means replication is healthy between all replicas and a test user can authenticate against each site.
Enroll Linux hosts as IPA clients
The systems team enrolls each Linux host in the inventory as an IPA client with SSSD, so that identities, groups and policies come from the central directory rather than local files. Enrollment should be scripted or otherwise repeatable so the same process runs for every host. Done means each enrolled host appears in the host list, resolves users from the directory and no longer relies on locally created accounts for ordinary users.
Define host-based access and sudo rules
The security and platform teams write HBAC rules that state which groups may log in to which hosts, and sudo rules that state which privileges those groups receive. Access should follow job roles, and rules should be grouped by host class so reviewers can read them. Confirm that no broad allow-all rule remains from the default configuration. Done means each host has an approved list of permitted groups and privileges, and a test non-member is denied login.
Require OTP for administrator accounts
The identity team enables OTP tokens (HOTP or TOTP, per the FreeIPA OTP design) for every account with administrative rights and enforces the second factor for their logins. If an existing RADIUS server holds the second factor for other systems, FreeIPA can proxy the OTP check to it. Confirm with your own environment which applications and administrative paths still accept a password alone, since those paths must be closed or documented. Done means each administrator's test login requires a valid token and the exceptions list is empty or formally approved.
Back up the configuration with ipa-backup
The operations team schedules ipa-backup, using full backups or online data-only backups as the environment requires, and stores copies outside the FreeIPA hosts. The backup documentation warns that the first server handles certificate renewal and CRL publication by default, and that restoring an outdated backup into an active replica topology can break replication, so restore procedures must be written and rehearsed in a separate environment. Done means a backup has been taken, stored off-host and documented with its restore steps.
Schedule recurring access reviews and retain evidence
The control owner sets a recurring review of group memberships, HBAC and sudo rules, administrator accounts and OTP enrollments, and records who approved each change. Exports of the directory state, rule lists and login records are kept as the evidence an assessor will request. The review cadence should be set by your own policy, since no timing is prescribed here. Done means the first review is signed off, its outputs are stored with the inventories from step one, and the next review date is on a calendar.

What evidence FreeIPA produces for CIS Controls reviews

A CIS Controls review asks whether accounts, access and administrative logins are managed from one place and whether you can show it. The cards below list the records a FreeIPA deployment can produce, how to keep them, and what an assessor usually asks for.

User and group exports

Account and group listings from FreeIPA are the core evidence for Safeguard 5.6, because they show that accounts come from one central directory. Keep dated exports of users, groups and their status at each review point, and confirm the export method with your deployment team before you rely on it. Assessors typically sample accounts and ask who approved each one, whether it maps to a named person, and whether disabled or departed users still appear in active groups. Check that every sampled account traces back to an HR or onboarding request.

HBAC and sudo rule configuration

Host-based access control and sudo rules show how central access control is applied to each Linux system, which is the focus of Safeguard 6.7. Keep an exported copy of the rule set with the date and the owner of each rule, and record which hosts and host groups each rule covers. Assessors usually ask whether access to every enterprise asset is governed centrally, whether any system is missing from the rules, and who can change them. Compare the rule set against the asset inventory at each review.

OTP token assignment records

Records of which accounts hold OTP tokens and which tokens are assigned to them support Safeguard 6.5 for administrative access. FreeIPA supports HOTP and TOTP tokens, including software tokens and hardware tokens, so keep a register of token type, owner and assignment date. Assessors commonly check that every administrative account has a second factor, that shared or unassigned tokens do not exist, and that lost tokens were removed promptly. Confirm with your team which administrative accounts are enforced for OTP and which are not.

Enrollment inventory cross-checked to assets

A list of Linux machines enrolled as FreeIPA clients shows which systems run under central identity. Compare it with your enterprise asset inventory, which Safeguard 1.1 requires, and record any asset that is not enrolled along with the reason. Assessors typically ask whether every in-scope server appears in the enrollment list, whether unknown hosts have joined the domain, and how stale host entries are removed. Keep the comparison dated so the gap list shows how it changed over time.

Backup and restore records

Backup and restore records show that the central directory can be recovered, which keeps account and access data available if a server fails. Keep logs of each backup, its type and its storage location, along with records of any test restores. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so record which server was restored and why. Assessors usually ask how often backups run, where they are stored, and when a restore was last tested.

Change history for accounts and policies

A change history of account, group, rule and policy edits shows who changed central access and when. Keep the audit trail from your FreeIPA servers together with the approval record for each change, and review it on a fixed schedule. Assessors often pick a privileged change and ask for the request, the approver and the matching log entry. Confirm with your deployment team where FreeIPA logs these changes and how long they are retained in your environment.

Why replica layout and backups are part of the access evidence

Central account management only holds up if the directory answers when a user signs in, and if it can be restored without splitting its own data. For Safeguard 5.6 and 6.7, the directory is the single place where accounts and access rules live, so an outage or a bad restore affects every Linux host that depends on it. FreeIPA's deployment recommendations advise at least two to three replicas in each datacenter, with no more than four replication agreements per replica. Decide that layout before the first client enrolls, and record it as part of the access design. Confirm with your own team how many replicas each site will run, where they sit relative to your DNS servers, and whether each client's resolv.conf lists at least two DNS servers.

The first server in the topology has a special role. By default it handles certificate renewal and CRL publication for the internal certificate authority. If that server is down for a long period, certificate and revocation duties need a plan, and your evidence should name which server holds those roles. Ask your operations team to identify the first server, document the roles it carries, and confirm how revocation status will still be published while it is offline. Certificates that authenticate administrators are part of the access record, so this detail matters for Safeguard 6.5 as well.

Backups are where access evidence can break. FreeIPA provides ipa-backup and ipa-restore, with full backups or online data-only backups. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Treat restore as a controlled procedure: keep a dated backup schedule, store backups away from the servers they protect, test restores on an isolated copy, and record which backup restores which topology. A restore that brings back accounts disabled since the backup can silently re-enable access that the organization already removed.

What FreeIPA does not cover for these safeguards

FreeIPA can centralize accounts, access control and MFA for the systems it actually gates. The cards below cover the places where Safeguards 5.6, 6.7 and 6.5 still need work from other tools, other owners or documented decisions. CIS states that the Controls do not replace any regulatory, compliance or authorization scheme, so the mapping is an input to your assessment, not a substitute for it.

Non-Linux and SaaS assets

FreeIPA manages identities for Linux and UNIX hosts that run SSSD and for services that accept Kerberos or LDAP. Windows endpoints, network devices, most SaaS applications and many appliances sit outside that boundary unless they are joined to an Active Directory trust or federated through another identity provider. Build a list of every enterprise asset and state, for each one, whether FreeIPA authenticates it, federates it, or leaves it in a local or vendor account store. Those local accounts remain in scope for Safeguard 5.6 until they are removed or documented as exceptions.

Applications without Kerberos or LDAP login

Some internal applications only support local password tables, vendor-specific directories or static API keys. FreeIPA cannot centralize sign-in for those without an intermediary, such as a federation gateway or a proxy that enforces authentication in front of the application. For each one, record the login method, who owns its accounts, and whether the application can disable local accounts after go-live. Without that record, Safeguard 6.7 cannot be shown as met for the asset, even when the Linux estate is clean.

Enterprise asset and software inventories

Safeguards 1.1 (enterprise asset inventory) and 2.1 (software inventory) are prerequisites for measuring Safeguards 5.6 and 6.7, because the assessment needs a complete population to test against. FreeIPA's host list is not an inventory of everything that holds accounts. Reconcile FreeIPA hosts and users against your asset management and configuration records, and confirm which systems exist outside the directory. Ask whether your inventory tool can export the data an assessor will sample.

Access review and approval processes

FreeIPA records group membership, host access rules and sudo rules, but it does not decide whether those grants are still justified. Quarterly or event-driven reviews, manager approval of new privileges, and removal after a role change are workflow decisions owned by your identity governance process. Define the review owner, the evidence they sign, and the trigger for removing access. Confirm whether your governance tooling can read FreeIPA group data directly or whether reviews will rely on exported reports.

Admin MFA on assets FreeIPA cannot gate

Safeguard 6.5 requires MFA for administrative accounts on every enterprise asset where the asset supports it, including assets a service provider manages. FreeIPA can enforce OTP or certificate-based MFA for logins that pass through its Kerberos and SSSD stack. Vendor consoles, cloud control planes, hypervisor management interfaces and network device logins often use separate authentication paths. Map each administrative path, confirm whether it can be fronted by an MFA-capable identity provider, and document the assets where it cannot.

The CIS mapping itself

CIS publishes the Controls and maps them to other frameworks, but a mapping on paper does not produce evidence. The Assessment Specification defines what to measure for each Safeguard, and CIS says it covers what to measure, not how. Decide which measurements your team will run, how often, and where the output is stored. Confirm with your assessor which reports and screenshots they accept before you design the evidence pack.

Questions buyers ask about FreeIPA and CIS Controls

Does CIS certify that FreeIPA or our environment meets CIS Controls?

No. CIS does not certify environments against the CIS Controls, and DeployOpen does not issue audit reports, attestations or certifications. The CIS Controls state that they do not replace any regulatory, compliance or authorization scheme. What DeployOpen can do is configure FreeIPA for Safeguards 5.6, 6.7 and 6.5, document how each one is met, and prepare the reports and evidence your own assessor or internal audit team will review. Ask any partner who claims otherwise to show who issued the assessment and under what scope. CIS Controls Accreditation exists for organizations that provide CIS Controls services, which is a different thing from certifying your estate.

What drives the cost and effort of a FreeIPA CIS Controls project?

The main drivers are the size of the estate and how many Linux assets must enroll, the replica design across your sites, the OTP rollout for administrative accounts, the integrations you need (for example Keycloak, Samba file servers or Active Directory trusts), and how much evidence you need to produce. Each driver adds design, configuration and testing work, and some of it recurs, such as token enrollment support and periodic access reviews. Ask for a quote that separates one-time build work from ongoing operations, and that lists which assets, sites and integrations are in scope. The quote should also state which Safeguard 1.1 and 2.1 inventories you will provide, because CIS treats those as inputs for measuring 5.6 and 6.7.

How long does a FreeIPA deployment for CIS Controls take?

Duration depends on the same drivers as cost, plus how quickly your teams can approve the design, supply change windows and test with real user populations. No duration is set here, so ask for a timeline in the written scope rather than relying on a generic estimate. Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. To keep the schedule realistic, prepare an accurate list of Linux hosts, current account sources, administrative users, existing sudo and access rules, and the sites that will host replicas. Confirm your change calendar early, because replica placement and OTP enrollment both touch production access.

What must our team provide before a FreeIPA engagement starts?

Your team typically provides access to the target cloud accounts, data centers or air-gapped networks, a list of Linux and UNIX systems, the current directory or LDAP sources and their account populations, DNS and NTP details, and named approvers for access and change decisions. You also need to confirm which administrative accounts will use MFA, which OTP tokens or hardware keys your users will receive, and who owns the policies for password quality and lockout. Early decisions on these items reduce rework during design. Ask the partner to list every input in the scope document so that missing items become visible before the build starts.

Can our own team implement FreeIPA for CIS Controls without a partner?

Yes, an internal team can do this, provided it has people who understand Linux identity, Kerberos, DNS, certificates and the CIS Controls Assessment Specification. The work spans server installation, replica topology, client enrollment with SSSD, OTP configuration, access policy design and the evidence set. FreeIPA is GPL-3.0-or-later and is a community project with no paid edition of its own, so the software cost is not the deciding factor. The deciding factors are staff time, operational ownership after go-live and the ability to maintain security releases, such as the 4.13.4 release that fixed two CVEs. Many organizations split the work, keeping ownership in-house and buying design review or specific build phases.

What should a fixed-scope quote for this work include?

A fixed-scope quote should name the in-scope Safeguards (5.6, 6.7 and 6.5), the Linux and UNIX asset list, the number of FreeIPA servers and replicas per site, the client enrollment method, the MFA scope for administrative accounts, each integration, and the evidence pack you will receive. It should list deliverables such as design documents, configuration records, test results, backup and restore verification, and operating runbooks. It should also state assumptions, client responsibilities, change control and what happens if scope changes. DeployOpen does not publish a price list, so the quote follows from the written scope. Ask for the exclusions in writing, including any assessment the quote does not cover.

Which CIS Controls safeguards does FreeIPA cover, and which need other tools?

FreeIPA covers the central parts of Safeguard 5.6 (one directory for accounts), Safeguard 6.7 (central access control through a directory and SSO) and Safeguard 6.5 (MFA for administrative accounts) when OTP tokens, hardware keys or proxied RADIUS checks are deployed for those accounts. Safeguard 6.5 applies to any asset that supports MFA, including assets a service provider manages, so check each system's support before you claim coverage. Inventory data from Safeguards 1.1 and 2.1 is needed to measure the results. Where a platform cannot join FreeIPA or cannot accept central authentication, the report should show that gap and the compensating control, rather than hiding it. Confirm the position of each asset class with your own assessor.

Where CIS Controls v8.1 sits for IG1, IG2 and IG3 buyers

The three safeguards this page covers do not sit at the same level of the CIS Controls. Safeguard 6.5, multi-factor authentication for administrative access, is part of IG1, the essential cyber hygiene baseline that CIS describes as the minimum for every enterprise. Safeguards 5.6 (centralized account management) and 6.7 (centralized access control) start at IG2 and are not part of IG1. In CIS Controls v8.1, each safeguard carries one asset class, one security function and its Implementation Groups. All three sit in the Users asset class. 5.6 is in the Govern function, while 6.5 and 6.7 are in the Protect function. Check your assigned Implementation Group before you scope the work, because it determines whether centralized account management is a requirement for you or a recommended next step.

The Controls contain 153 safeguards in total. IG1 has 56, IG2 adds 74 for a total of 130, and IG3 adds the remaining 23, according to the CIS Implementation Groups pages. For a FreeIPA project, that means IG1 buyers can treat the administrative MFA work as a baseline item, while IG2 and IG3 buyers should also document how every account and access decision flows from one directory. CIS describes IG2 as suited to enterprises with more operational complexity that often hold sensitive information, and IG3 as suited to regulated, sensitive environments facing targeted attacks. Ask your assessor or internal audit team which Implementation Group they will test against, since that choice changes the evidence list.

CIS also publishes the CIS Controls Navigator for v8.1, which maps the Controls to 30 other frameworks and versions, including NIST CSF 2.0, ISO/IEC 27001:2022 and SOC 2. Use it to find where the same FreeIPA evidence serves more than one obligation, but confirm each mapping against the current Navigator entry before you cite it. CIS content is licensed under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0. Under that license, you can use the Controls to improve your own security, but you should not modify them or use them commercially without CIS's prior approval. In practice, quote safeguard IDs and titles, describe your own controls in your own words, and link to the CIS Controls Navigator rather than reproducing its tables in client deliverables.

How DeployOpen scopes and delivers CIS-aligned FreeIPA configuration

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including FreeIPA. For CIS Controls account and access management, we treat Safeguards 5.6, 6.7 and 6.5 as configuration and evidence questions that are agreed in writing before any work starts.

How we scope

Engagements are fixed-scope, with the FreeIPA topology, enrolled systems and Safeguards named in writing before work starts.
We confirm which Safeguards and Implementation Groups apply to your enterprise, and which assets your asset and software inventories already cover.
The written scope lists the reports, configuration exports and evidence samples you will receive, so the measurement questions are settled up front.

How we build

We deploy FreeIPA servers and replicas in your cloud accounts, data centers or air-gapped networks, with the platform choices agreed in the scope.
We configure user and group lifecycle, host and service enrollment, host-based access control and sudo rules as a single central account and access model.
We set up OTP enrollment for administrative accounts and test each MFA path, including how any RADIUS proxy or external identity source behaves.

How we hand over

We document the configuration, the administrative runbooks and the recurring checks your team needs to repeat after handover.
We deliver the evidence pack described in the scope, mapping exported reports to each in-scope Safeguard so your assessor can trace them.
We walk your engineers through backups, restore steps and the replication cautions that apply to your topology before we close the engagement.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the original build.
Retainers can cover FreeIPA version upgrades, security releases and periodic re-checks of the access and MFA configuration against the agreed scope.
Your organization keeps ownership of the controls and the conclusions. CIS and independent assessors determine whether the Safeguards are met, and DeployOpen prepares the systems and evidence.