Differentiated kdc lists
Ken Raeburn
raeburn at MIT.EDU
Thu Dec 9 00:22:16 EST 2004
The syntax you chose seems okay, but it seems to me you'd get more
flexibility, and perhaps get it implemented faster, by having your DHCP
script (I realize I'm making some assumptions here) do some editing of
a local krb5.conf based on the assigned hostname or address block, when
the address is assigned. That does mean changes to the master in AFS
may not be immediately reflected in the client's behavior, but if
you've got the ability to run a script at lease renewal time, you can
bound the time after which all clients should be using updated data
taken from AFS.
Doing substitutions from a master in AFS into a local copy is one
approach. One (not very pretty) example where you could use one "sed"
invocation (with commands chosen based on the hostname) to produce the
new version:
@ifNotTestLan@ @ifNotSecure@ kdc = kerberos01.example.com
@ifTestLan@ kdc = kerberos20.test-lan.example.com
@ifSecure@ kdc = kerberos10.secure.example.com
If in secure.example.com,
sed -e "s/@ifNotTestLan@//" -e "s/@ifTestLan@/#/" -e "s/@ifSecure@//"
-e "s/@ifNotSecure@/#/"
etc.
Another option may be to pull in config file fragments, i.e.,
krb5.conf.general plus one of krb5.conf.secure or krb5.conf.test-lan or
krb5.conf.other, and just join the right ones together.
You could drop it all into a script (perhaps run out of AFS) that
people add to their DHCP callback scripts.
As Russ suggested, DNS SRV records might do too; hack your DNS servers
behind the firewalls to get you different results from the public ones
for this subdomain.
Or hack AFS magic symlinks (a la @sys) so you can create krb5.conf ->
krb5.conf. at location and tell each client what @location should be...
:-)
Ken
More information about the krbdev
mailing list