>I've been thinking about this recently, and I think what you want to do
>(though there is no clear API for this) is check the enctype of the
>long-term key that was actually used in getting the TGT.
Good point. Hrm, I guess that's not actually available currently
(although there's no reason an
On Tuesday, February 22, 2005 03:45:10 PM -0500 Ken Hornstein
<[EMAIL PROTECTED]> wrote:
krb5_change_password is not any worse to use than the init_creds API.
You can avoid the kadm5 API.
Oh, sure ... but I'm not sure that's sufficient. What you probably
want to do is query the database to see
>krb5_change_password is not any worse to use than the init_creds API.
>You can avoid the kadm5 API.
Oh, sure ... but I'm not sure that's sufficient. What you probably
want to do is query the database to see what enctypes your principal
record has (so you're not doing a whole lot of password chan
> "Ken" == Ken Hornstein <[EMAIL PROTECTED]> writes:
Ken> Thewre is one way ... but it requires you to have your
Ken> Kerberos Shit Together.
Ken> Write a custom login program that once you login correctly
Ken> using an AFS salted key, generates a V5 salted key from that
K
>To my knowledge there is no way to convert keys like you're wanting to do.
>My suggestion, if it's possible in your environment, would be to implement
>a password expiration policy with a deadline of a few months and let
>everyone gradually change their password.
Thewre is one way ... but it
Steve,
To my knowledge there is no way to convert keys like you're wanting to do.
My suggestion, if it's possible in your environment, would be to implement
a password expiration policy with a deadline of a few months and let
everyone gradually change their password.
The inevitable problem w
All;
We are in the process of converting our afs database (kaserver) to MIT
Kerberos 5
We have used Ken Hornstein's tool kit to get to where we are now.
We are finding however that many of the services that want to use K5
(Windows AD for example) will not succeed against the single des key
(des-cb