Difference between revisions of "Projects/Reporting-friendly KDB dump format"

Revision as of 17:06, 2 March 2015

This is split from Projects/KDB reporting and bulk operations.

Background

Operators often want to perform reporting operations on KDB data, but the dump format is optimized for loading by kdb5_util, not human reading or reporting using simple scripts. For example, the number of columns on each principal dump line depends on the number of keydata entries associated with that principal. Also, some useful metadata such as modification date are only present in a human-unfriendly hexadecimal format, as an artifact of being stored in the tl_data of the principal.

Format choice

Tab-separated value formats are probably acceptable to the largest variety of tools. These tools range from simple awk scripts to SQL databases.

There are several conceptual database tables, each of which will have a different set of columns. To allow combining these in a single dump file, each dump line will have a first column that indicates the conceptual table to which it belongs. Another option is to provide command line options to select an individual conceptual table to dump.

Conceptual tables

This is an attempt to split KDB data fields into a somewhat more normalized schema that is somewhat easier to manipulate for reporting purposes.

Principal metadata

• Principal name
• Last modified by (principal name)
• Last modification date

Principal keys

There will generally be multiple dump key data dump lines per principal. The order is significant (though typically it's only important within the active kvno), so there will need to be a key index number in case the user imports the dump into a data store that doesn't preserve the ordering of input lines (such as most relational databases).

Some open questions include whether to use numeric values or string representations for enctype or salt type. Maybe this can be a runtime option?

• Principal name
• Key index
• Key version number (kvno)
• Enctype
• Salt type
• Salt data as hex string (might be "-1" to denote no salt or normal/default salt)

A sample implementation of a "keyinfo" dump format is at https://github.com/tlyu/krb5/tree/keyinfo

Per-principal policy data

• Principal name
• Principal expiration date
• Password expiration date
• Max ticket lifetime
• Max renewable ticket lifetime
• Password policy name

Per-principal lockout data

These are the per-KDC (non-replicated) data that track failed logins due to incorrect passwords.

• Principal name
• Last success
• Last failure
• Count of failed attempts

Principal boolean attributes

This is currently an boolean flag word; it's probably best to make it a set of strings. This is a bit tricky because there are some flags that are of the form disallow_*.

• Principal name
• Attribute name if set (string form)

Principal string attributes

• Principal name
• Attribute name
• Attribute value

Password policy

• Policy name
• Min password life
• Max password life
• Min password length
• Min password character classes
• Password history length

Lockout policy

• Policy name
• Max failures
• Failure count reset interval
• Lockout duration

Ticket policy

• Policy name
• Max ticket lifetime
• Max renewable ticket lifetime

Policy boolean attributes

As for principal boolean attributes

Policy allowed keysalts

(Is this an ordered list?)

• Policy name
• Enctype
• Salt type