↓Skip to main content
  1. Words/

Part 3: Setting up a Kerberos test environment

·534 words·3 mins·
Table of Contents
Django + Authentication - This article is part of a series.
Part 1: Part 1: Django 1.5 Custom User Models
Part 2: Part 2: Apache and Kerberos for Django Authentication + Authorization
Part 3: This Article

This is part 3 of a series of posts on setting up Django to use external authentication. This post explains how to setup your own environment to test Django authentication against Apache and Kerberos/Active Directory/LDAP.

Setting up your own test environment
#

Naturally, you only care about coding and developing. I’ve made a Vagrantfile that spins up two VMs: an IPA server with a Kerberos KDC, and a client within the Kerberos realm that runs Apache, both on Fedora 18.

Setup your Kerberos test environment:
# 

$ git clone\
      https://gist.github.com/econchick/99699a6fee2eb44d13b0\
      KerbTestEnvironment
$ cd KerbTestEnvironment

# for a synced folder between local and Vagrant VM
$ mkdir synergizerApp  

# to spin up both machines at the same time:
$ vagrant up

# to spin up machines individually:
$ vagrant up ipaserver
$ vagrant up client

Using the test environment
#

To use your Kerberos test environment, make sure both VMs are up and running with vagrant status.

First, ssh into the server via vagrant ssh ipaserver then check to see if the IPA service is up and running, and if not, start it up:

[vagrant@ipaserver]$ sudo ipactl status
[vagrant@ipaserver]$ sudo ipactl start

Be sure you can kinit on the server:

[vagrant@ipaserver]$ kinit admin

Now, ssh into the client via vagrant ssh client, then check to see if you can kinit to make sure this VM can connect to ipaserver’s KDC:

[vagrant@client]$ kinit admin

To push your app to the client VM, you can just copy your Django code to the KerbTestEnvironment/synergizerApp/ directory we created earlier, and it will drop into Apache’s default directory, /var/www/. You will need to configure Apache for wsgi.

Then go on with the earlier described testing.

Possible issues
#

  • If you receive a similar error message during vagrant up $VM_NAME:

The following SSH command responded with a non-zero exit status. Vagrant assumes that this means the command failed! /sbin/ifup p7p1 2> /dev/null

then apply this fix within Vagrant’s installation. For my Mac OS X Mountain Lion + Vagrant v1.2.2 (most up-to-date at the time of this article), it was a bit tough to find the exact place where this fix should be made. Wherever the vagrant gems are installed, find plugins/guests/fedora/cap/configure_network.rb to adjust the line that contains this:

machine.communicate.sudo("/sbin/ifup p7p#{interface} 2>\
                          /dev/null")

to this:

machine.communicate.sudo("/sbin/ifup p7p#{interface} 2>\ 
                          /dev/null", :error_check => false)

(ya ya, a pull request containing this fix, or rather an update to ifup, should be made; who has time for that…)

  • If you get a clock skew error during kinit on the ipaserver, restart IPA via sudo ipactl restart and make sure ntpd is running with service ntpd status.

  • If you get a clock skew error during kinit on the client, you’ll need to resync NTP. Try the following (you’ll have to do the ntpdate command at least twice to adjust the NTP clock to at most 300 seconds/5 minutes difference):

[vagrant@client]$ sudo killall ntpd
[vagrant@client]$ sudo ntpdate ipaserver.example.com
[vagrant@client]$ sudo ntpdate ipaserver.example.com
[vagrant@client]$ kinit admin

Resources
#

Django + Authentication - This article is part of a series.
Part 1: Part 1: Django 1.5 Custom User Models
Part 2: Part 2: Apache and Kerberos for Django Authentication + Authorization
Part 3: This Article