Return-Path: <nalin@redhat.com>
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by krbdev.mit.edu (Postfix) with ESMTP id F0B893EFF1 for <rt@krbdev.mit.edu>; Thu, 13 Dec 2012 18:09:20 -0500 (EST)
Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qBDN9K0Q015198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <rt@krbdev.mit.edu>; Thu, 13 Dec 2012 18:09:20 -0500
Received: from blade.bos.redhat.com (blade.bos.redhat.com [10.16.184.36]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qBDN9JZY027240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <rt@krbdev.mit.edu>; Thu, 13 Dec 2012 18:09:20 -0500
Received: from blade.bos.redhat.com (localhost.localdomain [127.0.0.1]) by blade.bos.redhat.com (8.14.5/8.14.5) with ESMTP id qBDN9Q0C014325 for <rt@krbdev.mit.edu>; Thu, 13 Dec 2012 18:09:26 -0500
Received: (from nalin@localhost) by blade.bos.redhat.com (8.14.5/8.14.5/Submit) id qBDN9PBg014324 for rt@krbdev.mit.edu; Thu, 13 Dec 2012 18:09:25 -0500
Date: Thu, 13 Dec 2012 18:09:25 -0500
From: Nalin Dahyabhai <nalin@redhat.com>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #7502] kldap plugin always writes to krbLastAdminUnlock
Message-ID: <20121213230925.GA14048@redhat.com>
References: <rt-7502@krbdev.mit.edu> <rt-7502-37760.11.9781609070053@krbdev.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <rt-7502-37760.11.9781609070053@krbdev.mit.edu>
Organization: Red Hat, Inc.
X-Disclaimer: I am not a spokesmodel.  Views expressed are my own.
X-Key-ID: 78688BF5
X-Key-Fingerprint: 60BC AD87 AF51 3A00 8C99  0388 379B CE57 7868 8BF5
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-BY: MIMEDefang 2.67 on 10.5.11.11
RT-Send-Cc: 
X-RT-Original-Encoding: us-ascii
Content-Length: 609

On Thu, Dec 13, 2012 at 06:05:20PM -0500, Greg Hudson via RT wrote:
> The problem seems bigger than just this symptom:

Agreed.

> * 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.

Yes, I think that'll work.

Thanks,

Nalin