DICE development projects - toby

Prometheus: multiple identities

toby — Tue, 06 May 2014 07:34:17 +0000

Project ID:

305

Current stage:

3_Implementation

Assigned Priority:

Manager:

toby

Unit:

inf-unit

Summary:

Add support and tools to Prometheus for managing multiple identities

What:

Prometheus was designed to support the management of multiple identities for users, e.g. in the KDC case somebody/admin, somebody/cron. The various parts need to be tied together to implement this. It should be possible to support:

Creation of additional identities for any entity
Creation of account objects (e.g. AFS pts) for identities
Users creating additional identities (of form 'user/something' themselves)
Distribution of keytabs

Why:

Multiple identities gives a way of separating a user's privileges. Also it allows for automation of authenticated access to resources (e.g. an identity with an AFS account and keytab allows authenticated file system access to be automated).

When:

This work has already been started, as part of prometheus development. This project ties all the loose ends together.

How:

Adding multiple identities support to prometheus involves the following work:

Ensure multiple identity and account objects are supported as planned in prometheus
Add support to AFS PTS conduit to create new accounts (with uid automatically allocated from range)
Add support to command-line 'theogony' tool to allow sysadmins to create identities and accounts
Add support to prometheus remctl interface for identity/account creation
Adapt password setting CGI or write a new one to use remctl interface for users to manage identities (create, set password)
Configure wallet to support distribution of keytabs for additional identities

Effort estimate:

4 weeks

Other:

Dependencies:

Risks:

Produce a talks.cam not-a-service for trialling

ascobie — Fri, 30 Aug 2013 16:06:42 +0000

Project ID:

292

Current stage:

2_Evaluation

Manager:

toby

Unit:

inf-unit

Summary:

Produce a talks.cam trial service for disseminating information about School talks

What:

Install the talks.cam software (http://talks.cam.ac.uk/document/documentation) on a VM and configure to authenticate against DICE.

Why:

Iain Murray suggested this a few project periods ago.

"I won't rehash all of the advantages (please look at the docs). But advantages for us would include: 1) the webforms are nicer than plone and announcements and requesting abstracts from speakers are dealt with by the system. 2) people can subscribe to any mix of talk streams in their calendars, email, and RSS readers. 3) Any combination of lists can be listed on the system, or embedded in any webpage. The School could list all talks going on in informatics on the front display screen, the main website, etc.

The system was developed by the academics that first used it, and after going through a couple of versions it's very usable and has proved popular. Maybe ultimately this is a system that should be talks.ed for the whole University. But trialling it with a couple of institutes and then a whole School first seems sensible, and is how talks.cam developed in Cambridge."

We were going to put some effort into quickly putting it up, but it hadn't been ported to SL6. It looks like this has now been done, so perhaps worth spending a small amount of effort to get it going.

Effort estimate:

1 week

Other:

Dependencies:

Risks:

OpenLDAP: investigate slapd-config

boss — Fri, 25 Jan 2013 15:46:28 +0000

Project ID:

266

Current stage:

0_Pending

Manager:

toby

Unit:

inf-unit

What:

Description: Investigate and test slapd-config with a view to using it for our slapd configuration

Deliverables: Report initially. Following on, slapd configuration supplied by slapd-config

Why:

Customer: All

Case statement: For some time now, the recommended configuration for OpenLDAP has been
to provide slapd configuration using
slapd-config (i.e. storing
the configuration in ldap itself), rather than in slapd.conf. The
real difficulty with this may be incorporating it into LCFG. Support
for slapd.conf is scheduled to be dropped in openldap 2.5.

When:

Status:

Timescales:

Priority:

Time: Probably 2-4 weeks

How:

Proposal:

Resources: openldap knowledge

Plan: Initial plan (to be expanded)

Initial investigation into slapd-config (outside of LCFG)
Investigate adding support for slapd-config to lcfg-openldap
Test
Implement

Other:

Dependencies:

Risks: if openldap is unreliable, machines break.

Milestones

Proposed date	Achieved date	Name	Description

OpenLDAP: investigate mdb backend

boss — Fri, 25 Jan 2013 15:46:28 +0000

Project ID:

265

Current stage:

0_Pending

Manager:

toby

Unit:

inf-unit

What:

Description: Investigate and test the new mdb backend with OpenLDAP, with a view to using it on servers/clients

Deliverables: Initially, report on openldap using mdb and recommendations. Following on, systems using mdb.

Why:

Customer: All

Case statement: It is highly likely that the recommended backend for use with OpenLDAP
will become mdb (see http://www.symas.com/mdb/). We have been using a
bdb backend for both servers and clients since we started using
OpenLDAP. We have done some informal testing with mdb, but need to
test it properly.

When:

Status:

Timescales:

Priority:

Time: Probably 2+ weeks, much time may be spent in leaving systems running

How:

Proposal:

Resources: openldap knowledge

Plan: Initial plan (to be expanded)

Add support for mdb config to lcfg-openldap
Run some test machines
Report success or otherwise
Implement

Other:

Dependencies: None

Risks: If openldap is unreliable, machines break.

Milestones

Proposed date	Achieved date	Name	Description

Lifecycle code design

boss — Fri, 25 Jan 2013 15:46:27 +0000

Project ID:

262

Current stage:

3_Implementation

Manager:

toby

Unit:

inf-unit

What:

Description: The prometheus system won't really be complete without being able to handle account lifecycle in an integrated manner. This project is to design the lifecycle system and sketch out the code changes which will be required. Implementation will take place in a separate project.

Deliverables: A design for the prometheus lifecycle code.

Why:

Customer: All

Case statement: Simon's lifecycle code seems to be irretrievably lost, so we need to start again.

When:

Status:

Timescales: Expect to produce a design and have it reviewed within a T.

Priority:

Time: 4 weeks? It really depends on how much of the code that we did get can be reused.

How:

Proposal:

Resources: Moose and prometheus expertise is likely to be the resource in shortest supply.

Plan: Link to prometheus lifecycle wiki detailing what we have in terms of design and code.

Stocktake: we did get some code and outline thoughts from Simon. Take a look at these to see what we can use.
Design
Publish the design to the CO community for review
Iterate...

Other:

Dependencies:

Risks: Producing a design which, if implemented, might cause widespread breakage.

Milestones

Proposed date	Achieved date	Name	Description

Prometheus: enable account lifecycle

boss — Fri, 25 Jan 2013 15:46:13 +0000

Project ID:

188

Current stage:

3s_Stalled

Manager:

toby

Unit:

inf-unit

What:

Description: Enable the account lifecycle code. This will give us the ability to properly manage the user account lifecycle so accounts can be archived and subsequently deleted. See points 4 and 15 of https://wiki.inf.ed.ac.uk/view/DICE/PrometheusTodo#Project_Completion_TODO for more details.

Deliverables: Account lifecycles

Why:

Customer:

Case statement:

When:

Status: We will not get code from sxw. We have some sketchy design. Need to decide how to proceed, but almost certainly start again almost from scratch.

Timescales:

Priority:

Time: Anything between 2-4 weeks as a very rough estimate. sxw could comment more accurately

How:

Proposal:

Resources:

Plan:

Other:

Dependencies: Depends on the "account reconciliation" project
devproj #182.

Risks:

Milestones

Proposed date	Achieved date	Name	Description

Prometheus: migration to new database feeds

boss — Fri, 25 Jan 2013 15:46:12 +0000

Project ID:

187

Current stage:

5_Completed

Manager:

toby

Unit:

inf-unit

What:

Description: The school database will be changing the feeds it gives us. There'll be some prometheus work to cope. Initially we will be getting a 3G feed of new and current PGR cohort. Note 21/01: this work is currently in progress (as driven by rollout on 10/01/11).

Deliverables: Working account management with revised DB.

Why:

Customer:

Case statement: Has to be done if we want to keep working with the revised DB.

When:

Status:

Timescales:

Priority:

Time: Probably 2-3 weeks, but dependent on issues discovered.

How:

Proposal:

Resources:

Plan: Currently in progress, as indicated above. Plan is:

Write new prometheus store/conduit for new feed. done
Testing/data integrity checking of conduit. in progress
Roll out to live server
RAT to provide combined feed of 2g/3g data
Adapt conduits for new feed
Testing of new feed
Rollout

Other:

Dependencies: See also devproj #169.

Risks:

Milestones

Proposed date	Achieved date	Name	Description

KDC Rekey

boss — Fri, 25 Jan 2013 15:46:11 +0000

Project ID:

180

Current stage:

1_Proposal

Manager:

toby

Unit:

inf-unit

What:

Description: Migrate our KDCs away from single-DES keys.

Deliverables: Re-keyed KDC.

Why:

Customer: All

Case statement: For security reasons, we need to move away from using single-DES keys
in our KDCs

When:

Status:

Timescales:

Priority: High

Time:

How:

Proposal:

Resources: 1-2 weeks CO time.

Plan:

Evaluation:

Investigate encryption types and decide which to use.
Look for other organisations who have undertaken a rekey and seek to
learn from their experiences.

Implementation:

Remove both default_tkt_enctypes and default_tgs_enctypes from
krb5.conf everywhere. DONE
On KDC only, add new encryption algorithms to both supported_enctypes
and kdc_supported_enctypes. There is a complete list of supported
encryption types in the Admin manual MIT supply with each Kerberos
release.
Take des out of supported_enctypes on the KDC. Don't remove des from
kdc_supported_enctypes - kerberos component should be checked so that
it doesn't use same resource for supported and kdc_supported
attributes.
Rekey the TGT, using the --keepold option, to add the new encryption
types. Services will be rekeyed as they upgrade, users as they change
their passwords.

Flag day...

TGT - remove the old TGT from the database. This is scary, as you
either have to hand edit the database, or you have to rekey and not
--keepold, which breaks all of the clients.

Most vital is that throughout this all, it must be possible for DES
keys to still be issued, as the afs service key must remain a single
DES key. This means making sure that whilst the KDC defaults to
created DES keys, it is still prepared to issue and handle them.

Other:

Dependencies:

Risks: Kerberos underpins much of our infrastructure, so major changes present significant risk if problems arise.

Milestones

Proposed date	Achieved date	Name	Description

Prometheus Enhancements

boss — Fri, 25 Jan 2013 15:46:11 +0000

Project ID:

179

Current stage:

1_Proposal

Manager:

toby

Unit:

inf-unit

What:

Description: This project gathers together prometheus development work which didn't
happen as part of the main prometheus project.

Deliverables: Enhanced prometheus service.

Why:

Customer: All

Case statement: This page outlines the current state of Prometheus:

When:

Status: Pending

Timescales:

Priority: High

Time:

How:

Proposal:

Resources: 2-4 weeks, depending on progress of main project

Plan: Detailed plan pending, but will be based on work identified here.

Other:

Dependencies:

Risks:

Milestones

Proposed date	Achieved date	Name	Description

Testing and Development Environment

boss — Fri, 25 Jan 2013 15:45:47 +0000

Project ID:

Current stage:

4d_Dropped

Manager:

toby

Unit:

inf-unit

What:

Description: We've talked about this many times before as a good thing to do. To aid the development and testing of new, and particularly, existing services, a completely separate infrastructure/environment should be created. This entails things like a separate DNS domain, kerberos realm, LCFG servers, etc.

Deliverables: A fully functional test environment (in time). Although perhaps a sensible early stage would be to document all that would be required.

Why:

Customer: All computing staff

Case statement:

When:

Status: Pending

Timescales:

Priority:

Time:

How:

Proposal:

Resources: hardware, a fair bit of person-time

Plan:

Other:

Dependencies:

Risks:

Milestones

Proposed date	Achieved date	Name	Description