Chapter 33. Managing Kerberos ticket policies
Kerberos ticket policies in Identity Management (IdM) set restrictions on Kerberos ticket access, duration, and renewal. You can configure Kerberos ticket policies for the Key Distribution Center (KDC) running on your IdM server.
This chapter presents the following Kerberos ticket management topics and tasks:
- The role of the IdM KDC
- IdM Kerberos ticket policy types
- Kerberos authentication indicators
- Enforcing authentication indicators for an IdM service
- Configuring the global ticket lifecycle policy
- Configuring global ticket policies per authentication indicator
- Configuring the default ticket policy for a user
- Configuring individual authentication indicator ticket policies for a user
-
Authentication indicator options for the
krbtpolicy-mod
command
33.1. The role of the IdM KDC
Identity Management’s authentication mechanisms use the Kerberos infrastructure established by the Key Distribution Center (KDC). The KDC is the trusted authority that stores credential information and ensures the authenticity of data originating from entities within the IdM network.
Each IdM user, service, and host acts as a Kerberos client and is identified by a unique Kerberos principal:
-
For users:
identifier@REALM
, such asadmin@EXAMPLE.COM
-
For services:
service/fully-qualified-hostname@REALM
, such ashttp/server.example.com@EXAMPLE.COM
-
For hosts:
host/fully-qualified-hostname@REALM
, such ashost/client.example.com@EXAMPLE.COM
The following image is a simplification of the communication between a Kerberos client, the KDC, and a Kerberized application that the client wants to communicate with.

-
A Kerberos client identifies itself to the KDC by authenticating as a Kerberos principal. For example, an IdM user performs
kinit username
and provides their password. - The KDC checks for the principal in its database, authenticates the client, and evaluates Kerberos ticket policies to determine whether to grant the request.
- The KDC issues the client a ticket-granting ticket (TGT) with a lifecycle and authentication indicators according to the appropriate ticket policy.
- With the TGT, the client requests a service ticket from the KDC to communicate with a Kerberized service on a target host.
- The KDC checks if the client’s TGT is still valid, and evaluates the service ticket request against ticket policies.
- The KDC issues the client a service ticket.
- With the service ticket, the client can initiate encrypted communication with the service on the target host.
33.2. IdM Kerberos ticket policy types
IdM Kerberos ticket policies implement the following ticket policy types:
- Connection policy
To protect Kerberized services with different levels of security, you can define connection policies to enforce rules based on which pre-authentication mechanism a client used to retrieve a ticket-granting ticket (TGT).
For example, you can require smart card authentication to connect to
client1.example.com
, and require two-factor authentication to access thetestservice
application onclient2.example.com
.To enforce connection policies, associate authentication indicators with services. Only clients that have the required authentication indicators in their service ticket requests are able to access those services. For more information, see Kerberos authentication indicators.
- Ticket lifecycle policy
Each Kerberos ticket has a lifetime and a potential renewal age: you can renew a ticket before it reaches its maximum lifetime, but not after it exceeds its maximum renewal age.
The default global ticket lifetime is one day (86400 seconds) and the default global maximum renewal age is one week (604800 seconds). To adjust these global values, see Configuring the global ticket lifecycle policy.
You can also define your own ticket lifecycle policies:
- To configure different global ticket lifecycle values for each authentication indicator, see Configuring global ticket policies per authentication indicator.
- To define ticket lifecycle values for a single user that apply regardless of the authentication method used, see Configuring the default ticket policy for a user.
- To define individual ticket lifecycle values for each authentication indicator that only apply to a single user, see Configuring individual authentication indicator ticket policies for a user.
33.3. Kerberos authentication indicators
The Kerberos Key Distribution Center (KDC) attaches authentication indicators to a ticket-granting ticket (TGT) based on which pre-authentication mechanism the client used to prove its identity:
otp
- two-factor authentication (password + One-Time Password)
radius
- RADIUS authentication (commonly for 802.1x authentication)
pkinit
- PKINIT, smart card, or certificate authentication
hardened
- hardened passwords (SPAKE or FAST)[1]
The KDC then attaches the authentication indicators from the TGT to any service ticket requests that stem from it. The KDC enforces policies such as service access control, maximum ticket lifetime, and maximum renewable age based on the authentication indicators.
33.3.1. Authentication indicators and IdM services
If you associate a service or a host with an authentication indicator, only clients that used the corresponding authentication mechanism to obtain a TGT will be able to access it. The KDC, not the application or service, checks for authentication indicators in service ticket requests, and grants or denies requests based on Kerberos connection policies.
For example, to require two-factor authentication to connect to host secure.example.com
, associate the otp
authentication indicator with the host/secure.example.com@EXAMPLE.COM
Kerberos principal. Only users who used a One-Time password to obtain their initial TGT from the KDC will be able to log in.
If a service or a host has no authentication indicators assigned to it, it will accept tickets authenticated by any mechanism.
Additional resources
- To associate an IdM service with authentication indicators, see Enforcing authentication indicators for an IdM service.
33.4. Enforcing authentication indicators for an IdM service
This procedure describes creating an IdM service and configuring it to require particular Kerberos authentication indicators from incoming service ticket requests.
By associating authentication indicators with an IdM service, only clients who used those specific pre-authentication mechanisms to obtain their initial ticket-granting ticket (TGT) will be able to access the service.
33.4.1. Creating an IdM service entry and its Kerberos keytab
Adding an IdM service entry to IdM for a service running on an IdM host creates a corresponding Kerberos principal, and allows the service to request an SSL certificate, a Kerberos keytab, or both.
The following procedure describes creating an IdM service entry and generating an associated Kerberos keytab for encrypting communication with that service.
Prerequisites
- Your service can store a Kerberos principal, an SSL certificate, or both.
Procedure
Add an IdM service with the
ipa service-add
command to create a Kerberos principal associated with it. For example, to create the IdM service entry for thetestservice
application that runs on hostclient.example.com
:[root@client ~]# ipa service-add testservice/client.example.com ------------------------------------------------------------- Modified service "testservice/client.example.com@EXAMPLE.COM" ------------------------------------------------------------- Principal name: testservice/client.example.com@EXAMPLE.COM Principal alias: testservice/client.example.com@EXAMPLE.COM Managed by: client.example.com
Generate and store a Kerberos keytab for the service on the client.
[root@client ~]# ipa-getkeytab -k /etc/testservice.keytab -p testservice/client.example.com Keytab successfully retrieved and stored in: /etc/testservice.keytab
Verification steps
Display information about an IdM service with the
ipa service-show
command.[root@server ~]# ipa service-show testservice/client.example.com Principal name: testservice/client.example.com@EXAMPLE.COM Principal alias: testservice/client.example.com@EXAMPLE.COM Keytab: True Managed by: client.example.com
Display the contents of the service’s Kerberos keytab with the
klist
command.[root@server etc]# klist -ekt /etc/testservice.keytab Keytab name: FILE:/etc/testservice.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96) 2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96) 2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (camellia128-cts-cmac) 2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (camellia256-cts-cmac)
33.4.2. Associating authentication indicators with an IdM service
This procedure describes configuring a service to require particular Kerberos authentication indicators from incoming service ticket requests.
Prerequisites
- You have created an IdM service entry for a service that runs on an IdM host. See Creating an IdM service entry and its Kerberos keytab.
Do not assign authentication indicators to internal IdM services. The following IdM services cannot perform the interactive authentication steps required by PKINIT and multi-factor authentication methods:
host/server.example.com@EXAMPLE.COM HTTP/server.example.com@EXAMPLE.COM ldap/server.example.com@EXAMPLE.COM DNS/server.example.com@EXAMPLE.COM cifs/server.example.com@EXAMPLE.COM
Procedure
Use the
ipa service-mod
command to specify one or more required authentication indicators for a service, identified with the--auth-ind
argument.Authentication method --auth-ind
valueTwo-factor authentication
otp
RADIUS authentication
radius
PKINIT, smart card, or certificate authentication
pkinit
Hardened passwords (SPAKE or FAST)
hardened
For example, to require that a user was authenticated with smart card or OTP authentication to retrieve a service ticket for the
testservice
principal on hostclient.example.com
:[root@server ~]# ipa service-mod testservice/client.example.com@EXAMPLE.COM --auth-ind otp --auth-ind pkinit ------------------------------------------------------------- Modified service "testservice/client.example.com@EXAMPLE.COM" ------------------------------------------------------------- Principal name: testservice/client.example.com@EXAMPLE.COM Principal alias: testservice/client.example.com@EXAMPLE.COM Authentication Indicators: otp, pkinit Managed by: client.example.com
To remove all authentication indicators from a service, provide an empty list of indicators:
[root@server ~]# ipa service-mod testservice/client.example.com@EXAMPLE.COM --auth-ind ''
------------------------------------------------------
Modified service "testservice/client.example.com@EXAMPLE.COM"
------------------------------------------------------
Principal name: testservice/client.example.com@EXAMPLE.COM
Principal alias: testservice/client.example.com@EXAMPLE.COM
Managed by: client.example.com
Verification steps
Display information about an IdM service, including the authentication indicators it requires, with the
ipa service-show
command.[root@server ~]# ipa service-show testservice/client.example.com Principal name: testservice/client.example.com@EXAMPLE.COM Principal alias: testservice/client.example.com@EXAMPLE.COM Authentication Indicators: otp, pkinit Keytab: True Managed by: client.example.com
Additional resources
- To test requesting a service ticket for an IdM service, see Retrieving a Kerberos service ticket for an IdM service.
33.4.3. Retrieving a Kerberos service ticket for an IdM service
The following procedure describes retrieving a Kerberos service ticket for an IdM service. You can use this procedure to test Kerberos ticket policies.
Prerequisites
- If the service you are working with is not an internal IdM service, you have created a corresponding IdM service entry for it. See Creating an IdM service entry and its Kerberos keytab.
- You have a Kerberos ticket-granting ticket (TGT).
Procedure
Use the
kvno
command with the-S
option to retrieve a service ticket, and specify the name of the IdM service and the fully-qualified domain name of the host that manages it.[root@server ~]# kvno -S testservice client.example.com testservice/client.example.com@EXAMPLE.COM: kvno = 1
If you need to access an IdM service and your current ticket-granting ticket (TGT) does not possess the required authentication indicators associated with it, clear your current Kerberos credentials cache with the kdestroy
command and retrieve a new TGT:
[root@server ~]# kdestroy
For example, if you initially retrieved a TGT by authenticating with a password, and you need to access an IdM service that has the pkinit
authentication indicator associated with it, destroy your current credentials cache and re-authenticate with a smart card. See Kerberos authentication indicators.
Verification steps
Use the
klist
command to verify that the service ticket is in the default Kerberos credentials cache.[root@server etc]# klist_ Ticket cache: KCM:1000 Default principal: admin@EXAMPLE.COM Valid starting Expires Service principal 04/01/2020 12:52:42 04/02/2020 12:52:39 krbtgt/EXAMPLE.COM@EXAMPLE.COM 04/01/2020 12:54:07 04/02/2020 12:52:39 testservice/client.example.com@EXAMPLE.COM
33.4.4. Additional resources
- For more information on Kerberos authentication indicators, see Section 33.3, “Kerberos authentication indicators”.
33.5. Configuring the global ticket lifecycle policy
The global ticket policy applies to all service tickets and to users that do not have any per-user ticket policies defined.
The following procedure describes adjusting the maximum ticket lifetime and maximum ticket renewal age for the global Kerberos ticket policy using the ipa krbtpolicy-mod
command.
While using the ipa krbtpolicy-mod
command, specify at least one of the following arguments:
-
--maxlife
for the maximum ticket lifetime in seconds -
--maxrenew
for the maximum renewable age in seconds
Procedure
To modify the global ticket policy:
[root@server ~]# ipa krbtpolicy-mod --maxlife=$((8*60*60)) --maxrenew=$((24*60*60)) Max life: 28800 Max renew: 86400
In this example, the maximum lifetime is set to eight hours (8 * 60 minutes * 60 seconds) and the maximum renewal age is set to one day (24 * 60 minutes * 60 seconds).
Optional: To reset the global Kerberos ticket policy to the default installation values:
[root@server ~]# ipa krbtpolicy-reset Max life: 86400 Max renew: 604800
Verification steps
Display the global ticket policy:
[root@server ~]# ipa krbtpolicy-show Max life: 28800 Max renew: 86640
Additional resources
- To adjust the default ticket policy for a single user, see Configuring the default ticket policy for a user.
- To configure individual ticket policies for each authentication indicator for a single user, see Configuring individual authentication indicator ticket policies for a user.
33.6. Configuring global ticket policies per authentication indicator
This procedure describes adjusting the global maximum ticket lifetime and maximum renewable age for each authentication indicator. These settings apply to users that do not have per-user ticket policies defined.
Use the ipa krbtpolicy-mod
command to specify the global maximum lifetime or maximum renewable age for Kerberos tickets depending on the authentication indicators attached to them.
Procedure
For example, to set the global two-factor ticket lifetime and renewal age values to one week, and the global smart card ticket lifetime and renewal age values to two weeks:
[root@server ~]# ipa krbtpolicy-mod --otp-maxlife=604800 --otp-maxrenew=604800 --pkinit-maxlife=172800 --pkinit-maxrenew=172800
Verification steps
Display the global ticket policy:
[root@server ~]# ipa krbtpolicy-show Max life: 86400 OTP max life: 604800 PKINIT max life: 172800 Max renew: 604800 OTP max renew: 604800 PKINIT max renew: 172800
Notice that the OTP and PKINIT values are different from the global default
Max life
andMax renew
values.
Additional resources
-
For a list of authentication indicator options for the
ipa krbtpolicy-mod
command, see Authentication indicator options for thekrbtpolicy-mod
command. - To adjust the default ticket policy for a single user, see Configuring the default ticket policy for a user.
- To configure individual ticket policies for each authentication indicator for a single user, see Configuring individual authentication indicator ticket policies for a user.
33.7. Configuring the default ticket policy for a user
You can define a unique Kerberos ticket policy that only applies to a single user. These per-user settings override the global ticket policy, for all authentication indicators.
Use the ipa krbtpolicy-mod username
command, and specify at least one of the following arguments:
-
--maxlife
for the maximum ticket lifetime in seconds -
--maxrenew
for the maximum renewable age in seconds
Procedure
For example, to set the IdM
admin
user’s maximum ticket lifetime to two days and maximum renewal age to two weeks:[root@server ~]# ipa krbtpolicy-mod admin --maxlife=172800 --maxrenew=1209600 Max life: 172800 Max renew: 1209600
Optional: To reset the ticket policy for a user:
[root@server ~]# ipa krbtpolicy-reset admin
Verification steps
Display the effective Kerberos ticket policy that applies to a user:
[root@server ~]# ipa krbtpolicy-show admin Max life: 172800 Max renew: 1209600
Additional resources
- To adjust the global ticket policy for all users, see Configuring the global ticket lifecycle policy.
- To configure different default ticket policies per authentication indicator, see Configuring global ticket policies per authentication indicator.
33.8. Configuring individual authentication indicator ticket policies for a user
As an administrator, you can define Kerberos ticket policies for a user that differ per authentication indicator. For example, you can configure a policy to allow the IdM admin
user to renew a ticket for two days if it was obtained with OTP authentication, and a week if it was obtained with smart card authentication.
These per-authentication indicator settings will override the user’s default ticket policy, the global default ticket policy, and any global authentication indicator ticket policy.
Use the ipa krbtpolicy-mod username
command to set custom maximum lifetime and maximum renewable age values for a user’s Kerberos tickets depending on the authentication indicators attached to them.
Procedure
For example, to allow the IdM
admin
user to renew a Kerberos ticket for two days if it was obtained with One-Time Password authentication, set the--otp-maxrenew
option:[root@server ~]# ipa krbtpolicy-mod admin --otp-maxrenew=$((2*24*60*60)) OTP max renew: 172800
Optional: To reset the ticket policy for a user:
[root@server ~]# ipa krbtpolicy-reset username
Verification steps
Display the effective Kerberos ticket policy that applies to a user:
[root@server ~]# ipa krbtpolicy-show admin Max life: 28800 Max renew: 86640
Additional resources
-
For a list of authentication indicator options for the
ipa krbtpolicy-mod
command, see Authentication indicator options for thekrbtpolicy-mod
command. - To adjust the default ticket policy for a single user, see Configuring the default ticket policy for a user.
- To adjust the global ticket policy for all users, see Configuring the global ticket lifecycle policy.
- To configure different global ticket policies per authentication indicator, see Configuring global ticket policies per authentication indicator.
33.9. Authentication indicator options for the krbtpolicy-mod
command
Specify values for authentication indicators with the following arguments.
Table 33.1. Authentication indicator options for the krbtpolicy-mod
command
Authentication indicator | Argument for maximum lifetime | Argument for maximum renewal age |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|