Install the RADIUS Server on a Synology

Don’t let the name fool you, RADIUS, or Remote Authentication Dial-In User Service is more widely used today than ever before. This protocol enables remote access to servers and networks and is frequently a fundamental building block of VPNs, wireless networks and other high-security services that have nothing to do with dialup bulletin boards from the 80s. 

I’ve run RADIUS services on Mac servers for years. But as that code starts to become stale and no longer supported, let’s look at running a basic RADIUS service on a network appliance, such as a Synology. To get started, open Package Manager, click All in the sidebar and then search for RADIUS. 

Click Install for the RADIUS service.

Once installed, open RADIUS Server from the application menu in the upper left hand corner of the screen.

The options aren’t like raccoon. You can select a port, choose a directory service (which covers the authentication and a bit of the authorization portions of RADIUS. Click Clients and then Add.

Here you can configure a shared secret for a client, and allow for the source IP and netmask. To grab your certificate for deployment to clients, open the Control Panel, then Security, then Certificate and export the .p12. If you’re using this RADIUS service to enable other services for Macs, you’ll likely then want to distribute that certificate in a profile. We’ll cover how to leverage RADIUS for other services in other articles.

Set Up The VPN Server and Client on Yosemite Server

OS X Server has long had a VPN service that can be run. The server is capable of running the two most commonly used VPN protocols: PPTP and L2TP. The L2TP protocol is always in use, but the server can run both concurrently. You should use L2TP when at all possible. Sure, “All the great themes have been used up and turned into theme parks.” But security is a theme that it never hurts to keep in the forefront of your mind. If you were thinking of exposing the other services in Yosemite Server to the Internet without having users connect to a VPN service then you should think again, because the VPN service is simple to setup and even simpler to manage. Setting Up The VPN Service In Yosemite Server To setup the VPN service, open the Server app and click on VPN in the Server app sidebar. The VPN Settings  screen has two options available in the “Configure VPN for” field, which has two options:
  • L2TP: Enables only the L2TP protocol
  • L2TP and PPTP: Enables both the L2TP protocol and the PPTP protocol
vpn1 The VPN Host Name field is used by administrators leveraging profiles. The setting used becomes the address for the VPN service in the Everyone profile. L2TP requires a shared secret or an SSL certificate. In this example, we’ll configure a shared secret by providing a password in the Shared Secret field. Additionally, there are three fields, each with an Edit button that allows for configuration:
  • Client Addresses: The dynamic pool of addresses provided when clients connect to the VPNvpn2
  • DNS Settings: The name servers used once a VPN client has connected to the server. As well as the Search Domains configuration.vpn3
  • Routes: Select which interface (VPN or default interface of the client system) that a client connects to each IP address and subnet mask over. vpn4
  • Save Configuration Profile: Use this button to export configuration profiles to a file, which can then be distributed to client systems (OS X using the profiles command, iOS using Apple Configurator or both using Profile Manager).
Once configured, open incoming ports on the router/firewall. PPTP runs over port 1723. L2TP is a bit more complicated (with keys bigger than a baby’s arm), running over 1701, but also the IP-ESP protocol (IP Protocol 50). Both are configured automatically when using Apple AirPorts as gateway devices. Officially, the ports to forward are listed at Using The Command Line I know, I’ve described ways to manage these services from the command line before. But, “tonight we have number twelve of one hundred things to do with your body when you’re all alone.” The serveradmin command can be used to manage the service as well as the Server app. The serveradmin command can start the service, using the default settings, with no further configuration being required: sudo serveradmin start vpn And to stop the service: sudo serveradmin stop vpn And to list the available options: sudo serveradmin settings vpn The output of which shows all of the VPN settings available via serveradmin (which is many more than what you see in the Server app: vpn:vpnHost = "mavserver.krypted.lan" = "/var/log/ppp/vpnd.log" = 1 = 128 = _empty_array = _empty_array = "1" = "" = "2" = "" = yes = "PPTP" = "PPP" = 5 = 1 = "EAP-RSA" = "DSACL" = 1 = 0 = 1 = 1 = 60 = 1 = "MSCHAP2" = 0 = "DSAuth" = "/var/log/ppp/vpnd.log" = 1 = 7200 = "MPPE" = "Manual" = "" = "" = _empty_array = _empty_array = _empty_array = "" = 128 = 0 = "/var/log/ppp/vpnd.log" = 1 = _empty_array = _empty_array = "1" = "" = "2" = "" = yes = "L2TP" = "PPP" = 5 = 1 = "EAP-KRB" = "DSACL" = 1 = 0 = 1 = 60 = 1 = "MSCHAP2" = "DSAuth" = "/var/log/ppp/vpnd.log" = 7200 = "Keychain" = "" = "" = "SharedSecret" = "" = "None" = <> = "Manual" = "" = "" = _empty_array = _empty_array = _empty_array = "IPSec" = "yaright" To disable L2TP, set to no: sudo serveradmin settings = no To configure how long a client can be idle prior to being disconnected: sudo serveradmin settings = 10 By default, each protocol has a maximum of 128 sessions, configureable using sudo serveradmin settings = 200 To see the state of the service, the pid, the time the service was configured, the path to the log files, the number of clients and other information, use the fullstatus option: sudo serveradmin fullstatus vpn Which returns output similar to the following: vpn:servicePortsAreRestricted = "NO"
vpn:readWriteSettingsVersion = 1 = "MSCHAP2" = 0 = yes = "MPPEKeySize128" = "PPP" = "PPTP" = "DSAuth" = "MSCHAP2" = "PPP" = yes = 0 = "L2TP" = "DSAuth"
vpn:servicePortsRestrictionInfo = _empty_array
vpn:health = _empty_dictionary
vpn:logPaths:vpnLog = "/var/log/ppp/vpnd.log"
vpn:configured = yes
vpn:state = "STOPPED"
vpn:setStateVersion = 1 Security folk will be stoked to see that the shared secret is shown in the clear using: = "a dirty thought in a nice clean mind" Configuring Users For VPN Access Each account that accesses the VPN server needs a valid account to do so. To configure existing users to use the service, click on Users in the Server app sidebar. vpn5 At the list of users, click on a user and then click on the cog wheel icon, selecting Edit Access to Services.


At the Service Access screen will be a list of services that could be hosted on the server; verify the checkbox for VPN is highlighted for the user. If not, click Manage Service Access, click Manage and then check the VPN box. vpn7 Setting Up Client Computers As you can see, configuring the VPN service in Yosemite Server (OS X Server 2.2) is a simple and straight-forward process – much easier than eating your cereal with a fork and doing your homework in the dark.. Configuring clients is as simple as importing the profile generated by the service. However, you can also configure clients manually. To do so in OS X, open the Network System Preference pane. From here, click on the plus sign (“+”) to add a new network service.vpn8 At the prompt, select VPN in the Interface field and then either PPTP or L2TP over IPSec in the VPN Type. Then provide a name for the connection in the Service Name field and click on Create. vpn9 At the list of network interfaces in the Network System Preference pane, provide the hostname or address of the server in the Server Address field and the username that will be connecting to the VPN service in the Account Name field. If using L2TP, click on Authentication Settings. vpn10 At the prompt, provide the password entered into the Shared Secret field earlier in this article in the Machine Authentication Shared Secret field and the user’s password in the User Authentication Password field. When you’re done, click OK and then provided you’re outside the network and routeable to the server, click on Connect to test the connection. Conclusion Setting Up the VPN service in OS X Yosemite Server is as simple as clicking the ON button. But much more information about using a VPN can be required. The natd binary is still built into Yosemite at /usr/sbin/natd and can be managed in a number of ways. But it’s likely that the days of using an OS X Server as a gateway device are over, if they ever started. Sure “feeling screwed up at a screwed up time in a screwed up place does not necessarily make you screwed up” but using an OS X Server for NAT when it isn’t even supported any more probably does. So rather than try to use the server as both, use a 3rd party firewall like most everyone else and then use the server as a VPN appliance. Hopefully it can do much more than just that to help justify the cost. And if you’re using an Apple AirPort as a router (hopefully in a very small environment) then the whole process of setting this thing up should be super-simple.

10 Features I Miss From Mountain Lion & Mountain Lion Server

Apple’s not going to slow down innovation just to make me happy. I get that. But what have I noticed most about the differences between Mountain Lion and Mountain Lion Server and their predecessors, and maybe what to do to get some of them back?
  1. Podcast Producer: I am going to just put it out there. I liked Podcast Producer. I hope it shows back up in the future, even though I’m controlling my expectations. As someone who deals with a lot of video, there are a number of features that were really helpful to me, with or without Xgrid. I’ve replaced the command line aspects with tools such as ffmpeg, which we used in addition to at times, but some of the ways that pcastaction did things were really elegant comparably. On the graphical side, much of the functionality is available in the various sites that produce video streams and of course, there’s always YouTube. Either way, in regards to Mountain Lion Server, this represents one of the most substantial changes for those of us that deal with video.
  2. DHCP: I know, I know… I wrote an article on how to keep using DHCP. That doesn’t mean that the lack of GUI options is any less irritating. Every time I manually edit a config file that should have a GUI front-end it makes me ornery. Not that I’m not always ornery, but that’s not the point here…
  3. RSS: This is more of a client thing. But and Safari used to give me the ability to quickly and easily look at RSS feeds and handled them in a way that was very streamlined with my experience across the rest of the operating system. I am now using more and more Google Reader along with tools like Reeder, but I liked the fact that everything I needed for RSS madness was installed on even the test systems I used
  4. X11: I know, I know… Use XQuartz. It was nice having it built in though…
  5. Web Sharing: I guess the answer here is to just buy OS X Server. You can still fire up the LaunchDaemon and use Apache, but it’s a bit of a challenge. And the version in Server isn’t identical to Apache in Mountain Lion. There are two ways I’ve handled this. The first is to install Mountain Lion Server and then use the command `webpromotion demote` to switch the Apache configuration back to that of a client computer. The second is to fire up the LaunchDaemon directly using launchctl. If you’d like, there are also a number of free and/or 3rd party web servers, such as MAMP.
  6. Negative Mode: Well, I covered this already, and while the keystroke was gone, the feature never was – but here’s how to fix. Also, @sacrilicious turned me on to nocturne, which is pretty cool as well!
  7. iCal, Address Book and NetBoot: Actually, they’re now called Calendar, Contacts and NetInstall respectively. But still there. I actually like the renaming a lot, so I guess I don’t really miss any of them.
  8. Radius: OK, it’s there. Just command line only (unless you’re using an Apple AirPort). Maybe I should write an article about radius…
  9. The Server command line options: Actually, they just moved to a relative path to /Applications/, as I mentioned here.
  10. Server Admin: I was going to say FTP, then I remembered it’s back. And then I remembered I never missed it in the first place. But dropping the remainder of the GUI tools for servers represents a bit of a challenge, mostly in figuring out how to do a few of the minor things, like enabling Server Side File Tracking, etc.

Finishing RADIUS Kbase Article for AAPL

Troubleshooting radius is a crappy task. But crappy articles don’t help: To be more specific, the debug mode flag is -X (not sure why that was so hard). In that case it’s doing single server mode and the process cannot fork. You can also do the lowercase, -x (which is part of -X), or -xx for further granularity. In order to set the launchd item to debug mode you would therefore find the /System/Library/LaunchDaemons/org.freeradius.radiusd.plist file (only created once you’ve fired up RADIUS btw). From here, locate the array for invoking the command:
<string>/usr/sbin/radiusd</string> <string>-sf</string>
Change the -sf to either a -X or add an x or two in there as needed. I’ve also had to enable core dumps for troubleshooting RADIUS as well, which means editing the /etc/raddb/radiusd.conf file, looking for allow_core_dumps and changing it to an = yes instead of an = no. Anyway, just finishing their article for them as my own little core dump to you.

Basic pkcs12 Management with security

Recently, I did an article for where I explained that you can import a pkcs12 file into an 802.1x profile using networksetup. In that type of environment you would be leveraging TLS or TTLS with the Mac OS X client acting as the supplicant and the certificate required to establish authentication with the authenticator. So you need the certificate to get started, but how do you get the pkcs12 and dish it out to clients programatically? We’re going to start out with a new keychain where we’ve imported the certificate into that keychain (or skip this step if you already have a p12 file). First, find the certificate and verify the name, as this is very important to networksetup. For this, I like to use the security command’s find-certificate option. Here we’re going to look for
security find-certificate -c
Now we’ll use the export verb of the security command to dump a .p12 file from the specially created keychain called 8021xkey,keychain to my desktop:
security export -k 8021xkey.keychain -t certs -f pkcs12 -o ~/Desktop/krypted.p12
When run you’ll be asked for a password to give the new p12 for decryption. Once we have the keychain it can easily be imported, as we will do from the desktop of a client system:
security import ~/Desktop/krypted.p12 -f pkcs12
Now we can use the p12 along with the -settlsidentityonsystemprofile or -settlsidentityonuserprofile. For example (using the default AirPort as the service and mysecretpassword as the password to decrypt the p12):
networksetup -settlsidentityonsystemprofile AirPort ~/Desktop/krypted.p12 mysecretpassword
Overall, at this point you can finally automate the process of setting up the 802.1x aspect of a deployment using a script or a package. Simply setup profiles at the GUI, import them into the new computer (assuming you have setup the service names before hand) and if need be import the certificate. Much testing required though…

Mac OS X Server 10.5: Introduction to RADIUS

I originally posted this at Remote Authentication Dial In User Service (RADIUS) can help to take the security of your wireless network to the next level beyond standard WPA authentication. Prior to Leopard RADIUS communications could be obtained using Elektron or OpenRADIUS running on OS X – but in Leopard no 3rd party software is required beyond Leopard Server. So how difficult is it to setup RADIUS on Leopard? You be the judge after reading this quick walkthrough. For the purpose of this walkthrough we are going to assume that you are using the Advanced Mac OS X Server style. Before you begin this walkthrough, make sure that the server is running Open Directory and that the forward and reverse DNS information for the server is correct. The first step to using RADIUS is to enable it. To do this, open Server Admin, click on the name of the server in the SERVERS list and click on the Services tab. Find RADIUS in the services list and place a checkmark in the box to the left of it. When you click on Save then you should see RADIUS in the SERVERS list. Now that RADIUS has been enabled, let’s select a certificate. For the use of this walkthrough we’re going to use the default certificate that comes with OS X Server. Click on RADIUS under the SERVERS list and then click on the Settings button. Click on the RADIUS Certificate drop-down menu and select the Default certificate. Click on the Edit Allowed Users… button. By default all users of the OS X Server will have access to authenticate to the wireless network setup, so here we are going to click on the For Selected Services below Radio Button. Then click on RADIUS in the Service list. Now click on Allow Only Users and Groups Below and then click on the + sign. Now drag the users and groups into the Name list from the Users and Groups window. Once all users that should have access to your new wireless environment have been enabled, click on the Save button. From here, click on RADIUS and click on the Start RADIUS button in the bottom left hand corner of the screen. RADIUS is now ready to accept authentication. The next step is to configure an AirPort to work with RADIUS. To do this, click on the Base Stations button in the toolbar at the top of the screen. Now click on Browse and select the first base station of your new wireless environment from the list of found base stations. Enter the password for the AirPort and click on Save. Wait for the AirPort to complete its restart and then you should be able to log in from a client. To log in from a client, select the name of the wireless network from the wireless networks list and enter the username and password to the environment. The first time you do so you will get a second dialog asking you to enter the 802.1x username and password. Enter the same username and password and click on OK. If you click on the “Use this Password Once” checkbox then this password will not be saved for future use. That’s it, you’re done. Now this setup may be a little more complicated than WPA personal or WEP 128, but it’s far more secure and should be considered for any AirPort environment that has an OS X Server. While the default certificate will work for clients, things are often easier from a deployment and interoperability perspective if you purchase a certificate from a CA such as Thawte. Also, this has all been tested in a pure Mac OS X Leopard environment, not with an OD structure based on Tiger. More on that as time goes on…