Tired of log in to your favorite Web application? Integrate it with IPA, kerberize it! This blog post will guide you trough the kerberization of WordPress running on RHEL7 or Fedora. The magic is done by mod_intercept_form_submit and mod_auth_gssapi
- You have a running IPA or FreeIPA infrastructure
- Your Kerberos REALM is EXAMPLE.COM
- The hostname where your WordPress instance is running is wptest.example.com
- WordPress is installed in /var/www/html and ready to run
- You are using a Linux Workstation with Kerberos, other client OS may or may not work
You can log in to your WordPress instance with a Kerberos enabled Web Browser and username/password with Browser not enabled. The access is restricted by HBAC (Host Base Access Control)
Install the required software
root@wptest ~]# yum -y install ipa-client mod_intercept_form_submit mod_auth_gssapi root@wptest ~]# setsebool -P allow_httpd_mod_auth_pam 1 root@wptest ~]# wget https://downloads.wordpress.org/plugin/http-authentication.4.5.zip
Ensure the modules are loaded by Apache, please check the files in /etc/httpd/conf.modules.d/. The WordPress plugin is needed to enable WordPress to make use of the REMOTE_USER server environment. Unzip and place it in /var/www/html/wp-content/plugins/ and run restorecon to relabel the content to be able to use SELinux in enforcing mode.
root@wptest ~]# unzip http-authentication.4.5.zip root@wptest ~]# mv http-authentication /var/www/html/wp-content/plugins/ root@wptest ~]# restorecon -v -R /var/www/html/
Enroll your Linux server
Of course your server must be enrolled with IPA.
root@wptest ~]# ipa-client-install
Get your Kerberos Keytab
First the Kerberos service principal must be created. Go to one of your IPA servers and add the principal.
root@ipa1 ~]# kinit admin root@ipa1 ~]# ipa service-add HTTP/wptest.example.com
Go to the client, fetch the Kerberos Keytab and make it available for Apache
root@wptest ~]# kinit admin root@wptest ~]# ipa-getkeytab -s ipa1.example.com -p HTTP/wptest.example.com -k /etc/httpd/conf/http.keytab root@wptest ~]# chown apache /etc/httpd/conf/http.keytab root@wptest ~]# chmod 600 /etc/httpd/conf/http.keytab
We are going to create a PAM config file called “wordpress” as a requirement for the authentication method used. Remember, you need to use SSSD because want to make use of HBAC.
cat << EOF >> /etc/pam.d/wordpress auth required pam_sss.so account required pam_sss.so EOF
After the configuration of Apache, non-kerberized logins would not work anymore. This is probably not a scenario you want. You will still be able to log in with your IPA credentials, HBAC still works.
The trick is that if Kerberos authentication fails, you will be redirected to a non-kerberized login page.
[root@wptest ~]# cp /var/www/html/wp-login.php /var/www/html/wp-login2.php [root@wptest ~]# sed -i s/wp-login.php/wp-login.php /var/www/html/wp-login2.php [root@wptest ~]# restorecon -v /var/www/html/wp-login2.php
The two different modules must be configured to get ready to use.
Important to know: the parameters InterceptFormLogin and InterceptFormPassword are containing the name of the user and password input field name of the form, as defined in the HTML code. I.e. <input type=”text” name=”log” id=”user_login” …
cat << EOF >> /etc/httpd/conf.d/intercept_form_submit.conf <LocationMatch ^/wp-login.php> InterceptFormPAMService wordpress InterceptFormLogin log InterceptFormPassword pwd </LocationMatch> <LocationMatch ^/wp-login2.php> InterceptFormPAMService wordpress InterceptFormLogin log InterceptFormPassword pwd </LocationMatch> EOF
The next configuration files is for the mod_auth_gssapi
The interesting part is the ErrorDocument where you tell the browser to redirect to the previously created wp-login2.php form. Since that form is only protected by mod_intercept_form_submit there will be no Kerbros authentification and prompting the user for the username and password.
cat << EOF >> /etc/httpd/conf.d/auth_gssapi.conf <Location "/wp-login.php"> AuthType GSSAPI AuthName "Kerberos Login" GssapiCredStore keytab:/etc/httpd/conf/http.keytab GssapiCredStore client_keytab:/etc/httpd/conf/http.keytab GssapiDelegCcacheDir /var/run/httpd/clientcaches GssapiUseS4U2Proxy on Require pam-account wordpress ErrorDocument 401 '<html><meta http-equiv="refresh" content="5; URL=/wp-login2.php"><body><h1>Kerberos authentication did not pass</h1><h2>Make sure your browser is configured correctly and you got a Kerberos Ticket.</h2></body></html>' </Location> EOF
Configure the WordPress plugin
Point your Browser to https://wptest.example.com/wp-admin/options-general.php?page=http-authentication%2Fhttp-authentication.php and set the following Parameters:
- Allow WordPress authentication -> Enabled
- Automatically create accounts -> Enabled
- Email address domain -> Whatever the users domain is
Now point your browser to http://wptest.example.com/wp-admin/options-general.php And select the default role of the users being created when logging in the first time.
Create a HBAC rule
Usually you want to create a HBAC rule to i.e. allow only certain users or group(s) of users to log in.
Some time ago I wrote an article on how to do so.
Now it is time to restart your Apache Server to activate the settings.
[root@wptest ~]# systemctl restart httpd.service
To be able to use Kerberos with Firefox, you need to set a few options. Please point your browser to one of your IPA repliacas, i.e. http://ipa1.example.com/ipa/config/browserconfig.html”
- A generic description on how you can make use of IPA in your Web Applications
- Project Website of Mod_Auth_GSSAPI
- Project Website of Mod_Intercept_Form_Submit
Have fun 🙂 Feedback welcome..