Immediate password propagation

[g.w@hurderos.org]

On Apr 12,  7:26pm, <Rahul.Jain at wellsfargo.com> wrote:
} Subject: Immediate password propagation

Good morning to everyone, hope the day is starting out well.

> Is there a way or a plan to implement immediate propagation of password
> changes?

Not in the current MIT release.  We are getting infra-structure in
place to change that.

> If a client GSS implementation does not support the DNS
> _kerberos-master._udp SRV record and it gets load-balanced to a
> slave KDC, it will fail authentication if replication hasn't yet
> completed, right? Or is that implemented in the MIT KDC code itself
> when it recognizes that it is configured as a slave? Is there a way
> to use the standard kpasswd and have the master KDC push the new
> password to the slaves itself if the GSS implementation needs to be
> aware of this setup?

The MIT KDC code doesn't have any kind of an idea whether it is a
slave or master.  All it knows about is what its current database
contents tell it.  A 'master' KDC is more or less defined by the
whether or not the kadmind facility is up and running.

The MIT replication model consists of dumping the database in ASCII
and pitching it over to the 'slave' machines which replace their
current database with the imported ASCII copy.  If a client attempts
to target one of the slave machines for an AS_REQ or other services
for 'new' information before the database is updated the request will
fail.

This usually isn't a significant issue unless you are running your
KDC's behind some kind of hardware load-balancer.  Most sites will
have their primary KDC as the first or master KDC in their
configuration files or DNS entries and typically that primary will end
up answering about 98%+ of the requests.  General consensus on this
list is that hardware load balancing of a KDC isn't that great of an
idea.  Individual mileage and requirements may vary of course.

That being said there is legitimate rationale for quasi-synchronous
password updates if not a true multi-master configuration.  The latter
being a somewhat more difficult implementation than synchronous
password updates.  Sites with really large authentication databases
have sometimes found performance issues secondary to the
dump/pitch/load replication model.

We now have the infra-structure to support quasi-synchronous password
updates in place.  Our project needed to change the behavior of the
MIT KDC implementation and we chose to do that through a pluggable
extension architecture.  Our roadmap for the 0.1.5 release includes
support for centralized authentication services and synchronous
password updates using this infra-structure.

We ended up getting tied up with a Fortune 500 project which has cut
down on our GPL development time so 0.1.[45] are pushed back a bit.
In the meantime if you or anyone else is interested in working on
synchronous password updates you can grab the current 0.1.3 release or
I would be happy to send you our current development plugin patch for
1.3.6 or 1.4.x and a general outline for what needs to be done.

> TIA,
> 
> Rahul Jain

I hope the above information is helpful.  Let me know if you have any
questions.

Have a good day.

Greg

}-- End of excerpt from <Rahul.Jain at wellsfargo.com>

As always,
Dr. Greg 'GW' Wettstein
------------------------------------------------------------------------------
                         The Hurderos Project
         Open Identity, Service and Authorization Management
                       http://www.hurderos.org