FreeIPA for SaaS and technology companies

Why SaaS teams run FreeIPA for production Linux access

A SaaS engineering leader usually arrives at this problem from an audit request. The production fleet has grown to many hosts, SSH keys have been copied onto jump boxes and into automation over the years, a few shared accounts remain, and the SOC 2 auditor asks a simple question: who can reach production, under what approval, and how do you know the list is current. FreeIPA addresses that gap by centralizing Linux user identity, host-based access rules, sudo policy and host and service certificates on servers the company operates, so that access to a Linux host is decided by one directory rather than by whatever is in each machine's authorized_keys file. Before the design starts, the team should inventory where SSH keys and local accounts exist today, because that inventory defines the cutover work.

For platform teams, the change is mostly in where decisions get recorded. Users, groups and host groups live in the IdM directory, HBAC rules decide which groups may log in to which hosts, and sudo rules define privilege. Clients enrolled through SSSD resolve those identities and enforce the rules locally, which means an engineer who leaves the company can be disabled once instead of being hunted across the fleet. Certificates for internal services and hosts come from the built-in Dogtag certificate authority, which the team should plan to run on dedicated servers with a clear owner for renewal. Platform teams should confirm which replica will hold that CA role, since the backup documentation notes that the first server handles certificate renewal and CRL publication by default.

What stays with the existing web identity provider is the application sign-in layer. FreeIPA is built for Linux and UNIX access, so customer-facing and internal web applications are usually still fronted by a separate identity provider such as Keycloak, which can federate with FreeIPA through SSSD. The boundary matters for SOC 2 evidence: the web IdP records application sessions, while FreeIPA records who can become root on which host. Teams should write that split down in their access control description so that an auditor can trace each category of access to one system of record.

Requirements SaaS audits and engineering teams put on production access

This table maps the SOC 2 security criteria that govern production access (CC6 to CC9) to what each one means for a FreeIPA build. Read it as a design checklist: each row names the requirement, where it comes from, and the configuration decision it drives. DeployOpen prepares systems and evidence for the assessment, but the SOC 2 report itself is issued by an independent CPA firm.

Requirement	Source	What it means for the FreeIPA build
CC6 logical access: identify users, restrict access and manage credentials	2017 Trust Services Criteria, common criteria CC6	Every engineer and service account gets a named FreeIPA identity. Shared root logins on production hosts become exceptions that need a documented owner and review.
CC6 access granted on need: limit who can reach which hosts	2017 Trust Services Criteria, common criteria CC6	Use host-based access control (HBAC) rules scoped to host groups, such as production, staging and bastion, so each role reaches only the hosts it supports.
CC6 privileged access: restrict and log elevated actions	2017 Trust Services Criteria, common criteria CC6	Define sudo rules per role and record command logs on hosts. Confirm with your auditor which sudo events they expect to sample.
CC6 authentication strength for remote access	2017 Trust Services Criteria, common criteria CC6	Decide where multi-factor authentication applies (SSH, console, web consoles) and confirm which OTP or smart card methods your identity design supports before the build.
CC6 removal of access when people leave or change roles	2017 Trust Services Criteria, common criteria CC6	Tie offboarding to disabling the FreeIPA user and revoking Kerberos tickets and SSH keys. Test that a disabled account cannot log in to a sample of hosts.
CC7 system operations: detect and respond to anomalies	2017 Trust Services Criteria, common criteria CC7	Forward FreeIPA and host authentication logs to your central log platform. Confirm which login and directory events your monitoring must alert on.
CC8 change management: authorize and track changes to access	2017 Trust Services Criteria, common criteria CC8	Keep HBAC, sudo and group definitions in version-controlled Ansible content so every access change has a reviewer and a commit record.
CC9 risk mitigation: manage risk from vendors and dependencies	2017 Trust Services Criteria, common criteria CC9	Document FreeIPA as an open-source dependency with a named upgrade owner. Track security releases such as 4.13.4 and record when each cluster was patched.
Points of focus: design aids, not separate requirements	2017 Trust Services Criteria, points of focus (2022 revision)	Use these as prompts when writing controls. Not every point of focus must be addressed, so record which ones your design covers and why the rest do not apply.

Which FreeIPA modules and settings matter for SaaS fleets

A SaaS fleet needs the same identity decisions as any production estate, applied to short-lived access, many engineers and frequent deployments. The cards below cover the FreeIPA components that carry most of that load, and each one names the setting or check to confirm against your FreeIPA version before you commit to a design.

Host-based access and sudo for production roles

Use HBAC rules to decide which groups may log in to which hosts, and sudo rules to decide what they may run once they are there. Map production roles such as on-call, deployer and database operator to separate groups, so a rule change touches one role instead of every engineer. Check how your team names hostgroups and whether each production host belongs to exactly one environment group, because overlapping hostgroups are hard to audit later.

SSH keys and user lifecycle through SSSD

Clients read users, groups and SSH public keys from FreeIPA through SSSD, so offboarding is a directory change rather than a host-by-host cleanup. Confirm that your SSH configuration points at SSSD for key lookup and that revoking a user disables their login on every enrolled host. Test a departure end to end on a staging fleet, including sessions that are already open and any local accounts that were created outside FreeIPA.

OTP and RADIUS-proxied MFA for admin access

Require a second factor for administrative sessions, not for every login, so that routine deploys do not stall. FreeIPA supports HOTP and TOTP tokens, including hardware keys, and can proxy OTP checks to an existing RADIUS server if your identity provider already runs one. Decide which hosts and roles need the second factor, confirm how it applies to SSH and sudo in your version, and document the break-glass path for a lost token.

Service certificates from the Dogtag CA

Services such as internal APIs, message brokers and load balancers need certificates that renew without manual steps. FreeIPA issues them from an integrated Dogtag certificate authority, and certmonger on enrolled hosts can request and renew them. Decide which certificate profiles your services need, who may request certificates for which hostnames, and how you will monitor expiry. Confirm where the first server handles renewal and CRL publication in your topology, since that server becomes a dependency for every renewal.

Keycloak federation over SSSD for web SSO

Keycloak can sit in front of web applications and read users and groups from FreeIPA, so engineers sign in to dashboards with the same identity they use on Linux. Keep the identity source in FreeIPA and treat Keycloak as the broker, with role mapping set from FreeIPA groups. Confirm the LDAP and Kerberos configuration against the Keycloak release you run, and test that disabling a FreeIPA account also removes web access after the session token expires.

Ansible enrollment and policy as code

Enroll new instances and apply host access, sudo and certificate policy from version-controlled playbooks, so that a fleet built by autoscaling has the same rules as the rest. Store the enrollment credentials in a secrets manager, not in the playbook repository, and review how enrollment behaves when a host is rebuilt under the same name. Ask your team which parts of policy stay in code and which are changed by hand, because drift between the two is the usual source of audit findings.

How the design changes across cloud, Kubernetes and bare metal fleets

Cloud VM fleets change the enrollment model most, because instances are created and terminated by automation. Enrollment should happen during provisioning, through a golden image or cloud-init, so that every new instance joins without an engineer in the loop. Treat each cloud region where production runs as a site when you plan replicas, and place the IdM servers on dedicated instances that run nothing else, as the deployment recommendations advise.

Enrollment at provision time: Run the client install in the image build or first-boot script, and confirm which enrollment credential your team will use and how it is rotated.
Replica placement: Plan at least two or three replicas in each region you operate, and keep them on dedicated instances rather than shared application hosts.
DNS resolution: Give each client at least two DNS servers in its resolv.conf, and confirm that private DNS or resolver forwarding in your cloud network still answers the IPA domain's service records.
Replication limits: Keep no more than four replication agreements per replica, so add new regions with the topology in mind.
Host cleanup: Autoscaling leaves stale host entries behind, so add a deprovisioning step that removes the host from IdM.

Before you commit to a design, confirm with your cloud provider how security groups and private DNS handle the ports and name lookups FreeIPA depends on.

Rollout phases from pilot hosts to full production fleet

This sequence moves FreeIPA from an inventory of SSH and sudo access into a tested lab, a pilot group and a role-by-role production cutover, with evidence captured at each gate so that access decisions can be traced for SOC 2 review.

Inventory hosts, roles and current access paths
Your engineering lead and platform team list every production and non-production host, its role (bastion, application, database, build runner, Kubernetes node), its owning team, and how people reach it today. Include the SSH keys in authorized_keys files, sudoers entries, shared service accounts and deployment scripts that grant access. The step is done when each host has a named owner and an access path, and the team agrees which roles move first. Confirm the inventory against your configuration management and cloud asset records, not memory.
Build a lab with two replicas per datacenter
DeployOpen or your team builds a non-production FreeIPA topology with at least two replicas in each datacenter, following the vendor's deployment recommendations on dedicated servers and DNS. Each replica is installed on infrastructure you control, with DNS and client resolver settings tested. The step closes when replication is verified in both directions and a sample of lab clients can authenticate through SSSD.
Run and restore a tested ipa-backup
The team takes a full backup with ipa-backup in the lab, then restores it into a separate test environment and confirms users, groups, host entries, sudo rules and HBAC rules come back intact. Restore testing belongs in this phase because the backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so the runbook must state which server is restored and how replicas are rebuilt. Done when the restore is written up with timings observed, the restore owner is named, and the runbook is reviewed.
Enroll pilot non-production hosts
Engineers enroll a small set of non-production hosts across the roles inventoried earlier, including at least one bastion and one application host, and move their SSH logins to FreeIPA identities. Confirm that SSSD caches, host keys and home directories behave as expected after a reboot. The pilot is complete when the team has logged in and out of each pilot role, removed the local accounts it replaces in the pilot scope, and recorded any issues in a single tracker.
Migrate HBAC and sudo rules from keys and scripts
Using the inventory, the platform team rewrites access from authorized_keys files and scripts into HBAC rules that say who may log in to which hosts, and sudo rules that say what they may run. Sudo and HBAC rules need manual migration through LDIF or direct configuration, so each rule is reviewed against the owning team's need, not copied verbatim. The step is done when every pilot host has rules with a named business owner, and a reviewer confirms that no shared key or unowned script still grants production access.
Integrate Keycloak and Ansible
Platform engineers connect Keycloak for web single sign-on to internal tools, and set up Ansible roles so that enrollment, HBAC and sudo rules are applied from version-controlled code rather than hand edits. Changes go through the same review path as other infrastructure code. The step closes when a test change made in Git reaches a pilot host through Ansible, a web login via Keycloak succeeds, and the team can show who approved each change.
Cut over production hosts by role
Production hosts move in role groups, starting with the lowest-risk roles and ending with bastions and database hosts, each with a rollback plan and a named change owner. Before each group, the team confirms the restored backup procedure still works and that at least two replicas serve the datacenter. The cutover for a role is complete when its hosts authenticate through FreeIPA, shared keys are removed, and the on-call team confirms the access path in writing.
Capture access evidence for SOC 2 review
The compliance lead and platform team collect dated exports of user and group membership, HBAC and sudo rules, change records from Git and Ansible runs, and the restore test report. These records are mapped to the access and change management criteria your auditor will test, with management owning the description of the system. Ask your SOC 2 auditor which evidence samples they expect, because the auditor, not DeployOpen, decides what is sufficient. The step is done when the evidence set is stored, indexed and reviewed for the period under examination.

What SOC 2 access evidence looks like when FreeIPA is the source

A SOC 2 examiner does not take a access control claim on trust. They sample records that show who had access, when it changed and who approved it. FreeIPA can produce much of that record, but only if the evidence is collected continuously and matched to the controls your own system description commits to.

User provisioning and deprovisioning records

Auditors sample joiners and leavers and trace each one back to a request, an approval and a directory change. In FreeIPA, the user object, its creation and disablement events, and the group memberships at each point are the core trail. Check that leavers are disabled in the directory across every replica and that the ticket or HR event that triggered the change is recorded alongside it. Confirm that deprovisioning covers SSH keys and Kerberos principals, not only the web login.

Group and sudo rule change history

Privileged access on production fleets usually flows through group membership and sudo rules. Auditors ask who changed a sudo rule, when, and whether the change was reviewed. Keep rule definitions in version control, apply changes through your automation pipeline, and retain the directory audit output so that each live rule can be matched to an approved change. An unexplained edit made directly in the web UI is a common finding to avoid.

HBAC rule definitions with owners

Host-based access control rules decide which users can log in to which hosts. An examiner will want the current rule set, the business reason for each rule and a named owner who reviews it. Export the rules with their hosts and host groups, and record the owner as a group or attribute you maintain. Rules that allow all users to all hosts, or that point at retired host groups, deserve a documented exception or removal.

MFA enrollment for privileged roles

For administrators who reach production, the evidence is which accounts have a second factor enrolled and when it was enrolled. FreeIPA stores OTP tokens against user accounts, so an export of token assignments for the privileged group shows coverage. Compare that list against the roster of people with sudo or administrative rights. Any gap needs a compensating control that you can describe in your system description.

Certificate issuance records

Host and service certificates issued by the integrated certificate authority are evidence of how machines and services are identified. Keep the issuance and revocation log, the profile used for each certificate and the requesting host or service. Confirm which server performs renewal and CRL publication, since the backup documentation notes that this role sits with the first server by default. If you run certificates for customer-facing endpoints, export the list and check it against your inventory.

Access review exports

Periodic access reviews are where the other evidence is brought together. Produce a dated export of users, groups, sudo and HBAC rules, and privileged memberships, then record who reviewed it, what they removed and when the removals took effect. Because a Type 2 report tests operation over a period, reviews must recur on a schedule the examiner can see in the log, not only before the audit.

Which SOC 2 scope and report type shape the FreeIPA work

The scope of your SOC 2 examination decides how much of the FreeIPA estate an auditor will test. Every SOC 2 is built on the AICPA 2017 Trust Services Criteria, and the security category is covered by the common criteria CC1 to CC9, which apply to every SOC 2 regardless of what else is in scope. The other four categories (availability, processing integrity, confidentiality and privacy) add criteria only when you include them. For a SaaS team, the logical access criteria in CC6 are where FreeIPA does most of its work: who can reach production hosts over SSH, which accounts sudo elevates, how host-based access rules are defined and reviewed, and how joiners and leavers are removed from the directory. Confirm with your auditor early whether confidentiality or availability belong in scope, because each addition changes the evidence you must produce from FreeIPA and from the systems around it.

The report type is the second decision. A SOC 2 report is generally restricted in use, so it goes to customers and prospects under nondisclosure, while a SOC 3 report is a general use document that can be freely distributed but describes the same categories in less detail. Choose Type 1 or Type 2 with the same care. A Type 1 covers the system description and the design of controls as of one date, while a Type 2 adds an opinion on operating effectiveness across a period, which means your FreeIPA access reviews, group membership changes and sudo rule changes must have happened consistently over that window. The system description is prepared against the AICPA 2018 description criteria (DC 200), so the FreeIPA topology, enrolled host groups and authentication flows should be documented in a form that matches what the auditor will read. Engagements are assertion-based under AT-C section 205, which requires written representations from management, so the people who sign those statements should know what FreeIPA actually does.

If you have EU customers or operate in the EU, two regimes add obligations. NIS2 covers certain cloud, managed service and digital infrastructure providers, and the Commission's implementing regulation (EU) 2024/2690 sets technical requirements for some of them, so confirm whether your service falls within those sectors. The Cyber Resilience Act applies to products with digital elements, including software, and its reporting obligations already apply to in-scope products, so software vendors should classify their products early. Separately, GDPR Article 28(3) requires processor contracts to limit processing to documented instructions and to require Article 32 security measures, which means the FreeIPA access controls you describe to customers must match the contract. Ask counsel and your auditor to confirm which of these apply to your company before the scope is fixed.

What SaaS teams ask before hiring a partner for FreeIPA

What drives the cost of a FreeIPA rollout for a production fleet of a given size?

Fleet size matters less than how many distinct server types, environments and access models the rollout has to cover. The main cost drivers are the number of IPA servers and replica sites, how many Linux distributions and images need client enrollment, how much existing identity data must be migrated from LDAP or older directories, and how many sudo and host-based access rules have to be designed from scratch. Recurring costs come from patching, upgrades and support, which scale with how often your fleet changes. Ask any partner for a written scope that lists each of these items separately, states what is one-time and what is recurring, and names who performs the enrollment and automation work.

How long does a FreeIPA rollout take and what sets the schedule?

Duration depends on the number of hosts still to be enrolled, the state of your existing directory and access rules, and how many change windows your production systems allow. Teams often lose the most time to discovery, such as finding service accounts, shared logins and sudo rules that nobody documented. Pilot enrollment on a small group of non-production hosts, then staged rollout by environment, usually takes longer than the server build itself. Ask the partner to show the phases, the entry and exit criteria for each, and which dependencies sit with your team, such as DNS changes or approvals for production windows.

Can an in-house platform team deploy FreeIPA without a partner?

Yes, FreeIPA is a community project under GPL-3.0-or-later, so any team can install it. The questions to answer honestly are whether the team has run Kerberos, LDAP, certificate authorities and DNS in production, and whether it can staff on-call for an identity service that every SSH login depends on. The deployment recommendations call for at least two to three replicas in each datacenter, dedicated servers and at least two DNS servers in each client's resolv.conf, so the team also needs capacity for that topology. A partner is most useful for the parts your team has not done before, such as the first multi-site design, a bulk enrollment plan and a tested restore procedure.

What does DeployOpen need from our side before a FreeIPA engagement starts?

Most of the work depends on information that only your team holds. Expect to provide a host inventory with operating systems, roles and owners, a list of who needs access to which hosts and why, the current sudo and SSH access model, and the change windows your production environments allow. You also need named owners for the identity system, DNS, certificates and the on-call rotation, and a decision on whether the cloud accounts or data centers hosting the servers are yours to configure. Request a written scope that lists these inputs, the people who must approve each one, and the date each is needed.

How is SOC 2 access evidence handled, and what does DeployOpen not provide?

SOC 2 is assessed against the AICPA 2017 Trust Services Criteria, and its security common criteria CC1 to CC9 apply to every SOC 2 report. FreeIPA can support evidence for logical access controls, such as who can log in to which host, how privileges are granted through sudo and host-based access rules, and how accounts are removed. DeployOpen prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Only an independent CPA firm can perform a SOC 2 examination, and your auditor decides which evidence it accepts. Confirm the evidence list with your auditor before the build starts.

How does FreeIPA connect to an existing Keycloak or Okta-style identity provider?

FreeIPA handles Linux identity, Kerberos, SSH and sudo, while a web identity provider handles browser single sign-on for SaaS applications. The usual pattern is to keep FreeIPA as the source of users and groups for Linux and have the web provider federate with it, for example through Keycloak using SSSD on the connected hosts. Some teams instead use an external OAuth 2.0 identity provider for Kerberos sign-in. Decide early which system is the source of truth for each user attribute and group, how deprovisioning flows between them, and which MFA method applies to each path. Confirm the exact integration steps against your Keycloak or Okta version during scoping.

What happens to access if the FreeIPA servers are down?

Existing sessions and cached credentials determine what keeps working. SSSD on enrolled clients can cache credentials and support offline login for users who have already signed in, but new logins, new users and changed sudo rules depend on reaching an IPA server. This is why the deployment recommendations call for several replicas in each datacenter and at least two DNS servers per client. Ask the partner to document which logins survive an outage on your hosts, how break-glass administrative access is kept outside the identity system, and how a restore from ipa-backup is tested. Restoring an outdated backup into an active replica topology can break replication, so the restore runbook needs to be verified before you need it.

How DeployOpen scopes and supports FreeIPA for SaaS fleets

DeployOpen plans, builds, hardens, documents and supports FreeIPA inside your own cloud accounts or data centers, so the identity service for your production fleet stays under your control. Engagements start with a written scope that names the hosts, access paths and evidence your team needs before any work begins.

How we scope

Inventory production Linux hosts, SSH entry points, sudo use and the teams who need access to each fleet.
Agree in writing which SSH, sudo, host access and Keycloak federation paths are in scope, and which are not.
Define the SOC 2 access evidence the written scope must produce, such as account lists, approvals and access reviews.

How we build

Design replica placement across your environments, with the replica count and DNS layout set against your recommended topology.
Enroll hosts with SSSD, then configure HBAC and sudo rules that map to your roles and on-call model.
Wire Ansible roles and Keycloak federation into your existing change process, with tests run before each rollout.

How we hand over

Deliver runbooks for enrollment, access grants, revocation, backups and restores, and certificate renewal.
Document how access changes are logged and which reports your auditors can request for the review period.
Walk your platform and security engineers through operations, and record open items with owners and dates.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, scoped in writing like the original build.
Plan FreeIPA version upgrades and security releases in your change calendar, with a rollback path agreed up front.
Review access evidence and configuration drift on a schedule agreed with your compliance lead.