[36809] in Kerberos

home help back first fref pref prev next nref lref last post

RE: upgrading kerberos 1.9.4 to 1.13 with LDAP backend

daemon@ATHENA.MIT.EDU (Paul B. Henson)
Fri Feb 20 22:59:54 2015

From: "Paul B. Henson" <henson@acm.org>
To: "'Chris Hecker'" <checker@d6.com>
In-Reply-To: <CAOdMLc21QLW7hv4PbZMvRwOpt-9poheqwB67TFrY3ZRKp0FWvw@mail.gmail.com>
Date: Fri, 20 Feb 2015 19:59:30 -0800
Message-ID: <162701d04d8a$cd716250$685426f0$@acm.org>
MIME-Version: 1.0
Content-Language: en-us
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit

> From: Chris Hecker
> Sent: Wednesday, December 03, 2014 4:21 PM
> 
> I am going to need to make the exact same update at some point, so a report
> back on how it went would be great!

We finally finished this upgrade last week, and it went fine. Upgraded the schema on everything first, then one kdc at a time (a week or two apart), no problems no issues…

> On Dec 3, 2014 2:28 PM, "Paul B. Henson" <henson@acm.org
> <mailto:henson@acm.org> > wrote:
> 
> 
> 	We currently have three Kerberos servers running 1.9.4 using the LDAP
> 	backend and are planning to upgrade to 1.13. Historically we have
> always
> 	upgraded servers one at a time, slaves first, then the master, and done
> the
> 	upgrade in place with the temporary existence of different versions.
> 
> 	This is the first upgrade we have done since switching to the LDAP
> backend.
> 	We have account lockout enabled (shakes angry fist at ridiculous ISO
> audit
> 	checkbox), and our LDAP backend is multi master, so technically even
> though
> 	we have a load balancer in front directing kadmin load at any given time
> to
> 	only one of the three servers, they are all masters and updating the local
> 	database simultaneously.
> 
> 	I see that four new attributes (krbPwdAttributes, krbPwdMaxLife,
> 	krbPwdMaxRenewableLife, and krbPwdAllowedKeysalts) have been
> added to the
> 	krbPwdPolicy object class in the schema. openldap gets quite unhappy if
> one
> 	server tries replicating anattribute to another which does not have it
> 	defined 8-/, so I want to be sure to avoid that scenario.
> 
> 	I am tentatively thinking of updating the openldap schema on the
> existing
> 	systems prior to the update, and then updating Kerberos itself one
> system at
> 	a time as we have historically done. Does this seem reasonable, and will
> 	hopefully succeed without any interoperability issues?
> 
> 	Thanks much for any thoughts or suggestions.



________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos


home help back first fref pref prev next nref lref last post