IdentityManagement

  • 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

There are several specs dealing with authentication, most of which have been promised but not delivered. This is an attempt to apply some sanity to the process. We need to divide identity management in to bite-size chucks that we can deliver in a release cycle.

We need to discuss:

  • kerberos
  • LDAP server - OpenLDAP or Fedora
  • Pam config improvements
  • Shipping more auth-client-config profiles.
  • AD replacement
  • AD syncronization

Release Note

Ubuntu Server Edition allows for easy setup of a identity server that will easily integrate with other services such as mail or web access and allow for easy integration with existing directories such as Active directory

Rationale

If we want our server to be easily deployed :

  • in existing infrastructure
  • agregating authentication and authorization for other services

We need to set a clear path in order to implement identity management as a whole in our server.

Use Cases

Bob wants to set up a mail server that will reuse the active directory authentication mechanism that are already in place in his company.

Joe would like to use the same credential against his web, samba and email servers.

Jane is setting up Ubuntu in a legacy environment running NIS. She will want to have Ubuntu successfully work against her legacy ssytems.

Assumptions

The goal of this spec is to capture the result of a global discussion on how to implement identity management in Ubuntu Server Edition. There are already numerous specs on launchpad that propose various aspects of this. We need to define a clear path for the next fe releases in order to implement them. See :

Design

You can have subsections that better describe specific parts of the issue.

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

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 CD testing, and to show off after release.

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

Outstanding Issues

  • Don't forget about NIS. It's junk, but many places still use it. I found this problem at my last employer while useing a mass-Dapper deployment:
  • * Installing packages that called adduser or useradd in their maintainer scripts caused timeouts that lasted minutes on end; finally it timed out and worked.
  • * It's terribly annoying, yes.

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. 

FreeIPA (so far) is an integrated solution combining:

    * Linux (currently Fedora)
    * Fedora Directory Server
    * FreeRADIUS
    * MIT Kerberos
    * NTP
    * DNS
    * Samba
    * Web and commandline provisioning and administration tools 

The goal of this version is to allow an administrator to quickly install, setup, and administer one or more servers for centralized authentication and identity management.

Session: LDAP:

  • server side:
    • openldap 2.4 should be ready.
    • fedora directory server:
      • main advantage are the management tools, based on java.
  • client side:
    • package openldap-client 2.4 libraries.
  • preload a standard tree:
    • user management.
    • integration with samba3.

Kerberos:

  • configuration package are ready.

PAM configuration/integration:

  • Integration with auth-client-config:
    • add profiles for kerberos, ldap.
    • document/write a policy for auth-client-config.
  • each pacakge describes what it provides, the framework decides how they should be stacked.

As easy as authtools, but more flexible (preseeded). User management client:

  • mimic useradd, adduser.

AddUser + LDAP

Use cases:

  • Directory administrator wants to add a user from his directory console

Milestone 1:

  • Read /etc/ldap.conf, /etc/adduser.conf.
  • Override with /etc/adduser.conf content
  • When adding to LDAP, groups should always come from LDAP (primary and secondary)

Milestone 2:

  • Make it so that we build a backend independant AddUser (with a /etc/adduser.d/)

  • We add a tool so that directory users can be part of local groups on desktops (to allow him to suspend/write to cd/etc...)

Next unique uid, gid: need specific schema to store it. Unique username: doing search. uniquess overlay.

Structural class for user:

  • inetOrgPerson
  • configurable in adduser.

Structural class for group:

  • default to posixGroup of 2307.
  • if possible add 2307-bis

Default DIT:

  • dc=domain,dc=name
    • ou=People
      • next available uid, gid.
    • ou=Groups

Home Directories

  • create home directory automatically on local machine
  • less useful, but do for compatibility
  • create this w/ a switch
  • same default as local user: don't create home directory.

Password aging:

  • include shadow class in the user object.

Delete user:

  • remove primary group if group is empty (same as default behavior)

Directory

  • Build to match requirements for AddUser

  • Default backend is the one we use

Server/IdentityManagement (last edited 2008-08-06 16:19:12 by localhost)