The problem seems bigger than just this symptom:

* krb5_ldap_put_principal doesn't check whether KADM5_TL_DATA is set in 
entry->mask.  So any tl_data in the principal will be written out in any 
update, whether normalized to type-specific LDAP attributes or marshalled 
into krbExtraData.  If you're going to use the patch you provided as a 
downstream workaround, I'd suggest nulling out entry->tl_data temporarily 
instead of just resetting the last-admin-unlock value.

* There's no way to specify via entry->mask which tl_data values should be 
written out, and which were just along for the ride from a previous fetch.  
Fixing that seems like a somewhat difficult design problem.