Digant, Our KDC implements incremental propogation and provides the support for local password changes rather than a password change needing to connect to the master - we pass the password change request from slave to master(s) when received and then the master propogates this change back to ALL secondaries along with any updates made by administrators on the master. We rarely need to propogate the entire database since the slaves and masters are always in sync ...
Using this architecture allows a global realm to be deployed where a master, or masters can be deployed in HQ and regional slave servers can be used - there is no need to rely on wide area network for password changes or authentication since the slave servers in each regional location handle the needs of the clients in that location. We also provide load balancing support in our product. Thanks, Tim. -----Original Message----- From: Ken Hornstein [mailto:[EMAIL PROTECTED] Sent: 24 March 2004 19:38 To: Digant Kasundra Cc: '[EMAIL PROTECTED] ' Subject: Re: kerberos password change in master-slave environ >Changing is every 5 minutes still means you can't really login or do >anything until after 5 minutes have passed. And what do you do when your >password database is several megs and takes 2 or 3 minutes to transfer? I think you're making a mountain of a molehill here. It actually works pretty well in practice. There are three key things that you're missing: - People generally configure their KDCs so that queries go to the master first. Thus, you're almost always talking to the up-to-date KDC. - The MIT client code will requery the master KDC if it determined that there was an error and it talked to a slave KDC. - It only matters for the initial ticket; if you've already got a TGT, it doesn't matter if your key has changed. (Speaking as someone who deals with password changing issues very frequently). I'm not saying multi-master isn't desirable, but for the average realm, you can live without it. For a larger realm, (in the tens of thousands of principals) having incremental propagation probably takes care of the issues you have with DB propagation. --Ken ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
