logo_kerberos.gif

Difference between revisions of "Projects/What does God need with a password"

From K5Wiki
Jump to: navigation, search
(kinit -C)
 
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{project-early}}
+
{{project-rel|1.9}}
 
''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 passowrd.
+
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.
+
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 ==
   
Kinit will register and use the kdb keytab in order to access the database. It will actually contact the KDC process and go through th efull 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.
+
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 <code>-C</code> option to kinit was already taken, so the usage becomes something more like <code>kinit -k -t KDB:</code>.
  +
  +
==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
  +
:<nowiki>#~~~~</nowiki>
  +
(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 <nowiki>{{project-block}}</nowiki>.
  +
  +
===Approvals===
  +
  +
# [[User:TomYu|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.

Latest revision as of 15:19, 22 December 2010

This project was completed in release 1.9.

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

  1. 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.