Ubuntu Wiki

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.

• Launchpad entry: none yet

• Packages affected:

Summary

This spec outlines what is possible to implement from EasyLDAPServer for the Feisty Release. The complete informational spec is available at EasyLDAPServer for future releases.

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

• 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. Bob installs the Easy LDAP server and is able to deploy single sign on for all his platforms.
• 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. Using easy-ldap-server, he quickly replaces his proprietary system with an Ubuntu-based system, saving tons of money.

Scope

Design

Implementation

• Use OpenLDAP for feisty
• Switch to Fedora Directory Server when the packaging is fixed.
• Use a task to select "Install a Directory Server"
• Include the schema in a package
  • Follow POSIX schema.
    • Include SAMBA and have openldap include Samba schema.
• Windows Clients

  • Covered in the NetworkAuth

  • But put the schema in the .. (someone help here, I missed this part at the discussion)
• LDIF file
  • Includes default OU's
• Kerberos
  • Going with Heimdal
  • No sufficiently good way to store keys in LDAP. (Poorly?) wasabi: It's very poor.
  • If forcing Kerberos by default, then we don't care about SSL for LDAP.
    • But we need to check that SASL encrypts via Kerberos
• LDAP Configuration File
  • Turn off anonymous binds.
  • Turn off simple binds.

* Scope for Feisty:

• OpenLDAP working OOTB with Kerberos

• user management tools (CLI & GUI)

• these must automatically handle Kerberos principals correctly
• the GUI tools
• no such tools appear to exist at this time; an existing tool will need to be modified; possibilities include:
  • LAT - proposed for GNOME? (Don't think it make it)
  • EDSAdmin - Edubuntu is using this and removing the other tools from the menu.
  • cpu
  • gnome-system-tools

  • gosa2 (https://gosa.gonicus.de/) munich uses it, btw

  • smbldap-tools

• cfengine/puppet
  • Not specific, don't care.
    • someone: Use gconf and ldap. someone else: I don't like that idea.

Proposed schema amendment: (pixelpapst) - debian and ubuntu have a primary group for every user - this clutters directory - in our setup, we defined a AUXILIARY objectClass "debianGroup" - this can be combined with groupOfNames like posixGroup - but also with inetOrgPerson like posixAccount already is - difference to posixGroup is basically that the group name is

• stored in "uid" instead of "cn"

- libnss_ldap and libpam_ldap config has to be changed (in an easy but

• non-obvious way) - patching them to support this would be easier

- backwards-compatibility to setups using posixGroup should be investigated more

• - can you derive an AUXILIARY objectClass from another AUXILIARY ?

Code

Data preservation and migration

Unresolved issues

BoF agenda and discussion

CategorySpec