Kiwi Phase-in

How it works now:

1. Host principals, policy changes, etc. are applied to the KDC on niven01 directly via kadmind or kadmin.local.

2. Password change updates come in to niven01's kadmind.
   1. Our code, inserted into the "good password hook" in kadmind, snarfs the password changes and squirrels them away.
   2. The squirrelled passwords are handed out to secondary databases:
      1. Brad's nebula server
      2. The UA pwsync code
      3. Jones's NT domain

3. Account creation updates come in to niven01's kadmind. Unfortunately the squirrelling process above misses these additions for some reason. The secondary databases don't hear about new accounts until their passwords are changed. Oh well, we can only improve on that.

4. Every hour on the half hour, niven01 sends any updates it got to niven02 via the Kerberos "propagate" function. Due to the delay of up to an hour, niven02's KDC can only be used as a last resort backup server.

How it will work someday:

1. Policy changes, etc. are applied to the KDC on all nivens via kadmind or kadmin.local. It is not expected that there will be many (if any) of these. If there are ongoing maintenance type chores that need to be done on all the KDCs, kiwi functions should be designed that support them so they can be maintained in the kiwi logs for later replay and to ensure that all KDCs are on the same page.

2. Host and user principal creation and administrator password changes are applied through the kiwi interface. Someday kiwi will enforce the policy of who can change whose password. Alternatively, that enforcement could be delegated to an even higher level (Mango, perhaps).
   1. The master kiwi server assigns each transaction a sequence number and passes the change to each of the chief kiwi servers.
   2. Each kiwi server applies the change to its own KDC and passes the change to any slave kiwi servers attached to it. The slave servers would include updaters for the secondary databases:
      1. Brad's nebula server
      2. The UA pwsync code
      3. Jones's NT domain

3. The user process will pick its KDC and admin server through a load-based DNS name. User password changes come in to whatever KDC via its kadmind.
   1. Our code, inserted into the "good password hook" in kadmind, snarfs the password changes and passes them back to the master kiwi server.
   2. The master kiwi server applies the changes exactly as above. The local KDC gets updated twice -- c'est la vie.

The phase-in process:

1. Kiwi servers are brought up on all the nivens. One will act as the master, the rest will be chiefs. They'll each update their own KDC. Niven01 continues to propagate its changes to the other nivens as well.

2. We start kadmind on niven02. It does not yet receive any updates so it will simply idle. The squirrelling process tapped in at the "good-password hook" in kadmind on each KDC server begins sending password changes they get to kiwi. Niven01's squirrelling process continues to send updates to the secondary databases (nebula, pwsync, etc). Password updates made via niven02's kadmind will not make it to the secondary databases.

3. We begin switching the secondary databases from receiving squirrelled updates to being true kiwi slave servers.

4. All utilities and tools that create or delete principals are switched over to using kiwi.

5. Propagation of niven01 changes to niven02 (and niven00) are disabled. At this point any changes to the KDC made outside kiwi need to be applied to all the KDCs. New functions should be added to kiwi as required.

6. Users begin using a load-based name for their KDC. They still need to use niven01 as their admin server since that's the only way the unconverted secondary databases will receive updates.

7. The last of the secondary databases is switched over to using kiwi.

8. Users can now use the load-based name for both their KDC and their admin server. Process complete.

9. Done.