Network Directory Services

Network directory services are core to Internet functionality. The Domain Name System (DNS) provides a global (and/or local) directory of hosts and services. Lightweight Directory Access Protocol (LDAP) servers can provide some of the same information as DNS (or be used to back DNS), but are more frequently used to create network user databases, store user group information, providing centralized account information and password storage.

I recently completed an upgrade of these two core services on a network I manage. We had been running outdated (but functional) BIND v8 and OpenLDAP v2.0 instances for of DNS and LDAP servers. Also, throw a Windows Server 2003 into the mix, which, as an Active Directory domain controller has to run its own DNS and LDAP (AD is tweaked LDAP) servers.

First, the DNS upgrade was substantial, not just because we upgrade to a more modern BIND v9.x installation, but because we implemented a split view configuration. Previously, our local users operated on a sub-domain of “local.example.com” such that each computer was named “host.local.example.com”. The main public services utilized the proper full-domain of “example.com”. This was fine in the beginning, as when we set this up, few users had laptops, so we didn’t use individual client VPN or have road warriors with laptops out trying to access “local” services from home or a customer locations. Also, some services we started deploying (eg, our XMPP chat server, Openfire) preferred to be bound to one host name (like, im.example.com). Internally, that host name still resolved to our public IP address which then needed some interesting firewall rules in order to support the routing or traffic. But this issue was already present with mail services; if I wanted a laptop user to use “mail.example.com” for his server while out of the office, while on VPN that user would have to change to “mail” or “mail.local.example.com” because the VPN essentially made the user part of the local network.

The solution I came up with, as mentioned above, was to use BIND views, and get rid of a “local” DNS sub-domain. All our servers and host names would be part of the base “example.com” domain, thus, local, VPN, or public users would only have one host name for accessing services like mail (mail.example.com) or chat (im.example.com). BIND views essentially provide a different view to your DNS based on the host IP address you are using to access the server. So, if users are at the office, im.example.com resolves to a private RFC 1918 address, same as it resolves if they are connected via VPN, but if they are on the public internet, im.example.com resolves to a publicly routable address assigned to our organization.

Are there any tricks or gotchas when making a change like this in your organization’s DNS? The biggest trick is BE METICULOUS! Seriously, if your organization was like ours, you had a mix of both FQDNs and non FQDNs in your intranet & application URLs, user documentation, etc. Undertaking a naming change like this could be very daunting given a large enough organization. You may find that you can only migrate those services which really need to have split view DNS. In my case, most of the time spent prepping for this transition was spent searching out where the “local.” part of FQDNs was used and switching to non-qualified host names or making a note so I could change it to the new FQDN after the migration. All in all, this proved to be a fairly painless migration for this smaller organization.

The LDAP transition initially concerned me more than the change to DNS, but in the end, proved to be less painful. However, it did require more new knowledge to transition to a totally new server instead of simply upgrading and reconfiguring. OpenLDAP had served us well, but some other admins in the group had been playing with Fedora Directory Server (FDS) and had it installed in other production environments. A few key things prompted us to migrate. First, multi-master replication is a SNAP with FDS. Having that is key part of having redundant and available directory services. Yes, it can be done with OpenLDAP now (as of v2.4 or so), but it wasn’t there when we put our first FDS server into play. Also FDS has nice built-in facilities for account password expiration and password policies and account lockouts. Also, we’d used a bit of hack to push password updates to OpenLDAP from Windows Server for users who had both Windows and Unix accounts, but FDS prvoides a very complete two-way password synchronizer for Windows. Again, I’ll emphasize that replication is a SNAP with FDS. This is largely due to its very useful and easy to use Java based GUI management interface. This is a stand-alone client which runs on your desktop and connects to FDS’s admin server. Fear not, command-line junkies, everything that can be done in the GUI is available on the command-line and via ldapadd LDIF commands, etc. The management interface not only lets you configure the server, options, ACLs (FDS calls them ACIs), etc, but this tool is also a data management tool for all your LDAP data. This was plus for us as we’d never been thrilled with our data management options in OpenLDAP. We used multiple tools to managed accounts in OpenLDAP, but in the end, the best all around tool we had used was phpLDAPdmin. I’m sue the tool has matured A LOT since we last upgraded, and it was pretty nice, we may even install it again with FDS, but the built in GUI from FDS is just a nice touch.

The actual work of transitioning from OpenLDAP to FDS was not as hard as I’d expected. First, I installed FDS on the new server. The installation process was pretty straight forward if you’ve used OpenLDAP before and done your resarch ahead of time. A slapcat of the old OpenLDAP database created an LDIF dump of my old data. From there, I experimented with importing the data into FDS using ldapadd. There were a few schema changes required, but not many. In my case, the LDIF lines that FDS didn’t like were not required (eg, “struturalObjectClass” was dumped by OpenLDAP but required by FDS) and I simply ran my LDIF dump through a series of “grep -v” filters to remove the unwanted lines. One other concern was the format of the userPassword fields. I’d been storing passwords as MD5 hashes; FDS supports this, but the storage format of the hashes was not compatible. FDS’s website has links to user contributed scripts to solve this, but they didn’t seem to work for me. Again, having a small organization was useful, as I was able to change the default storage type to something more compatible (eg, SHA, SHA1, CRYPT, etc) and have my users update their passwords. Voila! Updated password formats. Once all this was completed, I simply pointed LDAP clients to the FDS instead of the old OpenLDAP and everything just worked!

Overall, my migrations were pretty smooth. Your mileage may vary, but if you need the features, or just yearn to run on updated software, the migration is well worth it.