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

FreeRADIUS: Omit PAP auth passwords leaking to logs

hWhen using remote authentication on switches, most will primarly support PAP, the simplest method. This way the password is sent MD5 encrypted (to my knowledge) via the shared secret between the NAS and the RADIUS server. Nowadays this isn’t considered to be secure, nonetheless I don’t expect most devices to support RADSEC when the don’t do it already to today. Anyhow, one misconfiguration I ran into was that I saw my own password leaked in plaintext to logfiles only when loggin into a switch, not using PEAP-MSCHAPv2 via WLAN

The log lines of a successful PEAP-MSCHAPv2 login (Wireless LAN) don’t leak problematic information:

Sun Oct 13 10:22:07 2013 : Auth: Login OK: [username/<via Auth-Type = EAP>] (from client wifi-aps 0 via TLS tunnel)
Sun Oct 13 10:22:08 2013 : Auth: Login OK: [username/<via Auth-Type = EAP>] (from client wifi-aps 0 cli <MAC-address>)

The second line is due to “use_tunneled_reply = yes” which is helpful for accounting since otherwise the outer tunnel doesn’t get much useful data when users use an anonymous outer identity. However when authentication requests get logged from a PAP authentication, things look quite bad:

Sun Oct 13 11:21:41 2013 : Auth: Login OK: [myadmin/myPasswordInPlaintext] (from client switches port 0)

The cause was that I enabled logging authentication requests, where default is set to no (likely for performance reasons):

/etc/freeradius/radiusd.conf:

log {

...

        #  Log authentication requests to the log file.
        #
        #  allowed values: {no, yes}
        #
        auth = yes

}

The solution I found via the FreeRADIUS list archives was actually simple, the default (on Debian) is to log good and bad passwords – but that’s only happening if you log authentication requests. Thus: when logging auth requests and with ¬†PAP – don’t forget to disable good and bad passwords logging!

log {
...
        #  Log passwords with the authentication requests.
        #  auth_badpass  - logs password if it's rejected
        #  auth_goodpass - logs password if it's correct
        #
        #  allowed values: {no, yes}
        #
        auth_badpass = no
        auth_goodpass = no

...

}

October 24, 2013

Posted In: Uncategorized

Tags:

Leave a Comment

A FreeRADIUS for your Switch authentication

As previously blogged, I wanted to share and comment a sample config – where I use ntlm_auth for authentication against AD and LDAP for authorization of Administrators, this was done using FreeRADIUS 2.1.12 on Debian wheezy (7.x). Remember to do your own reading. I found “FreeRADIUS Beginner’s Guide” over at PacktPub to be a very good read to get a better understanding of FreeRADIUS and overall AAA concepts.

Synopsis

  • Show an example of a (then-working) FR virtual server for (Netgear) CLI authentication.
  • Have some explanation why I did things this way or not ūüėČ
  • I derived from the preinstalled default server config and shrinked it to the minimum required
  • For the Samba / Winbind configuration, consider the Book at PacktPub or look at Alan Dekok’s DeployingRadius.com
  • I use a non-standard port since another (main) RADIUS server is already listening on UDP 1812
  • Uses PAP since that’s what the switch only does. PAP sends plaintext password, but AD doesn’t have the plaintext password stored – blimey. We need ntlm_auth from Samba to do the check for us.

The server config is located in /etc/freeradius/sites-available and has to be symlinked to sites-enabled, but before doing so, youneed to

  • Configure Samba and Winbind, join the box to your Domain
  • Configure ntlm_auth module
    • ntlm_auth binary path
    • ntlm_auth’s domain

These parts can be found on DeployinRadius.com, then you might want to do rememeber / adapt to AD specific behaviour:

  • Modify the LDAP module to support AD nested groups if your users are not direct members (thanks Nasser Heidari):
    • groupmembership_filter = "(&(objectcategory=group)(member:1.2.840.113556.1.4.1941:=%{control:Ldap-UserDn}))"
  • Check, that your user group you want to query is NOT the primary group of your admin users since that doesn’t appear in the memberOf attribute .
    (if you are a LDAP magician and know a trick, let me know)

Anyway, let’s get started with the server:

server netdevices {

listen {
        ipaddr = 10.0.0.2
        port = 41812
        type = auth
}

# local test listener for debug of this virtual server
listen {
        ipaddr = 127.0.0.1
        port = 41812
        type = auth
}

Then the authorize section basically tells the server:

  • To use PAP (some switch vendors support (MS)CHAP but Broadcom FASTPATH only does PAP, so we can disable all the rest
  • If no Auth-Type was sent, update the control to use our own ntlm_auth that will be defined in authenticate.
authorize {
        #  If you are using multiple kinds of realms, you probably
        #  want to set "ignore_null = yes" for all of them.
        #  Otherwise, when the first style of realm doesn't match,
        #  the other styles won't be checked.
        #
        suffix

        expiration
        logintime

        # Most switches support PAP only
        #
        #  This module should be listed last, so that the other modules
        #  get a chance to set Auth-Type for themselves.
        #
        pap

        # If no Auth-Type was sent, we assume PAP but that we should
        # use ntlm_auth for AD authentication through ntlm_auth.
        if(!control:Auth-Type) {
                update control {
                        Auth-Type = "ntlm_auth"
                }
        }
}

The authenticate section is quite simple but we need to tell the server that it can use ntlm_auth, at the end. You’ll need to adapt /etc/freeradius/modules/ntlm_auth.

authenticate {
        # For PAP against AD with ntlm_auth we need to
        # let Samba ntlm_auth do the authentication work.
        Auth-Type NTLM_AUTH {
                ntlm_auth
        }

        # For local users with plaintext password we can still use LDAP
        # Reminder - you might disable update conrol in such casse in
        # authorize because it's an unconditinal update.
        Auth-Type PAP {
                pap
        }
}

Most of the “magic” is finally done in the post-auth section:

  • Check if the user is in the required LDAP group, else reject
    • In AD I experienced problems with primary group memberships since they’re not written in memberOf Attributes
  • If it is an admin user, update the reply with the Netgear/Fastpath-specific AVpairs so the switch knows that it’s an administrative user
  • The remaining is from the default config, I’m not sure if we need it to work correctly.
#  Post-Authentication
#  Once we KNOW that the user has been authenticated, there are
#  additional steps we can take.
post-auth {
        # Only Domain admins are allowed, don't use the german group
        # name due to encoding issues
        if (LDAP-Group == "Network-Admins") {
                # Getting authorized requires informing the
                # (Netgear) device about privilege level.
                # Depending on the config only with this additional
                # reply message one gets authorized as admin on the shell.

                # Both seemed to work on Netgear 10.0.x,
                # Administrative-User is more vendor-neutral.

                update reply {
                        Service-Type = Administrative-User
                        Cisco-AVpair = "shell:priv-lvl=15"
                }

                noop
        }

        # No-one else is allowed.
        else {
                reject
        }

        # For Exec-Program and Exec-Program-Wait
        exec

        #
        #  Access-Reject packets are sent through the REJECT sub-section of the
        #  post-auth section.
        #
        #  Add the ldap module name (or instance) if you have set
        #  'edir_account_policy_check = yes' in the ldap module configuration
        #
        Post-Auth-Type REJECT {
                # log failed authentications in SQL, too.
#               sql
                attr_filter.access_reject
        }
}

}

Done, now symlink your config to /etc/freeradius/sites-enabled and start FreeRADIUS (as recommended for testing) in debug mode (service freeradius stop, then freeradius -X)
If everything went ok, you should now be able to authenticate against your Switch SSH and the Web-UI, as well as getting authorized for administration.

August 29, 2013

Posted In: Uncategorized

Tags:

3 Comments

Admin login through RADIUS on Netgear managed

When I had already dived into RADIUS for wireless network authentication, authorization (and accounting) – AAA – I started to think that it was worth to tinker about moving admin authentication of @work switches to RADIUS too. Netgear managed switches definitely support this – unfortunately neither their Websites, KB, nor the (mostly quite good) Software Administration Manuals for firmware 8.0 and 10.0 mention real-life configuration examples – only 802.1x port authentication.

I had to get inspired by comparing Cisco, Dell PowerConnect (see “P.S.”) documentation and blog post but in the end I hope this make sense for you too:

Configuration

First things first, define a local admin password and enable password (if your policy or you want to have it

(switch) #enable password
(switch) #configure
(switch) (Config)#username admin password

Then enter the RADIUS server configuration – and prepare authentication via RADIUS where Netger uses a concept of lists that contain methods of authentication (very close to Cisco IOS too). The first method will be use as long as it does not time out, I put local in there in case no RADIUS server is available. But since my environment was small and I wanted to keep the config files as small as possible I stuck to the default lists which for SSH and Telnet is the ‘networkList’.

(switch) (Config)#radius server host auth <ip|name> port 41812
(switch) (Config)#radius server key auth <ip|name>

(switch) (Config)#aaa authentication login "networkList" radius local

Still not getting to privileged mode?

The 10.x-based Netgears should let you authenticate with any user the RADIUS server allows to access, yet it doesn’t allow you to privileged exec mode other than with the local enable password. Here you have at least 3 options where for 2 of them I know how to achieve them:

Use a global enable admin (1)

You can configure ‘enableList’ (or create a enable List on your own) to do radius auth, but then it will ask your Server to verify a user called $enab15$ user (this is actually documented in the CLI manual). Obviously the point of having personal admin acccounts is to have shared global admin passwords agains. This works and is documented in the CLI manual personally but I don’t really like this idea.

Tell the switch that about being an administrative user (2 & 3)

Then you can configure your RADIUS server to inform the switch via additional reply message: “this is an admin, let him/her to privileged mode”. For Netgear the message is Service-Type = Administrative-User – finding this out was possible thanks to similarities with Dell PowerConnect and by trying it out.

(2) If you have your own lists you’ll have to figure out how to configure the switch to work correctly but in case you use the default lists (3), you have to tell your switch to interpret the additional message with:

(switch) (Config)#aaa authorization exec default radius local

For the Web-UI this additional reply message from the RADIUS server is (interestingly!) not required for the Web-UI. Any user your RADIUS-Server sedns “Access-Accept” gets full access to the Web-UI. (I’ll re-check this) Make sure you only let members of your admin group pass at the level of the RADIUS server. If you are ok with this, you only have to tell http method to use radius too:

(switch) (Config)#ip https authentication radius local

Obviously you can send cisco-avpair = “shell:priv-lvl=15” which is what you can do with Cisco Switches – the advantage being that you (should) be able to more granuarly pass privilege level although I haven’t investigated what the different privilege levels other than 15 (admin) means on Netgear.

Finally on 10.x the serial ports (line console) don’t use networkList by default but defaultList – by modifying networkList you obviously leave console to local authentication only – what’s your though on this? If I have physical access to the device should I make it possible to silently try and error network admin passwords or should I make things consistent for all logins?

 

Differences to pre-10.x firmware

For Firmware 8.0-based switches that can’t be updated to 10.x firmware things are a bit different – and likely 9.0 too according to CLI manuals. I didn’t have any’ 9.x available as all have been legit for 10.x upgrade).¬† The ‘aaa authorizaion’ command didn’t exist back then. Instead of this, create an authentication list and map it to the ssh method. The additionnal message from your RADIUS server thereafter is sufficient to get to enable mode.

aaa auhentication login mylist radius local
line ssh
(switch) >login authentication mylist

Difference in enable behaviour

Both 8.x/9.x and 10.x will happily pass you to privileged exec mode on a CLI with following differences (with this config, YMMV)

  • 10.x will put you directly into privileged exec mode (Prompt: hostname) #) if it has received Service-Type= Administrative-User
  • 8.x/9.x will continue asking for the enable command but let you pass without additional password query
  • 10.x will NOT let you in without this message – even if the RADIUS-Server has sent ‘Access-Accept’
  • 8.x/9.x will let any user to CLI for which it has received an “Access-Accept” – but it will deny privileged exec mode without receiving the additional message from the RADIUS server:
(8.x-switch) >enable

Access Denied! You are not authorized to enter into Privilege mode!

In a later post I’ll jot down a sample configuration for basic switch admin authentication for FreeRADIUS, note that Netgears only do the most basic RADIUS authentication method called PAP. With FreeRADIUS this requires you to have passwords store in cleartext in your password database¬† (which is not what AD does but NT hashes) – but there is a workaround for this dilemma at least with AD.

References

P.S. The chances are good that if you have some Dell PowerConnect switches and yet see FASTPATH mentioned in SNMP MIBs, Manuals etc. or you think that the syntax looks very close to Netgear Рyes both are running on the same Broadcom FASTPATH software (based on some embedded Linux kernel).

ftp://downloads.netgear.com/files/GDC/M5300/M5300_CLI_Aug2012.pdf

July 16, 2013

Posted In: Uncategorized

Tags: , , , ,

Leave a Comment