OS X Moutain Lion RADIUS: Logging & SACL

In our follow-up of RADIUS on OS X Mountain Lion we will look at some logging options and setting up a Service Access Control List (SACL).

RADIUS Logging:

The radiusconfig command can be used to adjust how freeRADIUS will do some of its logging, more specifically whether it logs authentication requests.

Again we will use a root shell (sudo -s) simply because making any changes to the radius server requires root priviledges for all the commands, so instead of typing sudo all the time, we can avoid that temporarily by using a root shell. You will require a root shell in any case in order to explore some of the radius directories, including where it logs to.

First up, let run radiusconfig -getconfig, here you will notice the following output.

"radiusd.conf" =     {
        auth = no;
        "auth_badpass" = no;
        "auth_goodpass" = no;
        "cleanup_delay" = 5;
        "hostname_lookups" = no;
        "max_request_time" = 30;
        "max_requests" = 1024;

The keys we are interested in are the top three. auth = no, control whether it will log authentication requests. The two below it, determines whether it will log a bad password attempt and/or a good password attempt. To enable authentication logging, we execute the following command:

radiusconfig -setconfig auth yes

To enable logging the other two is as simple as:

radiusconfig -setconfig auth_badpass yes
radiusconfig -setconfig auth_goodpass yes

If we run radiusconfig -getconfig, it should now look like this:

"radiusd.conf" =     {
        auth = yes;
        "auth_badpass" = yes;
        "auth_goodpass" = yes;
        "cleanup_delay" = 5;
        "hostname_lookups" = no;
        "max_request_time" = 30;
        "max_requests" = 1024;

If you plan to enable this type of logging its best to also enable auto rotation of the log file, again radiusconfig will do the trick.

radiusconfig -autorotatelog on

Any changes to the RADIUS server requires it to be restarted. You can use either one of the following options.

To stop RADIUS:

radiusconfig -stop
launchctl unload -w /System/Library/LaunchDaemons/org.freeradius.radiusd.plist

To start RADIUS:

radiusconfig -start (to start the server)
launchctl load -w /System/Library/LaunchDaemons/org.freeradius.radiusd.plist

Log files are stored in /var/log/radius.

Service Access Control List (SACL)

Having a SACL implemented for a service such as RADIUS is useful, as we can then control who has access to wifi. Without it, any user on our OS X Server has access to wifi, including ones from connected Directories. Lets dig in...

The SACL we are interested in is com.apple.access_radius. How do we know this? Lets quickly run our RADIUS server in debug mode, thus stop the server if its currently running, then run radiusd -sfX. Open another Terminal window and run the following, be sure to change user and password to a valid user on your system:

radtest user password localhost 0 testing123

If you look closely at the debug output you'll notice this section:

[opendirectory] The SACL group "com.apple.access_radius" does not exist on this system.
[opendirectory] The host does not have an access group.
[opendirectory] User raduser1 exists in OD
[opendirectory] no access control groups, all OD users allowed.
[opendirectory] Setting Auth-Type = opendirectory

From that we can draw the conclusion that if we had such a SACL group, that it would check whether a user is part of the group and grant or deny access as required. 

Creating the group can be achieved with dseditgroup.  The following command will create a group in the local directory node called com.apple.access_radius.

dseditgroup -o create com.apple.access_radius

If you stopped the RADIUS server, start it in debug mode again and repeat the step above with radtest. You will now see the output reflects our new SACL and looks like this:

[opendirectory] The host does not have an access group.
[opendirectory] User raduser1 exists in OD
[opendirectory] User raduser1 is not a member of the RADUIS SACL
++[opendirectory] returns reject
Invalid user (User is not authorized): [raduser1/raduser1pw] (from client localhost port 0)
Using Post-Auth-Type Reject

As per the text in bold we can see the user is rejected as it doesn't have the required authorisation due to not being part of the SACL group.

Keep the RADIUS server running.

Adding Users to the SACL

Using Server app, we first need to enable viewing of System Accounts, this can be done by clicking on the View > Show System Accounts in the menu bar. Select Groups in the Server app's sidebar. Then select "Local Groups" and scroll down and double click com.apple.access_radius. Add the same test user you used in the radtest command earlier.

See the screenshot below.

Run our radtest again. Notice the difference now in radiusd's debug output.

[opendirectory] The host does not have an access group.
[opendirectory] User raduser1 exists in OD
[opendirectory] User raduser1 is a member of the RADUIS SACL

In our example, raduser1 is granted access due to being part the com.apple.access_radius group and as such is authorised to use the RADIUS service .

You can now stop radiusd and set it to run as per usual:

launchctl -load -w /System/Library/LaunchDaemons/org.freeradius.radiusd.plist

There you have it. Now we have a working RADIUS server with a way to control who has access by adding/removing users as needed from the com.apple.access_radius group.

A more neat solution would be to create a new Network Group called "Wifi Access" or something similar, then adding this group to our com.apple.access_radius SACL. That way we can hide the System Accounts and add/remove users as per normal to "Wifi Access" instead.

Configure RADIUS on OS X Moutain Lion 10.8

Apple’s OS X Server has always been capable of running as a RADIUS server for as long as I care to remember. The now defunct Server Admin was able to target Apple’s Airport Extreme and Time Capsule, enabling them to create WPA2/WPA Enterprise Wifi networks. 

The underlying technology back then and still is freeRADIUS. 

Today however, there are no more tools available other than Server app, which if your Apple base station is configured in a certain way, will show up in the sidebar of Server app.  Setting up RADIUS is now a mere checkbox and requires an Apple base station if you want to enable RADIUS via a GUI. 

Perhaps you don’t have an Apple base station and/or would like to set up RADIUS for another type of Wifi access point. Fear not there is hope! You just have to delve into command line to get things done. 

This guide assumes you have OS X 10.8.3 installed with Server app, Open Directory configured and have a WPAx Enterprise capable Wifi access point with an IP address of

There are a few steps to complete.

  • Add a Network Access Server (NAS)
  • Configure certificates
  • Configure Wifi Access Point

Add a Network Access Server (NAS)

Open up the Terminal app and enter a root shell by running sudo -s and entering your admin password.

Add your NAS device as follow. Note: After running the command you’ll be prompted enter a shared secret, ideally this should be a strong password.

radiusconfig -addclient ZyXEL

You can double check that it was added correctly by running this:

radiusconfig -naslist

Configuring Certificates

For this exercise we will make use of a default SSL certificate that can be found in /etc/certificates, called Server Fallback SSL Certificate.

Installing the certificate is done by running radiusconfig -installcerts <private-key> <certificate> <trusted-ca>. Your certificates will have a different name. Just follow my example and replace certname in each of the three paths with your certificate's name in the command below.

radiusconfig -installcerts /etc/certificates/certname.key.pem /etc/certificates/certname.cert.pem /etc/certificates/certname.chain.pem

As we are using a certificates generated via Certificate Assistant, we need to make a tiny adjustment to the eap.conf file in /etc/raddb. To do this we use the following command.

radiusconfig -setconfig private_key_password Apple:UseCertAdmin

For interest sake, all this does is change the eap.conf file as per the before/after screenshot below.

At this point you server is ready to go, test it by running radiusd in debug mode:

radiusd -sfX

This will run your server in debug mode for testing purposes. If all is well, the last line will say “Ready to process requests.”

Configure Wifi Access Point

We still have to configure our Wifi access point though. How you do this will vary from device to device, I will just provide a guideline here of what it looks like on a ZyXEL router’s Wifi configuration.

Once completed, try connecting to your new WPAx Enterprise wifi network and look at the debug output of radiusd. You should see some output saying “Sending Access-Accept of id.....” That indicates that the client was accepted and is connected.

Hit Ctrl+C to stop the server.

Finally have radiusd launch persistently.

launchctl load -w /System/Library/LaunchDaemons/org.freeradius.radiusd.plist

Exit your root shell.

You now have a very basic RADIUS server running on OS X Mountain Lion!

In a follow up post I will detail a bit more about logging and the SACL that can be implemented on top of our existing RADIUS server.