Why FreeIPA for the public sector starts with where identity must live
A public body that runs Linux servers and needs central identity, Kerberos single sign-on and certificates has a basic constraint: the identity data about its staff and systems should stay under its own control. FreeIPA for the public sector fits that constraint because the whole stack runs on servers the agency operates. The 389 Directory Server holds users, groups, hosts and policies as a multi-master LDAPv3 directory, the MIT Kerberos KDC issues tickets for single sign-on, and the integrated Dogtag certificate authority issues host and service certificates. None of these components needs a shared cloud identity service to function, which is why the design suits agencies that must keep identity records in their own data centers.
On-premises operation changes the work your team owns. You decide where replicas sit, usually two or three per data center according to the FreeIPA deployment recommendations, and you must keep at least one replica running PKI in each site that uses it. The first server also handles certificate renewal and CRL publication by default, so your runbooks need to name it and your backups must be restorable into a live topology. Identification and authentication controls in frameworks such as NIST SP 800-53 and SP 800-171 will ask for evidence of how accounts are created, authenticated and removed. Confirm with your assessor which control IDs apply to your system before you decide what the directory must log and retain.
Most public bodies also run Active Directory for desktops and email, so coexistence is part of the design from the start. FreeIPA can establish a cross-forest trust with AD through Samba components, but the IPA DNS domain must not overlap with any domain in the AD forest. Settle that naming decision before installation, because changing it later is costly. Ask your integrator to document which identities come from which directory, who administers each one, and how a trust failure would affect Linux logins.
Which public sector requirements shape a FreeIPA build
This table maps the public sector requirements most likely to shape a FreeIPA design to the servers, clients and evidence they touch. Read each row as a question to settle with your authorizing official, compliance lead and assessor before the build is fixed. The main takeaway is that the impact level and data category decide how far validated cryptography and identity logging must reach.
| Requirement | What it asks for | What it means for the FreeIPA build |
|---|---|---|
| NIST SP 800-53 Rev. 5 and SP 800-53B baselines | Federal control catalog with low, moderate and high baselines selecting 149, 287 and 370 items respectively (NIST SP 800-53B, OSCAL profiles) | Confirm the system impact level first. The baseline sets how many identification and authentication, audit and access controls the IdM servers, replicas and enrolled clients must evidence. |
| NIST SP 800-171 and 32 CFR 2002.14(h)(2) | Protect controlled unclassified information on non-federal systems using NIST SP 800-171 unless the CUI category prescribes other safeguards (eCFR 32 CFR Part 2002) | If a contractor or grantee hosts CUI in FreeIPA-backed systems, the directory, Kerberos, certificate and SSSD components fall within the protected boundary. Confirm the CUI category with the agency. |
| FBI CJIS Security Policy v6.1 cryptography | FIPS 140-3 certified modules or FIPS 197 AES with keys of at least 256 bits for CJI in transit and at rest outside physically secure locations (California DOJ 2026-ISRS-001) | Plan FIPS mode on IdM servers, replicas and clients that handle CJI, and confirm which module certificates the platform and Dogtag CA use. Ask the CJIS Systems Agency how it reads the 256-bit rule for Kerberos and LDAP traffic. |
| CJIS Security Policy v6.1 vulnerability scanning | Vulnerability scanning at least monthly under control RA-5 (California DOJ 2026-ISRS-001) | Include FreeIPA server and client packages in the scan scope and record the 4.x release in use. Track security releases such as 4.13.4, which fixed two CVEs including LDAP access control flaws. |
| FedRAMP scope under OMB M-24-15 | FedRAMP covers cloud products that process federal information on behalf of an agency, and excludes single-agency systems on cloud infrastructure not offered as a shared service (OMB M-24-15) | An agency-run FreeIPA on its own cloud or data center usually sits outside FedRAMP scope. A FreeIPA service sold to several agencies could fall inside it. Confirm the service model with counsel and the authorizing official. |
| CMMC cloud rule for defense contractors | Cloud storage or processing of CUI requires FedRAMP Authorized at Moderate or higher, or equivalent (32 CFR 170.17(c)(5)) | If a contractor hosts FreeIPA in a cloud service that holds CUI, the provider must meet this rule. Self-hosted FreeIPA in the contractor's own scope is assessed within that scope. |
| ADA Title II web and mobile accessibility | WCAG 2.1 Level A and AA for state and local government web content and apps, including contracted content, from 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts (28 CFR 35.200) | Login pages and the FreeIPA web UI used for self-service or identity portals may fall under this rule when a government entity provides them. Confirm the entity population tier and whether the web UI is public-facing or internal only. |
Which FreeIPA modules and settings matter most in government
Government deployments of FreeIPA rise or fall on a small set of settings: how users prove identity, which cryptographic mode the platform runs in, how the directory meets an existing Active Directory forest, how servers are placed across sites, and whether backups can restore a working topology. Each card names the setting, the reason it matters for an agency or public body, and what the team must confirm in its own environment before accepting the design.
Second factors with OTP and RADIUS
FreeIPA supports HOTP and TOTP tokens, including software tokens and hardware tokens such as YubiKeys, and can proxy OTP checks to an existing RADIUS server. Agencies that already run a RADIUS-based VPN or privileged access service often want that service to keep its role. Verify which login paths enforce the second factor, including SSH, sudo, the web UI and any service that accepts a password directly, and test lockout behavior for each. Confirm the token enrollment and recovery process with your identification and authentication policy owner.
Certificate-based login and mapping
Smart card and certificate login maps a certificate presented at the console or over SSH to a FreeIPA identity, using the integrated Dogtag certificate authority or an external issuer. This is the approach most often asked for when federal or state credentials are involved. Confirm which mapping rules, certificate profiles and authentication indicators your target version supports, and test revocation behavior by removing a card or revoking a certificate and checking that login fails on every enrolled client.
FIPS mode on RHEL-family systems
FIPS mode changes which cryptographic modules and algorithms the operating system and its services use, and it is enabled per host rather than by FreeIPA alone. Auditors reviewing systems that handle controlled information will ask whether the FreeIPA servers, clients and the Kerberos and LDAP components on them run in FIPS mode. Confirm with your platform vendor which validated module versions apply to your release, and check that every enrolled client and replica supports the same mode before you rely on it for evidence.
Cross-forest trust with Active Directory
A cross-forest trust lets AD users sign in to Linux hosts enrolled in FreeIPA while the two directories stay separate. The IPA domain must use a DNS domain that does not overlap with any domain in the AD forest, so naming must be settled before installation because it is difficult to change later. Confirm the trust type, the ID mapping and view design, and which AD groups map to which Linux access. Agencies with separate Windows and Linux owners should agree on who administers the trust.
DNS over TLS and per-datacenter replicas
FreeIPA recent releases add DNS over TLS between clients and IdM DNS servers, which matters where resolver traffic crosses networks that officials do not control. The deployment recommendations advise at least two to three replicas in each datacenter, no more than four replication agreements per replica, and at least one replica per datacenter running PKI or DNS if used. Confirm the replica count, site placement and client resolver order against your continuity requirements, and test DNS over TLS with your own clients and certificates.
Backup and restore discipline
The ipa-backup and ipa-restore tools take full or online data-only backups, but restoring an outdated backup into an active replica topology can break replication. The first server also handles certificate renewal and CRL publication by default, so a restore decision affects certificate status. Write a restore runbook that states which server is restored first, how replicas are rebuilt, and who approves the step. Rehearse the procedure in a separate environment and keep backups offsite under the same controls as the live data.
How the build changes for federal, CJI, CUI and state environments
Federal agency systems are assessed against NIST SP 800-53 Rev. 5 controls, and the baseline that applies follows from the agency's own system categorization. Only the agency can set that categorization, so the FreeIPA design should follow it rather than assume one. The control catalog and the SP 800-53B baselines are published on NIST's CSRC site, and the design work is mapping FreeIPA settings to the identification and authentication controls the agency has selected.
- Baseline selection: Ask for the categorization and the selected baseline before mapping anything. NIST's OSCAL profiles select 149 items for low, 287 for moderate and 370 for high.
- Identification and authentication mapping: Map password policy, OTP, smart card and certificate settings to the IA family items the agency selected, and record which settings are inherited from a shared service.
- Assessment evidence: Assessors examine, interview and test each control, so plan configuration exports, audit log samples, backup restore records and access review output in advance.
- Authorization boundary: Decide which replicas, clients and administrative hosts sit inside the boundary and which external services, such as a cloud provider or a hosted DNS, fall outside it.
- Cloud hosting limits: FedRAMP scope under OMB M-24-15 covers cloud products that handle federal information on behalf of an agency. Confirm with the authorizing official whether a single-agency deployment on cloud infrastructure falls in or out of that scope.
Before scoping, confirm the system categorization, the baseline, the authorizing official, the boundary diagram and any agency-specific parameter values the control catalog allows the agency to set.
Systems that process criminal justice information (CJI) fall under the FBI CJIS Security Policy, and version 6.1 took effect on 26 June 2026 with a Requirements Companion Document. The policy sets cryptography and scanning requirements that shape how FreeIPA servers, replicas and clients are built, and it is administered through the state's CJIS Systems Agency. Your agency's CJIS Information Security Officer, not DeployOpen, decides how the policy applies to a given system.
- Cryptographic modules: For CJI in transit and at rest outside physically secure locations, the policy requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys. Confirm which cryptographic modules your FreeIPA build, including FIPS mode and its TLS and Kerberos paths, uses and whether their validation status is documented.
- Vulnerability scanning: The policy calls for scanning at least monthly under the RA-5 control, so plan scanner coverage for every FreeIPA server and any client that holds CJI.
- Physical location of replicas: Replicas outside physically secure locations change the encryption and access requirements, so place servers with that rule in mind.
- Control mapping: Trace the SC-13 and SC-28 items to the FreeIPA encryption settings and to the storage of the directory and backup data.
- Sign-off: Changes to cryptography and to the boundary usually need approval from the CJIS Systems Agency and the agency's security officer before any build starts.
Before scoping, confirm which CJIS Security Policy version your agency is audited against, whether CJI reaches the FreeIPA servers at all, and where each server and backup will physically sit.
Controlled unclassified information (CUI) on non-federal systems is governed by NIST SP 800-171 requirements, which federal agencies apply under 32 CFR 2002.14(h)(2) unless the CUI category sets other safeguards. Defense contractors pursuing CMMC Level 2 face a further limit: under 32 CFR 170.17(c)(5), a cloud service may store or process CUI only if it is FedRAMP Authorized at the Moderate baseline or higher, or meets equivalent requirements. The contract, not the platform, defines which revision and clauses apply.
- Scope reduction: Keep CUI systems in a dedicated FreeIPA domain or realm, with administrative access limited to that enclave, so the assessed scope stays small.
- Hosting model: A self-hosted FreeIPA on the contractor's own infrastructure is assessed within the contractor's scope. A cloud provider that stores or processes CUI must meet the FedRAMP Moderate condition or an equivalent, so confirm the provider's status before choosing it.
- Subcontractor flow-down: Identify every service provider that can reach CUI systems, including backup, DNS and monitoring vendors, and collect their evidence.
- Trusts with other domains: An AD trust with a corporate or program domain extends identity into adjacent systems, so review which users and groups cross the trust boundary.
- Sign-off: Contract compliance officers, the contractor's CMMC assessment lead and the legal team should approve the boundary and any cloud hosting decision.
Before scoping, confirm the contract clauses, the NIST SP 800-171 revision the contract cites, whether any cloud service will touch CUI, and which third parties can reach the enclave. DeployOpen prepares controls and evidence, but it does not issue certifications.
State and local bodies face a different mix of duties: accessibility obligations for the web and mobile services they offer, and, in EU member states, questions about NIS2 coverage. In the United States, the ADA Title II rule under 28 CFR 35.200 requires state and local government web content and mobile apps, including those provided through contracts or licenses, to meet WCAG 2.1 Level A and AA. Any self-service portal, password reset page or administrative interface built on FreeIPA or its surroundings is in that scope.
- Compliance dates: From 26 April 2027, the rule applies to entities serving 50,000 or more people. From 26 April 2028, it applies to smaller entities and special districts. Confirm your population threshold with counsel.
- Interface ownership: Decide whether the web UI and any custom enrollment or password pages are built, tested and remediated by your team, by DeployOpen or by a vendor, and write that split into the contract.
- NIS2 applicability (EU): NIS2 covers central government entities regardless of size and lists public administration as a high-criticality sector. Member States may extend it to local administration, and it excludes entities working in national security, public security, defense or law enforcement.
- Resilience planning: Replicas per site, tested backups and recovery steps matter for public services, so document them with the same care as the identity design.
- Sign-off: Accessibility officers, general counsel and, for EU entities, the national NIS2 competent authority guidance should approve scope.
Before scoping, confirm the population served, whether any service is delivered through a contract, which national or state security standards apply, and whether the NIS2 exclusions cover any part of the system.
Which compliance obligations the FreeIPA deployment must evidence
A public-sector FreeIPA deployment sits inside a stack of federal, criminal justice and defense obligations, and each one asks the agency to show how identity is controlled. The cards below set out which obligations usually reach the identity layer, what an assessor will ask to see, and where DeployOpen's role stops.
Identification controls mapped to SP 800-53
NIST SP 800-53 Rev. 5 groups identification and authentication requirements into the IA family, and SP 800-53A Rev. 5 gives an assessor a procedure for each control. Map each identification control your baseline selects to a specific FreeIPA setting, such as password policy, OTP enforcement or smart card mapping, and record where the setting is defined. The baseline you select comes from SP 800-53B, so confirm the baseline with your authorizing official before mapping starts.
FISMA and OMB A-130 context
Under FISMA, agency system security is assessed by Inspectors General, who report to OMB, and OMB Circular A-130 sets the broader management frame. Expect the Inspector General's assessors to ask for documented control design and evidence that controls operate over time, not only at installation. NIST does not set federal timelines or certification costs, so ask your agency's security office which assessment cycle applies to the FreeIPA system.
CJIS cryptography and scanning
If the FreeIPA estate holds criminal justice information, CJIS Security Policy version 6.1 requires FIPS 140-3 certified modules or FIPS 197 AES with keys of at least 256 bits for CJI in transit and at rest outside physically secure locations. It also requires vulnerability scanning at least monthly. Record the cryptographic modules used by each FreeIPA server and client, and keep scan reports for every host in scope.
Cloud limit for CUI under CMMC
Under 32 CFR 170.17(c)(5), a defense contractor pursuing CMMC Level 2 may store or process CUI in a cloud service only when that service is FedRAMP Authorized at the Moderate baseline or higher, or meets equivalent requirements. A FreeIPA deployment in your own data center or cloud account does not change that test for any cloud service it depends on. Inventory every hosted component, including backups and offsite replicas, and confirm its authorization status.
Evidence an assessor will request
Assessors typically ask for configuration exports, backup records showing that ipa-backup runs and restores were tested, access logs for administrative and login events, and change records for replica and certificate work. Keep these exports dated and tied to a named server. DeployOpen prepares these artifacts and the controls behind them, but it does not issue audit reports or certifications. The assessor decides whether the evidence is sufficient.
Where FIPS settings and certificate lifecycle change the design
Cryptographic requirements and certificate handling shape the FreeIPA design before any server is built. For criminal justice information, the FBI CJIS Security Policy version 6.1 requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys for CJI in transit and at rest outside physically secure locations, up from 128-bit. Your team should inventory every component that touches CJI (the 389 Directory Server, the MIT Kerberos KDC, the Dogtag CA, SSSD on clients, and any RADIUS or VPN endpoints) and ask each vendor or project for its validation status and certificate number. Do not assume that a FreeIPA host running with FIPS mode enabled at the operating system level satisfies the requirement until your assessor has confirmed which modules are in use and how they were validated. The policy text and its requirements companion document are the starting points for that conversation, and your assessor will decide how the evidence is accepted.
On the certificate side, the first FreeIPA server handles certificate renewal and CRL publication by default, so losing or rebuilding that server without a plan can stop renewals and revocation checks across the topology. Design the CA so that the first server's role is documented, its backups are tested, and the team knows how to promote another server if it fails. The backup documentation also warns that restoring an outdated backup into an active replica topology can break replication, so write a recovery runbook that states which backup to restore, in what order, and how replicas are re-synchronized. Replicas and the CA both need this plan, because a directory that replicates correctly can still hold certificates that cannot be renewed after an outage.
Confirm your target version and patch window before you finalize these choices. FreeIPA 4.13.0 made random certificate serial numbers the default, so check how your existing certificate profiles, audit tooling and any downstream systems handle serial numbers if you are upgrading from an older release. FreeIPA 4.13.4, dated July 9, 2026, fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, so the upgrade path and the timing of security patches belong in your security plan. Ask your integrator to confirm in writing which FIPS mode behavior has been tested on your exact operating system and FreeIPA version, rather than relying on general statements about the platform.
How a government FreeIPA rollout moves from scoping to evidence
This sequence takes a public sector FreeIPA rollout from classifying the data and impact level through to a controlled cutover and a set of evidence that assessors can review. Each step closes with an artifact the agency can keep, so the decisions and tests are traceable.
Confirm impact level and data category
The agency's security or compliance lead records which systems the identity service will support, the impact level of those systems, and the categories of data they handle, such as controlled unclassified information or criminal justice information. DeployOpen maps those answers to the applicable control baseline and to the authentication requirements that follow from it, including whether encryption modules must be FIPS 140-3 validated. The agency should confirm the applicable baseline with its authorizing official and any assessor before design starts. The step closes with a signed scope statement that names the systems, data categories and control baseline in force.
Define the trust and Active Directory coexistence design
The team decides whether FreeIPA will run beside an existing Active Directory forest, whether a cross-forest trust is needed, and which DNS domain the IPA realm will use. FreeIPA requires that its DNS domain not overlap any domain in the AD forest, so this choice is made before any server is built. The agency provides the AD forest and domain inventory, the owners of those directories, and approval from the directory team for any trust. The step closes with an approved naming, DNS and trust design document.
Size replicas per datacenter
Using FreeIPA's deployment recommendations, the design places at least two to three replicas in each datacenter, limits each replica to no more than four replication agreements, and runs PKI or DNS on at least one replica per datacenter where those services are used. Dedicated servers without other applications are planned, and clients are configured with at least two DNS servers. The agency provides datacenter locations, network paths between sites, and change approvals for the host builds. The step closes with a topology diagram and a server role table that the assessor can compare against the deployed state.
Build a lab with the target version
The team builds a non-production lab that matches the planned topology, using the FreeIPA version chosen for production after checking its release notes and known security fixes. The lab is used to confirm the platform, the configuration and the CA and DNS behavior before any production host is touched. The agency provides lab hosts, a test network and access for named engineers. The step closes with a recorded build of the lab, its version, and a list of deviations from the design that were resolved or accepted.
Enroll pilot hosts and test smart card and OTP logins
A small set of pilot Linux hosts is enrolled into the lab, and the team tests the authentication paths the agency relies on, including smart card logins with certificate mapping and OTP logins using software or hardware tokens. Where RADIUS proxying is required, the OTP check is tested against the existing RADIUS server. The agency provides test accounts, smart cards or tokens, and the user acceptance testers. The step closes with a test log that records each authentication path, its expected result and the observed result.
Run backup and restore drills
The team runs full and data-only backups with ipa-backup in the lab, then restores them to a clean environment and checks users, hosts, certificates and replication. The drill also confirms which server handles certificate renewal and CRL publication, because the backup guidance warns that restoring an outdated backup into an active replica topology can break replication. The agency provides a restore environment and the staff who will own recovery. The step closes with a documented drill that shows the restore succeeded and the recovery runbook was updated from what was learned.
Run controlled cutover
The production servers are built to the approved design, and clients are moved in batches under the agency's change process, with rollback steps written for each batch. DeployOpen supports the cutover and watches authentication and replication health during each change window. The agency provides change approvals, maintenance windows, site access for hardware work, and named owners who can accept or halt each batch. The step closes with a change record for each batch and a confirmed replication state across all replicas.
Collect evidence for assessors
The team assembles the material an assessor will ask for: the scope statement, the topology and design records, configuration exports, test logs, backup drill results, change records and access reviews of administrative roles. Each item is mapped to the identification and authentication controls the agency has chosen to address. DeployOpen prepares this evidence but does not issue any audit report or attestation, and the assessor decides what it proves. The agency confirms with its assessor the format and location of the evidence package. The step closes with an indexed evidence package that the agency owns and can hand over.
What public sector teams ask before hiring a FreeIPA partner
What drives the cost of a government FreeIPA build?
The software carries no license fee, because FreeIPA is licensed under GPL-3.0-or-later and has no paid edition of its own. You pay for services, hosting, staff time and support. One-time costs include design, installation, client enrollment, integration with existing directories, certificate and MFA configuration, and documentation for assessors. Recurring costs include the servers and storage you run, patching and upgrades, backup operations, and staff or retainer support. The biggest cost drivers are the number of sites and replicas, how many systems must enroll, whether an AD trust is needed, and how much evidence your assessment requires. Ask each bidder to split the quote into one-time and recurring lines, and to name who pays for hardware, hosting and hours.
How long does a FreeIPA build for an agency take?
The duration depends on scope, not on the software itself. The main drivers are the number of sites and replicas, how many Linux hosts and services must enroll, whether an Active Directory trust or user migration is involved, the smart card or MFA design, and how fast your change and accreditation processes move. Your own approvals, procurement and security reviews often take longer than the technical work. Ask for a written schedule that lists each milestone, the approvals each one needs from your side, and the test evidence delivered at each stage. Confirm the timeline against your own change calendar before you sign.
Can our agency team run a FreeIPA deployment without a partner?
Many agencies have Linux and directory staff who can do it, but the work needs skills across identity, Kerberos, DNS, PKI and Linux operations. Before deciding, check whether you have people who can design replica topology, run backups and restores safely, and manage certificate renewal. Also check who will handle upgrades and security releases after go-live. A useful test is to name the engineers who will own each component for the next several years. If that gap is large, a partner can cover design, build and documentation while your staff learn to operate the system.
What does a FreeIPA partner need from our agency?
A partner needs access and decisions from several groups. Expect to provide:
- Site access or remote access to the data centers, networks and hosts where FreeIPA will run
- Named owners for Active Directory, DNS, network segmentation and existing LDAP directories
- Contacts for your security assessors and authorizing officials, so evidence requirements are settled early
- Decisions on smart card issuance, MFA token types and the certificate authority design
- A test window, change approvals and a point of contact for each production cutover
Missing owners are a common reason builds stall, so confirm these names before the written scope is agreed.
Does a cloud deployment of FreeIPA fall under FedRAMP?
FedRAMP's scope covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. Under OMB memo M-24-15, systems used only for a single agency's operations on cloud infrastructure, and not offered as a shared service, are out of scope. A FreeIPA instance that only serves one agency's Linux estate may therefore fall outside FedRAMP, while a shared identity service offered to several agencies may not. The answer depends on who operates the service, who owns the data and how it is offered. Confirm the classification in writing with your agency's FedRAMP or authorizing official, and ask your partner to document the scope decision for your file.
Which NIST controls does FreeIPA help with for identification and authentication?
FreeIPA supports identification and authentication work in NIST SP 800-53 and in the NIST SP 800-171 requirements that apply to controlled unclassified information on non-federal systems. Its features include central accounts, Kerberos single sign-on, OTP tokens with HOTP and TOTP, certificate issuance and host access rules. Mapping these features to specific control IDs, such as the identification and authentication families, is an assessment task. The 800-53 baseline your system needs depends on its impact level, and SP 800-53B defines the low, moderate and high baselines. Ask your assessor which baseline applies and have the partner produce a control-by-control evidence map. The mapping is your input to the assessment, not the assessment itself.
What should a written FreeIPA quote for a public sector build include?
A written quote should follow the agreed scope and separate one-time work from recurring work. Ask for these items:
- The scope list, including sites, replica count, enrolled hosts and integrations
- Named deliverables, such as the design document, runbooks, test records and evidence packs
- Assumptions about your environment, approvals and access, with what happens if they change
- Hardware, hosting and license lines, so no cost is hidden in services
- Post-go-live support terms, upgrade handling and who pays for security releases
- The exit path, including documentation and knowledge transfer
Compare quotes against the same scope rather than against headline totals.
What does FreeIPA need from our Active Directory team?
If you plan an AD trust, the IPA domain must use a DNS domain that does not overlap with any domain in the AD forest. That constraint shapes naming decisions, so bring your AD owners in early. Ask them to confirm forest and domain names, DNS delegation, trust policy and which AD users need Linux access. Also confirm whether any users will be migrated instead of trusted. Trusts and migrations have different administrative effects, and your AD team should review both before the design is fixed. Confirm the trust type and supported Windows versions against the FreeIPA Trusts page before you commit.
How DeployOpen scopes and delivers government FreeIPA work
DeployOpen plans, implements, hardens, documents and supports FreeIPA inside your own infrastructure, whether that is a data center, a government cloud account or an isolated network. Engagements start from a written scope, and we prepare the systems, controls and evidence that your assessors and auditors will examine, without issuing any attestation ourselves.
How we scope
- Written scope covers which identification and authentication controls FreeIPA will support, mapped to your chosen NIST SP 800-53 or 800-171 baseline.
- Scope records the AD forest, trust type and DNS domain layout, confirming the IPA domain does not overlap any AD domain.
- Scope names smart card issuers, FIPS mode requirements and the systems that will enroll, so cost follows from a defined list.
How we build
- Replica topology is designed per site, with dedicated servers and PKI or DNS placed on replicas as the deployment recommendations describe.
- Smart card login, certificate mapping and OTP or RADIUS settings are configured and tested with real credentials on representative clients.
- Testing covers failover, ipa-backup and ipa-restore rehearsal, and confirmation that FIPS mode behaves as your policy requires.
How we hand over
- Documentation covers the build, the control-to-configuration mapping and the evidence each control produces for assessors.
- Operators receive runbooks for enrollment, certificate renewal, backup restores and the rule that outdated backups must not enter an active topology.
- Handover includes a walkthrough with your security, identity and platform teams, with knowledge transfer recorded in the written scope.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing like the original build.
- Upgrade planning reviews each FreeIPA 4.x release and its security fixes against your change control and test cycle before rollout.
- Periodic reviews confirm backups, replication health, certificate expiry and access policy still match your control documentation.
