Success using HTTP kerberos-auth + negotiation on Intranet site

[Enrico Ehrhardt]

My goal was to provide a single sign-on mechanism to avoid the
user/password promt at a web site.
I managed to setup a secure intranet site  using kerberos authentication in
conjunction with negotiation using Samba4 as primary domain controller.

It took a while to figure out the right setup, so I thought, it's a good
idea to share this experience.

Here's some kind of walkthrough - what I've done, common pifalls and
head-scatching moments. I think this is the secure way to setup - any
comments/suggestions/additions are appreciated.

Assuming you got Samba4/DNS (bind9.81+) and Kerberos up and running, let's
start by setting up the web server.

Install apache2 + mod_auth_kerb

    Ubuntu/Debian
    # apt-get install apache2 libapache2-mod-auth-kerb
    # a2enmod ssl auth_kerb

Setup a minimal ssl-secured site

We need to setup a vhost which will host our secured intranet site.
NOTE: You don't need to use a secured site to get this example working, but
in production environments it's highly suggested to use one for security
reasons.
A minimal configuration might look like this:

file: /etc/apache2/sites-available/default-ssl

<IfModule mod_ssl.c>
<VirtualHost _default_:443>
    ServerAdmin webmaster at localhost

    DocumentRoot /var/www
    <Directory />
        Options FollowSymLinks
        AllowOverride None
    </Directory>
    <Directory /var/www/>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride None
        Order allow,deny
        allow from all
    </Directory>

    #########################################################
    # add a private directory using kerberos authentication #
    #########################################################

    <Directory /var/www/private>
        AuthType Kerberos
         AuthName "Intranet Login"
        KrbMethodNegotiate on
        KrbMethodK5Passwd on
        KrbVerifyKDC on
        KrbSaveCredentials off

        # our keytab
         Krb5Keytab  /etc/apache2/http.keytab

         # specify your realm (upper case - like the krb5.conf)
         KrbAuthRealms YOUR.REALM
         Require valid-user
      </Directory>

      # rest of file
      ...

Add the private directory to the filesystem
    # mkdir /var/www/private
Enable the ssl site
    # a2ensite default-ssl

Next step is to create a user - a service account which will silently
authenticate the currently logged in AD user (you) ;). To create the user
account, we will use the remote server administration tools provided by
Windows. If you followed the HOWTO
http://wiki.samba.org/index.php/Samba4/HOWTO#Step_1:_Installing_Windows_Remote_Administration_Tools_onto_Windows,
you should already have them.

Fire up the Active Directory Users and Computers snap-in and open the
predefined Users-folder. If you take a closer look at it's content, you'll
notice samba's DNS account in there, which is named 'dns-<hostname of dc>'
- let's stick to this unwritten convention and name the new account
'http-<hostname of dc>'. Choose a proper password and tick the 'Account
never expires'-option. The password is required later on, so don't forget
it.

Now that the account is created successfully, switch back to
Linux-commandline.

Our account needs a proper service principal name (SPN). Samba4 provides a
tool named 'ldbedit' to modify AD data. To add a proper SPN to the service
account type in the following command:

    # ldbedit -H /usr/local/samba/private/sam.ldb
"(samaccountname=http-<hostname of dc>)" -e <your favourite editor>

This will open up the specified account for manipulation. the '-e' option
lets you specify an editor to use (nano in my case). Just add the required
SPN

    servicePrincipalName: HTTP/yourdomain.tld

and save the file.

In my case, the entry looks like this:

...
sAMAccountName: http-server-vm
sAMAccountType: 805306368
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=testnet,DC=dom
userAccountControl: 590336
description: HTTP Service Account for server-vm
servicePrincipalName: HTTP/testnet.dom
whenChanged: 20120624120002.0Z
...

Now we're ready to go on.

Back at Windows, refresh the content or reopen the Active Directory Users
and Computers snap-in. The properties of the service account now show an
additional tab named 'Delegation'. Tick the second option 'Trust User on
delegation of all services (Kerberos only)' - I don't know the exact
description, because I got the german version.

Now the service account is allowed the request authentication- and service
tickets for other user, which is what we want.

Next, we have to create a keytab for our account - this is the first point
of a common pitfall. For keytab-creation Samba provides the 'ktpass.sh'
shell script, which (by default) is located at
/usr/src/samba-master/source4/scripting/bin/. However, it doesn't work from
this path, as Matthieu Patou wrote on
http://samba.2283325.n4.nabble.com/samba4-keytab-management-tp2478287p2478297.html.
You have to copy it to samba/bin/ - for example:

    # cp /usr/src/samba-master/source4/scripting/bin/ktpass.sh
/usr/local/samba/bin/

Create the keytab

    # kinit http-<hostname of dc>

    This will initialize the service account (Now you should remember the
given password) ;)

    # ktpass.sh --out /etc/apache2/http.keytab --princ HTTP/yourdomain.tld
--pass '*'

    Retype the password again - now ktpass should answer with 'Keytab file
/etc/apache2/http.keytab created with success'

    # chown www-data:www-data /etc/apache2/http.keytab
    # chmod 0400 /etc/apache2/http.keytab

    This will change the owner of the keytab to www-data (the default user,
apache2 runs at) and make it readable only by this user - we want security,
right?

Finally, it's time to restart the web server for changes to take effect.
The last part is the client side setup - the browsers. Let's begin with
firefox.

Firefox needs to know the trustworthy uri(s) to use negotiation. We simply
need to set the appropriate configuration value and it will work out of the
box.

Start firefox and go to the url 'about:config' - you'll get a warning, but
don't panic, we will be careful - I promise ;)

Type 'negotiate' into the search field

Now modify the entry 'network.negotiate-auth.trusted-uris' and type in your
domain name (e.g. testnet.dom).

You may get a warning, if you're using a self-signed certificate (like me)
- just add an exception and the page will load. That's it! Open
https://yourdomain.tld/private/ and you're in - fully authenticated as
user at YOUR.REALM

On Internet Explorer, you have to add your site to the local intranet
security zone to enable negotiation support. The certificate will be
treated as insecure and IE will complain about that. Well, to be honest, I
haven't found a proper way to install and trust it permanently, so I'll
leave this up to you.

You may take a look at Samba's debug log (start it with -i -M single -d3)
to watch the whole authentication process. For convinience, here's my
output:

Kerberos: TGS-REQ Administrator at TESTNET.DOM from
ipv4:192.168.178.133:1088for HTTP/testnet.dom at TESTNET.DOM[renewable,
forwardable]
Kerberos: TGS-REQ authtime: 2012-06-28T18:28:22 starttime:
2012-06-28T18:28:22 endtime: 2012-06-29T04:28:22 renew till:
2012-07-05T18:28:22

If you see something like this, it works.

Feel free to add this to the wiki.

Cheers, Enrico