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