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:

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

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.

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.

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:

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

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 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:

LDAP clients include:

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:

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:

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)