This ticket is to allow to manage issuance of a Kerberos TGS for a principal on the server side depending on different factors.
We already have related tickets: - #433 - Implement authorization decisions in the KDC for the TGS operation.[[BR]] This ticket calls for restricting access to some services for some principals. - #3659 - [RFE] Add policies to define which principals can make specific TGS requests is very similar - Current ticket should also factor OTP. If the authentication was a 2FA the ticket might be issued but if not then no ticket might be issued.
In general all three tickets are sort of a part of the same feature: principal can not accesses services set X at all, can access set Y with password only and set Z with OTP based authentication.
One thing we need to care about is password based authentication which is used in many cases either as a fallback or instead of native kerberos authentication.
When we so password based auth (especially via PAM) we do not currently try to request a TGS for the service, so we may end up working around these rules.
In PAM we dop make a TGS call (for validation) but that's usually a ticket for the host/fqdn@REALM principal and not the specific service principal.
One way to implicitly check is to do validation against the specific service key. This requires configuration in the pam module (pam_krb5) or sssd to match a service with a specific key (and also point out where the keytab for that service is). Done that way password auth would fail unless a TGS from client to the service is allowed.
Alternatively we could request a TGS for the specific service after the auth phase in the access stack.
Can't we use HBAC for this? We already have service as a input to PAM. mod_intercept_form_submit has a configurable service name that it passes in so we might not need to do anything other then use standard HBAC rules.
Are you suggesting the KDC uses HBAC as a source to find out when to allow TGS requests ?
How do yuou know how many factors were used in an HBAC request ?
And how do you define factors in the HABC rule ?
OK, let us step back. May be we are talking about different workflows.
If we implement 1. we might want to create automatic HBAC rules that match the kerberos policy (something using managed entry plugin may be). This is IMO implementation detail. My point is that 2. is already possible with the existing technologies.
Replying to [comment:4 dpal]:
My point is that 2. is already possible with the existing technologies.
YUes but it requires the admin to "synchronize" HBAC vs TGS policies, also I see no clear way in HBAC to tell "accept 2FA auth but deny single factor" if both are allowed on a network.
YUes but it requires the admin to "synchronize" HBAC vs TGS policies,
Right but it should not be a big problem. If this is a problem then we can do some HBAC rule auto management to match HBAC with KDC policy. Do not want to design, just through some ides out. Best approach TBD.
also I see no clear way in HBAC to tell "accept 2FA auth but deny single factor" if both are allowed on a network.
This is a good point. We do not have a way to say that user must use OTP to log into host A and not into host B. IMO this is a separate ticket that needs to filed. If you agree I will fork it out.
Initially planned for FreeIPA 4.2.
Push out to same bucket as #433.
Metadata Update from @dpal: - Issue assigned to someone - Issue set to the milestone: FreeIPA 4.5 backlog
Handled by auth indicators, marking fixed.
Metadata Update from @rcritten: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.