[prev in list] [next in list] [prev in thread] [next in thread]
List: kerberos
Subject: RE: upgrading kerberos 1.9.4 to 1.13 with LDAP backend
From: "Paul B. Henson" <henson () acm ! org>
Date: 2015-02-21 3:59:30
Message-ID: 162701d04d8a$cd716250$685426f0$ () acm ! org
[Download RAW message or body]
> 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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic