Posted: March 27th, 2013 | Author: jordan | Filed under: Mac OS X, Mac OS X Server, Open Directory, RADIUS, VPN | 3 Comments »
So you’re using Mountain Lion Server for Open Directory. Good for you! But beware of your users, they have requested VPN access to the network and like any good sysadmin you think, “Jesus H Christ, here’s yet another credential combo for the user to forget, for the user to call me at 10pm Friday night asking: ummmmmm, what’s my password?” FOR WHAT?!?! Jeezus Christ why don’t they ever tell us which password they forgot? Anywho, I digressed. Well with the power of RADIUS on your trusty Mac OS X Server you can now defer the authentication of your Cisco VPN gateway to your directory system. Let’s setup RADIUS on Mac OS X Server.
Prep the directory
Either you Mac an OD Master or bind to a directory, I think this is a given but, just saying. Then, whatever directory system you’re using, you must create a group called “VPN Access” or something to that effect, and subscribe the users and/or groups you want to have access to VPN. I don’t care if this is in Active Directory or Workgroup Manager or Server.app.
Build the RADIUS service
ARD into your Mac OS X server. In Server.app navigate to your hardware and then Settings. Note which SSL certificate your server is currently using and then find that certificate in Keychain Access. Right below it will be the key, right click on the key and choose Export, the destination will be /Users/Shared/cert.p12 and the password can be blank.
Open Workgroup Manager and edit local directory, authenticate yourself so you have read/write privileges. From the view menu enable Show System Records, then click on the groups tab, sort by GID. Scroll down to the 200’s and look for records like “com.apple.ard_access” “com.apple.afp_access” find the last of these groups and note the GID. Now create a new group, the long name is blank, the short name is “com.apple.access_radius” and the GID is incremented by 1 from the last GID you noted earlier. Save changes. GID 2xx
Once created click on the members tab and then “+” symbol. A side pane will appear, in this pane you can choose any directory system the OS X box is bound to, active or open. Cool hey? Add “VPN Access” group. Save the changes.
Open a terminal and “sudo -s” up. As the root user paste in the following:
radiusconfig -setconfig auth yes
radiusconfig -setconfig auth_badpass yes
radiusconfig -setconfig auth_goodpass no
radiusconfig -autorotatelog on -n 15
Now, run these one at a time, when prompted for password, enter the password that you set when you exported the cert from Keychain, I told you to put no password but God knows that sysadmins rarely do what they’re told. 😉
paste one at a time:
WATCH THE LINE WRAP!
openssl pkcs12 -in /Users/Shared/cert.p12 -out /etc/raddb/certs/radius.key -nodes -nocerts
openssl pkcs12 -in /Users/Shared/cert.p12 -out /etc/raddb/certs/radius.crt -nodes -nokeys
radiusconfig -installcerts /etc/raddb/certs/radius.key /etc/raddb/certs/radius.crt
Finally for the server let’s grant access to our Cisco box, IP is obviously the IP of the box, short-name is just a nickname for the system.
radiusconfig -addclient <IP> <short-name> other
You should be prompted to enter a key, please remember this key, let’s call it: theKey.
finally run radius in verbose with
radiusd -X Leave the terminal open, do not close. It will help us deduce answers should problems arise. If all goes well you should get something like:
Listening on authentication *:1645
Listening on accounting *:1646
Ready to process requests.
Connect your Cisco VPN gateway
radius-server host <enter IP||FQDN> auth-port 1812 acct-port 1813
radius-server key <enter theKey>
aaa authentication login vpn group radius local
aaa authorization network vpn local
You’ll need to connect this AAA stanza to your crypto map, my crypto map is called
VPN. This is how I did it, note the bold similarities.
crypto map VPN client authentication list vpn
crypto map VPN isakmp authorization list vpn
This will allow AAA to check the RADIUS server, but fall back to local auth if RADIUS does not respond.
Finally we’re going to test all of this by using the test command. So get out of conf t by typing exit and try the following:
test aaa group radius <username> <password> legacy
If it returns “User was successfully authenticated.” You’re in business. Also, note the terminal where
radiusd -X is running, you’ll see some interesting output.
wr mem on your router and exit the session. Cancel that
radiusd -X process we started and set the process to run.
serveradmin start radius Immediately test the connection from the outside to ensure it’s stable.
Check out my next post: Authenticate APC UPS against RADIUS on Mac OS X Server 10.8 Mountain Lion
Posted: October 13th, 2009 | Author: jordan | Filed under: Free Geek, Insight, LDAP, Vancouver, VPN | No Comments »
As I touched on very briefly in one of my previous posts, I volunteer. I volunteer for a non-profit organization by the name of Free Geek. It’s the local chapter here in Vancouver and they have a very simple purpose. Their website states: Free Geek is a nonprofit community organisation that reduces the environmental impact of waste electronics by reusing and recycling donated technology. Through community engagement we provide education, job skills training, Internet access and free or low cost computers to the public.
When I first arrived at Free Geek I was amazed at how much computer hardware there actually was, but even MORE amazed the second time I went to see that it all had changed. I mean, all of it. The amount of hardware that that flows through their doors is mind boggling. Immediately I knew this was something I wanted to be a part of. I met one of the founders and explained my talents and I what I could do for them, Ifny LaChance, she hugged me! She explained that Free Geek was desperately in need of a good Systems Administrator as their current person could not adequately handle the failing systems. The Free Geek infrastructure suffered from network outages, power outages, overheating, and poor performance, and they were all considered part and parcel of the environment. Most of the users had learned to live with it, or work around the issues.
They use a system called LTSP for all of their public and private workstations. These workstations were at a crawl. The first thing I took care of was all the physical wiring between computers, switches, and servers. While pulling cable out I would find the oddest things, like a six foot ethernet cable running from a switch to hub, then from that hub another cable extending about four feet to a switch. This switch was not only then connected to three different computers but also plugged back into the same switch that this connection originated from! After the wiring had been taken care of, an 802.1d trunk was introduced between two main switches and then VLAN’s were placed on the network to segregate subnets up a little better and to give some added security.
Since then I’ve gone on to introduce an OpenLDAP directory system, integrate user authentication for all workstations and switches. Created an OpenVPN install and added services such as SNMP monitoring by way of Zenoss. I am on a never-ending mission to improve the stability and the scalability of their infrastructure while only being able to work with recycled hardware and open-sourced software. It has been a great challenge, but of all the years I have worked with technology I must say that nothing compares with the satisfaction I feel from knowing my hours of labour are enabling an amazing organization to help keep this planet green and give back to the community.
Please visit their website to see how you can help. freegeekvancouver.org
Posted: October 6th, 2009 | Author: jordan | Filed under: LDAP, VPN | 6 Comments »
I volunteer for an organization called Free Geek, it’s the local chapter here in vancouver and they are such an amazing group of people. Upon seeing the organization I felt compelled to get involved and offer my services as best I could for them. Since I’m a sysadmin by trade I figured that’s what I would do, although I what I did not know was the state of affairs in which their network lay. That is story onto itself however. For this post I’m going to be writing about the OpenVPN Access Server implementation I performed for them.
First, OpenVPN is a great product. Period. They make a secure, easy to configure and deploy, SSL based VPN solution. As long as you know how PKI works you can link multiple sites or users together in just a few minutes. For those of you though who do not want to bother all this command
OpenVPN AS User Portal
line stuff OpenVPN
makes a product called “Access Server.”
It’s an easy to install, complete with GUI admin interface VPN implementation. Basically the exact same thing as their open source version, just a HELL of a lot easier to get up and running. Especially for people who are not all familiar with VPN. Shown here in the thumbnail is what the user sees when he or she logs into the web interface of the vpn service. I very simple to read and understand page that asks them which OS they are on and how to configure that OS. Also listed here is the VPN key (client.ovpn) so they can setup their VPN software themselves.
To install this wonderful service I first went here,
got an account and downloaded the necessary linux package. After installing I went back to the Access Server site and requested a license key. Yes, a license key. Here’s the catch about OpenVPN Access Server. It’s free, for the first two concurrent connections, after that you have to pay per connection. They’re $10 each, which is a HUGE savings over other solutions out there, and they’re sold in packs of five. For my needs though I only require two.
After installation, I forwarded ports 443 and 8443 thru my firewall to the VPN server. You can sign into the admin interface using the root credentials of the computer it resides on at https://webaddress/admin. To configure it I did the following, first under Configuration
I selected “License” and installed my license keys. Next, I went to “VPN Settings” and told server to route using NAT, client Internet traffic should NOT go thru the VPN, that clients WILL be allowed access to network services on the VPN gateway IP. If you have Mac clients connecting, it’s just easier to select NO to altering your client’s DNS records. If it’s just Linux you could do them same considering push DNS support is just not there for linux either.
Now it’s time for the fun part, OpenLDAP integration. On the left hand side under Authentication
select “LDAP.” Now you don’t have to use LDAP, it’s just that I do cause I like it. If you have a small user base, or if its just for you, use PAM. I don’t care. I don’t judge! (much…) Type in all the normal stuff, LDAP server, base DN, and username attribute. (Either uid, or uniqueMember, or user. Usually uid) This will authorize any valid user in your LDAP directory authorization attempt authentication, but for my purposes this was way too wide open. Free Geek has number of lame-o accounts for guest access that are part of our LDAP schema. So I want to restrict access to only member that are part of the LDAP group “vpn.” This however proved to be more difficult than originally thought.
In OpenLDAP it’s not common for a user entry to list what groups they are part of. In fact, it’s the other way around, you ask the group who its members are. Since OpenVPN want to use a filter on the user’s entry in OpenLDAP this setup was not going to work for me. Enter the memberOf overlay. For those of you who do not know what this does, let me explain. When you add a user to a group the user’s entry does not change, instead the group’s entry changes. So let’s say we add Sally to the group, lusers. If we queried the group lusers we would get an entry like:
But if we queried Sally’s account it would appear the same as before we added her to this group. Therefore we need to modify our OpenLDAP install to allow for a reverse membership.
What I had to do was stop the ”slapd” service on my LDAP server and edit my slapd.conf file and add the following two lines.
Then I had to create an ldif file with the following contents:
#contents of memberOf.ldif
description: Users allowed to connect on VPN
And add this to my ldap database
slapadd -f memberOf.ldif
After this I fired up the ldap server in debug to check for errors
slapd -d 99 -f /etc/ldap/slapd.conf and check to make sure that my group membership of “vpn” was listed in my user entry.
ldapsearch -h ldap -x -b "dc=shop,dc=lan" '(uid=jordan)' memberOf and bam! success!
# jordan, People, shop.lan
So I fired the init.d slapd service back up and went back to the OpenVPN admin interface. For the LDAP filter at the bottom of the window I entered
memberof=cn=vpn,ou=Groups,dc=shop,dc=lan I saved and restarted the VPN service and poof. I now have authorization based on group membership!