Ops feedback notes 2014-06-03
Dumps and long-lived KDB locks
Currently, dumping a KDB with a DB2 back end will lock the database for the entire duration of the dump, causing the KDC to cease responding if it needs to write to the KDB (e.g., account lockout data). The likely solution is to drop the lock between iteration steps when doing any iteration over the KDB (including dumps). One question is whether to do this optionally or not. Code would be simplified if iteration always dropped the lock between iteration steps.
After some discussion, it becomes clear that some sites need to be able to perform database dumps that are as transactional as possible. Even though kadmin operations against a KDB are not transactional, sometimes sites want to batch a set of modifications in as small timespan as possible. In this situation, the sites would prefer to have an all-or-nothing with respect to database dumps surrounding this batch operation.
Reporting for auditors
- Do principals have the right policies set?
- Last password change?
- Who has no policy set?
- Any evidence of bypassed policies?
- What enctypes? Who has single-DES keys still?
Format? Tab separated? CSV? JSON? Some preference for self-describing. Maybe CSV with header, maybe JSON. CSV or tab-separated are easier for some tools (awk, SQL, etc.), but JSON can represent more structured data that would otherwise need multiple rows per principal.
Some discussion about log scraping to look for DoS, other attacks. Reminder that MIT krb5 has experimental audit plugin.
