Scott Gruby's Blog

Yesterday I wrote about using Passenger (mod_rails) for deploying Ruby on Rails applications. Well, this morning, I ran into my first problems with it. I had reports that WebDAV wasn’t working. After trying a bunch of ideas that I read about, I finally decided to try changing the load order of the Apache modules. I set Passenger to load first and then WebDAV load later. That amazingly fixed the issue; if it hadn’t, I would probably have had to scrap Passenger which would have been a huge disappointment.

When I first launched my first web site in Ruby on Rails (RoR) to get my store for ReceiptWallet (based on Potion Store) going, I learned a little bit about performance. A basic RoR application is launched each time a user hits a web site; this, of course, is only for development and isn’t practical for a production site. I opted to use lighttpd and FastCGI which worked well. However, modifying an part of the application required killing processes and restarting lighttd.

As a learned more about RoR and had to deploy more applications, I started using mongrel as we had a bug with lighttd that caused our application to not handle uploads. So I’ve been using mongrel for a bunch of RoR applications on 4 separate servers. Things work OK, but each time an application is updated, I have to either restart all of mongrel or kill individual processes and restart them (if I restart mongrel, non-updated apps get restarted and could disrupt people).

Last night as I was trying to catch up on some of my research (quiet time is only at night and allows me to leisurely do research), I came across Passenger which makes deploying RoR simple. All I have to do is setup the virtual host and point it to the RoR’s public directory and presto; this is in comparison to setting up mongrel with proxies from Apache. In addition, in order to restart an application after I update it, I just do ‘touch tmp/restart.txt’. Wow, that’s easy!

Is Passenger the holy grail for managing my RoR applications? It’s too early to know, but I’m optimistic.

One of the features of OS X Server’s LDAP is the ability to disable an account after X failed logins. While this sounds like a great thing to turn on from a security point of view, the implementation has a lot to be desired. I turned this on several months ago and within 30 minutes had to turn it off. The reasons why it is flawed are quite simple.

Let’s say you have a VPN, a mail server (incoming and outgoing), a calendar server and a chat server and you have the failed logins set at 4. Let’s also say that your mail server and calendar server are accessible outside of your VPN so that handheld clients that don’t have a VPN client can get in. Most, if not, all services on the Mac store your password in the keychain and many don’t offer you the option to enter it each time (which actually would get quite annoying). Next, let’s say you just changed your password using a provided mechanism (OS X server requires an add-on to offer this if you only use the LDAP server without all the other management capabilities). Within a few minutes, your mail client will check for mail with the old password, iCal will check your calendar with the old password, you might be sending mail with the old password, and you login to iChat using the old password. Boom, you just hit your 4 failed logins without you entering or being prompted for your password once.

A much more intelligent way to do this would be to have the 4 failed logins be 4 failed logins with different passwords. So if you tried to login 20 times with the same password, it would only be recorded as 1 failed login. Would this weaken security? I don’t think so, but could leave your server open for a denial of service attack. In that case, why not take an additional 10 seconds to authenticate for each failed login? So while it would take awhile to have your login fail, at least you could enter your new password without having to contact your administrator. If your administrator is any bit like me, password resets are not easy.

Leopard Server’s LDAP implementation allows an administrator to set requirements about user passwords, such as length of password, what characters it must include, how often it must be changed, etc. One major oversight on Apple’s part is a facility to inform users that their passwords will expire. Maybe if users login via AFP or using Network Home Directories they’d see a message, but we’re using LDAP for authentication from a bunch of other servers. As I didn’t want to have to remember to remind people to change their passwords, I came up with a script to handle it for me. I’ve seen other scripts out their, but they made some assumptions that didn’t work for us. Our mail server is on a different machine and usernames don’t match email addresses, so my solution had to be robust. The only requirement for my script is that the email address has to be filled in for the LDAP entry. Also you must have some facility for users to change his/her own password. We’re using a WebObjects program we found to let users do this.

You’ll need to change the LDAP server name and the number of days to send out the reminder; we require password changes every 90 days, so I send the reminder seven days before. This is run via a crontab at midnight (or so) each evening.

I’m not an awk master, but this seems to be working fine

#!/bin/sh
datelogfile=/backups/datechange.log
tmpfile=/tmp/passwordchange.tmp
grep -h "changed" /Library/Logs/PasswordService/ApplePasswordServer.Server.log* | awk '{ test=$1 " " $2 " " $3 " " $4; cmd="date -j -f \"%b %d %Y %H:%M:%S\" \047"test"\047 +%s"; cmd | getline day; close(cmd); {printf day " " $13"\n"}; }' | sed s/}/' '/g >> $datelogfile
sort -r $datelogfile | sort -r -k 2 -k 1 - | uniq -f 1 | sort -r - > $tmpfile
cat $tmpfile > $datelogfile

# Walk each line in $datelogfile
# See if the date > 83 days ago. If it is, send out a password change reminder
cat $datelogfile | awk '{ cmd="date -v-83d +%s"; cmd | getline expire; { if ($1 < expire) print}}' > $tmpfile
cat $tmpfile | awk '{test=$2; cmd = "ldapsearch -x -H ldap://ldap.gruby.com -b cn=users,dc=ldap,dc=gruby,dc=com uid=\047"test"\047 mail";  while ((cmd | getline) > 0) {if ($1=="mail:") {newcmd = "echo \"From: it@gruby.com\nTo: "$2"\nCc: it@gruby.com\nSubject: Password Change Reminder\n\nYour password will expire in less than 7 days. Please visit:  to change it.\n\n\nIf you have any questions, please contact it@gruby.com.\n\n\n--\nit@gruby.com\n\" | sendmail -bm -t"; newcmd | getline; close(newcmd); break;}}  }' 

rm -rf $tmpfile

Apple, please add some polish to the LDAP server; adding a little user interface on OpenLDAP is nice, but it isn’t finished. Building in the password change ability and the reminder system would be a good start. In addition, securing it out of the box by making the “require authenticated binding” setting actually work (I’ve ranted about this in the past; this actually makes it impossible for us to expose our LDAP server to the outside world and use it for integrating outsourced services like Salesforce that will do LDAP authentication to our server.)