Tag Archives: open directory

Configuring basic RADIUS on OS X 10.8 Server

For small deployments of Mac OS X Server, RADIUS based Wi-Fi referencing Open Directory can be a clean, secure way to provide employee access to the business network, and mitigates the problems of having one shared passphrase that rarely changes. Apple have provided automatic configuration of RADIUS and Airport base stations in OS X server for a while, but the FreeRADIUS install used by Mac OS X is of course able to provide RADIUS services to non-Apple APs and VPN services. Whilst not recommended for large deployments, this setup can do a very good job for many small to medium businesses with a highly mobile workforce.

In 10.8 server, like many services embraced in years gone by, RADIUS has disappeared into the deep dark depths of command line configuration. The following commands will get basic RADIUS functional on 10.8 Mountain Lion server for use with whichever RADIUS authenticator you wish.

All of the commands below assume that you are elevated to superuser:

sudo -s

Firstly, we have to create the SACL for accessing the RADIUS service:

dseditgroup -q -o create -u -n . com.apple.access_radius

Now, set some logging options for the RADIUS service. We want to log authentication attempts good and bad, and rotate logs and accounting information regularly:

radiusconfig -setconfig auth yes
radiusconfig -setconfig auth_badpass yes
radiusconfig -setconfig auth_goodpass yes
radiusconfig -autorotatelog on -n 15

Now we are going to add a client (RADIUS authenticator – access point, VPN endpoint). The first argument here is the IP of the client, the second is a shortname (alias), and the third is the client type. In most cases, this is other. More info can be found on types by reading the config files in /etc/raddb:

radiusconfig -addclient <IP> <short-name> other

Now, we need to generate or export an existing certificate for use with the RADIUS service. You need your certificate identity (certificate and private key) in a .p12 file to be referenced in the next set of commands. If you are unsure how to do this, the whole process is completed in the video at the bottom of this post.

Next, split the certificate identity into a separate, unencrypted certificate and private key, then install them into your RADIUS configuration:

openssl pkcs12 -in /Users/admin/Desktop/Identity.p12 -out /etc/raddb/certs/server.key -nodes -nocerts
openssl pkcs12 -in /Users/admin/Desktop/Identity.p12 -out /etc/raddb/certs/server.crt -nodes -nokeys
radiusconfig -installcerts /etc/raddb/certs/server.key /etc/raddb/certs/server.crt

At this stage, you can run radiusd with a debug flag to ensure everything is running as planned. With the -X flag on, you will see far more verbose output than you will ever see in the service logs, so if you are having any trouble, use this flag and look for problems:

radiusd -X

If everything went as planned, you will see Ready to process requests. at the end of your output. Now, add a user to the com.apple.radius_access local server group, and test authentication. You should see a whole lot of output fly by, and eventually catch a Sending-Access-Accept block when the user is authenticated, authorised, and connects.

Now, you can kill the debug process with Control-C, and start the service properly. This will start the RADIUS service and make it persistent across reboots:

radiusconfig -start

With that, you should have a fully functional basic RADIUS setup going. For all the commands inline, head over to this github:gist. For a more involved overview of the steps, check out the video.

The video below is a run through of all the steps required to get basic RADIUS configuration functional on a fresh 10.8 server instance, including Open Directory promotion, user and SACL creation, and importing a new self-signed certificate into your config. In this lab, we are using an Aerohive AP330 access point as the authenticator and access point for our wireless network.

I hope you found the commands and video lab useful.

List of all commands on github:gist


Hosting mail on 10.5 server with a 10.7/10.8 Open Directory

In one of my deployments, an emotional connection to an ageing Xserve G5 has meant that mail services continue to be hosted on 10.5 server. With almost all stock packages ripped out replaced with up to date or custom variants (big shoutout to Topicdesk!), everything works very smoothly, and has done for many years.

With the advent of Lion server however, directory and collaboration services were moved to a new Mac mini running 10.7, and as the OD was old and messy, it was entirely rebuilt from scratch, with manual entry of users and groups in Server.app. As 10.5 mail services are keyed off a users shortname and not the GUID, mailboxes carried across nicely when the Xserve was bound to the new 10.7 directory.

An error was encountered however, when users attempted an IMAP login:

Mar 28 12:23:45 mail imaps[27929]: badlogin from: jeddambp []. CRAM-MD5 user: johnsmith. mail is not enabled for this user

Mail SACLs were set correctly for users, but the error persisted.

10.7, having omitted the Mail tab from Workgroup Manager, maintains no way to set individual user quotas, or set a user’s mail server from within the GUI. In doing so, the MailAttribute attribute is not created in a 10.7 directory by default, unless mail services are hosted on the same machine.

Mail service on the 10.5 server was therefore restored by re-defining a MailAttribute based on the following plist for each user you want a mailbox for:

<?xml version="1.0" encoding="UTF-8"?>
<string>Apple Mail 1.0</string>

You will need to define kMailAccountLocation as your mail server’s hostname, and have the ability to set individual user quotas for users with the kUserDiskQuota key.

Adding this attribute is fairly easy in Directory Utility by navigating to the Directory Editor Tab, and clicking the plus button in the horizontal divider. You could also do this for a larger number of users by using dscl. There is good article here that has some examples of doing similar things.


Verifying your Open Directory databases using Nagios

Verifying individual .bdb files in an Open Directory instance is something I have traditionally performed as a troubleshooting step only once a major directory services failure is identified. Recently however, I have moved a weekly scripted verification to my Nagios workflow, and have been pleased with the results.

check_od_bdb.sh is a simple bash script which traverses over the bdb files in /var/db/openldap/openldap-data/, verifies them, and returns any failures it encounters. Due to the non-locking nature of the underlying db_verify tool that it uses, I wouldn’t be running this every 5 minutes in a production environment, but a weekly check should give you some peace of mind that your Open Directory instance is sailing along healthily.

check_od_bdb.sh on GitHub