Foreman and mod auth kerb » History » Revision 12
Revision 11 (Jan Pazdziora, 10/31/2013 08:55 AM) → Revision 12/17 (Jan Pazdziora, 12/10/2013 08:25 AM)
{{>toc}}
h1. Foreman and mod_auth_kerb
Setting up SPNEGO/GSSAPI/Negotiate authentication in Foreman 1.4-to-be. 1.3.
h2. Foreman 1.4-to-be (develop as of December 2013) 1.3
Stock Foreman 1.4 will have support for 1.3 can be configured to use SPNEGO/GSSAPI/Negotiate authentication.
We need mod_auth_kerb installed on the Foreman machine.
We assume the Foreman machine is IPA-enrolled:
<pre>
# ipa-client-install
</pre>
On the IPA server, we create the service:
<pre>
# ipa service-add HTTP/<the-foreman-hostname>
</pre>
On the Foreman machine, we get the keytab for the service:
<pre>
# ipa-getkeytab -s ipa.example.com -k /etc/http.keytab -p HTTP/$( hostname )
# chown apache /etc/http.keytab
# chmod 600 /etc/http.keytab
</pre>
On the Foreman machine, we install mod_auth_kerb:
<pre>
# yum install -y mod_auth_kerb
</pre>
On the Foreman machine, we configure it to be used by Apache:
<pre>
# to /etc/httpd/conf.d/auth_kerb.conf add
<Location /users/extlogin> />
AuthType Kerberos
AuthName "Kerberos Login"
KrbMethodNegotiate On
KrbMethodK5Passwd Off
KrbAuthRealms EXAMPLE.COM
Krb5KeyTab /etc/http.keytab
KrbLocalUserMapping On
require valid-user
ErrorDocument 401 '<html><meta http-equiv="refresh" content="0; URL=/users/login"><body>Kerberos authentication did not pass.</body></html>'
# The following is needed as a workaround for https://bugzilla.redhat.com/show_bug.cgi?id=1020087
ErrorDocument 500 '<html><meta http-equiv="refresh" content="0; URL=/users/login"><body>Kerberos authentication did not pass.</body></html>'
</Location>
</pre>
On the Foreman machine, we tell Foreman that it is OK to trust the authentication done dome by Apache:
<pre>
# to /etc/foreman/settings.yaml add
:authorize_login_delegation: true
:login_delegation_logout_url: /
:authorize_login_delegation_auth_source_user_autocreate: External
</pre>
On Foreman machine, restart Apache:
<pre>
# service httpd restart
</pre>
Now in your browser, if you kinit to obtain a ticket, accessing Foreman's WebUI should not ask for login/password and should display the authenticated dashboard directly. If
h2. The problems with the user was just created, page asking above approach
h3. It authenticates too much
Some of the locations in Foreman might need the authentication disabled and the proposed <Location /> will cover them all. They need to be identified and exceptions added to Apache configuration
h3. Two HTTP requests for each click
This configuration will force the email address of this new user negotiation to happen for every access to the WebUI -- first with 401 result, then second request with negotiation result with result 200.
h3. Users have to be defined in Foreman's database
h2. Possible solutions
h3. Separate logon location /users/extlogin
The solution to the first two problems will likely be shown. in only enabling the authentication for some logon location. That will however require some code changes. The /users/login cannot be used because in Foreman 1.3, there is
<pre>
app/controllers/users_controller.rb: skip_before_filter :require_login, :authorize, :session_expiry, :update_activity_time, :set_taxonomy, :set_gettext_locale_db, :only => [:login, :logout]
</pre>
so even if we'd use @<Location /users/login>@, the @require_login@ (== authenticate) would not be run and REMOTE_USER would not be consumed.
Pull request https://github.com/theforeman/foreman/pull/958 (https://github.com/adelton/foreman/commit/77bd5cde7bf530ca13127816b344fe0ce8de2a1c) was opened against Foreman. With these patches and the configuration of the mod_auth_kerb changed to
<pre>
<Location /users/extlogin>
AuthType Kerberos
AuthName "Kerberos Login"
KrbMethodNegotiate On
KrbMethodK5Passwd Off
KrbAuthRealms EXAMPLE.COM
Krb5KeyTab /etc/http.keytab
KrbLocalUserMapping On
require valid-user
ErrorDocument 401 '<html><meta http-equiv="refresh" content="0; URL=/users/login"><body>Kerberos authentication did not pass.</body></html>'
# The following is needed as a workaround for https://bugzilla.redhat.com/show_bug.cgi?id=1020087
ErrorDocument 500 '<html><meta http-equiv="refresh" content="0; URL=/users/login"><body>Kerberos authentication did not pass.</body></html>'
</Location>
</pre>
the user's browser is redirected to /users/extlogin where the SPNEGO authentication is tried, and if it fails, normal /users/login method is used. After the SPNEGO authentication, normal Foreman session is created and used and since the rest of the Foreman WebUI is not covered by any AuthType, the negotiation does not happen again.
The patches support /users/extlogin not being configured properly, session expiration, and session logout.
The setting
<pre>
:login_delegation_logout_url: /
</pre>
is not longer needed/used.
h3. Disabling auto-creation Auto-creation of externally authentication users
If only already existing Latest updates to https://github.com/theforeman/foreman/pull/967 contain code which allows previously unseen users should to be allowed to log in, remove/comment out the line automatically created. It gets enabled in /etc/foreman/settings.yaml via
<pre>
:authorize_login_delegation: true
:authorize_login_delegation_auth_source_user_autocreate: External
</pre>
from /etc/foreman/settings.yaml. where the authorize_login_delegation_auth_source_user_autocreate is the name of auth_source to be used as target for these new users.
With the current code, only the login is populated, so upon login, the user is redirected to the Edit User page where at least the email address needs to be filled.
h3. Namespace separation
If clear namespace separation of internally and externally authenticated users is desired, the KrbLocalUserMapping should be off:
<pre>
# in /etc/httpd/conf.d/auth_kerb.conf use
<Location /users/extlogin>
AuthType Kerberos
...
KrbLocalUserMapping Off
</Location>
</pre>
Then the @REALM would be part of the username and it would be clear that bob is INTERNAL-authenticated and bob@EXAMPLE.COM is different user, EXTERNAL-authenticated. The admin then can manually create another admin@EXAMPLE.COM user (with administrator privileges) and even the admin can use Kerberos.
h2. This work
See "older version of this page":http://projects.theforeman.org/projects/foreman/wiki/Foreman_and_mod_auth_kerb/11 for the original situation in Foreman 1.3.