Difference between revisions of "Ops feedback notes 2014-06-03"
(New page: {{opsnotes|2014}} == 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 r...) |
|||
| Line 18: | Line 18: | ||
Some discussion about log scraping to look for DoS, other attacks. Reminder that MIT krb5 has experimental audit plugin. |
Some discussion about log scraping to look for DoS, other attacks. Reminder that MIT krb5 has experimental audit plugin. |
||
| + | |||
| + | == Java GSS == |
||
| + | |||
| + | Different versions of Java have interop issues. <=1.6.0.24? Can people use JNI? Not always. |
||
== Keytab provisioning == |
== Keytab provisioning == |
||
| + | |||
| + | Clustered services that have multiple hosts needing to share a single service principal/key. Different sites have different requirements for how this needs to work. Some have security checks to determine if an individual host may retrieve the current shared service key for the cluster. One example is to have username.hostname.domain, using a *.hostname.domain wildcard for each host. (Obviously some DNS administrators won't like this.) |
||
| + | |||
| + | == Face-to-face Kerberos ops forum == |
||
| + | |||
| + | Kerberos ops forum in person Sep. 17 (day before MIT-KIT conference). |
||
Latest revision as of 09:49, 30 June 2014
Contents
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.
Java GSS
Different versions of Java have interop issues. <=1.6.0.24? Can people use JNI? Not always.
Keytab provisioning
Clustered services that have multiple hosts needing to share a single service principal/key. Different sites have different requirements for how this needs to work. Some have security checks to determine if an individual host may retrieve the current shared service key for the cluster. One example is to have username.hostname.domain, using a *.hostname.domain wildcard for each host. (Obviously some DNS administrators won't like this.)
Face-to-face Kerberos ops forum
Kerberos ops forum in person Sep. 17 (day before MIT-KIT conference).
