From krb5-bugs-incoming-bounces@PCH.mit.edu Thu Dec 13 17:24:19 2012 Return-Path: Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by krbdev.mit.edu (Postfix) with ESMTP id D6D263F00B; Thu, 13 Dec 2012 17:24:18 -0500 (EST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id qBDMOICf024067; Thu, 13 Dec 2012 17:24:18 -0500 Received: from mailhub-dmz-2.mit.edu (MAILHUB-DMZ-2.MIT.EDU [18.7.62.37]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id qBDMH2Vs023206 for ; Thu, 13 Dec 2012 17:17:02 -0500 Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by mailhub-dmz-2.mit.edu (8.13.8/8.9.2) with ESMTP id qBDMGu27002869 for ; Thu, 13 Dec 2012 17:17:01 -0500 X-AuditID: 1209190d-b7f266d00000092b-10-50ca53dd1a96 Authentication-Results: symauth.service.identifier; spf=pass; senderid=pass Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id D3.B9.02347.DD35AC05; Thu, 13 Dec 2012 17:17:01 -0500 (EST) Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qBDMH0GB025764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 13 Dec 2012 17:17:00 -0500 Received: from blade.bos.redhat.com (blade.bos.redhat.com [10.16.184.36]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qBDMGxgw005448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Dec 2012 17:17:00 -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 qBDMH6ar011424 for ; Thu, 13 Dec 2012 17:17:06 -0500 Received: (from nalin@localhost) by blade.bos.redhat.com (8.14.5/8.14.5/Submit) id qBDMH5Ga011423; Thu, 13 Dec 2012 17:17:05 -0500 Date: Thu, 13 Dec 2012 17:17:05 -0500 Message-Id: <201212132217.qBDMH5Ga011423@blade.bos.redhat.com> To: krb5-bugs@mit.edu Subject: kldap plugin always writes to krbLastAdminUnlock From: nalin@redhat.com X-send-pr-version: 3.99 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleJIrShJLcpLzFFi42K52LJdRvdu8KkAg1+PNS0aHh5nd2D0aDpz lDmAMYrLJiU1J7MstUjfLoErY1HnVtaC4+IVrc0bWBsYO4W6GDk5JARMJBbeaWQEsRkFvCXe XD3ODhEXk7hwbz1bFyMXh5DACUaJec0/2SGcTUwSj1/cYIRwljJJPJr+jxXCOckoce7QIaiy NkaJ57cvgg1jEVCVuPR2FpjNK2AnsfLAJ1YQW0RAVOLl32MsILawgKXEptcTmUBsNqDlN+ad AqsREpCSaL80nQ3EZhZgkfjzZgMLxIHiEju2n4Y6Vlvic/NMlgmMggsYGVYxyqbkVunmJmbm FKcm6xYnJ+blpRbpGunlZpbopaaUbmIEhpoQpyTvDsZ3B5UOMQpwMCrx8E7gPBUgxJpYVlyZ e4hRkoNJSZRX3RsoxJeUn1KZkVicEV9UmpNafIhRgoNZSYS31w8ox5uSWFmVWpQPk5LmYFES 572SctNfSCA9sSQ1OzW1ILUIJsvEwX6IUYaDQ0mC93UQULdgUWp6akVaZk4JshpOEMEFsoYH aM0VkELe4oLE3OLMdIiiU4y6HIuX3HzKKMSSl5+XKiXOOxukSACkKKM0D24YLG1cYpSVEuZl ZGBgEOIBugYYCKjyrxjFgQEgDDGFJzOvBG7TK6AjmICOiLt0HOSIkkSElFQDY2tbj6Z9b+/h 0m+vK1OTQ+d9dtrwxDB0bty+aUHxQhun/5xseWLrq7WvJ+zY5PfCo6HPJNPANWqu7NOy45Um u/9tmaPeopl9btcFOctG5zwRg0drixddDXKKYlm/uLbL6/7epu23j5s/PsN1waZ2avzMWQH5 cc4vnsVHriouy7BKqtsTefB0rhJLcUaioRZzUXEiAElhC9cWAwAA X-Mailman-Approved-At: Thu, 13 Dec 2012 17:24:17 -0500 X-BeenThere: krb5-bugs-incoming@mailman.mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: nalin@redhat.com Sender: krb5-bugs-incoming-bounces@PCH.mit.edu Errors-To: krb5-bugs-incoming-bounces@PCH.mit.edu >Submitter-Id: net >Originator: >Organization: Red Hat >Confidential: no >Synopsis: kldap plugin always writes to krbLastAdminUnlock >Severity: non-critical >Priority: low >Category: krb5-kdc >Class: change-request >Release: 1.10.3 >Environment: System: Linux blade.bos.redhat.com 3.6.9-4.fc18.x86_64 #1 SMP Tue Dec 4 14:12:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Architecture: x86_64 >Description: When the kldap plugin is being used for accessing the realm database, if an administrator ever uses kadmin to manually unlock an entry in the database, an entry will have a krbLastAdminUnlock added to it. We've gotten a report that after that happens, whenever a KDC attempts to audit log an AS request, the KDC will attempt to write the current value of the entry's krbLastAdminUnlock attribute to the entry. In deployments where the KDC's write access is restricted to specific attributes, this will fail. >How-To-Repeat: Set up a KDC and directory server using the kldap db2 module, and either tcpdump or directory server logging to observe any LDAP modify requests that the KDC makes. Either create a new client entry with the preauth-required flag set on it, or choose an already-created one and ensure that it doesn't have a krbLastAdminUnlock value in its entry. Apply a policy to the client entry that includes lockout-related parameters. Use kinit to obtain new credentials as the client. Use "modprinc -unlock" to set a krbLastAdminUnlock value on the client entry. Use kinit to obtain new credentials as the client. Compare the set of attributes which the KDC attempted to modify in the entry after each successful AS request. The second set will unnecessarily include krbLastAdminUnlock. >Fix: It's not particularly elegant, but this appears to work: Try to avoid writing krbLastAdminUnlock when we're just doing auditing in the KDC. Because we know that kdb5_ldap_put_principal() only writes the attribute when it's nonzero, we temporarily set the value to zero to make sure that it isn't written. --- src/plugins/kdb/ldap/libkdb_ldap/lockout.c +++ src/plugins/kdb/ldap/libkdb_ldap/lockout.c @@ -217,8 +217,14 @@ krb5_ldap_lockout_audit(krb5_context context, } if (entry->mask) { - code = krb5_ldap_put_principal(context, entry, NULL); - if (code != 0) + /* temporarily clear the last-admin-unlock time so that we don't try + * to write to it -- we're just here to update audit data */ + if ((code = krb5_dbe_lookup_last_admin_unlock(context, entry, + &unlock_time)) || + (code = krb5_dbe_update_last_admin_unlock(context, entry, 0)) || + (code = krb5_ldap_put_principal(context, entry, NULL)) || + (code = krb5_dbe_update_last_admin_unlock(context, entry, + unlock_time))) return code; }