When there's only one

...there's only one choice
Everything here is my opinion. I do not speak for your employer.
September 2009
October 2009

2009-09-03 »

Introducing jfauth: Just Fast Authentication

I have a simple problem. I just want to set up a bunch of Linux machines on my LAN, and I want them to check all their passwords against a central server.

Okay, my problem is a little more complicated than that: each machine has only a subset of users, and I don't want my whole network to drop dead just because the central server goes down for a few minutes.

Oh, and I don't trust all the users on all the machines, so I can't reveal the central /etc/shadow to them, so any simple replication scheme involving rsyncing /etc/shadow is out... even if that would ever be a good idea.

Also, I'm using apache_mod_pam, which does a PAM authorization for every single page (or image file, or whatever). That's fast enough when using pam_unix to read /etc/shadow, but it's sucktastic if you use any kind of remote authentication.

Did I mention I have no idea how to properly configure a secure LDAP server? And would it be okay if I wanted the central server to actually be part of a Windows domain controller network and check all the passwords against Windows?

Yeah. I didn't think so.

The Solution

I've had some variation of the above set of problems for years. In Nitix we solved at least some of them using pam_uniconf and nss_uniconf and a wvauthdaemon and some more PAM modules and an auto-configuring LDAP server. It was kind of cool, actually, but it grew into a bit of a mess, and then NITI (which included me, at the time, oops) dropped the final bomb: we started charging extra for each user license. Ouch.

As it turns out, there's an easier way and it involves basically none of that stuff. The problem is, nobody had actually implemented that easier way before. So I spent the last couple of days doing it. The result is jfauth: Just Fast Authentication.

In a nutshell:

  • There's a jfauthd server that listens on Unix and (optional) SSL sockets.
  • There's a jfauth client program that connects to jfauthd.
  • There's a pam_jfauth module that connects to jfauthd.
  • One jfauthd can connect to another over SSL.
  • jfauthd itself authenticates against any PAM service you want, including pam_unix, pam_ldap, and pam_winbind (which lets you use a domain controller)
  • jfauthd caches successful authentications for variable time (default 60 seconds), so apache_mod_pam goes fast even if your PAM provider is slow.
  • jfauthd can use its cache for an even longer time (default infinite) if the master server goes down temporarily.

Oh, and for fun, there's an optional mode where it can automatically run smbpasswd for you whenever someone successfully authenticates, because nobody ever remembers to set their samba password correctly, least of all me.

There are packages for Debian (etch and lenny) and Ubuntu. The whole binary package is under 50k. I can't believe I waited so long to do this.

Much of the awesomeness, particularly the SSL awesomeness (thanks, ppatters and others) is due to WvStreams.

You can read the README for more information.

Troublesome bits

The caching isn't persistent across daemon restarts (yet, anyway). We also don't do any validation of the server's SSL certificate, so it's subject to a man-in-the-middle attack. (I hear there are tools for that.) Although I was pretty careful, there may be other problems too, probably security related. Use at your own risk, etc.

And let me know what you think!

I'm CEO at Tailscale, where we make network problems disappear.

Why would you follow me on twitter? Use RSS.

apenwarr on gmail.com