FreeIPA SSO and identity integration guide

How FreeIPA SSO works for Linux hosts and web apps

FreeIPA gives Linux hosts and services one login by issuing Kerberos tickets from its MIT Kerberos KDC, while users, groups, hosts and policies are held in 389 Directory Server. On each enrolled Linux machine, SSSD asks the IPA servers for those identities and handles authentication for local logins, SSH and services that accept Kerberos tickets. If you run Linux servers, internal services and web applications and want people to sign in once, this is the part of the stack that works for hosts you enroll. FreeIPA is licensed under GPL-3.0-or-later and is a community project with no paid edition of its own, so the software carries no license fee. The cost sits in design, integration and operations, which the rest of this section explains.

Web applications are where the picture changes. Most browser-based apps expect SAML or OIDC, which are separate protocols from the Kerberos tickets FreeIPA issues to hosts. Bridging the two usually means placing an identity provider such as Keycloak in front of FreeIPA, or using a gateway that accepts Kerberos from the browser and passes an assertion or token to the app. The choice depends on each application's supported protocols, how it maps group membership to roles, and where session lifetimes are set. Before you commit, list every web app, the protocol it supports, and the team that owns its redirect URIs, signing keys and logout behavior.

Windows users add a second identity source. If people sign in with Active Directory accounts, those identities live in a separate forest. 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, so the naming decision comes first and is hard to change later. Second factors are a further path. FreeIPA supports HOTP and TOTP tokens, including software tokens and hardware tokens such as YubiKeys, and it can proxy OTP checks to an existing RADIUS server. Each token type needs its own enrollment, lost-token and recovery procedure, and each login path, whether Kerberos, AD trust, OTP or web SSO, needs its own test case.

Every login path depends on DNS and time being correct. Kerberos rejects tickets when clocks drift beyond the allowed skew, and clients locate KDCs and services through DNS records, so a missing forward or reverse entry can surface as what looks like a password failure. FreeIPA's deployment recommendations advise at least two DNS servers in each client's resolv.conf. Before go-live, confirm that every host resolves the IPA servers in both directions, that NTP is synchronized across all hosts and replicas, and that your web apps and identity provider resolve and trust the same host names. Ask your implementation partner to write these checks into the acceptance tests so they are verified, not assumed.

Which login path fits each system

This table compares four login paths FreeIPA can support: Kerberos tickets, OTP or RADIUS second factors, AD cross-forest trust, and a broker such as Keycloak. Read each row for when the path fits and what it asks your team to run, especially keytab handling, token enrollment, a second identity system, and DNS and time dependencies. The main takeaway is that most estates use two or three paths together, and the operational cost of each is set by different dependencies.

Login path	When it fits	Operational cost to plan for
Kerberos ticket login for Linux hosts and services	Linux and UNIX hosts, SSH with GSSAPI, and services that accept Kerberos such as NFS or web services using SPNEGO, all enrolled in the FreeIPA domain	Keytab creation and rotation for services, client enrollment with SSSD, and strict DNS and time synchronization because Kerberos fails when clocks drift or name resolution is wrong
OTP or RADIUS proxy for second-factor login	Privileged or remote access that needs a second factor, with HOTP or TOTP tokens in FreeIPA, or an existing RADIUS server that FreeIPA can proxy to	Token enrollment and recovery for each user, hardware token stock if used, and a decision on who owns the RADIUS server and its availability when it is proxied
AD cross-forest trust for Windows users	Windows users in an existing Active Directory forest who must sign in to Linux hosts under FreeIPA policy without a second account	A separate trust to set up and maintain, ID mapping and ID views to manage, DNS domain separation, and Samba-based trust components that your team must patch and monitor
Broker such as Keycloak for SAML or OIDC web apps	Browser-based applications that speak SAML or OIDC, where FreeIPA supplies the user directory and Kerberos or password checks behind the broker	A second identity system to run, its own certificates, upgrades and backups, and a configuration that must stay aligned with FreeIPA groups and user attributes

FreeIPA SSO build sequence, step by step

This sequence takes a FreeIPA domain from verified foundations to single sign-on for Linux hosts, services, two-factor login and web applications. Each step closes with a check, so the team knows the layer works before the next one depends on it.

Confirm DNS and time on every host
Before any identity work, confirm that every server and replica resolves forward and reverse names for the IPA domain and for each other, and that clocks are synchronized across the topology. Kerberos is sensitive to clock skew, and FreeIPA's deployment guidance expects at least two DNS servers in each client's resolv.conf. Take a backup of the initial state as well, so that later changes can be rolled back. Done means name lookups succeed from every host, time sources report synchronized, and the first backup is stored off the servers.
Enroll Linux clients with SSSD
Enroll each Linux client into the domain so that SSSD handles identity lookups and Kerberos. Enrollment should be tested on a small pilot group of hosts first, using the client tooling for your distribution. Confirm that a directory user can log in, that a Kerberos ticket is issued at login (check with klist), and that the ticket is available to other tools on the host. Done means a test user logs in on each host type in the pilot and holds a valid ticket without typing a second password.
Verify service principals and keytabs
For an HTTP or other application service, create the service principal in FreeIPA, generate its keytab on the host that runs the service, and restrict the keytab file to the service account. Then obtain a ticket for the service from a client and confirm that Kerberos negotiation succeeds end to end. Remember that the first server handles certificate renewal and CRL publication by default, so confirm that any service certificate you issue for this principal follows the renewal path you expect. Done means a test client authenticates to the service with a Kerberos ticket and the service logs the expected principal.
Add OTP tokens and attach them to users
Add second-factor authentication by creating OTP tokens in FreeIPA. FreeIPA supports HOTP and TOTP tokens, including software tokens and hardware tokens such as YubiKeys. Enroll a small set of pilot users, attach each token to the right account, and decide which groups must use a second factor. Test a login with the password and token together, and test a rejected login with a wrong code. Done means pilot users are prompted for a token where policy requires it, and the rejected attempt is recorded in the logs.
Configure RADIUS proxying where needed
Configure RADIUS proxying only if an existing RADIUS server must remain the system of record for OTP checks, such as for VPN or network equipment that already depends on it. FreeIPA can proxy OTP checks to that server. Confirm the shared secrets, network paths and failover behavior with the owner of the existing RADIUS service before changing anything, and keep the prior configuration in the backup. Done means a test login that depends on the proxied check succeeds, and a failed check is refused by both systems.
Connect web apps through a broker
Only after the Kerberos, OTP and client layers are verified, connect web applications through a broker such as Keycloak, using SAML or OIDC against FreeIPA as the user source. Keep the broker's configuration and any signing keys in the backup plan. Test one application at a time, starting with a non-production instance, and confirm that group membership from FreeIPA controls access. Done means a test user signs in through the broker, receives the expected claims, and is denied when the group check fails.
Back up before each change and test restores
Take a full backup with ipa-backup before each change window, and keep online data-only backups between them where your topology supports that. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so restores must follow the documented procedure and be tested in a separate environment. Record which backup corresponds to which change. Done means each change has a named backup, and a restore has been rehearsed on a non-production copy.

How OTP and RADIUS add a second factor to FreeIPA logins

FreeIPA can add a second factor to logins in two ways: it can hold OTP tokens itself, or it can forward OTP checks to an existing RADIUS server. FreeIPA supports HOTP (RFC 4226) and TOTP (RFC 6238) tokens, including software tokens in an authenticator app and hardware tokens such as YubiKeys. Before enrolling anyone, decide which of the two models matches your environment, because the choice determines where token secrets live, who administers them, and which login paths can use them.

Native OTP keeps token records in the FreeIPA directory, so enrollment, disablement and recovery happen through the IdM web UI or the ipa command. Token seeds are then replicated across your replicas like other identity data, which keeps administration in one place. RADIUS proxying suits organizations that already run a RADIUS service with its own token inventory, vendor tooling and audit trail. In that model FreeIPA passes the OTP check to the RADIUS server rather than verifying the code itself. Confirm which system your security team already treats as the source of record for tokens, since moving that record later is the costly part.

Token enrollment and recovery need a written process before go-live. Enrollment usually binds a token to a user account and requires that user to prove possession of their password first. Recovery covers lost, broken or replaced hardware tokens, and it is where account takeover risk tends to enter, because a help desk reset can quietly weaken the second factor. Define who may reissue a token, how the requester is verified, how old tokens are revoked, and how these actions are logged. Ask whether your help desk can perform these steps without bypassing the second factor for the user.

The second factor does not behave the same way on every login path. Web logins through the FreeIPA UI and SSH logins with keyboard-interactive prompts can ask for an OTP code directly, while console and some legacy PAM services depend on how their PAM stack is configured. Kerberos tickets obtained with a password alone may bypass the OTP prompt unless your policy requires pre-authentication with the token. Test each service you protect, because a path that skips the second factor is a gap regardless of how strong the token is. Hardening rules for enforcing OTP across these paths are covered on the security hardening page.

Before relying on RADIUS, confirm the behavior of your RADIUS server and client in your own environment. Check the supported authentication methods, the timeout and retry settings, how the server handles a repeated or out-of-window OTP code, and whether it returns clear error codes that FreeIPA can log. Confirm the shared secret handling, the server's high availability, and whether it can fail open or closed when unreachable. Test a locked account, an expired token and a RADIUS outage in a lab replica first. These checks should be scoped and documented in the implementation plan before any production login changes.

What drives effort in an SSO integration

This table lists the factors that change how much work an FreeIPA single sign-on integration takes, how each one changes the work, and how to keep it contained. Read each row against your own estate to see which drivers apply, then use the same list to check any written quote for missing scope. The main takeaway is that most of the effort comes from how many hosts, services and web apps are connected, so standardizing those early lowers cost more than any single technical choice.

Driver	Why it changes effort	How to keep it down
Linux hosts and enrolled services	Each host needs SSSD enrollment, Kerberos keytabs for services, and access rules. Effort grows with host count and with every service that needs its own principal.	Standardize on one SSSD enrollment method and a single build image. Group services by function so keytab handling follows a repeatable pattern.
Web apps needing SAML or OIDC	FreeIPA issues Kerberos tickets for hosts and services, but browser SAML and OIDC apps usually need a broker such as Keycloak in front. Each app adds client registration, claim mapping and testing.	Put all web apps behind one broker and reuse the same realm and client templates. Confirm early which apps can accept Kerberos or LDAP directly.
User source: AD or FreeIPA-native	Users already in Active Directory require a cross-forest trust, DNS domain separation, ID mapping and testing of AD logons on Linux. Native FreeIPA users need none of this.	Decide the identity source before design starts. Confirm that the IPA DNS domain does not overlap with any AD forest domain.
Datacenters and replicas	Each site needs its own replicas, replication agreements and client DNS settings. Replication topology and failover testing scale with site count.	Keep to the documented guidance of two to three replicas per datacenter and no more than four replication agreements per replica. Limit sites to those that truly need a local server.
Existing token and RADIUS infrastructure	If OTP or RADIUS already exists, FreeIPA can proxy OTP checks to it, but that adds integration testing, token migration and support for two systems.	Reuse the existing RADIUS server where it is supported. Confirm token types and migration needs before choosing between proxying and re-enrolling tokens in FreeIPA.
Compliance evidence needs	Assessors may ask for access reviews, authentication logs, policy settings, certificate records and backup restore results. Each evidence set is extra collection and documentation work.	Agree the evidence list before build. Use central policy and export it on a schedule. DeployOpen prepares evidence for assessors, but auditors issue the audit opinion.
In-house Kerberos experience	Kerberos ticket lifetimes, keytabs, time synchronization and DNS SRV records are the usual points of failure. Teams without this experience need more hands-on support and more troubleshooting time.	Ask for a documented runbook covering keytab rotation, clock checks and DNS validation. Plan knowledge transfer into the sprint or phase plan, and name who will own it after go-live.
Cost components in a written quote	Fixed-scope quotes usually separate design, build, integration per app, testing, handover and any retainer. Scope gaps appear as unpriced host or app counts.	Ask for the host, service and app counts in writing, the named integrations, the test plan, the evidence list, and whether ongoing support is a separate retainer or included.

Pairing FreeIPA SSO with Keycloak for SAML and OIDC apps

Most web applications that speak SAML or OIDC should not talk to the Kerberos KDC directly. FreeIPA's MIT Kerberos KDC issues tickets to Linux hosts, services and clients that can use the GSSAPI, but browser-based SAML and OIDC flows expect redirects, signed assertions and JSON Web Tokens. A broker such as Keycloak sits between the two worlds: it authenticates the user against FreeIPA's directory, then issues the protocol tokens each application expects. This keeps FreeIPA as the source of identity while letting each application integrate with a standard protocol instead of a Kerberos-specific client stack.

The first design decision is which system owns users and groups. In most FreeIPA deployments the 389 Directory Server is the authoritative store, so Keycloak should federate to it through an LDAP user storage provider rather than keep a second copy of accounts. Decide early whether Keycloak imports users, caches them, or only queries them on login, and whether group membership is read live or synchronized. Also decide whether any applications need accounts that do not exist in FreeIPA, because local Keycloak users will drift from the directory unless you manage them deliberately. Confirm the federation options and mapper features against the Keycloak documentation for your version, since the exact provider settings change between releases.

Group claims are where access decisions become visible to applications. Map FreeIPA groups to Keycloak roles or group attributes, then map those to SAML attribute statements or OIDC claims in each client. Keep the mapping explicit: one FreeIPA group should correspond to one application role, and nested groups should be flattened in the mapper rather than assumed. Test with a user from each group and inspect the issued assertion or ID token, because a missing claim often looks like an authorization failure in the application. Remember that FreeIPA host-based access control governs Linux logins and does not decide which web application roles a user receives.

Sessions and token lifetimes need to be set in two places: the Keycloak realm, which controls SSO session idle and maximum times, and each client, which may override access token and refresh token lifetimes. Shorter access tokens reduce exposure but increase refresh traffic, and a long SSO session means a revoked FreeIPA account may still hold a valid browser session until it expires. Decide how account disablement in FreeIPA should propagate, and document the answer for security reviewers. Ask your Keycloak support provider which logout and back-channel options your version supports.

If users sign in from domain-joined Linux workstations or browsers that can perform Kerberos negotiation, Keycloak can accept a Kerberos ticket instead of a password prompt. This requires a keytab for the Keycloak host principal issued by FreeIPA, correct forward and reverse DNS, synchronized time, and browser policy that allows negotiation only for the intended domains. Test with an expired ticket and with a client outside the domain so the password fallback behaves as you intend. Confirm the exact Kerberos and browser settings against current Keycloak and FreeIPA documentation for the versions in your environment, because version details were not verified for this page.

Protecting keytabs, OTP seeds and the CA in the SSO path

These cards cover the secrets and roles that make FreeIPA SSO work: Kerberos keytabs, OTP seeds, RADIUS shared secrets, service principals, certificate requests and the servers that hold the CA. Each is a place where one weak control can let an attacker sign in as someone else. For the full hardening baseline, see the FreeIPA security hardening topic.

Keytab files and rotation

Keytab files hold the long-term Kerberos keys that services use to decrypt tickets, so anyone who reads one can impersonate that service. Check that each keytab is readable only by the owning service account and root, and that copies in backups or configuration repositories are encrypted. Confirm how your team will rotate service keys after staff changes, a suspected host compromise or a host retirement, and rehearse that procedure on a test realm before go-live. Keep a record of which hosts hold which keytabs so revocation is fast.

OTP seeds and RADIUS secrets

OTP token seeds are shared secrets between FreeIPA and each enrolled token, so a copy of the token data can let an attacker generate valid codes. Restrict read access to the directory data that stores them, and limit who can enroll, resynchronize or delete tokens. If FreeIPA proxies OTP checks to an existing RADIUS server, the shared secret between the two systems is also a credential. Confirm where it is stored, who can read it, and how it changes when the RADIUS server is replaced.

Least-privilege service principals

Service principals let applications authenticate with Kerberos, and each one should exist only for a workload that needs it. Grant administrative roles to named people and keep routine work in narrow delegated roles. Review which principals can manage hosts, services and certificates, and remove accounts for decommissioned applications. Ask your implementation partner to document each role and its permissions so audits can trace who changed what and when.

Restricting host and service certificate requests

FreeIPA issues host and service certificates from its built-in Dogtag certificate authority, so anyone allowed to request one can obtain an identity for each name they are permitted to claim. Review certificate profiles, the principals allowed to request certificates for each host and service, and whether automated enrollment is limited to hosts that need it. FreeIPA 4.13.0 uses random certificate serial numbers by default, which is worth confirming in your own build.

First server and backups hold CA roles

By default the first server handles certificate renewal and CRL publication, so its role cannot be assumed by other replicas without planning. Its backups carry the same CA material and directory data. FreeIPA's backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so restore decisions should involve people who know the current topology. Confirm where the first server runs, who can reach it, and how backups are stored, encrypted and tested.

Dedicated servers for FreeIPA

The FreeIPA deployment recommendations advise dedicated servers without other applications, so the identity service is not exposed to the risks of unrelated software on the same host. Plan the CA, DNS and replica roles on hosts that run only FreeIPA components. Check that operating system access, administrative logins and network paths to these servers are limited to the people and clients that need them. Confirm this against the current recommendations before you finalize the architecture.

How to test that FreeIPA SSO works and fails safely

Test each login path in two directions. First, confirm that the right identity gets access. Second, confirm that the path refuses access when a ticket, keytab, code, server or session is missing or invalid. Start with Kerberos from an enrolled client. Run kinit as a test user, then klist to check the principal, the ticket lifetime and the renewable window. Request a service ticket for a host or HTTP service and confirm access works with a valid keytab. Then run kdestroy, remove the keytab or swap in a wrong one, and confirm access is refused. Check the SSSD and service logs for the failure reason. A login that silently falls back to a password prompt that succeeds is a finding, not a pass. Next, test two-factor login. Enroll a test user with a software TOTP token, sign in with a valid code, then try an incorrect code and an expired one from an earlier time window. Confirm rejection and check that the failure counter and lockout behavior match your password and lockout policy. For the RADIUS proxy path, stop or block the upstream RADIUS server during the test and observe whether login denies or allows access. Decide that outcome before go-live, record it in the runbook, and confirm the proxy settings against the FreeIPA version you run.

Test the identity provider path next. If Keycloak or another broker sits in front of FreeIPA for SAML or OIDC web applications, sign in through a test application, then let the broker session expire and load the application again. Confirm the user is sent back to authenticate instead of being served from a stale assertion or token. Then disable the test user in FreeIPA and request a new Kerberos ticket. The kinit attempt should fail. Also confirm that tickets issued before the disable remain valid until their lifetime ends, because that window is part of the risk you accept. Shorten ticket lifetimes or plan revocation steps if that window is too long for your data.

Test name resolution and time. Take the DNS server that clients normally query offline and confirm that clients with at least two DNS servers in resolv.conf still find the KDC and LDAP service records and can complete a Kerberos login. Restore the server and confirm normal resolution resumes. For clock skew, move a test client's clock beyond the tolerance configured in your Kerberos policy and attempt a login. Expect a clock-related authentication error, then confirm recovery once time synchronizes. Confirm the tolerance value in your own environment, along with the NTP sources your servers and clients use, instead of assuming a default.

Run the restore test in a non-production copy only. Restore a backup taken at a known point into an isolated environment with no network path to live replicas. Verify that users, groups, hosts, services, certificates and replication status match what you expect at that point. Check which server holds the certificate renewal and CRL publication role, because a restored copy can behave differently in that role. Do not use a live replica topology as the test target. FreeIPA's backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Record the restore steps, the time it took, the gaps you found and who approves the next run. Ask your implementation partner to show the exact procedure for your version before you schedule it.

How the SSO design changes by environment

In one datacenter, the design keeps identity services close to the clients that depend on them. Replica placement is the simplest of the three environments: the project's deployment recommendations advise at least two to three replicas in each datacenter, with no more than four replication agreements per replica. Clients reach Kerberos, LDAP and DNS over the local network, so the main design question is how to avoid a single point of failure inside the site.

Replica placement: Run two or three replicas on dedicated servers, and spread them across separate hypervisors or racks where the site allows it.
DNS reachability: Point each client's resolver configuration at at least two DNS servers in the same site, and host the IdM DNS zones on replicas.
RADIUS and broker location: Keep the RADIUS server and any Keycloak broker in the same datacenter, so OTP checks and SAML or OIDC logins do not depend on a WAN link.
Certificate issuance: Run the Dogtag CA on at least one replica. The first server handles certificate renewal and CRL publication by default, so confirm which server holds that role.
Time sources: Point replicas and clients at internal NTP servers in the site, since Kerberos depends on closely matched clocks.

Confirm the replica count and agreement layout against the project's current deployment recommendations before you size the servers.

What to monitor, back up and document after go-live

Monitoring after go-live should focus on the failures that stay quiet until a login breaks. Check replication status on every replica, because a broken agreement can leave one site authenticating against stale credentials and OTP state. Track certificate expiry for the Dogtag CA and for service certificates used by web and broker endpoints, and confirm that renewal is working on the first server, which handles certificate renewal and CRL publication by default. Test KDC and LDAP health from client subnets with real kinit and LDAP bind attempts, not only from the servers. Alert on OTP and RADIUS failures separately from password failures, since a spike often points to token drift or a proxy outage. Record login errors from the identity broker, and compare SSSD configuration on enrolled hosts against an agreed baseline to catch enrollment drift early.

Backups need a schedule, a restore test and a clear rule for where they can be restored. FreeIPA provides ipa-backup and ipa-restore, with full backups and online data-only backups. Full backups capture the complete server state, while data-only backups are useful for frequent copies between full runs, so confirm with your own runbook which backup type covers each recovery scenario. The FreeIPA backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Restore only into a topology that matches the backup, meaning the same server names and replica roles, and rehearse this in a non-production environment. Ask your team who holds the encryption and offsite copy arrangements, because backups contain sensitive directory and key material.

Upgrades on the 4.x line are security work as much as feature work. FreeIPA 4.13.4, a stabilization release dated July 9, 2026, fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, and it hardened authentication checks across the API. Treat that release as a priority, and confirm the version on every replica, not only the first one. Take a fresh backup, test the upgrade on a non-production replica, then upgrade production replicas one at a time while checking replication and Kerberos login after each step. Keep a rollback plan and record the exact package versions for each server, so that the next audit or incident review can show what was running and when it changed.

The documentation handover is what lets an internal team run the platform without the people who built it. Start with a principal inventory covering user, host and service principals, with owners and purposes. Record keytab locations for each host and service, along with the permissions and the process for rotating them. Write the token enrollment procedure: who may enroll HOTP or TOTP tokens and hardware keys, how a lost token is revoked, and how RADIUS proxy settings are verified. Map every identity broker client to its FreeIPA source, including attribute mappings and redirect URIs. Finally, write runbooks for replication failure, certificate renewal, restore and password reset, and review them at each upgrade so they match the running version.

Questions buyers ask before building FreeIPA SSO

What does a FreeIPA SSO integration cost, and what drives the price?

The cost is the services fee for the agreed scope, plus your infrastructure and staff time. FreeIPA is licensed under GPL-3.0-or-later and has no license fee, so the spend is on people, servers and operations. DeployOpen fixed-scope quotes follow from a written scope.

Main drivers:

Number of sites, datacenters and replicas
Number of Linux hosts and services to enroll with Kerberos
Whether two-factor login (OTP or RADIUS) is in scope
Whether Keycloak or another identity provider is added for SAML or OIDC web apps
Active Directory trust, existing LDAP or NIS sources, and any identity migration
Testing effort and change windows

Recurring costs include servers, operating system lifecycle, certificate operations, upgrades and support time. Ask any quote to separate one-time work from recurring work and to list assumptions about your environment.

How long does a FreeIPA SSO rollout take?

Timing depends on scope and environment, so no single duration applies to every project. A written scope should give a phased schedule that shows which steps depend on your decisions and access.

Factors that move the timeline:

Number of realms, sites and replicas
Existing DNS design and certificate authority choices
Number of hosts and services to enroll
Whether identities must be migrated from another directory
Whether AD trust or two-factor login is included
Change approval cycles and maintenance windows

Delays most often come from waiting on DNS changes, host access and approvals. Ask for milestones tied to those dependencies, and confirm which phases can run in parallel before you accept a schedule.

What does our team need to provide for a FreeIPA SSO project?

Your team needs to provide access, decisions and named owners before the build starts. Missing items are the most common reason a schedule slips, so confirm them in the written scope.

Required from your side:

Directory access: read access to existing LDAP, NIS or Active Directory sources that hold identities
DNS control: ability to create and change DNS records, including SRV records for Kerberos and LDAP
Host access: administrative access to the Linux hosts and servers that will run FreeIPA and enroll as clients
Keytab and token owner: a named person who controls service keytabs, OTP tokens and their rotation
Keycloak or RADIUS decision: whether web apps need an identity provider, and whether two-factor login uses FreeIPA tokens or an existing RADIUS server

Agree on who approves changes to each item.

Can our internal team set up FreeIPA SSO without an outside partner?

Yes, an internal team can build FreeIPA SSO alone if it has working Kerberos and LDAP skills and a test environment that matches production closely enough to rehearse changes. Most teams underestimate the operational side, so check that skills are present before committing.

Skills to confirm:

Kerberos realm design, keytabs and ticket behavior
LDAP schema, access control and replication
DNS records, client resolver settings and failover
Certificate authority operation, including renewal and revocation lists
SSSD, PAM and sudo configuration on client hosts

The team also needs a tested backup and restore procedure and time for upgrades after go-live. The FreeIPA backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so rehearse that path first.

Do Active Directory users need a separate trust project?

Usually yes. Active Directory users are normally treated as a separate workstream because the trust crosses a forest boundary and involves the AD team. FreeIPA can establish a cross-forest trust with Active Directory through Samba components, according to the FreeIPA Trusts page.

Points to plan:

The IPA domain must use a DNS domain that does not overlap with any domain in the AD forest.
ID mapping and ID views determine how AD users appear on Linux hosts.
Host access and sudo rules must cover AD users under the same policy as local users.
The AD forest owners must approve and support the trust.

Some organizations migrate a subset of users instead of trusting the whole forest. Confirm which users must sign in to Linux hosts before you scope the trust work.

Does FreeIPA support two-factor login with OTP or RADIUS?

Yes. FreeIPA supports HOTP (RFC 4226) and TOTP (RFC 6238) tokens, including software tokens and hardware tokens such as YubiKeys, and it can proxy OTP checks to an existing RADIUS server, according to the FreeIPA OTP design page.

Decisions to make:

Use FreeIPA-managed tokens, an existing RADIUS server, or both.
Confirm which login paths need the second factor, such as SSH, sudo, VPN or web logins.
Decide who enrolls tokens, issues replacements and handles lost devices.

Confirm in your own environment that each client and login service accepts the OTP flow you choose before you commit to a design. Test fallback behavior when the RADIUS server is unavailable.

Should we pair FreeIPA with Keycloak for SAML and OIDC web apps?

FreeIPA handles Kerberos and LDAP-based login for Linux hosts and services. SAML and OIDC web applications usually need an identity provider that speaks those protocols, and Keycloak is one option to evaluate. The decision depends on how many web apps you run and which protocols they support.

Questions to answer first:

How many web applications need single sign-on, and which protocol does each one support?
Who will operate the Keycloak instance, including upgrades and backups?
What session length and multi-factor rules must web logins follow?
Which user source will Keycloak read from, and how will group membership map to application roles?

Confirm the federation method and supported versions against the current Keycloak documentation for your deployment before you finalize the design.

How DeployOpen scopes, builds and hands over FreeIPA SSO

DeployOpen plans, implements, integrates, documents and supports FreeIPA SSO and identity integration inside your own infrastructure, whether that is your cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as a retainer.

How we scope

The written scope names which login paths are in scope: Kerberos for Linux hosts, OTP or RADIUS, AD trusts and any SAML or OIDC web apps.
Scope lists the FreeIPA servers, datacenters and client populations that will be enrolled and tested.
Scope states where the Dogtag CA and DNS run, and which replicas carry those roles.

How we build

Builds follow a documented replica topology with dedicated FreeIPA servers and no other applications on them.
Each login path is tested end to end, including Kerberos ticket issuance, OTP enrollment and client sign-in through SSSD.
An identity provider such as Keycloak is configured for SAML or OIDC only where the scope includes it, with the trust settings recorded.

How we hand over

Handover includes configuration records, enrollment runbooks and the verification steps used during acceptance testing.
Backup and restore procedures are documented and a restore is exercised before handover, so the team knows the recovery path.
Operating notes cover certificate renewal on the first server and the rules for returning a replica to the topology.

How we support

Post-go-live support can be arranged as a retainer covering upgrades, security fixes and periodic checks.
Support scope, response expectations and review cadence are written into the agreement, not assumed.
Your team receives the documentation needed to run FreeIPA itself, with DeployOpen available for planned changes.

FreeIPA SSO and identity integration