In the first part of this series, we looked at migration in general. We discussed the planning stage and discussed how to make a comprehensive inventory of all details that need attention. We spoke of user awareness and training, and we considered various procedures.
Now it's time for the gory details. How can we replace mission-critical services with OSS alternatives? Let's get one thing straight: It is entirely possible for your company to replace mission-critical proprietary applications with open source applications. It's not simple, but tools like OpenLDAP and Samba can help you slip from the clutches of proprietary apps and vendors. Come on. I'll show you the way.
In part one of this article, I'll cover the components and the configuration of OpenLDAP, and in part two, I'll cover the configuration of Samba and the rest of the migration process.
Although directory services serve all kinds of administrative and organizational purposes, their main role is authentication. Thanks to directory services, users can be authenticated and access permissions can be controlled centrally rather than on each server separately. The pivotal role of this mechanism is obvious; without proper authentication, either the protection of critical data and services goes right out the window, or the data and services become unavailable.
Directory-based authentication requires two components:
- The directory; that is, the actual database that holds the identity, access rights, group memberships, etc. on which the authentication is based,
- The authentication mechanism that performs the actual identity verification and access control.
Commercial, closed-source network operating systems such as Novell Netware and Windows Server incorporate both components as "part of the package" in a single, monolithic service. Open source products take a more modular approach.
The typical open source solution for directory services is OpenLDAP, the open source implementation of LDAP.
LDAP (Lightweight Directory Access Protocol) is a mature, well-established, platform-independent standard for accessing directory services. The directory database usually (but not necessarily) follows the X.500 specification. Based on solid industry standards, OpenLDAP offers extensive software support and future compatibility. Like all leading commercial directory services, OpenLDAP fully supports the use of master and slave servers, replication of data and a hierarchical directory structure. All network services, including intranet, Web and mail services, can use OpenLDAP for authentication.
Both Microsoft's Active Directory and Novell's eDirectory are derived from X.500. (Novell's NDS on the other hand holds a lot of Netware-specific underlying detail.
Migrating it to anything else involves upgrading NDS to eDirectory and a certain amount of directory restructuring.)
Although OpenLDAP takes care of directory services, it does not offer the necessary authentication mechanism for our purposes. Unix-based workstations (e.g. Linux) can use OpenLDAP directly, but Windows clients need more. Windows clients expect something at the server end that understands the SMB protocol and the API behind Windows' networking.
The staple ingredient of any open source solution that serves Windows clients is Samba, the open source SMB server suite. Samba has been around for about fifteen years now; it is used extensively to link Windows environments to the rest of the world. We will need Samba later on anyway, to take care of file and print services, so deploying it now to negotiate between Windows and OpenLDAP won't add significant workload to the migration as a whole.
The OpenLDAP server and the Samba server may run on the same physical server platform, or they may live on totally different systems. We may use a separate Samba server for authentication and another one for file and print services, or we could use a single Samba server that performs all these tasks. Most administrators prefer to run OpenLDAP and Samba on the same machine and to use Samba in this configuration exclusively for authentication. Your preference as to what service to run on which server is likely to be influenced by expected load, availability requirements, budget considerations and other factors.
The OpenLDAP server
If you migrate from Active Directory or eDirectory (or from NDS with eDirectory as an intermediate step) the hierarchy of the new directory should be similar to what you are already used to. On the other hand, because you are going to set up new directory services anyway, this might be a good moment to consider improvements to the existing directory services and their structure. If you migrate from NT domains only, you must set up directory services from scratch.
Two crucial elements to consider in planning the new directory services are location and structure.
Location and availability are more than somewhat interrelated. Given the crucial importance of directory services, fault tolerance and redundancy are not just luxury options. At least two OpenLDAP servers (set up to replace directory data between them) are advisable in networks with more than one physical server. If your network spans several different locations, deploy an OpenLDAP server at each remote location so that authentication is not dependent upon the WAN link to the central location.
The structure of your directory will largely depend upon your existing network configuration, the directory you already have and the needs of your organization. If you are migrating from an existing directory service, you will already be familiar with directory structures. Those migrating from NT domains should thoroughly familiarize themselves with directory services before attempting to implement directory services in a production environment.
For the benefit of the latter group, let's look briefly at a simple network (part of the ubiquitous example.com domain) in which the basic hierarchy could look like this:
dc=example,dc=com --ou-Groups -ou=Users -ou=Computers -ou=Etcetera
This simple tree structure puts each object type in the directory into a separate container object. For those new to OpenLDAP, this is a fairly good way to get started, because the out-of-the-box setup of most management tools often assumes something like the above. Larger networks, especially those spanning multiple departments or locations, will of course need multiple levels in the directory tree. In this case, the use of multiple Organizational Units, each with its own container and sub-containers, are essential here to keep the tree manageable.
The best way to install OpenLDAP on the Linux server depends on the Linux distribution. A mainstream distribution with decent support and the available updates (automated or not) is advisable. SuSE Linux Enterprise Server 9 (Novell) incorporates OpenLDAP right out of the box; during installation the service is configured and certificates are installed, while YaST provides simple maintenance. But other mainstream distributions are perfectly suited as well. Webmin and various command line programs are available as maintenance tools. As usual, the choice of a particular Linux distribution depends on many factors, including personal preference and experience.
The manual configuration of OpenLDAP involves, among other things, editing the slapd.conf file to specify what schema files to include and what administrative privileges to assign, as well as indexing and access permissions. All relevant details are covered in the OpenLDAP documentation; this article won't attempt to duplicate that information.
Continue on to part two to read about configuring Samba and completing the migration.