Personally, I think kpropd functionality should just be merged into kadmind to make it cleaner code. That is fundamentally the split-brain framework I had to work within (it drove me nuts).
The other recommendation would be to create a hook interface for all principal changes and layer this on the hook, but that is significantly more work. This also opens up other user-configurable options to judge if some operations should be performed and possibly override values based on local business rules. Downstream from the master, however, sync is the only logical response, but I guess it could selectively sync (this would be scary).
I'm willing to invest the time in the first (merging into kadmind) if you agree with such. The second, however, isn't on my radar... Eventually, after it is merged into one, I could see a collaborative operating mode between a couple kadmind where multi-master could be implemented... (This might be my next thing.) The hook, however, is something MIT needs to decide upon and deviates a bit from the current hook design.