How FreeIPA constrained delegation lets a front end act for users safely
A web front end often has to call back-end services as the user who signed in, so that the back end applies that user's own permissions. Full delegation solves this by letting the front end act for any user toward any service, which is far broader than the job requires. Constrained delegation narrows that trust so the front end may only obtain Kerberos tickets for users toward a named list of target services. FreeIPA provides general constrained delegation for Kerberos services since FreeIPA 3.0.0, and the delegation is configured on the service principals that the front end is allowed to use, not on the users themselves.
FreeIPA's FreeIPA design document for resource-based constrained delegation describes integrating RBCD alongside the general model. In RBCD, the back-end service itself names which front ends may delegate to it, so the control sits with the service owner rather than with the domain administrator who manages the front end. Before you design around this, confirm in your target release whether RBCD is delivered, how it is administered from the CLI and web UI, and which Kerberos settings it depends on. Do not assume the design document describes shipped behavior.
Start by listing each front end, each back-end service it calls, and the reason it needs the user's identity rather than its own. Then decide which model fits each pair: general constrained delegation when a central administrator should approve every link, or RBCD when the service owner should decide. Test the chain with a non-production user and a sample request, and confirm that the back end logs the delegated identity and rejects calls to services outside the approved list. Also plan for the front end's own keytab, since a leaked credential would let an attacker act for any user on the permitted services.
General constrained delegation versus resource-based constrained delegation
General constrained delegation is the model FreeIPA has offered for Kerberos services since FreeIPA 3.0.0. The trust is configured centrally in the domain, so a domain administrator decides which front-end service may obtain tickets on behalf of users and which back-end service principals it may reach. The front end's permission is recorded against its own service principal, and the back-end targets are listed explicitly, which keeps the full set of permitted paths visible in one place.
- Control point: the domain administrator grants and removes delegation rights.
- Setup: the front-end service principal is allowed to delegate to named back-end service principals, and the rule is reviewed in the central configuration.
- Good fit: a small number of stable web front ends calling a known set of back ends, such as a portal reaching a database or file service.
- Trade-off: every new back-end target is a central change, so teams that deploy often may wait on the administrator.
- Operations: list the delegation rules as part of access reviews so that stale permissions are removed.
Before you rely on this model, confirm with the FreeIPA release notes and documentation for your version how the delegation rules are managed and audited on your servers.
Resource-based constrained delegation (RBCD) moves the decision to the back-end service. Instead of the domain administrator naming every permitted path, the owner of the target service states which front-end accounts may act for users against it. The trust sits on the resource being protected, which fits service-owned architectures where the team running the back end should decide who may reach it. A FreeIPA design document describes integrating RBCD alongside general delegation, so confirm in your release which parts are supported before you plan around them.
- Control point: the back-end service owner decides which front ends may delegate to that service.
- Setup: the back-end principal is configured to accept delegation from named front-end principals, which the owning team can change without a central ticket.
- Good fit: many back-end services owned by different teams, each protecting its own data.
- Trade-off: authority is spread across teams, so a central view of who can reach what must be built through reporting and review.
- Operations: require each owning team to record its accepted front ends in the service inventory.
If your deployment depends on RBCD, verify the exact configuration steps and supported behavior against your installed release with a test environment first.
The two models can coexist in one realm, but mixing them without a plan makes it hard to answer the question of who can reach a back-end service. The decision depends on who should own the trust and how often the topology changes. Central control suits a fixed, small set of integrations. Service-owned control suits organizations where application teams run their own back ends and need to change access without waiting on identity administrators.
- Ownership test: if a domain administrator should approve every new path, use general delegation.
- Change rate: if teams add back ends often, evaluate resource-based delegation for those services.
- Audit view: decide how each model's grants will appear in your access review before go-live.
- Mixed estates: document which services use which model, so reviewers do not need to reconstruct the rules.
- Pilot: test one front end and one back end in a non-production realm before extending either model.
Ask your FreeIPA support contact to confirm which delegation model your release supports for the exact front-end and back-end types you plan to connect.
What a FreeIPA constrained delegation setup needs before work starts
Constrained delegation only works when the identity, network and credential pieces behind it are already sound. The cards below cover what must be in place on the FreeIPA side and on the hosts before anyone configures a delegation rule.
A supported FreeIPA release
Confirm the target release against its release notes before you plan the delegation design. The FreeIPA 4.13.4 release notes record security fixes, including LDAP access control flaws and hardened authentication checks across the API, so the version you run decides which authentication behavior you are designing against. Record the server and client versions you will test with, and confirm the same versions on every host in the chain.
Enrolled front end and back-end hosts
Every host that takes part in the delegation chain must be enrolled as a FreeIPA client, with SSSD running and the host object present in the directory. The web front end accepts user logins, and the back-end service accepts the delegated ticket, so both need valid host principals. Check that each host resolves its own identity and group membership through SSSD before you touch Kerberos settings.
Working DNS and time synchronization
Kerberos service names are derived from DNS, and ticket validity depends on clock agreement, so both must be right before delegation can succeed. Confirm forward and reverse lookups for each front end and back-end host, and that every host uses at least two DNS servers in its resolv.conf, as the FreeIPA deployment recommendations advise. Verify time synchronization across the hosts and the KDC, and treat a DNS or clock fault as the first suspect when a delegated request fails.
Dedicated FreeIPA servers
The FreeIPA deployment recommendations call for dedicated servers without other applications. Apply that to the IPA servers that issue the tickets, and confirm the front end and back-end application hosts are the systems you intend to delegate from. Mixing the identity servers with the application workloads makes it harder to show who changed a delegation rule and which host held the credential.
Service principals and keytabs for each tier
Each tier needs its own service principal, with a keytab stored on the host that runs that service. The front end's principal is the one permitted to request tickets on behalf of users, and the back-end principal is the target. Decide which principals exist, who can retrieve each keytab, and how keys rotate, because a leaked front-end keytab lets its holder impersonate users toward the services it is allowed to reach.
A named owner for the delegation policy
Name one person or team who approves each delegation grant, reviews the list of target services and retires grants when an application changes. Write down which service each front end may act for, which users it may act for, and the change process. Without a named owner, delegation rights accumulate after the applications that needed them are gone.
Configuring constrained delegation in order, with a check after each step
This sequence takes a web front end from an unconfigured FreeIPA realm to a tested delegated request against a back-end service, with a verification check at each step so that problems surface before the next change is made. It is written for the team that owns the FreeIPA realm and the application teams that depend on it.
Confirm the service design and owners
Before touching FreeIPA, write down the front-end service, the back-end service it must reach, the users who will be delegated, and which team controls each service principal. Confirm the FreeIPA release you run and read the constrained delegation and resource-based delegation documentation for that release, since command syntax and object names change between versions. Done when a short design note names both principals, the owning administrator for each, and the target release. Verification: a reviewer outside the project can state which principal will act for which user.
Register the front end and back-end service principals
Create the service principal for the web front end and the principal for the back-end service in the FreeIPA realm, using the naming pattern your release documents. Make sure both hosts are enrolled as FreeIPA clients and that DNS resolves the fully qualified host names used in the principals. Done when the principals are visible to the administrator who will manage them. Verification: list each principal from a FreeIPA server and confirm the host name, realm and service class match the design note exactly, since a mismatch here breaks every later step.
Choose the delegation model
Decide between general constrained delegation, which is configured by the realm administrator and lets the front end delegate to the services listed for it, and resource-based constrained delegation, where the back-end service itself names the front ends allowed to act for users against it. Weigh who must be able to change the rule, whether the back-end owner should control access, and whether your release supports the approach you choose. Done when the model and its owner are written into the design note. Verification: the decision record states who can add or remove a delegation target without a ticket to the realm team.
Create the delegation target and allowed list
Under the chosen model, create the delegation rule or resource-side setting that names the back-end service as the target and the front-end principal as the permitted delegator, and keep the list as narrow as the application needs. Use the command forms documented for your FreeIPA release and do not copy examples from older posts. Done when the rule exists in the realm. Verification: display the rule with the administrative command for that release and confirm the front end appears only against the intended back-end service, with no wildcard or extra targets.
Set keytab ownership and permissions
Retrieve the keytab for each service principal and install it on its host with ownership limited to the service account that runs the process and with file permissions that block other local users from reading it. Confirm the keytab is not world-readable and is not copied into shared configuration repositories. Done when each service can read its own keytab and nothing else on the host can. Verification: check ownership and mode on each keytab file and confirm the service starts and obtains its own ticket from the keytab without an interactive password.
Test a delegated request end to end
Obtain a test ticket for a known user through the front end's own authentication path, then make the front-end request that asks the back-end service to act for that user, and confirm the back-end accepts the delegated identity and returns the expected data. Test a second user who is not granted the delegation to confirm the request is refused. Done when both results match expectations. Verification: the back-end log shows the delegated identity for the permitted user and a denial for the excluded user, and the ticket cache on the front end shows the expected service ticket.
Record the configuration and test for regressions
Save the final rule, principal names, keytab locations and the two test results in your change record, and schedule a repeat of the end-to-end test after each FreeIPA upgrade, key rotation or change to either service. Note who may change the delegation rule and how changes are reviewed. Done when the record can rebuild the setup without reference to the original administrator. Verification: a colleague who did not do the work repeats the denied and permitted tests from the record and gets the same results.
Which identities and attributes map to each delegation hop
This table maps each hop in a constrained delegation chain to the identity it carries, who controls that mapping, and what to verify before go-live. Read it top to bottom as the path a request takes from the signed-in user to the back-end service, then check each row against your own realm and host configuration.
| Hop or identity | What it represents | Owner | What to verify |
|---|---|---|---|
| Signed-in user principal | The FreeIPA user whose Kerberos ticket the front end presents, such as a user@REALM principal | IPA administrators, through user accounts and password or OTP policy | The user obtained a forwardable ticket, and the account is active and not locked out |
| Front-end service principal | The web service identity that receives the user's ticket and requests delegated access, such as HTTP/app.example.com | Service owners, with IPA administrators registering the principal and keytab | The keytab is readable only by the service account, and the principal is the one named in the delegation rule |
| Back-end service principal | The target service the front end is allowed to act toward, such as a database or file service principal | Service owners and IPA administrators, who set which front-end principals may delegate to it | The delegation target matches the exact service principal name, not a host-wide or wildcard scope |
| Host principal | The machine identity of each host running a service, used to validate the service and its keytab | Platform or systems team, through host enrollment and host keytab management | Each host is enrolled and its host keytab is current, and the service runs on the host it is registered to |
| Group or HBAC context | The FreeIPA groups and host-based access rules that limit which users may reach the service on each host | IPA administrators, who define groups and HBAC rules and assign them to hosts | Membership is read through SSSD on each host, so the same group result is returned wherever the request lands |
| Local UID and group mapping | The POSIX identity the service process uses on the host after SSSD resolves the user | Systems team, through SSSD configuration and the ID range set for the domain | The resolved UID matches what the back end expects, and lookups succeed on every host in the path |
Security controls that keep delegation from becoming full impersonation
Constrained delegation lets a web front end act for a user against only the services you name, but that power is still impersonation within those services. The controls below decide whether the trust stays narrow, and each one depends on how FreeIPA keytabs, delegation targets and server patches are managed.
Limit delegation to named targets
Allow the front end to delegate only to the specific back-end service principals it needs, never to a broad set of hosts. Each allowed target is a grant that lets the front end obtain tickets for any user it is permitted to impersonate, so the list is the main boundary of the design. Review the list whenever a back end is added, renamed or retired, and confirm in your own environment which delegation type each target uses before you expand it.
Restrict keytab creation and retrieval
Decide who may create service principals and who may retrieve their keytabs, and grant those rights to named administrators or automation accounts only. A user who can retrieve the front-end keytab can act as the front end, so keytab rights are as sensitive as the delegation rights themselves. Check these permissions in FreeIPA's access control rules after every change to the service design.
Treat the front-end keytab as the top secret
The front-end keytab is the most sensitive credential in this design. Anyone holding it can request service tickets as the front end and, where delegation is configured, obtain tickets for users it may impersonate. Store it with restricted file permissions on the web host, keep it out of images, repositories and shared backups, and confirm which accounts on that host can read it.
Grant delegation only where needed
Do not enable delegation on services that only receive user requests. Build a list of services that must act for users, justify each entry, and remove the rest. Keeping delegation off by default means a compromise of a non-essential service cannot be turned into impersonation of users against other back ends.
Rotate keys on a planned schedule
Plan key rotation for the front-end service and each delegated target, and rehearse it in a test realm before production. Rotation invalidates old keytabs on the host, so update the web server's configuration and confirm that tickets issued with the previous key no longer work. Ask your team to document who performs the rotation and how it is verified.
Keep FreeIPA servers on current releases
Apply security releases to FreeIPA servers promptly. The 4.13.4 release fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, and hardened authentication checks across the API. Because those flaws sit beneath any delegation design, confirm your server version against the release notes before you treat the trust as settled.
Common constrained delegation failures and how to fix them
This table lists the failures teams most often hit when a web front end requests service tickets on behalf of users in FreeIPA, with the likely cause and first fix for each. Read each row as a starting hypothesis, and confirm the cause in your own Kerberos and service logs before changing configuration. The main takeaway is that most failures come from time, naming and policy mismatches rather than from the delegation design itself.
| Symptom | Likely cause | Fix to confirm in your environment |
|---|---|---|
| Tickets fail with clock or skew errors | Front end, KDC and back-end hosts disagree on time beyond the Kerberos tolerance | Confirm all hosts sync to the same NTP source, check time offsets on each host, then correct the time service before retesting |
| Service ticket request fails for an unknown or mismatched server | The hostname the client uses does not match the service principal registered in FreeIPA, often a CNAME or load balancer alias | Use the canonical host name in the service principal and in client configuration, and check DNS forward and reverse records for the back end |
| Front end cannot obtain or use its credentials | Keytab is missing, belongs to a different principal, has an old key version, or is unreadable by the service account | Check the keytab principal and key version against the directory, re-retrieve or rotate the keytab, and confirm file ownership and permissions |
| Delegation request is refused for a target service | The back-end service is not on the front end's list of services it may delegate to, or the resource-side policy does not name the front end | Compare the configured delegation targets with the exact target principal in the error, then add or correct the entry under your chosen delegation model |
| Delegated ticket is rejected or the back end sees the front end's identity | The user's ticket was not obtained as forwardable, so the front end cannot forward it to the target | Confirm the user's ticket carries the forwardable flag, check the Kerberos realm policy for forwardable tickets, and retest with a fresh login |
| Delegation works on one FreeIPA release but not another | The front end was configured for the general model while the target expects resource-based rules, or the reverse | Identify which model the target release and your configuration use, align both sides to one model, and test on a non-production copy first |
| Authorization fails after delegation succeeds | The delegated identity is correct, but the back end's access rules do not allow that user or group | Check HBAC and service-side authorization for the delegated user, not only the ticket exchange, and confirm group membership in the directory |
Questions buyers ask before delegating access to FreeIPA services
How much effort does constrained delegation setup take in FreeIPA?
Effort depends mainly on how many tiers a request passes through, how many back-end services must accept delegated tickets, and which delegation model your release supports. A single front end calling one service is a small job. A web tier, an API tier and several file or database back ends multiply the service principals, delegation targets and test cases. General constrained delegation has been available since FreeIPA 3.0.0. The resource-based model is described in a design document, so confirm in the release notes for your version whether it is usable before you size the work. Each back-end service also needs its own review of which principals may delegate to it, and each change needs a test with a test user account.
Can our in-house team build constrained delegation without a partner?
Yes, if the team already runs Kerberos and FreeIPA in production. The work involves service principals, keytabs, ticket settings, DNS naming, time synchronization and access rules on the back-end services, plus configuration of the front-end application. Most of the risk sits in the access rules. A misconfigured delegation right can let a front end act for any user against a service that should only serve a narrow group. An internal team usually needs someone who can read Kerberos traces, someone who owns the application, and someone who can write the test plan. If one of those skills is missing, a fixed-scope engagement can cover the gap while your staff keep ownership of the policy.
How long does a constrained delegation project take?
Duration depends on the written scope, so no general figure applies. The main inputs are the number of tiers, the number of back-end services, the state of the existing FreeIPA deployment, and whether test users and test hosts already exist. Most DeployOpen engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. To compare offers, ask each provider to list the hosts, services, delegation paths, test cases and change windows it assumes. A timeline without that list cannot be checked against your environment.
What does our team need to provide for a delegation engagement?
The engagement needs several inputs from your side before build work can start:
- Named hosts with fully qualified names for the front end, each back-end service and the FreeIPA servers.
- DNS records for those hosts, and client resolver settings that point to at least two DNS servers, as FreeIPA's deployment recommendations advise.
- Time synchronization on every host, since Kerberos rejects tickets when clocks drift.
- A named policy owner who approves which front ends may act for users against which services.
- Test users and test groups that match real access patterns, plus an administrator account for FreeIPA changes.
- A change window on each affected server, so that rollback steps can be rehearsed.
Does DeployOpen issue a compliance certificate or audit report for delegation?
No. DeployOpen does not issue audit reports, attestations or certifications. The work prepares systems, controls and evidence, such as delegation configuration exports, a record of which services accept delegated tickets, access rule documentation and test results. Independent auditors and certification bodies review that evidence and issue their own reports. Before the work starts, ask your auditor which evidence format and sampling approach they expect, so the delegation records can be produced in that form.
What usually goes wrong with delegated Kerberos tickets?
Four failure patterns recur. Clock skew between hosts causes ticket rejections that look like authentication faults. Host names that do not match the service principal name cause lookups to fail, often after a DNS change. Missing or outdated keytabs stop the front end from obtaining its own ticket. Broad delegation rights let a front end reach services it never needed, which widens the impact of a compromised web tier. Test each delegation path with a test user from each group, check time sync and DNS before tuning the application, and confirm that a denied request is logged on the back end.
Should we choose general or resource-based constrained delegation?
The choice depends on who should control the delegation right and which release you run. In general constrained delegation, the right sits on the front-end principal and names the services it may reach, so administrators who manage that principal decide the paths. In resource-based designs, the back-end service declares which front ends may act for users against it, so the team that owns the service controls its own access. FreeIPA has supported general constrained delegation since version 3.0.0. For resource-based constrained delegation, read the FreeIPA design document on resource-based constrained delegation and confirm with your release notes whether your version supports it before you commit to that model.
How DeployOpen scopes and delivers FreeIPA delegation work
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and treats FreeIPA constrained delegation as a scoped piece of that work. We start by mapping which front ends need to act for users, which back-end services they call, and who should control each delegation right before any configuration changes.
How we scope
- Inventory each front-end service that must obtain tickets on behalf of users and the back-end services it calls.
- Decide between general constrained delegation and resource-based constrained delegation for each service pair, and record who controls each setting.
- Agree the scope in writing before work starts, since most engagements are fixed-scope with deliverables and timelines listed.
How we build
- Create service principals and keytabs for each front end and back end, with access limited to the hosts that run them.
- Configure delegation rules in a test realm that mirrors your production FreeIPA topology before any production change.
- Test impersonation paths for both allowed and denied cases, and confirm that unintended services cannot receive forwarded tickets.
How we hand over
- Deliver a written record of each delegation rule, its owner, the principals involved and the approval path for future changes.
- Document the verification steps and expected results so your team can rerun them after upgrades or host changes.
- Walk your platform and security teams through the runbook covering key rotation, removal of rules and troubleshooting.
How we support
- Review delegation rules when FreeIPA releases affect Kerberos or service principal behavior, and plan changes with you.
- Offer ongoing support and upgrades as a retainer for teams that want continued help after handover.
- Confirm support terms, response expectations and included testing with DeployOpen before the retainer starts.
