FreeRADIUS packages for Debian

Although announced a bit more than a month ago on the FreeRADIUS-users list, I though I might mention the package repository that I maintain for FreeRADIUS on Debian: Welcome 1Labs Packages!

There you can find:

  • Point releases for Debian jessie and wheezy of 3.0
  • (Bi-)weekly snapshots for Debian jessie and wheezy of 3.0
  • (Bi-)weekly snapshots for Debian jessie for 3.1 (until 3.1 gets released)

This is a complementary service that Fajar Nugraha has been providing via an unofficial Ubuntu PPA for the community. A similar offer hasn’t existed yet for Debian (only a rather stale SuSE OBS depot). So this is where I’d like to complement the current gap for Debian for anyone insterested.

(… from my point of view and knowledge) As of early to mid 2016 Debian and its siblings including Ubuntu only ship FreeRADIUS 2.x, this release branch has been EoL-ed by the FreeRADIUS project. Citing the commit message right after 2.2.9 preparing for a future 2.2.10 release:

commit c69b7e0abdb69e821133bbe030749bb119466256
Author: Alan T. DeKok <removed>
Date:   Tue Oct 6 09:11:27 2015 -0400

    Bump for 2.2.10

    Which will only be released if there are catastrophic security
    bugs.  Everyone should upgrade to 3.0

This isn’t the only occurrence where FreeRADIUS main developers emphasize on upgrading to 3.0 since their focus has shifted on this stable branch and the upcoming 3.1/3.2. I’d like to point out that the first 3.0.0 release has been made in October 2013. Most Linux distributions and the BSDs ship FreeRADIUS 3.0 in some way (even the rather conservative RHEL 7!) but not Debian and any derived distribution who get source packages from Debian.

As of now a bug report 797181 exists in Debian about FreeRADIUS 3, however in Alan’s DeKok’s own words:

The Debian maintainer seems to have disappeared, and is unresponsive.  
We need a new Debian maintainer, but the process isn't trivial, and no one has stepped forward.

(freeradius-users from Feb 26 2016)

Becoming a Debian maintainer isn’t such a quick thing and requires some efforts if you want to provide quality packages. This isn’t something I can afford my time on right now. However if nobody uses FreeRADIUS on Debian and Ubuntu, issues will go unseen and FreeRADIUS is going to get blamed for not running well on these distributions.

The FreeRADIUS source tree has been shipping with Debian packaging definitions for a long time but the exchange between up- and downstream hasn’t been so active. For some time the Debian packaging information in the FreeRADIUS source tree has been not in the best shape. Luckily this has changed for some months now and (IMHO) all deal-breaking issues have been resolved by a couple of helpful individuals (for example). With the snapshots build I hope to capture regressions more quickly and get a wider audience testing FreeRADIUS on Debian in order to make a future Debian maintainer’s life as smooth as possible. For what I can tell I’ve made rather positive experience with bug reports and small pull requests I have been involved with so far.

I can’t give any warranty that my package builds are bug free or are made with the best practises. For me it’s a learning experience and I have promised on the FreeRADIUS list to keep people informed if I have to or find a good reason to cease this effort. For the moment that’s what I can help with making the FreeRADIUS experience a bit more smooth and ease a future Debian maintainers’ effort.

March 14, 2016

Posted In: Uncategorized

Tags: ,

Leave a Comment

FreeRADIUS 2 to 3.0: Migration experience and nested LDAP groups

Since I migrated a FreeRADIUS 2.x server to 3.0 (finally!) I ran across some syntactical changes that have been in this release branch and sharing a small bit on the experience here on my blog.

Do I have redo my config from scratch?

The good news from my experience: No. If you haven’t totally messed up the default configurations a lot of snippets will still work with quick minor changes. Read twice, enter once and it’s likely going to fly quickly. As the project strongly recommends: You should really NOT reuse your FreeRADIUS 2.x configuration but start with the clean default configuration for v3, then modify them to the desired state. Unfortunately the experience of successfully adding back previous settings one by one I didn’t spot a difference that made my LDAP queries not work as I had expected them.

In FreeRADIUS 2.1.2 modules/ldap had the following default:

ldap {

[...]
   groupmembership_filter = "(|(&(objectClass=group)(member=%{control:Ldap-UserDn}))(&(objectClass=top)(uniquemember=%{control:Ldap-UserDn})))"
[...]

In FreeRADIUS 3.0.11 these options are split into into their own group section but the groupmembership_filter was also separated:

    group {
[...]
    #  Filter for group objects, should match all available
    #  group objects a user might be a member of.
    filter = '(objectClass=posixGroup)'

[...]
    #  Filter to find group objects a user is a member of.
    #  That is, group objects with attributes that
    #  identify members (the inverse of membership_attribute).
#   membership_filter = "(|(member=%{control:Ldap-UserDn})(memberUid=%{%{Stripped-User-Name}:-%{User-Name}}))"

[...]

Now the filter for to identity group objects is short with filter and the membership_filter contains the query related to filtering the membership.

In my case the LDAP directory is an Active Directory where nested groups are not only allowed but I see them quite frequently used. Unfortunately standard queries won’t reveal nested memberships as this requires a specific query only supported by AD LDAP servers. Thankfully Nasser Heidari blogged how this could be achieved with FreeRADIUS 2 – and since most of my local changes worked readily with FreeRADIUS 3 I didn’t realize this had to be changed in a minor way.

In short in FreeRADIUS 2.x it was

groupmembership_filter = "(&(objectcategory=group)(member:1.2.840.113556.1.4.1941:=%{control:Ldap-UserDn}))"

In FreeRADIUS 3.0 you want to split this to i.e.

filter = '(objectCategory=group)'
membership_filter = "(member:1.2.840.113556.1.4.1941:=%{control:Ldap-UserDn})"

Not a huge difference but if someone is rubbing his or her eyes during migration, this one seemed to be ok for me.

If you care about not running outdated software that isn’t really receiving much more love by the developers I can only encourage you moving to 3.0. Not only have there been a ton of performance improvements – there are definitely improvements in the configuration syntax I like as well.

January 5, 2016

Posted In: Uncategorized

Tags: , , ,

Leave a Comment