FreeIPA, Kerberos, LDAP, Subversion Stack Part 2: Apache Kerberos Setup

Lots to configure.  This step is only the Apache configs.  There are files needed to make the configs work.  That’s the next post.

Apache SVN Root

You obviously need a base directory.  Since CentOS ships with SELinux enabled, you have to be sure the context of the new directory is correct. If you put it under /var/www, my recollection is the selinux contexts are assigned auto magically.

mkdir /var/www/svn

ls -lhZ /var/www/svn

You need to move the default instance files to another folder and change the appropriate httpd.conf directives.  This should be easy.

mkdir /var/www/default80
mkdir /var/www/default80/cgi-bin
mkdir /var/www/default80/http
 
ls -lhZ /var/www/default80

Double-check your permissions!  Check your SELinux contexts!

Apache LDAP Config

To be 100% clear, Kerberos provides password authentication.  LDAP via freeIPA’s 389DS instance provides access permissions.

You can do SVN without LDAP, but that’s kind of awkward as everyone in the freeIPA domain with a valid account can login.  Controlling access with Subversion’s flat file will be kind of tough for many to administer without LDAP.

mkdir /etc/httpd/certs

Be sure to keep the permissions quite tight.  Your apache user needs read access, and that’s it.

Apache SVN Directives

There is a bunch of SSL stuff to setup including the Listen directive before you get to the VirtualHost.  Your default SSL config shipped with the package should have sensible defaults.  It should be pretty easy to get the keys and cert path adjusted.

Here is the start of the Apache SVN path.

<Location /svn>
 SSLRequireSSL
 DAV svn
 SVNParentPath /var/www/svn
 RedirectMatch ^(/svn)$ $1/
 SVNListParentPath on

A couple of things worth mentioning.

You need all of the stanzas.  RedirectMatch directive is important.  It’s important the regex matches the Location directive.

The Auth portion of the Location directive.

AuthType Kerberos
AuthName "Domain Subversion Repositories"
Krb5Keytab /etc/httpd/keytabs/kwkla3.keytab
#Use your freeIPA domain name.
KrbAuthRealms MyDomain.foo
KrbServiceName HTTP
#More to follow! LDAP access comes next

The authentication directives are in place.  However, lots of things missing.  We’ll need to get files from your freeIPA server. The list of things we need in no particular order.

  • LDAP permissions directive.
  • CA certificate from the freeIPA instance.
  • A signed host certificate for the Apache host.
  • A private key for the Apache host.
  • An HTTP Kerberos principal.
  • TBD

NetworkManager and the Vanishing /etc/resolv.conf

I rebooted a Fedora 25 server to find the network interface did not come up.  Using the old “ifup eth0” returned an error.

 /etc/resolv.conf "no such file or directory"

Huh?  ls /etc/resolv.conf returns /etc/resolv.conf

It turns out NetworkManager replaces /etc/resolv.conf with a symbolic link to a NetworkManager directory.

Since NetworkManager is about as useful as lipstick on a pig with a server, it has to be removed. When you remove NetworkManager, it leaves /etc/resolv.conf as a dead symbolic link.  Which, you don’t see without ls -lh /etc/resolv.conf.

When systemd’s init tries to bring up the interface without NetworkManager, there’s no /etc/resolv.conf there to write DNS information and therefore the interface never comes up.

TL;DR The three commands below fix it.

rm /etc/resolv.conf;  ifdown eth0; ifup eth0;

FreeIPA, Kerberos, LDAP, Subversion Stack Part 1: Intro

This one took me a long while to figure out.  I’m using CentOS 7.x.  Everything will be specific to the “Redhat way” of doing things.

The bigger goal is having clear roles for hosts and a solution that can scale elegantly with good security bells and whistles. FreeIPA hosts authenticate, SVN servers host files.  As long as the subversion servers have enough disk space and RAM, this should scale elegantly.

This design can even fail over pretty elegantly as long as a second server is kept in sync with the primary.   Alternately, you can get into using some kind of shared storage and run a primary/secondary very easily.

Before you go looking for the configs, please understand the following:

  1. What this solution provides is front-end authentication to a Subversion repository.
  2. What this solution does NOT provide is permissions the flat file directive AuthzSVNAccessFile addresses.
  3. It’s uncertain to me how the authzsvnaccessfile interacts with an LDAP + Kerberos setup.  It seems like authz_svn_module and LDAP and Kerberos are not well documented.  Authz_svn_module and Kerberos + LDAP are is probably another big chunk of time to figure out.  Tons of how-tos for using Apache’s flat file as user auth.   It may be the case the subversion flat file auth needs to move to the Apache config.  It’s not terrible if that’s the case as it is only a config reload for Apache.
  4. It’s not an Active Directory connection.  It’s not a matter of making some minor changes to get it to work with Active Directory.

What the final solution will do:

  • A basic functioning Subversion server with centrally hosted users.
  • Kerberos authentication from FreeIPA host.
  • Basic LDAP permission control at login.
  • Encrypted (ssl) communication between your Apache host and FreeIPA. Kerberos handling the authentication means user passwords aren’t in the clear anywhere.
  • Encrypted (ssl) communication between subversion clients and the subversion server.

What you need before you get started:

  • Root access to the FreeIPA server to grep LDAP logs.
  • A functioning FreeIPA server with enough ports open to your Apache host that Kerberos and LDAP over SSL will work.
  • The Apache server already joined to the freeIPA server.
  • An LDAP browser already configured to login via LDAPS:/  I like jxplorer.
  • Some awareness of how Kerberos works.  I don’t pretend to know it well, but I know there’s a key table that needs reading/writing and very accurate time is very important.  I will probably have a couple of unnecessary steps because I don’t fully comprehend the Kerberos way.
  • Apache server and Subversion, LDAP, Kerberos modules enabled.  I tried the GSSAPI module and could not get it working.
  • The Certificate Authority’s certificate from the FreeIPA install.
  • The Certificate Authority’s private key.
  • A private key for the Apache server. The certificate for the host from freeIPA.
  • Port 443 available on the Apache host for Apache’s SSL process.  I confined mine to localhost.
  • Another port open and listening for your subversion server.

I think that’s enough for this post.  I’ll walk through some of those requirements in later posts.

 

Stay tuned!

Building and Running Freeipa 4.4.4 on Centos 7

I was trying to replicate Freeipa from a Fedora 25/Freeipa 4.4.4 to NOT Fedora 25.  How hard could it be to rebuild Freeipa 4.4.4 on Centos?  It turns out it is fiddly to get the packages built.

The following is not for the faint of heart and leaves out a bunch of build environment stuff, so this is not a good package to learn rebuilding a package.  But, the instructions  should save you a ton of time.

Download Fedora 25’s Freeipa source.  It should be in this directory: http://dl.fedoraproject.org/pub/fedora/linux/updates/25/SRPMS/f/

Download mod_wsgi source from Fedora 25.  It should be in this directory.  http://dl.fedoraproject.org/pub/fedora/linux/updates/25/SRPMS/m/

Download dinglibs source for Fedora 25.  I found it here: http://rpm.pbone.net/index.php3/stat/26/dist/103/size/895373/name/ding-libs-0.6.0-29.fc25.src.rpm

Download cmocka source for Fedora 25.  I found it here: https://kojipkgs.fedoraproject.org//packages/cmocka/1.1.1/0.fc25/src/cmocka-1.1.1-0.fc25.src.rpm

And so on for the following: ldns, python-astroid, pylint.  I was unable to build the sssd version that ships with Fedora 25 and a couple of the Python packages.  That means the freeipa.spec file gets modified with lower version requirements and the python package requirements get commented out and installed with pip.

There are also modifications to the spec files needed to be sure the packages don’t conflict with themselves.

The modifications to the spec files to accept a lower version of some of the packages are easy.  The build script should complain the correct version isn’t available. Figure out what your distro packages and modify the spec file accordingly.

My recollection is the general order of build was:

  1. build mod-wsgi
  2. build dinglibs
  3. build cmocka
  4. build python-astroid
  5. build pylint
  6. build ldns
  7. build free-ipa

The freeipa build will probably fail a couple of times on simple dependencies in the spec file.  Just keep adjusting the spec file and you’ll get built packages in a few tries.

Here is my freeipa.spec file.  It is not perfect as a number of the packages built complain about conflicting with themselves. freeipa.spec

If, after you get the packages built and the install goes okay AND you are running in an SELinux environment, be sure to run audit2allow -w -a after the IPA server stack is up to check for policy denials.

Do This Too!

For some reason, the replication setup script demands testing TCP port 7389 as another way to reach the LDAP server.  You need a port address translation for it.

firewall-cmd --permanent --zone=public --add-rich-rule="rule 
family="ipv4" \
source address="192.168.1.0/24" \
port protocol="tcp" port="7389" accept"

firewall-cmd --permanent --zone=public --add-forward-port=port=7389:proto=tcp:toport=636:toaddr=192.168.1.88

That’s the firewall-cmd way to forward anything showing up on TCP 7389 from the LAN and sending it to 636.  Adjust as needed.  It works for me.

Good luck!