General Kerberos 1.9 Upgrade Issues

• The kerberos slave servers are also AFSDB machines. We therefore have to coordinate their upgrade with the AFS side of things.
  • Ideally we might have taken one of the slaves out for development work, but we can't now do that
  • The only other KDC we currently have is the master, but we want to do it last if we can
  • ... so we'll need to bring up another slave, or else a totally different realm
  • Is there a DevProj or wiki page or something tracking the AFSDB upgrades? We should cross-link.
  • Our kit list is here

• Previously we said: "There would be some robustness advantage in having the slave KDCs on site wires, rather than on B aka Transit aka .64 ..." On further reflection, this probably isn't worth it. The gain would be in external visibility, but routing failover should cover it in most cases. Internally each site's local KDC is accessible through the site's own routers, so partition wouldn't be such an issue. We do just have to be a bit more careful while KDCs are down (for upgrades and the like). For simplicitly, then, just leave the KDCs on B.

• The iFriend KDCs coexist at the moment with the cosign servers, so there'll be some coordination needed there too. Fortunately this time it's with ourselves!

Specific details

• See also:
  • DevProj #223
  • kerberos 1.9 release notes
  • kerberos roadmap
  • kerberos password quality interface
  • KDC rekeying page - we should bear this in mind

• We have to be aware of the AFS/single-DES issues, and work around them as necessary. It might be that 1.6.1 solves these.

• Along the way we need to put hooks in so that we can enable loading of a password-strength module.
  • Actually creating and configuring such is part of a different project.

• 1.9 should allow us to turn on the last-ticket history. We may need to add the hooks for that.
  • We'll also need a way to harvest and merge these from all the KDCs.

-- GeorgeRoss - 02 Feb 2012