Kerberos Ticket Policy

There is a single Kerberos ticket policy. This policy defines the maximum ticket lifetime and the maximum renewal age, the period during which the ticket is renewable.

You can also create a per-user ticket policy by specifying the user login.

For changes to the global policy to take effect, restarting the KDC service is required, which can be achieved using:

service krb5kdc restart

Changes to per-user policies take effect immediately for newly requested tickets (e.g. when the user next runs kinit).

Ticket Lifetime Jitter: To avoid overwhelming the KDC with simultaneous renewal requests, all TGT lifetimes are varied slightly. The KDC reduces actual lifetimes by up to one hour from the configured maximum lifetime (per policy). This means a ticket configured with a 24-hour maximum lifetime may actually be issued with a lifetime between 23-24 hours. Significantly shorter requested lifetimes (less than a few hours) will be unaffected by jitter.

EXAMPLES

Display the current Kerberos ticket policy:

ipa krbtpolicy-show

Reset the policy to the default:

ipa krbtpolicy-reset

Modify the policy to 8 hours max life, 1-day max renewal:

ipa krbtpolicy-mod —maxlife=28800 —maxrenew=86400

Display effective Kerberos ticket policy for user ‘admin’:

ipa krbtpolicy-show admin

Reset per-user policy for user ‘admin’:

ipa krbtpolicy-reset admin

Modify per-user policy for user ‘admin’:

ipa krbtpolicy-mod admin —maxlife=3600

Commands

krbtpolicy-mod

Usage: ipa [global-options] krbtpolicy-mod [USER] [options]

Modify Kerberos ticket policy.

Arguments

Argument Required Description

---

USER no Manage ticket policy for specific user

Options

Option	Description
--maxlife MAXLIFE	Maximum ticket life (seconds)
--maxrenew MAXRENEW	Maximum renewable age (seconds)
--otp-maxlife OTP-MAXLIFE	OTP token maximum ticket life (seconds)
--otp-maxrenew OTP-MAXRENEW	OTP token ticket maximum renewable age (seconds)
--radius-maxlife RADIUS-MAXLIFE	RADIUS maximum ticket life (seconds)
--radius-maxrenew RADIUS-MAXRENEW	RADIUS ticket maximum renewable age (seconds)
--pkinit-maxlife PKINIT-MAXLIFE	PKINIT maximum ticket life (seconds)
--pkinit-maxrenew PKINIT-MAXRENEW	PKINIT ticket maximum renewable age (seconds)
--hardened-maxlife HARDENED-MAXLIFE	Hardened ticket maximum ticket life (seconds)
--hardened-maxrenew HARDENED-MAXRENEW	Hardened ticket maximum renewable age (seconds)
--idp-maxlife IDP-MAXLIFE	External Identity Provider ticket maximum ticket life (seconds)
--idp-maxrenew IDP-MAXRENEW	External Identity Provider ticket maximum renewable age (seconds)
--passkey-maxlife PASSKEY-MAXLIFE	Passkey ticket maximum ticket life (seconds)
--passkey-maxrenew PASSKEY-MAXRENEW	Passkey ticket maximum renewable age (seconds)
--setattr SETATTR	Set an attribute to a name/value pair. Format is attr=value.
--addattr ADDATTR	Add an attribute/value pair. Format is attr=value. The attribute
--delattr DELATTR	Delete an attribute/value pair. The option will be evaluated
--rights	Display the access rights of this entry (requires —all). See ipa man page for details.
--all	Retrieve and print all attributes from the server. Affects command output.
--raw	Print entries as stored on the server. Only affects output format.

krbtpolicy-reset

Usage: ipa [global-options] krbtpolicy-reset [USER] [options]

Reset Kerberos ticket policy to the default values.

Arguments

Argument Required Description

---

USER no Manage ticket policy for specific user

Options

Option	Description
--all	Retrieve and print all attributes from the server. Affects command output.
--raw	Print entries as stored on the server. Only affects output format.

krbtpolicy-show

Usage: ipa [global-options] krbtpolicy-show [USER] [options]

Display the current Kerberos ticket policy.

Arguments

Argument Required Description

---

USER no Manage ticket policy for specific user

Options

Option	Description
--rights	Display the access rights of this entry (requires —all). See ipa man page for details.
--all	Retrieve and print all attributes from the server. Affects command output.
--raw	Print entries as stored on the server. Only affects output format.

Use Cases

Setting Shorter Ticket Lifetimes for Security Compliance

Organizations with strict security requirements reduce default Kerberos ticket lifetimes to limit exposure if tickets are compromised.

# View current global policy
ipa krbtpolicy-show

# Set global policy to 4-hour max life, 12-hour renewable
ipa krbtpolicy-mod --maxlife=14400 --maxrenew=43200

# Restart KDC for global changes to take effect
systemctl restart krb5kdc

# Verify new policy
ipa krbtpolicy-show

Configuring Per-User Extended Ticket Lifetimes

Service accounts or administrators requiring longer-lived tickets receive custom per-user policies without affecting global defaults.

# Set extended lifetime for service account
ipa krbtpolicy-mod svc_automation --maxlife=86400 --maxrenew=604800

# Verify per-user policy
ipa krbtpolicy-show svc_automation

# User policy takes effect immediately on next kinit
# Service account can now get 24-hour tickets, renewable for 7 days

Implementing Stricter Policies for OTP Authentication

Two-factor authentication using OTP tokens warrants shorter ticket lifetimes to enforce frequent re-authentication with second factor.

# Set shorter lifetimes for OTP-based tickets
ipa krbtpolicy-mod --otp-maxlife=3600 --otp-maxrenew=7200

# Restart KDC
systemctl restart krb5kdc

# Users authenticating with OTP get 1-hour tickets, renewable for 2 hours

Resetting Policy After Testing Custom Settings

After testing custom ticket policies, administrators reset to default values to restore standard behavior.

# Reset global policy to defaults
ipa krbtpolicy-reset

# Reset per-user policy to inherit from global
ipa krbtpolicy-reset username

# Restart KDC after global reset
systemctl restart krb5kdc

Configuring PKINIT-Specific Ticket Lifetimes

Smart card authentication via PKINIT justifies longer ticket lifetimes due to stronger authentication mechanism.

# Set longer lifetimes for PKINIT (smart card) authentication
ipa krbtpolicy-mod --pkinit-maxlife=86400 --pkinit-maxrenew=604800

# Restart KDC
systemctl restart krb5kdc

# Smart card users get 24-hour tickets, renewable for 7 days
# while password users follow default policy

Implementing Hardened Policy for Privileged Users

Administrators and privileged accounts receive shortened ticket lifetimes requiring frequent re-authentication.

# Set per-user policy for admin account
ipa krbtpolicy-mod admin --maxlife=7200 --maxrenew=14400

# Policy effective immediately for admin's next kinit
# Admin tickets last 2 hours, renewable to 4 hours

# Verify admin-specific policy
ipa krbtpolicy-show admin

Viewing Effective Policy for Troubleshooting

When investigating authentication issues, administrators check effective policy to understand ticket lifetime behavior.

# Check global default policy
ipa krbtpolicy-show

# Check specific user's effective policy
ipa krbtpolicy-show jsmith

# Output shows if user has custom policy or inherits global default
# Helps diagnose ticket expiration timing issues

Setting External IdP-Specific Ticket Lifetimes

Organizations using external identity providers configure appropriate ticket lifetimes matching IdP session characteristics.

# Set policy for external IdP authentication
ipa krbtpolicy-mod --idp-maxlife=28800 --idp-maxrenew=86400

# Restart KDC
systemctl restart krb5kdc

# External IdP authenticated users get 8-hour tickets, renewable for 24 hours

Configuring Passkey Authentication Ticket Policy

FIDO2/WebAuthn passkey authentication can justify extended lifetimes due to strong cryptographic authentication.

# Set policy for passkey authentication
ipa krbtpolicy-mod --passkey-maxlife=43200 --passkey-maxrenew=259200

# Restart KDC
systemctl restart krb5kdc

# Passkey users get 12-hour tickets, renewable for 3 days

Aligning Ticket Lifetime with Business Hours

Organizations can configure ticket lifetimes matching typical work shifts to balance security and user experience.

# Set policy matching 8-hour workday plus buffer
ipa krbtpolicy-mod --maxlife=32400 --maxrenew=43200

# Restart KDC
systemctl restart krb5kdc

# Tickets last 9 hours, renewable to 12 hours
# Covers full workday without frequent re-authentication

Security Considerations

Extended Ticket Lifetimes Increase Credential Theft Window

Longer ticket lifetimes provide attackers more time to use stolen credentials. Tickets extracted from compromised systems or captured from network traffic remain valid for the entire maxlife period. Extended renewable periods allow attackers to maintain access through ticket renewal without re-authentication.

Set maxlife to minimum duration supporting operational needs. For interactive users, 8-10 hours typically sufficient. For service accounts requiring extended access, use Kerberos keytabs instead of long-lived tickets. Implement monitoring detecting unusual ticket usage patterns. Document justification for any maxlife exceeding 24 hours. Consider network segmentation and encryption to reduce credential theft opportunities.

Per-User Policy Overrides Create Inconsistent Security Posture

Custom per-user ticket policies create security exceptions that may not receive proper scrutiny. Service accounts with extended lifetimes bypass global security controls. Tracking which users have custom policies becomes difficult as exceptions accumulate over time.

Maintain inventory of all per-user policies: regularly query ipa krbtpolicy-show for known special accounts. Require approval and documentation for per-user policy exceptions. Periodically audit per-user policies for continued necessity: ipa user-find --all | grep krb. Prefer service account keytabs over extended ticket lifetimes. Implement expiration dates for temporary policy exceptions.

Global Policy Changes Require KDC Restart

Modifying global Kerberos ticket policy requires restarting krb5kdc service, causing brief authentication service interruption. Unplanned restarts during business hours disrupt operations. In environments without HA KDC configuration, restart creates single point of failure window.

Schedule global policy changes during maintenance windows. Implement redundant KDC servers for high availability. Test policy changes in non-production before production deployment. Document KDC restart requirement in change procedures. Use rolling restart procedures in multi-server KDC deployments. Monitor KDC availability during and after restart.

Short Ticket Lifetimes Cause Operational Disruption

Overly aggressive short ticket lifetimes cause frequent re-authentication interruptions. Automated processes and scripts may fail when tickets expire mid-execution. User productivity suffers from constant kinit prompts. Help desk tickets increase due to authentication failures.

Balance security and usability when setting lifetimes. Test proposed policies with representative user workflows before production deployment. Educate users about ticket renewal: kinit -R extends tickets without password. Configure applications to handle ticket expiration gracefully. For automated processes, use keytabs or renewable tickets with k5start/krenew tools.

Authentication Method-Specific Policies May Bypass Intent

Setting different policies for OTP, PKINIT, passkey, etc., creates complexity where users can bypass stricter policies by choosing different authentication methods. Attackers understanding policy differences may prefer weaker authentication paths with longer ticket lifetimes.

Ensure authentication method-specific policies align with actual security of each method. Document rationale for different policies by authentication method. Monitor authentication method usage to detect attempts to bypass stricter policies. Consider whether all authentication methods should have similar policies. Implement controls preventing users from arbitrarily choosing authentication methods.

Policy Modification Without Testing Breaks Applications

Reducing ticket lifetimes without testing breaks long-running applications, batch jobs, and automated processes expecting longer-lived tickets. Applications lacking proper ticket renewal logic fail when tickets expire earlier than previously. Emergency rollback of policy changes requires KDC restart causing additional disruption.

Test policy changes in non-production environments matching production workloads. Identify applications depending on current ticket lifetimes before changes. Gradually reduce lifetimes in multiple steps rather than drastic single change. Implement monitoring detecting ticket expiration errors after policy changes. Maintain rollback procedures including KDC restart. Document current policy as baseline for troubleshooting.

Maximum Renewable Age Less Than Max Life Creates Confusion

Misconfiguring maxrenew less than maxlife means tickets cannot be renewed at all. This configuration appears to work initially but causes confusion when users attempt ticket renewal. Documentation often assumes maxrenew exceeds maxlife, but IPA doesn’t enforce this relationship.

Ensure maxrenew always greater than maxlife: renewable period should extend beyond initial lifetime. Typical ratio is maxrenew = 3-10x maxlife. Validate policy math: if maxlife=8 hours, maxrenew should be 24 hours or more. Document renewal workflow expectations. Test ticket renewal with new policies: kinit -R should succeed before initial ticket expires.

Per-User Policy Reset Doesn’t Immediately Remove Policy

Using krbtpolicy-reset for a user removes custom policy but user’s current ticket retains old policy until expiration. Administrators expecting immediate policy change may be confused when old policy continues affecting active tickets.

Inform users to destroy current tickets and re-authenticate after policy changes: kdestroy && kinit. Document that active tickets reflect policy at time of issuance, not current policy. For immediate effect, expire user’s tickets centrally if capability exists. Consider communication plan when resetting user policies. Test that new tickets reflect reset policy.

RADIUS Policy Settings Rarely Used Create Confusion

RADIUS-specific ticket policy options exist but are rarely applicable in most deployments. Administrators may misunderstand these settings or set them unnecessarily. Misconfigured RADIUS policies affect users authenticating via RADIUS proxy but not others, creating inconsistent behavior.

Configure RADIUS-specific policies only if RADIUS authentication is actually deployed. Document which authentication paths use which policy settings. Test RADIUS authentication with configured policies. Leave RADIUS settings at defaults unless specific RADIUS use case requires customization. Clearly label RADIUS-specific settings in documentation to prevent confusion.

Policy Visibility Restricted by Permissions

While viewing ticket policy seems administrative, overly restrictive permissions may prevent troubleshooting. Users unable to view effective policy can’t understand ticket expiration behavior. Help desk staff lacking policy viewing rights cannot effectively troubleshoot authentication issues.

Allow authenticated users to view global policy: no sensitive information in ticket lifetimes. Permit users to view their own per-user policy if exists. Grant help desk appropriate permissions to view ticket policies for troubleshooting. Document which roles can view vs modify policies. Audit permission grants ensuring appropriate access.

Policy Doesn’t Affect Existing Tickets

Ticket policy only affects newly issued tickets, not existing tickets. After modifying policy, users with active tickets continue using old policy until current ticket expires. This delay between policy change and full enforcement creates temporary security gaps or extended user disruptions.

Communicate to users that policy changes require new tickets: recommend kdestroy && kinit. Document policy change effective time = max current ticket lifetime. For security-critical policy tightening, consider forcing ticket expiration across environment. Test policy enforcement with newly requested tickets. Monitor for users still using tickets issued before policy change.

Troubleshooting

Global Policy Changes Not Taking Effect

Symptom: Modified global Kerberos ticket policy using krbtpolicy-mod but users still receiving tickets with old lifetimes.

Diagnosis: Verify KDC service was restarted after policy change. Check if users have existing tickets issued before policy change. Review actual policy configuration: ipa krbtpolicy-show. Verify change replicated to all KDC servers in multi-server deployments.

Resolution: Restart KDC service on all servers: systemctl restart krb5kdc. Instruct users to destroy and recreate tickets: kdestroy && kinit. Verify policy change: ipa krbtpolicy-show. Check ticket details: klist -f to see current ticket lifetimes. Wait for old tickets to expire if immediate refresh not needed. Force replication if multi-server: ipa-replica-manage force-sync.

Per-User Policy Not Effective

Symptom: Set custom ticket policy for specific user but user still receiving default policy tickets.

Diagnosis: Verify per-user policy exists: ipa krbtpolicy-show username. Check exact username spelling. Verify user obtained new ticket after policy change. Review if user has active ticket from before policy modification.

Resolution: Confirm policy set correctly: ipa krbtpolicy-show username should show custom values. User must destroy old tickets: kdestroy && kinit. Verify username matches exactly: ipa user-show username. Check ticket details: klist -f shows current ticket lifetime. If policy reset recently, verify reset completed successfully. Re-apply policy if needed: ipa krbtpolicy-mod username --maxlife=value.

Cannot View Ticket Policy Due to Permissions

Symptom: Running krbtpolicy-show fails with insufficient permissions or access denied error.

Diagnosis: Verify user authentication: klist for valid Kerberos ticket. Check user permissions and roles: ipa user-show $(whoami) --all. Confirm connection to IPA server. Review if custom ACIs restrict policy viewing.

Resolution: Authenticate if no ticket: kinit username. Policy viewing should be available to authenticated users. Check admin group membership if needed: ipa group-show admins. Use admin account for troubleshooting: kinit admin. Review permission settings: ipa permission-find krbt. Contact IPA administrators if custom permissions blocking access.

KDC Restart Fails After Policy Modification

Symptom: After modifying ticket policy and attempting KDC restart, service fails to start or restart command errors.

Diagnosis: Check KDC logs: /var/log/krb5kdc.log for errors. Review Kerberos configuration: /var/kerberos/krb5kdc/kdc.conf. Verify LDAP connectivity for KDC. Check for syntax errors in policy values.

Resolution: Review KDC logs for specific error messages. Verify policy values are reasonable: maxlife and maxrenew should be positive integers in seconds. Check LDAP backend accessibility: ldapsearch -Y GSSAPI -b "dc=example,dc=com". Validate Kerberos database integrity: kdb5_util dump /tmp/dump.txt. If policy values invalid, reset to defaults: ipa krbtpolicy-reset. Restore from backup if KDC corrupted. Check filesystem permissions on Kerberos database files.

Ticket Policy Shows Wrong Values

Symptom: Viewing ticket policy shows unexpected values different from what was configured.

Diagnosis: Check if viewing global vs per-user policy: ipa krbtpolicy-show vs ipa krbtpolicy-show username. Verify modification command syntax used correct options. Check if policy was reset after modification. Review command history for actual commands executed.

Resolution: Verify viewing correct policy scope: include or omit username as intended. Check global policy: ipa krbtpolicy-show with no arguments. Check per-user policy: ipa krbtpolicy-show username. Re-apply intended policy: ipa krbtpolicy-mod --maxlife=value --maxrenew=value. Verify values in seconds, not hours (28800 seconds = 8 hours). Document intended policy values before modification attempts.

Policy Reset Doesn’t Restore Default Values

Symptom: After using krbtpolicy-reset, policy still shows non-default values.

Diagnosis: Check if global vs per-user reset: reset command scope. Verify KDC restarted after global policy reset. Review what “default” values actually are: may differ from expectations. Check if policy was modified again after reset.

Resolution: For global reset, restart KDC: systemctl restart krb5kdc. Verify reset successful: ipa krbtpolicy-show should show default values. For per-user reset, check user inherits global: ipa krbtpolicy-show username. Default values typically: maxlife=86400 (24 hours), maxrenew=604800 (7 days). If defaults seem wrong, check IPA installation defaults. May need to manually set expected values rather than relying on reset.

Users Report Frequent Re-Authentication Required

Symptom: After ticket policy modification, users complain about constant kinit prompts and authentication interruptions.

Diagnosis: Check if maxlife set too short: ipa krbtpolicy-show. Verify users understand ticket renewal vs new tickets. Review if applications are properly handling ticket renewal. Check if users configured ticket renewal tools.

Resolution: Review maxlife value: very short lifetimes (< 2 hours) cause frequent re-authentication. Educate users on ticket renewal: kinit -R extends tickets without password. Extend maxlife if too aggressive: ipa krbtpolicy-mod --maxlife=28800 (8 hours). Configure automated ticket renewal: use krenew or k5start for long-running processes. Ensure maxrenew allows sufficient renewal period. Test workflow with new policy before full deployment.

Long-Running Jobs Fail with Ticket Expiration

Symptom: Batch jobs, automated scripts, or long-running processes fail with Kerberos ticket expired errors after policy modification.

Diagnosis: Check ticket lifetimes vs job duration: jobs exceeding maxlife will fail. Verify if jobs use ticket renewal. Review job design: proper Kerberos credential handling. Check logs for ticket expiration timing relative to job execution.

Resolution: Extend ticket lifetimes for service accounts: ipa krbtpolicy-mod svc_account --maxlife=86400. Use Kerberos keytabs instead of tickets: jobs can obtain new tickets as needed. Implement ticket renewal in job scripts: periodic kinit -R or use krenew wrapper. Configure jobs to handle ticket expiration gracefully and retry. Consider breaking long jobs into shorter phases with credential refresh.

Per-User Policy Modification Fails

Symptom: Attempting to set per-user ticket policy fails with errors about user not found or invalid policy.

Diagnosis: Verify user exists: ipa user-show username. Check username spelling and format. Review error message for specific failure reason. Verify policy values are valid: positive integers in seconds.

Resolution: Confirm user exists in IPA: ipa user-show username. Use exact username: case-sensitive. Verify policy values reasonable: --maxlife=28800 --maxrenew=86400. Check permissions to modify user policies: may require admin rights. Ensure maxrenew >= maxlife: renewal period should exceed initial lifetime. Review command syntax: ipa krbtpolicy-mod username --maxlife=value.

Authentication Method-Specific Policy Not Applied

Symptom: Set OTP, PKINIT, or other authentication method-specific policy but users authenticating with that method still getting default policy tickets.

Diagnosis: Verify policy set correctly: ipa krbtpolicy-show --all shows all authentication method policies. Check if users actually authenticating via intended method: OTP, smart card, etc. Review KDC configuration supporting specified authentication method.

Resolution: Verify authentication method-specific policy set: ipa krbtpolicy-show --all | grep method. Restart KDC after setting method-specific policies: systemctl restart krb5kdc. Confirm users using intended authentication method: check KDC logs. Test with specific authentication method: kinit -n for anonymous, smart card for PKINIT. If method not supported, policy won’t apply. Enable and configure authentication method if needed.

Cannot Modify Policy Due to Locked Entry

Symptom: Policy modification fails with error about entry being locked or modification not permitted.

Diagnosis: Check for concurrent modifications: another administrator may be modifying policy. Verify LDAP backend status. Review if custom ACIs restrict policy modification. Check user permissions.

Resolution: Wait and retry modification: concurrent access may cause temporary lock. Verify user has appropriate permissions: admin or policy modification role. Check LDAP server health: systemctl status dirsrv@REALM. Review custom ACIs if implemented: ipa permission-find krbt. Use admin account for troubleshooting: kinit admin. Check for LDAP replication conflicts if multi-server.

Policy Values Appear Converted Incorrectly

Symptom: Set policy in hours but values appear in seconds, or calculations seem wrong when viewing policy.

Diagnosis: Understand that ticket policy uses seconds for all values. Calculate expected seconds: 8 hours = 28800 seconds. Check if viewing raw vs human-readable output. Verify conversion math.

Resolution: All policy values are in seconds: convert hours to seconds (hours * 3600). Use calculator for conversions: 24 hours = 86400 seconds, 7 days = 604800 seconds. Verify calculations when setting policy. Use consistent units in documentation: prefer seconds for precision. Create reference table: common durations in seconds. Double-check math before applying policy changes.