Projects/KDB reporting and bulk operations

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.

This page attempts to capture some thoughts about KDB operations across sets of policies, principals, or keys. It does not yet make a specific proposal.

Background

Our administrative toolset mostly provides support for operating on one principal entry or policy at a time. As the number of principals in a database increases, it becomes less feasible to perform operations on all principals manually.

Scope

Some known and hypothesized use cases for reporting and bulk operations are:

As part of migrating away from DES or another enctype:

• Find all principals which have DES keys.
• Find all principals which have only DES keys.
• Remove DES keys from all principals.
• Remove DES keys from all principals, but only if they have keys of another type.

As part of instating password expiration:

• Display the last password change time of all principals.
• Find all principals whose password has not changed since a particular date.
• Set the password expiration time on a set of principals.

Uncategorized:

• Find all principals using a policy, or which have no policy.
• Associate a set of principals with a policy.
• Find all principals which are currently locked out.
• Set the maximum ticket life or maximum renewal life on a set of principals.

Audience

Administrators who use Kerberos as part of an integrated system such as FreeIPA are mostly served by the larger system's toolset, although they might make use of native reporting and bulk operations tools in special cases. The primary audience of any new reporting functionality would be the administrator of a standalone Kerberos authentication service.

Different administrators are comfortable with different kinds of tools for manipulating large amount of data. Some are most comfortable with SQL database, some are most comfortable with basic Unix commands like grep and sed, and some are most comfortable with a scripting language such as Perl or Python.

Design considerations

There are several directions we could go in to improve reporting and bulk operation functionality.

kadmin extensions

Building new functionality into kadmin has several advantages:

• Operations could be performed by lower-level administrators who are not granted direct access to the database.
• libkadm5 already "knows about" some of the affected data types (such as the KADM_DATA tl-data which contains the policy name).

But it also has some disadvantages:

• The kadmin protocol is not easily extensible, and this functionality is likely to need frequent extensions.
• The kadmin server is single-threaded. Reporting or bulk operations which do not complete quickly would block password changes and other kadmin operations.
• kadmin's ACL design might not be easily applied to operations on sets of principals.

kdb5_util extensions

We could extend kdb5_util dump by adding dump formats which are actually reports (perhaps with parameters), or add new kdb5_util commands, or create a new command which operates directly on the Kerberos database like kdb5_util does.

Dump file parsing

We could write a tool which examines a dump file and produces reports, or spits out an altered dump file. Advantages include:

• It does not impact any existing code.
• The tool could be written in Python, making it easier to extend.
• If the tool is a script, it could be used with older versions of krb5.

Disadvantages include:

• Dumping the database and then running a command over the dump is inherently more complicated than running a command directly.
• This approach probably only works for reporting. Performing bulk operations via dump-modify-load is not practical in most environments.
• The tool would have to know how to marshal and unmarshal tl-data, including KADM_DATA tl-data which is currently private to libkadm5.

This approach might work well for specific tasks such as generating reports of principals containing DES keys, but is probably not a good long-term general approach.

Scripting integration

We could make it easier to write scripts which iterate over the database to make reports or changes. This could take several forms.