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

Re: Incomplete documentation

Andreas Haupt <ahaupt@ifh.de> writes:

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

It won't, just just the keys are encrypted, and not the asn1 data structure
holding the keys, the kdc have no way of knowing if the keys are encrypted
of not. The only exception is that the size of the keys might change when
encrypting the data, so if you get a lot of KRB5_BAD_KEYSIZE, you are
either running old code or are without the master key.

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

Adding DNS SRV rr will also help you find the kdc, kpasswd and
kadmind. I've appened the documentation that I just wrote for this
(probably not good enough yet).


@node Setting up DNS, , Cross realm, Setting up a realm
@section Setting up DNS
@cindex Setting up DNS

If there is information about where to find the KDC or kadmin in the
@file{krb5.conf} for a realm that information will be preferred and
DNS will not be queried.

Heimdal will try to use DNS to find the KDCs for a realm. First it
will try to find @code{SRV} resource record (RR) for the realm. If no
SRV RRs are found, it will fall back to looking for a @code{A} RR for
a machine named kerberos.REALM, and then kerberos-1.REALM, etc

Adding this information to DNS makes the client have less
configuration (in the common case, no configuration) and allows the
system administrator to change the number of KDCs and on what machines
they are running.

The backside of using DNS that the client might be fooled to use the
wrong server if someone fakes DNS replies/data, but storing the IP
addresses of the KDC on all the clients makes it very hard to change
the infrastructure.

Example of the configuration for the realm @code{EXAMPLE.COM},


$ORIGIN example.com.
_kerberos._tcp          SRV     10 1 88 kerberos.example.com.
_kerberos._udp          SRV     10 1 88 kerberos.example.com.
_kerberos._tcp          SRV     10 1 88 kerberos-1.example.com.
_kerberos._udp          SRV     10 1 88 kerberos-1.example.com.
_kpasswd._udp           SRV     10 1 464 kerberos.example.com.
_kerberos-adm._tcp	SRV	10 1 749 kerberos.example.com.

@end example

More information about DNS SRV resource records can be found in
RFC-2782 (A DNS RR for specifying the location of services (DNS SRV)).

PGP signature