Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
RT-Send-CC:
X-RT-Original-Encoding: iso-8859-1
Content-Length: 687

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.