Policies by authentication indicators#
Based on the pre-authentication mechanism a user used to acquire the credential, the KDC can enforce policies such as service access control, user authentication and ticket lifetime/reissue time policies to achieve a finer control over ticket issuance.
Authentication indicators are attached by KDC to tickets issued to user and depend on which pre-authentication mechanism used to acquire the credential. Indicators and corresponding mechanisms are listed below:
Two factor authentication (password + OTP)
Hardened Password (by SPAKE or FAST)
External Identity Provider
Hardened password means a password authentication with either SPAKE or FAST armoring enabled. Although it is possible to assign separate indicators to SPAKE and FAST, when both SPAKE and FAST are used, only the indicator for SPAKE will be applied. Since there is no practical reason to forbid the use of SPAKE while using FAST armoring, these two are assigned the same indicator to represent a brute-force hardened form of password authentication.
By requiring certain authentication indicators to a user, we can force a user to be authenticated with one of the mechanisms associated with those auth indicators to obtain a ticket. By defining an allow list of authentication indicators to a service, we can allow a user to use the service only if the user obtained a ticket with at least one of those indicators included.
For unattended services (services that is a part of the IPA core system), the authentication indicator should not be set,
or it may break the whole system. Examples for such services are
HTTP/* (for webUI and IPA API end-points),
ldap/* (for user data management etc.),
cifs/* (for SMB and DCE-RPC services),
host/* on IPA masters which are used by DCE-RPC services to validate client-server communication.
Available policies and user interface#
Different service may need different security strength and consequently requires different pre-auth mechanism.
e.g. must have used 2FA or OTP in order to connect to
Services with no authentication indicator assigned will accept tickets authenticated by any mechanism.
Administrators can specify required auth indicators for a service via
ipa service-mod command.
ipa service-mod service/@REALM --auth-ind otp --auth-ind pkinit
Administrators can specify required auth indicator on service settings page. As default no auth indicator is specified which means all pre-auth mechanism is accepted.
Ticket lifecycle policy#
Administrators may want to define different ticket expiration and renewal values as well as ticket flags based on the type of the authentication conducted.
e.g. the lifetime of the OTP based ticket can be longer than for a single-factor
Tickets without an authentication indicator will have the default lifetime / renewtime.
Administrators can specify max life and renew for each auth indicator and global default via
ipa krbtpolicy-mod command.
ipa krbtpolicy-mod --otp-maxlife=604800 --pkinit-maxlife=604800
--maxrenew options for
ipa krbtpolicy-mod will set the default max life / renew respectively.
After this, the output for
ipa krbtpolicy-show will look like:
Max life: 86400
OTP max life: 604800
PKINIT max life: 604800
Max renew: 604800
In Policy/Kerberos Ticket Policy tab, there is a table where administrators can specify max renew and life for each supported auth indicator.
Ticket lifetime jitter#
All TGT lifetimes are varied slightly to avoid overwhelming the KDC with simultaneous renewal requests. Jitter will reduce lifetimes by up to one hour from the configured maximum lifetime (per policy). Significantly shorter requested lifetimes will be unaffected.
Kerberos policy, as krb5 presents it, consists of two interfaces: the authentication indicator attributes and the kdcpolicy plugin. Authentication indicator attributes allow us to make boolean access choices (i.e. allow or deny service principal requests) on the KDC based on configuration in the Kerberos Database (KDB). The kdcpolicy plugin is a much more powerful hook, allowing refinement of the request itself rather than a solely boolean decision.
Connection Policy can be implemented with authentication indicator attribute in krb5 alone,
but ticket lifecycle policy will require LDAP to store relations between authentication indicators
and lifetime information. We have global ticket lifetime and renew time setting stored as attribute
krbmaxrenewableage inside the
which represents the default lifetime policy.
Two new multi-valued attributes are added to store an authentication indicator-specific maximum ticket life and ticket’s maximum renewable age. The type of authentication indicator is specified as LDAP attribute option:
They are stored in the same policy object in LDAP.