upgrading kerberos 1.9.4 to 1.13 with LDAP backend

[Todd Grayson]

>From a pure LDAP perspective;  You should be able to update schema in an
unobtrusive way as long as none of the attributes are "mandatory" for the
objectClass. If upon examination of the schema any of those new attributes
are mandatory as opposed to optional, then you have a requirement to update
entries with the mandatory attribute as you extend the schema.  That or
turn schema checking off for the window of migration until you can populate
the mandatory entry values... but that is less optimal if you have
provisioning going on still in the background.

As far as the rest of the plan - I've not performed this migration so there
might be folks who have that have wisdom to share (but it looks sound to
me).  Obviously have a clean back-out plan...



On Wed, Dec 3, 2014 at 3:25 PM, Paul B. Henson <henson at 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 at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>



-- 
Todd Grayson
Customer Operations Engineering