Nov 062019
 

My activities in October were mostly related to updating my COPR repositories for CentOS 8 and cleaning up the old repositories:

  • I updated the ganto/jo COPR repository to support CentOS 8.
  • I updated the ganto/vcsh COPR repository to support CentOS 8 and added package builds for the alternative architectures (aarch64 and ppc64le).
  • Thanks to the help of jmontleon I was finally able to build LXD which is available in my ganto/lxc3 repository for CentOS 8. I also updated the RPM for the latest stable release LXD 3.18.
  • After years of development the distrobuilder tool which is meant to replace the shellscript-based LXC templates was tagged in a first 1.0 release that should now also be able to build CentOS 8 container images. Of course I updated the corresponding RPM in the ganto/lxc3 COPR repository accordingly. I’m not sure how they decide to do new releases therefore I might decide to go back building regular git snapshot releases of this tool in the future.
  • I updated the ganto/goaccess COPR repository to support CentOS 8 and also increased the built goaccess version to a git snapshot from May 2019 based on version 1.3. Unfortunately the official Fedora package is still only at version 1.2. I was first testing the latest git snapshot but then found that it is affected by a bug (GitHub issue 1575) which would fail to render the access graphs properly.
  • The last COPR repository pending an update for CentOS 8 is ganto/umoci which still fails because of go-md2man missing from EPEL 8.
  • I deleted some outdated COPR repositories (ganto/lxc, ganto/lxd, ganto/lxdock) and archived the related GitHub repositories holding the RPM spec files.

Then I was also experimenting with adding Debian machines to a CentOS FreeIPA identity management server via Ansible. Years ago I wrote an Ansible role freeipa-client which was able to do that but still required manual setup of the Kerberos keytab on the client machine. I plan to replace that with a collection of new roles trying to blend-in with DebOps as much as possible. But unfortunately nothing ready to show yet.

Finally, as always, I updated a lot of ebuilds in my linuxmonk-overlay Gentoo overlay.

Aug 282014
 

Today I just found out, how super easy it is to setup a safe HTTP authentication via Kerberos with help of FreeIPA. Having the experience of managing a manually engineered MIT Kerberos/OpenLDAP/EasyRSA infrastructure, I’m once again blown away by the simplicity and usability of FreeIPA. I’ll describe with only a few commands which can be run within less than 10 minutes how it’s possible to setup a fully featured Kerberos-authenticated Web server configuration. Prerequisite is a FreeIPA server (a simple guide for installation can be found for example here) and a RedHat-based Web server host (RHEL, CentOS, Fedora).

Required Packages:
First we are going to install the required RPM packages:

# yum install httpd mod_auth_kerb mod_ssl ipa-client

Register the Web server host at FreeIPA:
Make sure the Web server host is managed by FreeIPA:

ipa-client-install --domain=example.com --server=ipaserver.example.com --realm=EXAMPLE.COM --mkhomedir --hostname=webserver.example.com --configure-ssh --configure-sshd

Create a HTTP Kerberos Principal and install the Keytab:
The Web server is identified in a Kerberos setup through a keytab, which has to be generated and installed on the Web server host. First make sure that you have a valid Kerberos ticket of a FreeIPA account with enough permissions (e.g. ‘admin’):

# kinit admin
# ipa-getkeytab -s ipaserver.example.com -p HTTP/webserver.example.com -k /etc/httpd/conf/httpd.keytab

This will create a HTTP service principal in the KDC and install the corresponding keytab in the Apache httpd configuration directory. Just make sure that it can be read by the httpd server account:

# chown apache /etc/httpd/conf/httpd.keytab

Create a SSL certificate
No need to fiddle around with OpenSSL. Requesting, signing and installing a SSL certificate with FreeIPA is one simple command:

# ipa-getcert request -k /etc/pki/tls/private/webserver.key -f /etc/pki/tls/certs/webserver.crt -K HTTP/webserver.example.com -g 3072

This will create a 3072 bit server key, generate a certificate request, send it to the FreeIPA Dogtag CA, sign it and install the resulting PEM certificate on the Web server host.

Configure Apache HTTPS
The httpd setup is the only and last configuration which needs to be done manually. For HTTPS set the certificate paths in /etc/httpd/conf.d/ssl.conf:

[...]
SSLCertificateFile /etc/pki/tls/certs/webserver.crt
SSLCertificateKeyFile /etc/pki/tls/private/webserver.key
SSLCertificateChainFile /etc/ipa/ca.crt

Additionally do some SSL stack hardening (you may also want to read this):

[...]
SSLCompression off
SSLProtocol all -SSLv2 -SSLv3 -TLSv1.0
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH EDH+aRSA !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"

Kerberos HTTP Authentication:
The final httpd authentication settings for ‘mod_auth_kerb‘ are done in /etc/httpd/conf.d/auth_kerb.conf or any vhost you want:

<Location />
  SSLRequireSSL
  AuthType Kerberos
  AuthName "Kerberos Login"
  KrbMethodNegotiate On
  KrbMethodK5Passwd On
  KrbAuthRealms EXAMPLE.COM
  Krb5KeyTab /etc/httpd/conf/httpd.keytab
  require valid-user
</Location>

That’s it! After restarting the Web server you can login on https://webserver.example.com with your IPA accounts. If you don’t already have a valid Kerberos ticket in the Web client, KrbMethodNegotiate On enables interactive password authentication.

Troubleshooting
In case you get the following error message in the httpd error log, make sure the keytab exists and is readable by the httpd account (e.g. ‘apache’):

[Wed Aug 27 07:23:04 2014] [debug] src/mod_auth_kerb.c(646): [client 192.168.122.1] Trying to verify authenticity of KDC using principal HTTP/webserver.example.com@EXAMPLE.COM
[Wed Aug 27 07:23:04 2014] [debug] src/mod_auth_kerb.c(689): [client 192.168.122.1] krb5_rd_req() failed when verifying KDC
Dec 022012
 

FreeIPA is an integrated user, host and service identity management solution combining 389 Directory Server (LDAP), MIT Kerberos, a BIND DNS server and the Dogtag Certificate Authority service with a simple but powerful Web GUI and an extensive command line interface for easy administration. It claims to become something like an Active Directory for Linux and Unix environments and is heavily pushed by Red Hat, which also integrates it as IPA server in their Red Hat Enterprise Linux distribution. A nice overview can be found in this presentation.

After having the pleasure of playing around with the Red Hat IPA server on RHEL and CentOS for the past few weeks, I also wanted to use this excellent identity management platform with my Gentoo Linux boxes. Some years ago, a bug report was opened in the Gentoo bugzilla (#297665), to coordinate the inclusion of FreeIPA in Gentoo. Andreis Vinogradovs, another Gentoo user, then started an effort, to write some of the necessary ebuilds for building FreeIPA, however they are still far from complete and therefore haven’t made it into the official Gentoo repository yet. This means that FreeIPA is unfortunately still not fully available for Gentoo.

Based on Andreis’ work, I started another effort, to update and polish the FreeIPA ebuild and its dependencies, so that they can be used on a Gentoo Linux box. The server part has dozens of dependencies not yet officially integrated in Gentoo, and the available ebuilds are mostly outdated, so I haven’t put too much effort yet into integrating the server parts on Gentoo. Especially the entire PKI infrastructure is still missing.

However, I succeeded to configure a Gentoo box as full-featured FreeIPA client, including OpenRC support for `authconfig` and `ipa-client-install`. I also found and reported some bugs in official Gentoo ebuilds (#445394, #445478), where you have to work-around in case you try out the setup yourself.

Of course you are curious now, where you can find the ebuilds. Because the work on them and especially the testing is still ongoing, I created a repository on Github so that everybody who is interested can have a look at ebuilds and provide constructive feedback in terms of pull requests.

I’m especially looking for people who would like to try the FreeIPA client with a Gentoo systemd or/and a hardened SELinux system.

How can you test the FreeIPA client on your Gentoo box?

You have to begin with setting up a (Free)IPA server, which is currently only possible on a Red Hat-based distribution. The easiest way is to setup a CentOS 6 VM, then run:

[root@centos6 ~]# yum install ipa-server
[root@centos6 ~]# ipa-server-install

More information can be found in the upstream installation guide.

Then add the ‘freeipa-overlay’ to the layman configuration of your Gentoo client. How you do this is described here.

ATTENTION: This guide is meant to be for experimental testing only. Don’t do this on your workstation if you are not familiar with FreeIPA and its technologies. I don’t take any responsibility if you blow up your machine. You have been warned!

Finally you are ready to emerge FreeIPA. Make sure tho have a look at the various
USE flags. They don’t have too much influence on build-time functionality but
on run-time dependencies. So you can slim down your installation in case you
already know, that you don’t need another DNS server or winbind support for
example. Set the ‘minimal’ USE flag for only building the IPA client
(Update 07.12.2012: This USE flag was replaces with ‘server’, so the client will be installed by default):

gentoo ~ # emerge -av freeipa

Some keyword unmasking may be required when you run a stable Gentoo installation.

Before you can start your IPA client installation, you have to make sure, that an empty NSS certificate database exists. This is expected to be under /etc/pki/nssdb. Gentoo however puts all the SSL stuff under /etc/ssl. I solved this by creating a symlink:

gentoo ~ # ln -s ssl /etc/pki
gentoo ~ # certutil -N -d /etc/pki/nssdb

Eventually the IPA client can be configured. E.g.:

gentoo ~ # ipa-client-install --mkhomedir --no-dns-sshfp
Discovery was successful!
Hostname: gentoo.example.com
Realm: EXAMPLE.COM
DNS Domain: example.com
IPA Server: centos6.example.com
BaseDN: dc=example,dc=com

Continue to configure the system with these values? [no]: yes
User authorized to enroll computers: admin
Synchronizing time with KDC...
Password for admin@EXAMPLE.COM:

Enrolled in IPA realm EXAMPLE.COM
Created /etc/ipa/default.conf
Domain example.com is already configured in existing SSSD config, creating a new one.
The old /etc/sssd/sssd.conf is backed up and will be restored during uninstall.
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm EXAMPLE.COM
SSSD enabled
Configured /etc/openldap/ldap.conf
NTP enabled
Configured /etc/ssh/ssh_config
Warning: Installed OpenSSH server does not support dynamically loading
authorized user keys. Public key authentication of IPA users
will not be available.
Configured /etc/ssh/sshd_config
Client configuration complete.

That’s it! Your system is now able to use user accounts created on the IPA server. Check it with:

gentoo ~ # id admin
uid=155960000(admin) gid=155960000(admins) groups=155960000(admins)

As you can see in the generated /etc/pam.d/system-auth, pam_unix will be checked before pam_sssd. This means your local user accounts still have precedence towards the IPA accounts.

Happy testing… 🙂