EasyLDAPServer

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

Summary

Supply and support a standard LDAP directory service for Ubuntu, along with client utilities and management tools. Clearly defined backup, recovery and upgrade procedures must also exist for the datastore, due to the central role that the LDAP service may play in the management and security of many networks.

Rationale

A standard LDAP service within Ubuntu is an essential foundation for developing a wide range of other network features, and getting third-party support for them. These include:

  • Systems management applications
  • Centralized user authentication ("single sign-on")
  • Offering consistent user desktop settings across separate systems
  • Providing shared address book facilities, such as corporate directories

Any facility that involves sharing a common tree of records between separate services or multiple systems may potentially use an LDAP directory as the storage mechanism. The systems involved may be on either a private network, or the public Internet.

Use cases

  • Alice has been made responsible for the network at the small non-profit organization where she works. She already has other duties, and is not an IT professional. The organization has begun to use IT much more extensively over the past couple of years, particularly email, and the number of systems has grown over time. She and some of her colleagues have also begun to use Skype and are interested in the potential savings that VoIP provides. They are now considering purchasing their own server and upgrading the mixture of Windows systems that have accumulated. The organization has previously bought a NAS device to provide a shared file store.

She can obtain some technical help, and follow documentation if it is provided, but cannot afford the time to become a expert herself. Some of the IT professionals that she has spoken to have suggested Microsoft Small Business Server, which includes Active Directory and Exchange. The documentation for the NAS device states that it can share accounts with either a Windows server, or with a standard LDAP directory. To match the integrated facilities that Small Business Server offers Alice, and provide for any future small business VoIP system that she purchases, the Ubuntu server product must include an LDAP directory service.

  • Bob works as the IT administrator for a medium-sized organization with multiple servers and about 50 users. The systems currently use a mixture of Windows systems in an Active Directory domain, several Macs, and some Linux servers. Many users have multiple accounts in order to access the various systems. He wants to implement single sign-on for his users. For security he would like to apply account expiry and password complexity policies, as he already can easily do for accounts within Active Directory. He would prefer to move towards an open source environment with Linux desktops, but in the short-term it not feasible to migrate all of the Windows and Mac OS systems to Linux. He determines that the optimum solution for his organization is to implement a Kerberos realm with a standards-compliant LDAP directory on a Linux server, and extend this LDAP directory to support Linux desktop management in future.
  • Charles is the lead developer for a software vendor that provides a specialized application for managing medical practices of various sizes. His company often provides this application preinstalled on a server that plugs into the customer's existing network. He and his colleagues are currently modernising the architecture of their application to meet new requirements, which include meeting the growing demands from customers and internal technical staff for Linux client support, and modifying the application to run on Linux servers.

His application must meet the requirements of both regulations and auditors regarding account management and access control. In order to provide Linux compatibility he is willing to commit resources to supporting one other network directory service, in addition to Active Directory. The Linux directory service must be well documented with clear support channels. The directory server product should also have name recognition with both the technical staff for potential customers, and with the other vendors that support them.

  • David is a member of the IT operations team at a large company, with responsibility for DNS and DHCP. As the networks grow systems are constantly added or updated, and the workload for managing the various DNS zones and DHCP scopes involved continues to increase. This now means that he must delegate some duties to other technicians. He decides that the next step is to migrate the data for DHCP and DNS into an LDAP directory. He can then work with developers to provide a Web application that enables junior staff to easily maintain the network details for systems.

  • Eric is the IT administrator for a university Physics department. Both his department and several other groups within the organization independently maintain their own sets of UNIX servers and desktop environments. The central operations team use Windows for the main facilities with Active Directory for managing user accounts, and are reluctant to permit schema changes for UNIX support. Users complain about the inconsistent settings and accounts between the various systems. The administrators meet, and agree to standardise their Solaris and Linux desktops on the GNOME environment. They decide to use the Glokenspiel facilities for desktop management. A separate LDAP directory will be created that reuses account information from the Active Directory, with additional data to support GNOME desktops. A legacy NIS system will be merged into the new directory. They now need an LDAP product to implement these requirements.

  • Fraser runs a expanding cluster of servers for a network application, and now wishes to implement centralized management facilities. He decides to create a local mirror for package installation, use the LDAP support in deb-conf to guide software configuration on the nodes, and implement automated system management with Puppet. He determines that he needs to deploy an LDAP service to store the data for these services.

  • Gill is an internal developer at a college, working on modernising the student record tracking. Initial research shows that although the enrolment applications use SQL databases, LDAP enables direct integration with the network facilities that users require. She decides to set up a test LDAP service and extend the enrolment system to manage records in the directory. If the test system is successful then the approach may be put into production. As she already uses Ubuntu, she begins by looking for information on using Ubuntu Server for her development LDAP directory.
  • Harry is the senior email administrator for a small ISP. His company already uses a proprietary LDAP product to handle host certificates, as well as store account and mail routing information for the email services that they provide to customers. The current LDAP product is only supported on a limited range of operating systems, which do not include the Debian-based platforms that his team uses for the majority of their needs. Overall the proprietary product has proven to be somewhat complex to install and maintain. He would like to simplify management and reduce costs by migrating to an open source LDAP service, preferable on a Debian-based operating system. The software must be well-maintained, as the LDAP services are essential to mail delivery.

Scope

This specification only covers the LDAP service itself. Use other specifications to handle specific system management applications, configuration of client authentication, and Edubuntu configuration integration.

Related existing specifications for including a directory service in Ubuntu:

Related existing specifications for authentication facilities:

Asterisk and other VoIP facilities rely on directories of users, phone extensions etc.:

LDAP services enable system management facilities running on multiple systems to share data and maintain a consistent view of the network. For this reason, network management frameworks need to both be able to manage LDAP services, and use them for storing data:

Small networks benefit from shared user account and address book information, just as large ones do:

Integrating with Microsoft Windows networks requires that the supplied LDAP service interoperate with Active Directory:

Design

The core consists of an LDAP service that listens on standard network ports. This service must be supported by additional tools to support deployment, management, and backup. The Kerberos service needed for single sign-on is not covered by the specification, although it may be necessary to ship and configure the two together.

Common tasks include:

  • Server Maintainer: Setting up a master server
  • Server Maintainer: Setting up a slave server
  • Server Maintainer: Backing up the databases
  • Server Maintainer: Adding new schema
  • Account Admin: Importing records from an LDIF file
  • Account Admin: Setting policies for user accounts, such as account expiry
  • Account Admin: Adding a new user account
  • Account Admin: Adding a new group, and populating it with accounts
  • Account Admin: Resetting the stored password for a user account
  • Account Admin: Disabling user accounts
  • User: Searching the directory for details of other users, such as their email addresses or IM username
  • User: Updating fields in your own record, such as your listed mobile phone number
  • User: Resetting your own password

It is likely that several interfaces will be required in order to support the different classes of user:

  • Experienced administrators who need a tool that exposes the underlying LDAP infrastructure of records and schema
  • Support personnel who wish to perform routine tasks such as adding new printers, or updating user accounts
  • End users who wish to look up information in the directory, or amend their own records

Many networks are heterogenous, and users may need to access the LDAP server from non-Ubuntu systems. In order to allow this it may be useful to implement interfaces as Web applications. Web-based management interfaces for standard tasks would also enable convenient support of remote sites such as branch offices.

As the default installation of Ubuntu Server does not include a graphical interface it must be possible to setup the LDAP service and perform simple maintenance tasks from the command-line, although inexperienced administrators may prefer to work with the service through a desktop or Web-based interface.

Note that although LDAP is often used as an authentication service and the configuration must support it, this is not best practice. Ideally authentication should be handled by a facility such as Kerberos, which in turn uses the LDAP service to store data. Any configuration and management facilities reused from existing products may need adaptation, in order to integrate the LDAP service with Kerberos.

It is recommended practice to maintain at least one slave service with a replica of your directory even on smaller networks, in order to provide fault-tolerance. Multiple servers are also necessary for load-balancing on busy networks, and for supporting multiple physical sites. For these reasons, multiple LDAP services should probably be considered the standard configuration.

Implementation

The complete system probably requires several components:

  • The LDAP service
  • A Kerberos service for secure authentication (another spec dicusses this)
  • A simple configuration routine that enables administrators to easily initialize either a new master server with basic settings and directory contents, or a slave service to maintain a replica of an existing directory. This may need to configure Kerberos in addition to LDAP.
  • A graphical wizard to setup each of the supported network services (this probably requires a separate spec). This would collect information from the user and feed them to debconf. This should enable the user to set up specific services, as facilities may be divided between different servers on the network.
  • LDAP schemas for supported applications
  • A means of generating a certificate for the LDAP service
  • A graphical interface for maintaining the directory
  • A backup facility
  • Supporting documentation for administrators to be able to confidently set up services and authentication
  • Supporting best practices documentation for third-party OSS and proprietary developers who wish to enable their products to work with the directory
  • (optionally) A simple graphical interface for routine management tasks
  • (optionally) A simple Web application for lookups and testing

The key portion of the implementation of this specification is likely to consist of packaging a chosen LDAP service, along with supporting configuration and management utilities to make it accessible to less experienced administrators.

Debconf offers facilities for basic post-installation setup, and also provides support for automating the configuration process. The setup routine could use the existing software management facilities to install a specified set of packages, and configure them with debconf.

The setup process may also need to reconfigure a new master server to use the services that it now hosts for authentication, deb-conf settings, and other facilities. As debconf supports LDAP storage it may be possible to automatically configure slave LDAP servers, secondary Kerberos DCs, and other services using data from the network master server, once one has been established.

In order for the LDAP service to be useful relevant facilities in Ubuntu main also need to support it as a store for accounts, configuration or data. These may include:

  • Apache (supporting packages are currently in universe)
  • BIND 9

  • CUPS (package: cupsys)

  • deb-conf
  • Dovecot

  • ISC DHCP (package: dhcp3-server)

  • MoinMoin

  • OpenSSH

  • Postfix (The postfix-ldap package provides LDAP support)

  • Samba
  • Schoolbell
  • Schooltool
  • Squid
  • Zope

LDAP clients include:

  • Ekiga
  • Evolution
  • Gaim
  • Kmail
  • Kopete
  • Mozilla Thunderbird

  • OpenOffice.org (Supports LDAP as a database type)

  • pam_ldap

In this context support may mean a combination of shipping example configuration files, shipping utilities to configure the products to use an LDAP service rather than their own private data stores or configuration files, and patching.

Good security practices must be observed for all configuration and access. These include encouraging the use of strong passwords, encrypting connections, and logging access to the directory and other services. Removing records from the directory potentially breaks audit trails, and may be against policy on some networks, so it may be preferable to include a process for retiring accounts without purging the records from database. Several existing LDAP services permit access without a username and password ("anonymous binds"), but this may not be a desirable default.

Again, services should probably authenticate by a secure mechanism such as Kerberos, even where account data is held in an LDAP directory.

The types of record that the directory holds depend upon the schema installed on the server. It may be initially convenient to ship schemas for the most important services with the LDAP service itself. The supplied graphical interfaces will need to support the record types defined by the default set of schema, and offer some facility for additional record types.

Common record types include:

  • Users
  • Groups
  • Computers
  • Printers
  • File shares
  • Network Services
  • Software Packages

It will be necessary to provide a method for adding new schema to support other services as they are added to the network.

Many services and Web applications in Ubuntu universe would also benefit from LDAP integration, although it may not be practical or desirable to attempt to mandate LDAP or Kerberos support in software packages from universe.

Key software in universe includes:

  • Apache modules (libapache-mod-ldap and libapache2-mod-vhost-ldap)

  • Asterisk

  • Automounter (autofs-ldap)

  • Cyrus IMAP (cyrus-imapd)

  • Exim (package: exim4)

  • FreeRADIUS

  • Kolab (package: kolabd)

  • Jabber (server)
  • Lighttpd
  • Moodle
  • OpenVPN
  • Plone

Code

See tinyldap, Fedora Directory Server, and OpenLDAP for existing Open Source directory servers.

Several client utilities come with Fedora Directory Server. It also has copious documentation, although this material under a licence which is probably not DFSG-compliant, since modification and commercial reproduction are not permitted. Note that the code for the related certificate server is not open.

UltraPossum extends OpenLDAP to support monitoring, high-availability, and other features.

The Samba project provides a schema for storing account information in an LDAP directory, which is a standard means of sharing account details across Samba services. Version 4 of Samba should include AD migration facilties, and an internal LDAP directory service to conveniently support small networks, but it may be better to use a more generic LDAP service to hold Samba information.

BIND-SDB enables BIND 9 to use an LDAP directory as a database. The ldapdns 3 DNS server apparently has no dependencies on either BIND or OpenLDAP.

The rlm_ldap module provides LDAP support in FreeRADIUS. See rlm_krb5 for details on the Kerberos module.

Brian Masney's patch enables ISC DHCP to use an LDAP backend.

OpenSSH LPK patches OpenSSH with LDAP support.

The OpenVPN Auth-LDAP Plugin provides OpenVPN with LDAP support.

Hula uses OpenLDAP, a local config setting (for testing, it doesn't scale), but will have support for connecting to an external LDAP server in the near future.

Data preservation and migration

Many organizations already use LDAP services as a central part of their network. Whichever LDAP product is chosen, there will be many users on other products who will want to interoperate or migrate. Incumbant services may be OpenLDAP, Fedora Directory Server (aka Red Hat Directory Server aka Netscape Directory Server), or proprietary products such as Microsoft Active Directory.

Some organizations still use legacy technologies such as LANMAN (NT 4.0) and NIS to share data across systems, and so migration strategies need to be presented for them as well.

Losing an LDAP database providing user account credentials would effectively break the whole network, and possibly force all of the users to reset their passwords. For this reason, upgrades must not corrupt or lose data.

Unresolved issues

  1. Need to investigate the available LDAP server products, and select one.

  2. The LDAP service probably needs to offer at least two standard configurations: Stand-alone application database (LDAP uses completely internal logins), and Network single sign-on (a separate Kerberos service uses LDAP as a data store, and mediates access to the LDAP service by Kerberized clients).

  3. It may be necessary to target one of the two Kerberos implementations in order to achieve the tight integration required between the two services to provide a workable network single sign-on facility. Both Microsoft and Apple directory products configure LDAP and Kerberos together for this reason.

  4. If LDAP is run without Kerberos then the setup process probably needs to ensure that a digital certificate exists. See Dovecot for an example of an application that includes the facility to generate certificates for it's own use.

  5. Determine the LDAP schemas to include in the default configuration.
  6. Determine a preferred method for new services to introduce their own schema to the directory.
  7. The existance of an LDAP service provides the possibility of using it for the backend of a certificate server. This would probably be a separate project, but planning a specification for this may prove useful for furthering this project.
  8. Determine supportable migration paths for networks using obsolete technologies. If user accounts have to be recreated then all of the users must reset their passwords, which creates a significant support issue for larger organizations.
  9. Importing from Active Directory is a must-have to enable many organizations to migrate from Windows. Need to determine what is required to enable at least a successful one-time migration.
  10. It may be necessary to define a brand identity for the complete set of software in order to compete for mind share with Active Directory and other well-known products (In other words, a logo and a cool name).

BoF agenda and discussion

Comments

RobJCaskey: "It may be necessary to target one of the two Kerberos implementations in order to achieve the tight integration required between the two services to provide a workable network single sign-on facility. Both Microsoft and Apple directory products configure LDAP and Kerberos together for this reason." I think the fact that both Microsoft and Apple setup the two together is a good indication that any "hand-holding" assistants can also disregard that use case.

StuartEllis: The Microsoft solution is to provide a wizard that sets up AD with LDAP, Kerberos, and all the other pieces without asking anything more than basic questions. The admin is not really exposed to the underlying technologies at all at that point, which means that even many smaller Windows networks have had these facilities in place for a long time. I've amended the spec to hopefully make this bit clearer. My own feeling is that these technologies are probably not yet standard on UNIX partly because they are needlessly difficult to get going ATM.

StuartEllis: This page introduces Apple Open Directory, which is based on OpenLDAP and MIT Kerberos. The code itself is under a non-free license, but the architecture and graphical utilities may be interesting for comparison purposes.

[NicolasKassis] It would be nice to also have a graphical wizard to setup the directory and add some initial users and groups. Also this same wizard could help setup the other services.(Similar to what AD has) This, in my view, would help people who aren't used to the terminology. I think this could be useful as an installation tool, since a user could choose which services are needed and the system could download and install the specific packages required.

[NicolasKassis] Printer information should be included in the ldap database.

StuartEllis: Yes, I think that it is important that user accounts for single sign-on are just one application, and that the directory may hold other data about other things too.

Ideally, I think that each device (computer, printer, etc.) on the network should have an LDAP record - the DHCP, DNS and system management services would use that record to provide information to their clients. At work we don't actually permit devices on to the main networks unless their MAC address etc. is registered, to ensure that stuff can be traced back.

IIRC, the Add Printer Wizard in Windows adds a record for the printer to Active Directory that details things like the physical location and printing capabilities, and Windows systems periodically re-register their printers. Stale records get pruned by a server process after a period of time. The advantage over just relying on browsing is that you have a unified database of printing devices across the network (and all of the subnets). I don't really know how printer discovery works on Mac OS.

StuartEllis: Analysis of a 2006 survey of admins running GNOME: http://primates.ximian.com/~federico/docs/gnome-deployments-2006/index.html

Interesting to note that printer management is cited as a particular issue.

[NicolasKassis] One thing I saw is that there exist a printer.schema but from what I red it's not officially accepted. Is that still true ?

[MikaelOlenfalk] RFC3712 describes several object classes for defining printers in LDAP schema, its status is Informational, but still it might be a good starting point. On the CUPS site I found this enhancement request which defines a LDAP schema CUPS Enhancement Request 1962.

Dkg: It's worth noting that debconf itself can use LDAP as a backend datastore. While this introduces a chicken and egg problem for the EasyLDAPServer host machine itself, it would mean simpler automated deployment of other ubuntu/debian machines in an environment where such a server exists. Perhaps this is another use case?

StuartEllis: Thanks - that's a very good point, and I've amended the main spec. The setup process for a master LDAP server probably ought to be able to prefill the directory with the sensible defaults to "jumpstart" a new network, so I think it would be reasonable for that to be an interactive application that reconfigures the master server.

StuartEllis: (from flint on IRC): In the US the SIF standard defines data for a learning environment to enable interchange between different products. Defining mappings between the LDAP service and third-party schema may be out of scope for the project itself, but it raises the point that external developers will want to exchange data between the directories and their own products.

AchimBohnet: Some time ago I had a look into kolab. It's has already a web interface to manage users and more .Mabe it's worth to check if it can be used as a start for the ubuntu ldap web interface.

CategorySpec

EasyLDAPServer (last edited 2008-08-06 16:36:59 by localhost)