Ubuntu Wiki

• Launchpad Entry: ldapbydefault (not created yet)

• Created: 2008-11-09

• Contributors: SorenHansen

• Packages affected: slapd, adduser, libpam-ldap, libnss-ldap

Summary

Install an OpenLDAP server by default. Change everything to authenticate against an LDAP server (preset to the local one, but easily changable to a remote one). Make the installer autodiscover LDAP servers.

Release Note

Ubuntu no longer uses legacy passwd/shadow as its user backend. An OpenLDAP server is installed by default, and pam and nss is changed to use the ldap backend, and adduser interacts with LDAP.

Rationale

• It makes it easy to share your user database when you add a new machine to your network.
• When the entire system is LDAP-aware, hooking into remote LDAP servers is a simple matter of changing the IP of the LDAP server from localhost to the remote one.

Use Cases

• Joe installs Ubuntu on one of his machines. He plays around with it for a few days and likes it so much that he wants to install Ubuntu on the other computers in the house: During install, the new machines offer to hook into the existing LDAP server on the existing Ubuntu machine.
• John's company has an existing LDAP infrastructure. He wants his Ubuntu installation to hook into it: He finds the ldap configuration and changes the IP of the LDAP server from his local one the company's one.

Assumptions

Design

Everything in main will be taught to consult LDAP for authentication of users, thus providing a tightly integrated environment. An appropriate caching mechanism will be put in place for the eventuality that slapd has broken down, the network is failing, etc., etc.

Implementation

Anything that currently looks directly at /etc/passwd and/or /etc/shadow will need to be changed to talk to LDAP. libpam-ccreds and nscd or nss-updatedb should be installed by default as well.

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Migration

Include:

• data migration, if any
• redirects from old URLs to new ones, if any
• how users will be pointed to the new way of doing things, if necessary.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release.

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

CategorySpec