RADIUS Setup for OS X El Capitan – Server 5.x

Quite simple to setup. First paste in the following commands.

radiusconfig -setconfig auth yes
radiusconfig -setconfig auth_badpass yes

Now install an SSL cert/key pair for your host, the built in ones are found in /etc/certificates or you followed my previous article about becoming a certificate authority and you have the certs on hand.

radiusconfig -installcerts /path/to/key /path/to/cert


Now… if you didn’t make your own CA and you’re using the built in Apple Server certs then you’ll have to do some extra magicary. First use pull an ls /etc/certificates and not the key, cert, and chain files for your host.


radiusconfig -installcerts /path/to/key.pem /path/to/cert.pem /path/to/chain.pem
radiusconfig -setcertpassword
Apple:UseCertAdmin


The last line is the ‘magic’ that I spoke of earlier.

Finally add some clients

radiusconfig -addclient other

Then start the radius server

serveradmin start radius


When I did this recently I didn’t have a way to test the server so I installed the FreeRadius server via brew.

brew install freeradius-server

And then tested the server by using radtest The binary can be found in the following directory /usr/local/Cellar/freeradius-server/3.0.9/bin

The syntax of the command is as follows:

radtest username password radius-server[:port] nas-port-number secret

Here’s an example:

radtest username password 192.168.1.1 10 secret


An Access-Accept is a passing grade!

Open Directory Replication 10.8.5 problems with Kerio Connnect 8.3.0

I recently was hired to implement an Open Directory Master/Replica into a network that wanted to leverage Kerio Connect mail server. At first, all seemed fine. I created the directory, the replica, and installed the kerio extension on both servers as was instructed by the fine folks at Kerio. Now I’d just like to say that this is different than what I remember in the days of 10.6. Back then you only had to install the OD extension on the master, the replica would then copy the schema over so that it could import the extended schema data at that time.

The problem comes into play when you have a master with already provisioned users in Kerio and you want to add an OD replica. Since the replica does not copy over the extended LDAP schema it is unable to replicate any provisioned users. The result is that those users will not exist in the replica which is bad news if you have services relying on that replica. To resolve this problem use the following procedure on the replica you wish to build:

sudo slapconfig -createreplica <master IP> diradmin

Once complete install the Kerio extention.

slapconfig -stopldapserver
slapadd -v -F /etc/openldap/slapd.d -c -l /var/db/openldap/openldap-data/backup.ldif
slapconfig -startldapserver


#gowellandinpiece
#replication

Automated Backups of Mac OS X Server 2.2.2

Hi Everybody!

So I’ve been in the Mac game for quite some time now and all along I was always longing for a good automated backup solution. A few years ago myself and a colleague got together and wrote osx-backup.sh. A simple shell script with a few variables inside. Simply edit the shell script and then install as a cronjob to run nightly. Features of this backup script include:

• Open Directory archiving
• Service Plists
• CalDAV/CardDAV database
• Profile Manager database
• DNS records
• Wiki database and binary files
• Webmail

I’ve been using this script for years now under 10.6, 10.7 and 10.8. The version listed here is for Server 2.2.2 under 10.8.5

Restoration of these backups is fairly simple to do as long as you know some postgres commands. Here’s the article on how to restore the wiki.

Calendar, webmail are fairly similar. DNS restoration is just a matter of placing the files back in /var/named and /etc/named.conf

If you need to restore open directory archive you should use Apple’s latest knowledge base instructions. Just make sure that the server hostname matches the backup.

To restore OS X Server setting plists:

sudo serveradmin settings < /path/to/your-sa_backup-servicename-plist

Get the code here.

Cisco AAA VPN and RADIUS on Mac OS X Server 10.8 – Mountain Lion

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

conf t
radius-server host <enter IP||FQDN> auth-port 1812 acct-port 1813
radius-server key <enter theKey>
aaa new-model
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.

Clean Up

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

Zentyal 3.0, Mountain Lion, Kerberos and SSO

Now with Zentyal, you can kerberize your shoes.

This article is a continuation of a really great read by shabangs.net His article is great to bind your Macintosh to a Zentyal directory server however, after completing the how-to I was unable to change a network user’s password, store a local copy of the network user’s password for “mobility” nor leverage some great single sign on services from zentyal.

What we will attempt is to configure /etc/krb5.conf for Mac OS X 10.8, Mountain Lion, so that we will receive a TGT from zentyal when the user either logs in or wakes the computer from sleep.

First you need to get the kerberos realm. To do this sign into Zentyal and go to Users and Groups. In here you’re looking for the LDAP search base, this base will also be your Kerberos realm.

Now we want to search and replace EXAMPLE.COM with that realm, and replace your.server.example.com with the FQDN of your Zentyal server. Only set the dns_lookup_* values to true if you’re using the Zentyal server for DNS.

All edits are client side ONLY
If /etc/krb5.conf does not exist then just create it.

[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_kdc = true
dns_lookup_realm = true
default_tgs_enctypes = arcfour-hmac-md5 des-cbc-md5 dec-cbc-crc
default_tkt_enctypes = arcfour-hmac-md5 des-cbc-md5 dec-cbc-crc
preferred_enctypes = arcfour-hmac-md5 des-cbc-md5 dec-cbc-crc

[kadmin]
default_keys = des-cbc-crc:pw-salt des-cbc-md5:pw-salt arcfour-hmac-md5:pw-salt aes256-cts-hmac-sha1-96:pw-salt aes128-cts-hmac-sha1-96:pw-salt

In order to obtain a Ticket Granting Ticket (TGT) when logging in via the login window, edit /etc/pam.d/authorization and append default_principal option to the pam_krb5.so line.


auth optional pam_krb5.so use_first_pass use_kcminit default_principal


In order to obtain a Ticket Granting Ticket (TGT) when authenticating to the Screen Saver, edit /etc/pam.d/screensaver and append default_principal option to the pam_krb5.so line.


auth optional pam_krb5.so use_first_pass use_kcminit default_principal


Now sign out and back in as a network user, open a terminal and type klist You should get something like:


lisa:~ test$ klist
Credentials cache: API:51104:6
Principal: test@EXAMPLE.COM

Issued Expires Principal
Mar 2 09:28:04 Mar 2 19:28:04 krbtgt/EXAMPLE.COM@EXAMPLE.COM


If so, great! This means kerberos is running, now try to change the user’s Open Directory password. It should succeed as well. If not make sure you have the console open to see what’s going on. 99% of the time it’s a DNS issue or the clocks on your workstation is out of sync with Zentyal.

Now try to mount an SMB volume from the Zentyal server, it *should* mount without credentials and a new ticket will appear in the output of klist


Issued Expires Principal
Mar 2 09:34:52 Mar 2 19:34:48 krbtgt/EXAMPLE.COM@EXAMPLE.COM
Mar 2 09:34:56 Mar 2 19:34:48 cifs/your.server.example.com@EXAMPLE.COM


Magic Triangle, Snow Leopard Server, Lion Clients

Just tried to bind a Lion client to our Magic Triangle infrastructure. Apple describes the problems as: A Mac OS X v10.7 Lion client may be unable to connect to a Mac OS X v10.6 Open Directory Server. This can happen if Lion uses Authenticated Binding to a Mac OS X v10.6 Open Directory Server that is also bound to Active Directory by means of a magic triangle.

Apple’s fix is to use Terminal to run a pair of shell commands on the Snow Leopard Server Open Directory Master Server and Replicas. Apple says:

Note: These commands will turn off GSSAPI authentication for the LDAP Server on the Mac OS X v10.6 Open Directory Master Server and Replicas. The servers will then use CRAM-MD5 authentication.

sudo rm /usr/lib/sasl2/openldap/libgssapiv2.2.so
sudo rm /usr/lib/sasl2/openldap/libgssapiv2.la

Restart the server after making this change.

If you want to restore the original settings, execute these commands:

cd /usr/lib/sasl2/openldap
sudo ln -s ../libgssapiv2.2.so
sudo ln -s ../libgssapiv2.la

Restart the server after making this change.