Just one username
Imagine the dream scenario of having one set of usernames and passwords to log in to all your Linux, Solaris and Windows boxes. It can’t be possible, can it? Well, we were determined to try. Yes, we encountered a few problems, but read on to see that it can be done using just a couple of open-source products.
The UK arm of our company has a collection of servers spread between two hosting centres and our office, most of which run Solaris and Linux, but a few run Windows. In particular, we have several Dells running Windows-based NAS that not only support Windows file sharing but also Unix’s NFS (Network File System) via Windows’ Services For Unix (SFU). There’s also a group of users who use Windows and Mac OS X machines, and we needed to give them access to the server resources in the hosting centres. If we could centralise our usernames and passwords, we’d have a completely flat space in which users could log in and access files on all servers.
Apart from requiring a single username for everyone, we also wanted resilience – any solution needed to be duplicated so that, if a username server became inaccessible, people could still work. The solution also needed to fit with our main skills, so it had to be Unix based. Until we undertook this exercise, we didn’t know much about how Windows networking or authentication worked, so when some people read this they’re going to exclaim, “How could they not know that?”
Unix has had a centralised user-authentication system – called NIS (Network Information System) or “yellow pages” – for many years now, and our experience of it from university days was such that we decided not to use it. More recently, most Unix variants have started supporting LDAP (Lightweight Directory Access Protocol) servers in place of NIS and, although we didn’t know much about LDAP, it became apparent that they supported various kinds of replication.
Windows’ user authentication is based around the notion of a domain – ever since NT, it’s offered the ability to set up a primary domain controller (PDC) that’s replicated onto backup domain controllers (BDC). It was obvious that LDAP was the way to go for our Linux and Solaris systems, but what about the Windows machines? We did find the pGina package (www.pgina.org), which allows a user to log in to a Windows machine using LDAP, but it didn’t look as if it was going to work with Windows SFU.
At this point, we turned to Samba – that popular open-source package that brings Windows services to Unix – and it turns out that its preferred username back-end is LDAP. If we could get Samba to use an LDAP back-end and serve as a Windows domain controller, we’d have the solution we wanted. We still had to choose an LDAP server, but the obvious candidate is OpenLDAP (www.openldap.org), which ships with many Linux systems and can be easily obtained for Solaris.
We now had a thumbnail sketch of a solution: an OpenLDAP server running on a Unix system in one hosting centre would be replicated to a backup OpenLDAP server in the other centre. On the primary OpenLDAP server, we’d set up Samba as a PDC using OpenLDAP as a back-end – on the other, we’d set up Samba as a secondary domain controller. It also became obvious that we’d require some extra glue to make the Windows domain work, which, as we’ll see below, is WINS (Windows Internet Name Server).
We now knew which packages to use, but we weren’t entirely sure where to start. Some Googling uncovered the Linux Samba OpenLDAP How To – a substantial PDF available from www.idealx.com. We made our lives slightly more difficult by choosing a Solaris server that doesn’t bundle OpenLDAP, so we found one and installed it, and then thought we’d better find out what an LDAP server does!