Categories: braindump

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.

required reading

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

/etc/httpd/conf/httpd-access-groups-kerberised

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:admin@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>

Related