LDAP, pGINA 2.1 and Single Sign-on

Now that the frenzy of IPv4 exhaustion is over for a little while, it was time to turn my hand to some of the more mundane aspects of computing.  One of the “things to do” on my list was single sign-on; that is, being able to log in using the same user name and password at any machine on my network.

There’s two main problems getting this to work – the main one is that I have a mix of Windows and Linux machines on my network.  This requires a bit of thought.  Many years ago, there was a fantastic piece of software called pGina which implemented the Microsoft GINA specification (which if you want the simple explanation, is the bit of code that does the login box).  Using pGina, you could add plugins to authenticate users via something other than local users or a Windows domain controller.  So I used the LDAP plugin, and it worked, and it was great.

Then something happened.  Microsoft released Windows Vista.  And in that version of Windows, Microsoft decided to revamp the way the login box was done, replacing the GINA stuff with something called ‘Credential Providers’.  And my beloved pGina stopped working.  With the author at the time indicating that a Vista version wasn’t going to be forthcoming very quickly, I gave up and went to local authentication again.

But…

Last week I discovered that there was a new 2.x version of pGina which *did* implement a Credential Provider, so now Vista and Windows 7 users can once again use LDAP login on the Windows box.  Great news!  So, it was time to get all this up and running again.  To cut a long story short, I have pGina 2.1 installed, but it is not working yet.  The reason why is that I wanted to concentrate on getting the Linux part of it working first, and then sort pGina out later.

The Linux part was going to be interesting.  Using concepts that I first discovered the best part of 15 years ago, and remembering how to do it, was going to be fun.  The first job was to implement a common login system between all the Linux machines.  There are multiple ways to do this, and I would have preferred to have gone the Kerberos+LDAP route, but this isn’t actually possible yet using pGina since it was the LDAP plugin, but not a Kerberos one.  So plain LDAP it was.

It’s been a long time since I’d used OpenLDAP with any kind of sensible purpose, and a bit of a surprise was waiting for me – in Debian squeeze, they had decided to move to the ‘dynamic’ cn=config type configuration, where all the config is stored in the directory itself, rather than the old-fahsioned slapd.conf method.  It took a while to figure this out… but once I had, it was just a case of firing up Eclipse, using Apache Directory Studio to navigate the LDAP tree, and to put all the right options and permissions and suchlike in.

So, now I have an LDAP tree which will support single sign on.  It was just a case then of installing the libpam-ldap and libnss-ldap packages and configuring them up appropriately.  One thing that did catch me out was the fact that Debian seem to link their packages with GnuTLS rather than OpenSSL.  Although I knew this, it wasn’t working properly.  Much frustration later, it appears that reason it wasn’t working was that you cannot use the tlscertdir parameter when using GnuTLS – only tlscertfile will work.  So, having figured that out, all my clients are now talking to each other using StartTLS rather than plain text.

That done, the next job was to somehow make my ‘network’ home directories appear on all the machines.  NFS is the obvious choice for this, but for one reason and another, using straight NFS is not likely to work in my network.  Specifically, I didn’t want the situation where I could not mount my NFS drives on boot, if the virtual machines didn’t come up in the right order or it got ‘stuck’.  So, I decided to resurrect the automounter.  I haven’t used this in donkeys’ years, but I was nicely surprised to see that the latest version of autofs, autofs5, comes with LDAP support – which is handy, since I had just set up my LDAP server anyway.

So, a little scratching of heads and a few entries in my LDAP server later, I had the automounter configured, which would pick up my NFS directories up from the file server but (most importantly) only mount them when required, which means that none of my virtual machines would hang upon boot if the file server hadn’t started up yet, since the home directories aren’t required then.

So far, all is well, and it seems to be quite a good solution.  I still haven’t got pGina working, mainly because I haven’t had time, but hopefully that shouldn’t be too difficult to get going, now that I know the rest of it works.

IPv4 all gone

The news has been announced.  In the last two hours, APNIC have been allocated the last two /8s in the IPv4 address pool, which will trigger the distribution of the ‘final five’ blocks, one to each Regional Internet Registry, which officially means that there are no more IPv4 addresses left in the IANA pool.

What does this mean now?  Well, each RIR still has a stock of addresses.  With APNIC taking the last two blocks, they now have in the region of 3.2 /8s left, ARIN have about the same, and RIPE have nearly 4.  Obviously each RIR will get an additional 1/8 from the ‘final five’ in addition to this.  Current estimates are that these addresses will be gone in around 6 months.

Party time!