Kerberos SSO for web applications with FreeIPA

How Kerberos single sign-on for web applications works with FreeIPA

With this integration, an internal web application accepts the Kerberos ticket that a user already holds from signing in to an enrolled Linux workstation, so the user reaches the app without typing a password. The supported method, as shown in the FreeIPA workshop on web application authentication and authorization, runs on an IPA client where Apache performs the Kerberos negotiation. Apache authenticates the user against the ticket, PAM enforces host-based access control (HBAC) rules to decide whether that user may use the app on that host, and mod_lookup_identity populates the request environment with user attributes so the application can read them. This is a Kerberos and Apache path, not a generic OIDC or SAML login, so the application receives an authenticated identity from the web server rather than from a redirect to an identity provider.

The moving parts are a service principal for the web server host, its keytab, and the Apache modules that consume them. Your team must register an HTTP service principal in FreeIPA for the application's host name, retrieve its keytab to the server with restricted file permissions, and confirm that Apache can read it. Browsers also need Kerberos negotiation enabled for the application's domain, because the browser must offer a ticket before any SSO takes place. Red Hat's guide to accessing IdM services describes this browser requirement for the IdM Web UI, and the same principle applies to your own apps. Expect the browser settings to be the most frequent source of support tickets, since a missing allowlist entry fails silently into a password prompt.

Plan the access decision before the build starts. HBAC rules, not Apache configuration alone, define which users and host groups may reach the service, so agree on the rule set with the owners of the application and the identity team. Confirm with your own environment which Apache and SSSD package versions your distribution ships, and test the PAM path with a user who is allowed and one who is not. Also decide how the application will consume the attributes that mod_lookup_identity passes, since reading identity data directly from LDAP inside the app creates a second access path to review.

What you need before enabling Kerberos SSO for a web app

Kerberos single sign-on for a web app depends on several components agreeing with each other before Apache sees a single ticket. The cards below cover the FreeIPA servers, the app host, DNS, time, workstations and certificates, and what to confirm in each.

FreeIPA server and enrolled app host

Confirm a working FreeIPA server (or replica) is reachable from the host that will run Apache, and that the host is enrolled as an IPA client with SSSD running. The web server host must be a managed IPA client so it can hold a keytab and use PAM for HBAC checks. Confirm the exact FreeIPA and RHEL or other distribution versions against the Red Hat and FreeIPA documentation for your target environment before you plan the install.

App hostname resolving through IPA DNS

The service principal is built from the app's fully qualified hostname, so the name clients use must resolve forward and reverse to the app host. Kerberos fails when a browser requests a name that does not match the principal. Decide the public or internal name early, create the matching DNS record in IPA DNS or your external DNS, and confirm that enrolled clients use the IPA DNS servers in resolv.conf.

Time synchronization across all parties

Kerberos rejects tickets when clocks drift beyond the allowed skew, so the browser workstation, the app host, the KDC and every replica must use synchronized time. Confirm that the app host and the IPA servers both sync from a reliable source and that workstations in scope do the same. Check time sync first when a ticket is rejected with a clock-related error.

Workstation and browser enrollment state

Users reach the app without a password only from machines that hold a valid Kerberos ticket, which means enrolled Linux or Windows workstations that have obtained one from the FreeIPA KDC. Confirm which operating systems and browsers are in scope, then test that a user with a valid ticket can complete negotiation. Browsers must also be set to allow Kerberos negotiation for the app's domain, as covered later in this topic.

TLS certificates for the app host

Browsers expect the app to be served over HTTPS with a certificate that matches its hostname, and a missing or mismatched certificate blocks sign-in even when Kerberos works. Decide whether the app certificate comes from the FreeIPA Dogtag CA, an internal CA you already trust, or another source, and confirm that the client trust chain includes it. Plan renewal and where the private key is stored on the app host.

Keytab ownership and HTTP service principal

The Apache process needs a keytab for the HTTP service principal, and that file grants the ability to decrypt tickets for the app. Confirm who may create or retrieve the keytab in FreeIPA, which local user owns the file, and that its permissions limit access to the web server account. Treat the keytab as a secret that is rotated and replaced when the host is retired.

Build sequence for FreeIPA Kerberos SSO on an Apache web app

This sequence takes an internal web app from no Kerberos setup to a state where enrolled users reach it without a password, and only the users your HBAC rules allow get in.

Create the HTTP service principal for the app host
An IPA administrator creates a service principal named HTTP/fully-qualified-hostname for the Apache host, using the host's FQDN exactly as it appears in IdM, and confirms the host is already enrolled as an IPA client. The principal is the identity browsers request tickets for, so a typo here causes every later negotiation to fail. Check that the principal appears in the IdM Web UI or in the output of the service show command for that host. Ask your team to confirm the naming convention for service principals in your environment before creating the first one.
Retrieve the keytab to the Apache host securely
On the Apache host, retrieve the keytab for the HTTP principal into a file such as /etc/httpd/conf/http.keytab, then set ownership so only the Apache service account can read it and the mode is restrictive. Keep the file out of web-accessible paths and out of version control. Verify the keytab with klist -k, confirming the HTTP principal and its key version are present, and then run kinit -k with the keytab to confirm the host can obtain a ticket for the service principal.
Configure Apache Kerberos authentication
Install the mod_auth_gssapi module and set the Kerberos directives on the protected location, including AuthType GSSAPI, the keytab path through the GssapiCredStore setting, and a require valid-user rule. Restart Apache and confirm the configuration parses cleanly. Test with a user holding a valid ticket: run kinit as that user on an enrolled workstation, then run curl with the --negotiate and -u : options against the app URL. A 200 response from the protected page confirms that ticket validation works end to end.
Enable PAM-based HBAC enforcement
Configure Apache to use PAM for account checks so that FreeIPA host-based access control rules decide who may use the app. This means setting the PAM service used by the location and making sure an HBAC rule exists that allows the intended users or groups on this host for that service. The FreeIPA workshop routes this check through PAM. Confirm the setting with a user the rule allows, then run the same curl negotiate request as a user outside the rule and expect a denial. That denial is the proof that HBAC is enforced, not just Kerberos.
Configure mod_lookup_identity for user attributes
Load mod_lookup_identity and configure it to read user attributes and group membership through SSSD, so the application receives these values in the request environment without its own LDAP code. Map only the attributes the application needs and avoid passing sensitive fields. Verify by writing a test page or log entry that prints the identity variables for an authenticated request, then confirm the values match what id and getent report for the same user on the Apache host.
Set browser Kerberos negotiation
Configure each browser that should use single sign-on to negotiate Kerberos for the app domain. In Firefox this means adding the app hostname or domain to the network negotiation allow list, and in Chromium-based browsers the equivalent policy or AuthServerAllowlist setting, with Windows and macOS handling defined by their own settings. Red Hat's IdM access guide states that the browser must be configured for Kerberos negotiation for single sign-on, so confirm the steps for your browser versions. Done means an enrolled user with a valid ticket opens the app without a password prompt, and a user outside the HBAC rule is refused.

Which FreeIPA identities and attributes reach the web app

This table maps each identity element in a Kerberos SSO setup, from the principal and keytab to group checks and request variables, to where it is set and what the application sees. Read it as a checklist: each row names a value your own configuration must confirm before users log in. Most failures in this setup come from a mismatch between the principal Apache accepts and the name the application expects.

Element	What it carries	Where it is set or checked	What to confirm
Kerberos principal	User identity from the ticket, usually the FreeIPA login with the realm suffix	Negotiated by Apache mod_auth_gssapi during the browser handshake	Whether the realm suffix is stripped before the name reaches the app
REMOTE_USER	Short username the app uses as the account key	Set by Apache after successful Kerberos authentication	Whether your app reads REMOTE_USER or a header, and whether the realm is included
HTTP service principal	Service identity Apache presents, named HTTP/hostname in FreeIPA	Registered in FreeIPA for the web server host, with its keytab on the server	That the principal name matches the ServiceName and the host's DNS name exactly
Apache keytab	Long-term key Apache uses to decrypt client tickets	Keytab file on the web server, readable only by the Apache service account	File permissions, key version after any rotation, and that the keytab is not shared with other services
HBAC service and host groups	Rules deciding which users may reach the app on which hosts	Checked by PAM through the HBAC service configured for Apache	Which HBAC service name covers the app and which user groups it allows
FreeIPA groups	Group membership used for application roles	Available to Apache through mod_lookup_identity and SSSD, not authorized by Kerberos itself	Whether the app maps groups to roles, and that group names match what SSSD returns
User attributes in request environment	Fields such as mail, display name or group list passed as environment variables	Populated by mod_lookup_identity from SSSD for the authenticated user	Exact variable names and which attributes your FreeIPA schema exposes to the web server
Header handling by the app	Whether the app trusts REMOTE_USER directly or reads a forwarded header	Depends on the reverse proxy and framework configuration	That incoming copies of identity headers are stripped at the proxy so clients cannot spoof them

Browser negotiation settings by audience and client type

On enrolled Linux desktops, Firefox and Chromium-based browsers each read their own negotiation allowlist. Firefox uses the network.negotiate-auth.trusted-uris preference, and Chromium-based browsers use the AuthServerAllowlist policy or an equivalent setting. Both need the application's host name or domain suffix listed, and the user must hold a valid Kerberos ticket from SSSD or kinit before the browser asks for one.

Firefox preference: list the app's domain suffix, such as .apps.example.internal, in network.negotiate-auth.trusted-uris.
Chromium allowlist: set the server allowlist through managed policy so it applies to every profile.
Ticket state: confirm that klist shows a current ticket for the user before testing the browser.
Profile scope: check whether preferences are set per user profile or system-wide on the workstation image.
Packaging: Firefox may be installed from distribution packages or a vendor archive, and the policy location depends on which build is in use.

Confirm the current preference names and policy keys in each vendor's documentation for your browser version, since these settings change across releases.",

Security controls for Kerberos SSO on internal apps

Kerberos single sign-on moves trust into a few artifacts: the HTTP keytab, the HBAC rules that decide who may reach the app, the TLS session that carries the ticket exchange, and the login path users fall back to. Each card below names one of those controls and what to confirm on your platform version before go-live.

Keytab file ownership and permissions

The HTTP service keytab holds the long-term key that lets Apache decrypt Kerberos tickets for the app, so anyone who reads it can impersonate the service. Keep the file owned by the account that runs the web server, readable only by that account and root, and out of web-accessible paths and version control. Check the file mode and owner after every renewal or re-retrieval, because a keytab copied with loose permissions is easy to miss.

Who may retrieve the HTTP keytab

In FreeIPA, the right to create or retrieve a service keytab is controlled separately from the right to log in, and it is the step most likely to be granted too broadly. Limit retrieval to the administrators who deploy the app host, and confirm which roles and permissions your IPA version assigns for keytab retrieval. Record each retrieval in your change process so a copied key can be traced to a request.

HBAC rules scoped to host and service

HBAC rules decide which users and groups may access which hosts and services, so a rule that names only the HTTP service on the app host limits the blast radius of a mistake. Avoid rules that use the allow-all category for the app, and confirm that the service name in the rule matches the Apache service the PAM stack evaluates. Test with a user outside the permitted group to confirm the denial.

TLS on the application

Kerberos negotiation does not encrypt the page content that follows authentication, so the app still needs TLS for the traffic it serves. Issue the server certificate for the app's host name through the FreeIPA certificate authority or your approved CA, and confirm that the certificate's subject matches the host name users type into the browser. Check certificate renewal, since an expired certificate breaks the app even when Kerberos works.

Fallback login path

When Kerberos fails, for example on an unenrolled laptop or a browser without negotiation enabled, users need a defined alternative. Decide whether that path is a form-based login, a VPN route or no access at all, and do not leave an unauthenticated route beside the Kerberos one. Confirm how the fallback is authenticated, how its rules are reviewed, and whether it bypasses the HBAC checks.

Logging of denied HBAC decisions

Denied access decisions show whether the HBAC rules work and whether someone is probing the app. Confirm where your platform version records PAM and SSSD denials for the Apache service, and forward those logs to your central log store with retention that matches your policy. Review denials on a schedule, since a rule that blocks a legitimate group is often first noticed through these logs.

Why Kerberos SSO for a web app fails and how to fix it

This table lists the failures most often seen when Kerberos single sign-on to an internal web app does not work, with the likely cause and the fix for each. Read it from the top when a user is prompted for a password, and check the rows in order, since several symptoms share the same root cause.

Symptom	Likely cause	Fix
Browser never sends a Negotiate token	The browser is not configured to use Kerberos negotiation for the app's domain, so it falls back to a password prompt	Add the app's host name to the browser's trusted authentication sites or negotiation allow list, then confirm the user holds a valid ticket with klist on the enrolled machine
Apache returns 401 even with a ticket	The keytab does not contain the HTTP service principal for the exact host name the browser used, or the keytab file is unreadable by the Apache user	Retrieve the HTTP keytab for the app's host on the IPA client, check the principal with klist -k, and confirm ownership and read permission for the web server account
Keytab principal mismatch	The principal is named for a different host, an alias or a short name, so Kerberos cannot match the service ticket	Register the service principal under the canonical name the browser requests, then regenerate the keytab and restart Apache
Authentication fails only for some users	Clock skew between the browser's machine, the web server and the KDC exceeds the Kerberos tolerance	Synchronize all three against the same time source, such as the NTP service that FreeIPA can run, and check the time on each host before changing settings
Name does not resolve to the service principal	The URL uses a CNAME, an IP address or a name without a matching DNS record, so the client requests a ticket for a principal that does not exist	Use the fully qualified host name in the URL, add or correct the forward and reverse DNS records, and confirm the client resolves the name the same way the keytab expects
Valid users receive access denied	An HBAC rule does not include the user's group, the host, or the PAM service used by Apache, so PAM denies the login	Review the HBAC rule for the app's host and service name, confirm the user's membership with id, and test the rule with the HBAC test tools before changing the app
Authenticated user, but no attributes or groups reach the app	mod_lookup_identity cannot read the user's record through SSSD, or the attributes it requests are not present for that user	Check the SSSD domain configuration and the attributes listed in the Apache configuration, then query the user with getent passwd on the web host to confirm SSSD returns them

Questions buyers ask before enabling FreeIPA SSO for web apps

How much effort does Kerberos SSO for a web app take?

Effort depends mostly on how many applications you expose, how many distinct hostnames and Apache servers they run on, and how much your browsers and clients already work with Kerberos. Each app needs its own HTTP service principal and keytab, an Apache configuration that performs Kerberos authentication, and an HBAC rule that says who may use it. The workshop path covers Apache on an IPA client with Kerberos authentication, HBAC enforcement through PAM and user attributes passed to the application through mod_lookup_identity. Plan extra time for the first app, because that is where the shared pattern gets settled, and less for each app after that.

Can our own team set this up without a partner?

Yes, if your team already runs Linux services and has someone comfortable with Kerberos, DNS and Apache modules. The work is well documented in the FreeIPA workshop and in Red Hat's guide to accessing IdM services. The common stumbling points are DNS and time synchronization for Kerberos, keytab handling on the Apache host and browser negotiation settings on user machines. A partner adds value when you want the pattern designed once for many apps, a written verification plan and a fixed-scope handover, which is what a DeployOpen engagement covers.

What does the work need from our staff?

Expect to involve four groups: IdM administrators who can create service principals and HBAC rules, web application owners who can change how their app reads the authenticated user, Linux administrators who manage the Apache host and the IPA client enrollment, and desktop or endpoint staff who can push browser negotiation settings. Each group should name a contact and agree on who approves keytab creation and HBAC changes. Ask for a list of the apps, their hostnames and their current login methods before the work starts, since that list drives most of the schedule.

How long does it take with many apps and different environments?

Duration is driven by app count, the number of Apache hosts, how many environments (development, test and production) need the same pattern, and whether each application already has a clear owner and login behavior. Applications that accept identity from the web server need less change than those that parse their own login forms. Ask any provider for a timeline that is tied to a written list of applications and environments, and for the dates on which each milestone is checked. No duration can be given from this page without that scope.

Do we need Keycloak to make this work?

No. Kerberos SSO through Apache works directly with FreeIPA when users are on enrolled machines with Kerberos-capable browsers. Keycloak becomes useful when users sign in from unmanaged devices, need OIDC or SAML for applications that cannot use Kerberos, or come from partner organizations. In those cases, Keycloak can sit in front of FreeIPA so that web applications receive standard tokens while Linux identities stay in FreeIPA. Decide this per application group, and record which apps stay on Kerberos and which move to federation.

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

A fixed-scope quote should list each application, its hostname and Apache host, the service principal and keytab handling, the HBAC rules and groups for each app, the browser negotiation settings to be applied and how they are delivered, and the test cases that show access works for allowed users and fails for others. It should also state what the client provides, such as IdM admin access, DNS records, test accounts and change windows, and what is handed over, including documentation and runbooks for keytab rotation. Ask whether ongoing support is separate, because most engagements are fixed-scope and retainers are optional.

What happens to users who are not on enrolled machines?

They will not get silent Kerberos sign-in, so the application must still offer a fallback, or the request should be refused by design. Confirm with each application owner whether a fallback login is acceptable, and decide whether that fallback should pass through Keycloak or another identity provider. Plan this before the rollout so that support teams know what users will see on unmanaged devices.

When Keycloak or application-level LDAP is the better route

Kerberos SSO fits when users sit on enrolled machines and the application can accept authentication from Apache in front of it. In that pattern, a user who already holds a Kerberos ticket from their FreeIPA login reaches the app without a second password, and the web server decides access through HBAC rules enforced by PAM. Before committing, confirm three things: the users are enrolled Linux or supported workstation clients, the application can run behind Apache (or accept a trusted identity header from it), and the browsers your staff use can be configured for Kerberos negotiation. If any of these fails, Kerberos SSO will not work for that population no matter how well the server is built.

Kerberos is the wrong route for external users, contractors on unmanaged devices, and mobile clients. Applications that need OpenID Connect or SAML for partners or customers should sit behind a broker such as Keycloak. In the sibling topic on Keycloak federation over SSSD, Keycloak takes the OIDC or SAML role while FreeIPA remains the source of Linux identities. Applications that cannot use Kerberos or a web broker at all, such as some legacy clients or scripts, need a separate decision. The sibling topic on LDAP system accounts covers a dedicated bind identity for that case, and it carries its own password handling and least-privilege duties that this page does not cover.

The decision is easier to make per application than per organization. Write down, for each internal app, who uses it, from which devices, and whether it needs token-based access or group claims for another system. Then ask the app vendor or maintainer whether it supports header-based or Kerberos authentication, and confirm the exact version you will run. Where the answers point to more than one route, plan for both and keep the authorization source the same, so a user's groups in FreeIPA produce the same access decision regardless of the front door.

How DeployOpen scopes and delivers FreeIPA web app SSO

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Kerberos single sign-on with FreeIPA, we start from the applications, hosts and users involved, then build and hand over the service principal, keytab, Apache configuration and HBAC rules in your environment.

How we scope

Inventory the internal web applications, their hostnames, and whether each runs on an IPA client or a separate host.
Confirm which user groups may reach each application and map them to HBAC rules and FreeIPA groups.
Agree the written scope in advance, including deliverables, test cases and timelines, since most engagements are fixed-scope.

How we build

Register the HTTP service principal, retrieve the keytab on the application host, and set file ownership and permissions for it.
Configure Apache Kerberos authentication, PAM-based HBAC enforcement and user attribute passing in a staging environment first.
Test browser negotiation on enrolled machines, including failure cases where a user has no valid ticket or lacks access.

How we hand over

Document the principal names, keytab locations, rotation steps, HBAC rules and browser settings used for each application.
Provide a runbook for adding applications, revoking access and diagnosing negotiation failures on client machines.
Walk your platform and security teams through the configuration so they can operate and audit it after handover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover, scoped in writing.
Plan re-testing after FreeIPA and Apache upgrades, since changes to either can affect negotiation and keytab handling.
Confirm with your team who owns keytab rotation, certificate renewal and access requests once the engagement ends.

Kerberos single sign-on for web applications with FreeIPA