[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: kpasswd lies

David Komanek <xdavid@lib-eth.natur.cuni.cz> writes:

> Hi all,
> although I have still unresolved questions in the list, I have new ones,
> sorry :-)
> I.
> Unfortunately I got into the following situation: "primary" kdc and
> kadmind were not running, so kpasswdd ran on another host than kdc.
> According to man pages there is a need to run kpasswd on the same host as
> primary kdc. In this situation user passwords are really not changed, but
> kpasswd tells it was successfull on every attempt:
> $ /usr/local/heimdal/bin/kpasswd
> komanek@NATUR.CUNI.CZ's Password:
> New password:
> Verifying password - New password:
> Success : Password changed
> I consider it to be a bug, isn't it ?

The database/applications is not aware where the master database is, its
assumed that the sysadmin do the right thing and configure the master to be
the host that run the hprop, kadmind, kpasswdd, and that slave hosts
(hpropd) do not run kadmind and hpasswd.

> II.
> Another question: I use my own program to change passwords simultaneously
> in various environments where the user has an account. One of them is
> kerberos. After I verify the old password and verify the complexity of the
> new password of the user, I subsequently call routines changing passwords
> in various databases. My idea is to change password in heimdal directly,
> without the need to run kpasswdd and reimplement code from kpasswd.c to my
> own program. Another problem could be if kpasswdd would be accessible
> for users directly - they could de-synchronize their passwords. How can
> the direct password change on kdc be done via API (a working example is a
> best answer for me :-) ?

The simple way is to run `kadmin -l, but if you want to do it with C just
use the kadm5 api, and bind with kadm5_s_init_with_password_ctx() instead
of kadm5_c_init_with_skey_ctx().

Dunno if the perl module from can be forced to use


PGP signature