EasyLDAPServer

Differences between revisions 36 and 37
⇤ ← Revision 36 as of 2006-11-02 02:57:56 →
Size: 26184
Editor: jax
Comment:
← Revision 37 as of 2006-11-02 03:05:07 → ⇥
Size: 26129
Editor: jax
Comment:
Deletions are marked like this. Additions are marked like this.
Line 272: Line 272:
[NicolasKassis] This should also be added to the Ubuntu Software Update services spec (I don't know the exact name) Clients. This will require setup on the client side. We need to have a tool for that.
[NicolasKassis] I added a comment at the end of the UpdateServer spec to include the debconf ldap backend. I believe that this is where it should go.

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 [http://en.wikipedia.org/wiki/LDAP 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 [http://www.microsoft.com/windowsserver2003/sbs/default.mspx 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 [http://live.gnome.org/Glockenspiel 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 [http://reductivelabs.com/projects/puppet 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:

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 LDAP service itself must be supported by additional tools to support deployment, management, and backup.

Common tasks include:

  • Admin: Setting up a master LDAP server
  • Admin: Setting up a slave LDAP server
  • Admin: Backing up the LDAP database
  • Admin: Importing records from an LDIF file
  • Admin: Adding new schema
  • Admin: Setting policies for user accounts, such as account expiry
  • Admin: Adding a new user account
  • Admin: Adding a new group, and populating it with accounts
  • Admin: Resetting the stored password for a user account
  • 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 simple configuration routine to initialize either a new master LDAP service with basic settings and directory contents, or a slave service to maintain a replica of an existing directory.
  • 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 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
  • (optionally) A simple graphical interface for routine management tasks
  • (optionally) A simple Web application for lookups and testing

The key portion of the implementation 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 LDAP service 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 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. 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 schemas define the types of record that the directory holds. 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

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 [http://www.fefe.de/tinyldap/ tinyldap], [http://directory.fedora.redhat.com/ Fedora Directory Server], and [http://www.openldap.org/ 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 [http://www.redhat.com/solutions/rhcs/ certificate server] is not open.

[http://ultrapossum.org/ UltraPossum] extends OpenLDAP to support monitoring, high-availability, and other features.

The [http://www.samba.org/ 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.

[http://www.venaas.no/ldap/bind-sdb/ BIND-SDB] enables BIND 9 to use an LDAP directory as a database. The [http://ldapdns.sourceforge.net/ ldapdns] 3 DNS server apparently has no dependencies on either BIND or OpenLDAP.

The [http://wiki.freeradius.org/index.php/Rlm_ldap rlm_ldap] module provides LDAP support in FreeRADIUS. See [http://wiki.freeradius.org/Rlm_krb5 rlm_krb5] for details on the Kerberos module.

[http://www.newwave.net/~masneyb/ Brian Masney's patch] enables ISC DHCP to use an LDAP backend.

[http://dev.inversepath.com/trac/openssh-lpk OpenSSH LPK] patches OpenSSH with LDAP support.

The [http://dpw.threerings.net/projects/openvpn-auth-ldap/ OpenVPN Auth-LDAP Plugin] provides OpenVPN with LDAP support.

[http://www.hula-project.org/ 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 [http://www.dovecot.org/ 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.

BoF agenda and discussion

Comments

StuartEllis: [http://www.apple.com/server/macosx/features/opendirectory.html This page] introduces Apple Open Directory, which is based on OpenLDAP and MIT Kerberos. [http://developer.apple.com/opensource/dirservices/ 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] [http://www.rfc-archive.org/getrfc.php?rfc=3712 RFC3712] describes several object classes for defining printers in LDAP schema, its status is [http://www.rfc-archive.org/getrfc.php?rfc=2026 Informational], but still it might be a good starting point. On the CUPS site I found this enhancement request which defines a LDAP schema [http://www.easysw.com/~mike/cups/str.php?L1962 CUPS Enhancement Request 1962].

["Dkg"]: It's worth noting that [http://svn.kitenet.net/trunk/src/debconf/doc/debconf.schema?rev=10022&view=log 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.

[NicolasKassis] I added a comment at the end of the UpdateServer spec to include the debconf ldap backend. I believe that this is where it should go.

CategorySpec

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