Re: Incomplete documentation

[Andreas Haupt <ahaupt@ifh.de>]

On Fri, 19 Sep 2003, [iso-8859-2] Martin MOKREJ? wrote:

> On Fri, 19 Sep 2003, Andreas Haupt wrote:
> > The database is also encrypted on the slaves, just as Love already told
> > you. If you don't put /var/heimdal/m-key onto the slave as well, the kdc
> > on the slave will no be able to read the database - this means you cannot
> > authenticate against a slave server.
>
> So you say the data stored on slaves is encrypted with the m-key key
> present on master? That means hpropd on slave receives the data encypted
> and just stores them on the disk.

Right!

> Will kdc on slaves complain that there's no m-key and therefore it cannot
> decrypt the database hpropd created?

That's a good question. I think yes.

> I still don't understand how kdc on slaves knows it's not master kdc, and
> therefore should accept any password changes.

The kdc does not even care about this. It just takes the requested key out
of the database. The kdc does not care about key changing at all. Other
processes like hpropd, ipropd do the changes in the database. The kdc just
gets the new ones after changing.

> Is it so that kadmind accepts the user's password changes? I thought it's
> only for convience of admins to give them chance to use kadmin(1). ;)

kpasswdd (taking the new password from the client part kpasswd) does
the changing of user passwords. But kadmind is able to do this as well
(with kadmin).

> Or is it so that the `kdc = host.domain' defines on users machine where the
> passwords are sent to? As there can be multiple `kdc = ' lines I deduce
> that slaves do accepts password changes from users and cross-talk together.
> But I don't believe this as I don't run hpropd on my master. ;)

No, the entry kpasswd_server tells kpasswd where to find the daemon. If
this is not set it takes the entry admin_server.

Greetings
Andreas

-- 
Andreas Haupt         E-Mail: ahaupt@ifh.de
 DESY Zeuthen
 Platanenallee 6
 15738 Zeuthen