This is a discussion on Kerberos with dynamic address - Kerberos ; My basic situation is that I have a small group of computers in a domain where the KDC's public address changes from time to time (pppoe). I would just put the internal address in each machine's /etc/hosts file, but some ...
My basic situation is that I have a small group of computers in a domain
where the KDC's public address changes from time to time (pppoe). I
would just put the internal address in each machine's /etc/hosts file,
but some machines leave the network and must still connect to the KDC
and other kerberized services(pam_krb5 services, authenticating to LDAP,
authenticating to email services, etc) from remote locations.
I would still like to make kerberos work for my network services, if
possible. Is there any way to do this, without configuration steps
required on each bootup on the client machines, or specialized scripts
on the server side?
A couple of ideas I had - is it possible to disable reverse dns checks
on requests to kerberized servers? My KDC has a dyndns.org FQDN, but I
can't control the reverse dns. If this is possible, I'm done, because
that would solve all my problems. I'm a little unclear as to why the
reverse DNS checks are very necessary in the first place, since
information is only presented in encrypted form to servers providing
kerberized services anyway.
Is it possible for ldap, nss, dns to somehow serve up the appropriate
host names/resolutions of those names to my roaming clients? I'm not
sure if BIND can dynamically change the address it serves up, and I'd
rather still allow my clients to just get their nameservers via dhcp
when they're out roaming.
Basically, the question is - If I can't control my reverse DNS, and
don't have a static IP to put in /etc/hosts, can I have clients outside
my internal network that can still connect seamlessly, and use
I have seen this, but am looking for a workaround.
It just seems a shame that kerberos is out of the question for everyone
without static ip or reverse dns mapping, and want to make sure this is
really the case.
Kerberos mailing list Kerberos@mit.edu