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: identity-management
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:
- LDAP server - OpenLDAP or Fedora
- Pam config improvements
- Shipping more auth-client-config profiles.
- AD replacement
- AD syncronization
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
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.
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.
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 :
You can have subsections that better describe specific parts of the issue.
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:
Should cover changes required to the UI, or specific UI that is required to implement this
Code changes should include an overview of what needs to change, and in some cases even the specific details.
- 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.
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.
- 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.
- 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.
- configuration package are ready.
- 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
- Directory administrator wants to add a user from his directory console
- 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)
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:
- configurable in adduser.
Structural class for group:
- default to posixGroup of 2307.
- if possible add 2307-bis
- next available uid, gid.
- 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.
- include shadow class in the user object.
- remove primary group if group is empty (same as default behavior)
Build to match requirements for AddUser
- Default backend is the one we use