[19417] in Kerberos_V5_Development
Re: Kerberos transport DNS record design
daemon@ATHENA.MIT.EDU (Roland C. Dowdeswell)
Thu May 26 22:59:37 2016
Date: Thu, 26 May 2016 22:59:05 -0400
From: "Roland C. Dowdeswell" <elric@imrryr.org>
To: Brandon Allbery <ballbery@sinenomine.net>
Message-ID: <20160527025904.GB14501@roofdrak.imrryr.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <278f6d54abdd4706a8be2e2a528ce62d@sinenomine.net>
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Thu, May 26, 2016 at 05:25:19PM +0000, Brandon Allbery wrote:
>
> - For either one, using LDAP backend with its replication facilities
> makes fallback unnecessary.
Does the LDAP backend promise that all of the slaves are up to date
before kadm5_create_principal() returns successfully? If not,
there will still be a race condition. We are currently starting
to see our developers deploy new services using VMs and containers
in an on-demand fashion on a large scale expecting to be able to
hit those services the moment the master KDC reports that the
principal has been created.
I also quite like the master failover because it provides additional
resiliency against things like: a slave's clock going out of skew;
an administrator truncating the Kerberos DB on a slave; a slave
running out of disk space and somehow rubbishing the KDB causing
the KDC to respond inappropriately; or an administrator of DNS
(often people in a different group in the organisation) messing up
the one of the SRV RRs to point at a different realm's KDC. I
suppose that I don't think that it makes sense for the client to
simply give up at the first sign of errors when there is a decent
chance that one of the other KDCs may very well have a better
answer. Remember that in many environments, almost all requests
to the KDCs should succeed, after all: if I'm making a TGS_REQ for
a service then in general I've connected to the service in question
and it has asked me to use GSSAPI/Kerberos authentication (at least
in the case of protocols like HTTP/Negotiate, SSH, SASL where GSSAPI
auth is negotiated.)
--
Roland Dowdeswell http://Imrryr.ORG/~elric/
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
