Difference between revisions of "Projects/What does God need with a password"
| Line 2: | Line 2: | ||
''kinit -C'' with apologies to [http://www.imdb.com/title/tt0098382/quotes Star Trek]. |
''kinit -C'' with apologies to [http://www.imdb.com/title/tt0098382/quotes Star Trek]. |
||
| − | The administrator of a Kerberos database has access to all user keys within that database. This is sufficient to impersonate any user. Today, no convenient user interface is provided for logging in as a given user without changing that user's |
+ | The administrator of a Kerberos database has access to all user keys within that database. This is sufficient to impersonate any user. Today, no convenient user interface is provided for logging in as a given user without changing that user's password. |
| − | This project proposes to add a ''- |
+ | This project proposes to add a ''-C'' (cheat) option to kinit. If this option is supplied, then the key will be extracted from the database rather than prompting for a password. This option requires that kinit be run on a KDC with read access to the Kerberos database and stash file. |
| − | |||
== Implementation == |
== Implementation == |
||
| Line 25: | Line 25: | ||
===Discussion=== |
===Discussion=== |
||
| − | Discussion on the krbdev mailing list focused on concerns that packagers would have to |
+ | Discussion on the krbdev mailing list focused on concerns that packagers would have to take the somewhat surprising action of bundling the KDC libraries with the client libraries in order to make kinit function. No one could identify a significant practical problem, and some packagers already bundle the KDC libraries with the client libraries. In the future, a plugin capability for keytabs should make this moot. |
Latest revision as of 15:19, 22 December 2010
kinit -C with apologies to Star Trek.
The administrator of a Kerberos database has access to all user keys within that database. This is sufficient to impersonate any user. Today, no convenient user interface is provided for logging in as a given user without changing that user's password. This project proposes to add a -C (cheat) option to kinit. If this option is supplied, then the key will be extracted from the database rather than prompting for a password. This option requires that kinit be run on a KDC with read access to the Kerberos database and stash file.
Implementation
Kinit will register and use the kdb keytab in order to access the database. It will actually contact the KDC process and go through the full AS-REQ path. The advantage of this is that any authorization data is generated. The disadvantage is that users who require pkinit or hardware preauth cannot be logged in using this mechanism. As a result, kinit will link against libkdb5 and libkadm5srv.
The -C option to kinit was already taken, so the usage becomes something more like kinit -k -t KDB:.
Review
This section documents the review of the project according to Project policy. It is divided into multiple sections. First, approvals should be listed. To list an approval type
- #~~~~
(hash mark followed by four tilde characters) on its own line. The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with {{project-block}}.
Approvals
- TomYu 19:42, 18 October 2010 (UTC)
Discussion
Discussion on the krbdev mailing list focused on concerns that packagers would have to take the somewhat surprising action of bundling the KDC libraries with the client libraries in order to make kinit function. No one could identify a significant practical problem, and some packagers already bundle the KDC libraries with the client libraries. In the future, a plugin capability for keytabs should make this moot.
