Authorzing External Servers to use your FreeRadius Server

FreeRadius is a fantastic piece of software, and one of the great things about it is practically any piece of software that is either Open Source or allows the development of plugins and extensions will be able to use a FreeRadius installation either by use of an existing plugin or you creating one!

The benefits of a centralized authentication system is very valuable in a network and large scale multi-service provider. A user taking the same credentials with them everywhere they go is a great way to make the user experience of a product or a set of products far more pleasurable and easy – I mean who likes having 1000s of accounts, usernames and passwords?

By default however, FreeRadius only allows (and only has configuration for)localhost to attempt authentication. So how do we add permission for an external server you ask? Let’s find out!

Remote Server Requirements

Before we try to give permission to a server for authentication attempts we need to make sure that a few basic settings of the server suit the requirements of a server for FreeRadius.

A Static IP Address or; A public hostname that will have a valid reverse DNS lookup

Servers with permission to use FreeRadius are identified by a specified IP Address or hostname. For an extra layer of security when it comes to hostnames (because let’s face it, its so easy for a server to pretend that it is someone else with a spoofed hostname) the hostname must pass a reverse DNS lookup when the server attempts to verify an authentication with FreeRadius.

This means that if you want to specify a server by it’s hostname, you need to make sure that it’s reverse dns will pass ok!

A secure connection? or over the public web?

I am a massive fan of running secure connections for your radius auths. Auths are clear-text and that means even if you are collecting a user’s credentials over SSL or other means, when you go to send them to the remote radius server – yep it’s going to be unencrypted and plain to see for every hop on the internet highway between you and your radius server.

So what could you do about this? Well if both your servers are on the local network then there is probably nothing to worry about (except maybe tech savvy IT family members and employees sniffing the network), otherwise probably the best thing you could do is have a VPN connection between your two servers, and configure your servers to talk over that connection. This way traffic between the two servers are encrypted, and as an extra bonus, if the VPN server is setup on the radius server then you could even go as far as reserving an IP address for the VPN user account that is for the external server meaning that your radius couldn’t be more secure as it’s only listening to inbound requests from the VPN DHCP pool!

Anyways, that aside – Let’s begin!

I could talk forever about security practices and suggestive setups and the like, however that’s beyond the scope of this doco, so from here on it we’re going to focus on a very ‘vanilla‘ setup. You can build upon this tutorial however you like and if you have security questions post them in the comments!

To help explain a few ideas we’re going to use the following scenario in our demonstration

The Scenario – Xavier’s Widgets & Co

The company has 2 factories (one in Australia and the other in Taiwan), a head office in Sweden (because that’s a pretty classy place to live) and 2 sales offices (UK and the USA) and an Administration office in Sweden’s HQ building.

The head office has a Samba server that hosts the company’s files, the factories have web based ordering systems (Apache) and the sales offices host nothing of value, they only contribute to the network.

The company requires staff in all locations to be able to login to the Head Office VPN in Sweden, and our factories in Taiwan and Australia using the same credentials for all locations.

So you have come up with this little solution:

The company wants the most secure setup possible, so your suggesting that they use a VPN server on the radius that gives out the following IP addresses for the following clients:

• tw.xavwco.com – 192.168.50.101
• au.xavwco.com – 192.168.50.102

Since the Samba server is on the same LAN as the Radius and the company isn’t concerned about radius traffic over a LAN we can just add a rule for it’s LAN identifier, there is no need to configure it to use the VPN. However the workstation gets it’s IP address from a Windows Server that hosts a DHCP service, so we cannot rely on a static IP in our configuration, what we can use however is the workstation’s hostname which is swadmin1, and reverse dns will work as they are using a local dns server.

They only want the radius to respond to IP addresses that are VPN clients for radius work and localhost. And the great thing is, FreeRadius does this out of the box for you (If an authorization request is received by FreeRadius that is not from an approved source or contains the wrong secret, then the request is ignored and it will appear from the requesting side that nobody is listening!)

Modifying clients.conf

Depending on your linux distro, this file could be in 1 of a couple locations, the most common locations / distros are listed below with a nano command to edit it, you are of course free to use whatever editor your partial to!

CentOS:

nano /etc/raddb/clients.conf

Ubuntu:

nano /etc/freeradius/clients.conf

Once we have this file open we need to scroll right down to the bottom of the file and add our entries for our servers.  First off we will add the Administration PC in the Sweden HQ:

client swadmin1 {
        secret          = 85r9j76to87o8u6ro8
        shortname       = sweedenAdminPc
        nastype         = other
}

And if you save that, then the Admin PC is now able to authenticate logins against FreeRadius

Now we need to add the other servers, notice how the IP address of the server goes in the same spot as where we specified the hostname of the Sweden admin pc:

client 192.168.50.102 {
        secret          = o87qfm9a8m8pasmfjk
        shortname       = auFactory
        nastype         = other
}
client 192.168.50.101 {
        secret          = 2q309dm90jaksuyege
        shortname       = twFactory
        nastype         = other
}

Remember after you make changes you need to restart FreeRadius:

CentOS:

service radiusd restart

Ubuntu:

service freeradius restart

You should see something like this:

And then you’re done! You have now successfully authorized external servers to use your FreeRadius server. Well Done!

Xavier.