1

Let me start from describing my real goal, because I am not sure that I am trying to solve it in a proper way =)

I am simply trying to make my web application obtain Kerberos credentials on behalf of the user who logs in. The webserver is part of my Linux domain (enrolled with FreeIPA / RedHat IdM). The client is external, but the user exists in my domain. So what I want to achieve is this:

  1. The user browses to my webapp and enters his username/password (in a custom login form)
  2. The webapp validates the username/password against FreeIPA
  3. The webapp obtains Kerberos credentials on behalf of the logged in user, so that (for example) the webapp can now display the user's vaults or perform some privileged tasks on FreeIPA (which requires Kerberos authentication to it).

So far, I played with mod_intercept_form_submit, and I was able to authenticate the user against FreeIPA, using pam_sss.so (PAM + SSSD). This worked fine, but I couldn't find a TGT obtained for the user, so I couldn't accomplish the item 3.

Alternatively, I could probably use GSSAPI authentication on Apache, but since the client is not enrolled in the domain, this would display a system login form (while ideally I'd like to use the custom login form from the webapp).

Alternatively, I think the webapp could just bluntly take the password from the login form and run kinit <username> with it, directly on the webserver.

What would be your recommended way? Because I feel like there must be something elegant... E.g. if PAM would just obtain Kerberos TGT for me, and my webapp would be able to access it after the login, that would be great...

1 Answers1

0

I wonder if you really need a TGT in the web application for the subsequent operations against vault or FreeIPA. It seems that Kerberos service ticket should be enough.

For that, using S4U2Proxy and S4U2Self might be the best approach. The mod_auth_gssapi module supports them via GssapiUseS4U2Proxy and GssapiImpersonate directives. In fact, FreeIPA's WebUI is using the very same mechanism when operating against its LDAP backend.

  • Hi Jan, thanks for the direction! One question though... doesn't `mod_auth_gssapi` work only when the client is also part of the domain (so that its browser can negotiate)? How is the connection done between `mod_auth_gssapi` and the custom login form? I guess, the same problem is solved by FreeIPA WebUI, but at least in their Apache configs I don't see how (so maybe the processing of the login form is done by the FreeIPA code, not by Apache means?) – Dmitry Perets Mar 18 '19 at 11:40
  • Not for `GssapiImpersonate` -- you can get the service ticket based just on the principal name (provided permissions for that are configured) because the assumption is that the authentication happened via some other means, precisely because the client might not be in the Kerberos domain. After all, you can authenticate via login + password on FreeIPA's logon page, from client which is not in the same realm. – Jan Pazdziora Mar 19 '19 at 14:36