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.

1. User authenticates using kerberos and gets TGT on his machine. He navigates to the service that is kerberized. The request for TGS is sent to KDC. KDC checks its policy and issues the TGS if the user is allowed to access the service. This is this ticket.
2. If service need a fallback and password authentication it can be configured to use other modules as described here http://www.freeipa.org/page/Web_App_Authentication . One of the modules is mod_intercept_form_submit that will go to SSSD to do PAM auth. SSSD will enforce HBAC if the user authentication is not allowed against a specific service. This is the case that you were talking about. No?

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.

Handled by auth indicators, marking fixed.