Using Kerberos authentication with Apache HTTP Server
Table of Contents
from time to time I need to configure an apache httpd with Kerberos authentication, a quick braindump follows.
Read Using Kerberos authentication in apache httpd in the CentOS Wiki. I will not repeat here neither how to get your keytab, nor the client setup instructions shown there.
main config options
My config diverges from the one in the CentOS Wiki. The reasons for this are explained below. While I like to keep mine in a separate file in /etc/httpd/conf.d/ nothing prevents you from adding the lines to the main httpd.conf
extract from apache config file
<Location /some-location/> AuthType Kerberos AuthName "Kerberos Login" KrbMethodNegotiate on KrbMethodK5Passwd off KrbAuthRealms YOURREALM.COM Krb5Keytab /etc/httpd/conf/apache.keytab Require group mygroup AuthGroupFile /etc/httpd/conf/httpd-access-groups-kerberised ErrorDocument 401 /some-location/401-page.html </Location>
KrbMethodK5Passwd off because I do not like popping username/password dialogs at users, if the user does not have a properly configured browser, a 401 happens and I serve up a custom page which explains how to set up kerberos properly. IMO this is much better than educating users into accepting authentication dialogs that pop up.
Require group mygroup because in most of the setups I do it is not sufficient for the user to be valid in the realm. Generally only a subset of the valid users are to be granted access to a protected location.
user groups file
Create a file containing the users that should have access if they have a valid kerberos TGT
mygroup: \ user1@YOURREALM.COM \ user2@YOURREALM.COM \ user3@YOURREALM.COM anothergroup: \ user1@YOURREALM.COM \ user4@@YOURREALM.COM
I’ll quite often have a couple kerberised locations and keep them all in the same lookup file. You can also have one lookup file per location.
custom 401 page
I use the following 401 page to help users set up kerberos for their browser;
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <title>Access denied</title> </head> <body> <h1>ACCESS DENIED (!read the rest of the text below!)</h1> <!-- <p>2010-11-08: k5srvutil has been used to refresh. We now use strong cyphers. pcfe</p> --> <p><i>Note: Access to these pages is done through Kerberos. Your system and browser must be set up as described below.</i></p> <p>Your access to either the <a href="http://www.example.com/Location1/">Location 1</a> or <a href="http://www.example.com/Location2/">Location 2</a> was denied (401). This can have several reasons: <dl> <dt>i. You do not have a valid kerberos ticket</dt> <dd>type <b>kinit</b> in a shell to get a ticket, verify with <i>klist</i> that your ticket is valid</dd> <dt>ii. Your web browser is not set up for single sign-on</dt> <dd>read the <a href="http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/sso-config-firefox.html">relevant documentation</a>, then configure <b>network.negotiate-auth.trusted-uris</b> to <b>.example.com</b>. You do not need to configure delegation.</dd> <dt>iii. If you get your TGT after launching the browser</dt> <dd>please quit and restart your browser, some do not handle TGT acquired after browser launch.</dd> <dt>iv. you are not on the list of users granted access to the pages</dt> <dd>email <a href="mailto:email@example.com">your admin</a> and ask for access, stating <ul> <li>which department you work in</li> <li>which logs you need access to</li> <li>why you require access to the logs</li> </ul> </dd> </dl> <p>the primary aim of the access control is to make sure that no person who should not access these pages gets in. As such, I use a white-list, meaning you must explicitly be listed to have access.</p> <p>These pages do not, and will never, ask you to enter your kerberos login/password. You should be wary of any pages that do. Single sign-on means you kinit once a day and never enter your kerberos password after that.</p> <p>pcfe, 2014-03-12</p> </body> </html>