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 127.0.0.1 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 127.0.0.1 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.

View fullsize

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

[opendirectory] The host 127.0.0.1 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.