[2440] in Kerberos_V5_Development
Re: Password changing protocols
daemon@ATHENA.MIT.EDU (Naomaru Itoi (RISE!))
Tue Jul 15 19:00:44 1997
To: krbdev@MIT.EDU
Cc: andros@citi.umich.edu
In-Reply-To: Your message of "02 Jul 1997 17:23:44 EDT."
<t53en9hgnbz.fsf@rover.cygnus.com>
Date: Tue, 15 Jul 1997 18:58:36 -0400
From: Naomaru Itoi (RISE!) <itoi@eecs.umich.edu>
Hi.
I'm trying to write k5 password change program in NT. The client is
"The NT ALPHA 2 Snapshot", and the server is MIT krb5-1.0pl1 , running
on UNIX.
If I understand correctly,
- The Cygnus "krb5_change_password()" protocol can be used only if the
server is Cygnus KerbNet.
- Functions used in "GSS-API RPC" protocol in MIT kpasswd,
e.g. ovsec_kadm_chpass_principal_util(), do not exist in "The NT ALPHA
2 Snapshot". So I cannot make this work in NT.
- Thus, the only way to write change password in NT is to use
"v5passwdd" protocol.
Is this correct reasoning?
Ken Hornstein <kenh@cmf.nrl.navy.mil> writes:
>> Next question --- obviously there's nothing (in a practical sense) to stop
>> me from taking the necessary bits out of KerbNet and putting them in
>> the MIT kadmind ... but could I legally distribute those changes?
And how is this going?
I don't really know what's advantage and disadvantage of each
protocol, and cannot decide which I should follow...
Please give me some advice,
thanks.
--
Naomaru Itoi <itoi@eecs.umich.edu>
Center for Information Technology Integration, University of Michigan
http://www-personal.engin.umich.edu/~itoi/
---
Ken Hornstein <kenh@cmf.nrl.navy.mil> writes:
> As I see it, there are now three different protocols to change passwords
> in V5:
> - The "v5passwdd" protocol, used by v5passwd/v5paswdd and Annex
> terminal servers.
> - The massive "GSS-API RPC" protocol, used by the MIT kpasswd and kadmin.
> - The Cygnus "krb5_change_password()" protocl, used by the Cygnus kadmind
> and all of the
Marc Horowitz <marc@cygnus.com> writes:
> The Cygnus protocol is documented as
> <draft-ietf-cat-kerb-chg-password-00.txt>, and I'm pushing it for
> standards-track. I hope to issue a revision before Munich IETF.
