[krbdev.mit.edu #6108] A client can fail to get initial creds if it changes the password while doing so.
The RT System itself via RT
rt-comment at krbdev.mit.edu
Wed Sep 3 19:10:09 EDT 2008
>From krb5-bugs-incoming-bounces at PCH.MIT.EDU Wed Sep 3 19:10:03 2008
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by krbdev.mit.edu (8.12.9) with ESMTP
id m83NA2o4013251; Wed, 3 Sep 2008 19:10:02 -0400 (EDT)
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 m83N9vOK022930;
Wed, 3 Sep 2008 19:09:57 -0400
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
[18.7.7.76])
by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m83JNcIZ021576
for <krb5-bugs-incoming at PCH.mit.edu>; Wed, 3 Sep 2008 15:23:38 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
m83JNTQh011519
for <krb5-bugs at mit.edu>; Wed, 3 Sep 2008 15:23:29 -0400 (EDT)
X-ASG-Whitelist: Barracuda Reputation
Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31])
by mit.edu (Spam Firewall) with ESMTP id 58C7FFCFE22
for <krb5-bugs at mit.edu>; Wed, 3 Sep 2008 15:23:29 -0400 (EDT)
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com
[172.16.52.254])
by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m83JNSKv004077
for <krb5-bugs at mit.edu>; Wed, 3 Sep 2008 15:23:28 -0400
Received: from blade.bos.redhat.com (blade.bos.redhat.com [10.16.0.23])
by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m83JNSeB025046
for <krb5-bugs at mit.edu>; Wed, 3 Sep 2008 15:23:28 -0400
Received: from blade.bos.redhat.com (localhost.localdomain [127.0.0.1])
by blade.bos.redhat.com (8.14.3/8.14.2) with ESMTP id m83JNSxO009896
for <krb5-bugs at mit.edu>; Wed, 3 Sep 2008 15:23:28 -0400
Received: (from nalin at localhost)
by blade.bos.redhat.com (8.14.3/8.14.3/Submit) id m83JNSsE009895;
Wed, 3 Sep 2008 15:23:28 -0400
Date: Wed, 3 Sep 2008 15:23:28 -0400
Message-Id: <200809031923.m83JNSsE009895 at blade.bos.redhat.com>
To: krb5-bugs at mit.edu
Subject: try to get creds from a master KDC if a non-master denies us right
after a password change
From: nalin at redhat.com
X-send-pr-version: 3.99
X-Scanned-By: MIMEDefang 2.42
X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254
X-Spam-Score: -1.638
X-Spam-Flag: NO
X-Mailman-Approved-At: Wed, 03 Sep 2008 19:09:51 -0400
X-BeenThere: krb5-bugs-incoming at mailman.mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: nalin at redhat.com
Sender: krb5-bugs-incoming-bounces at PCH.MIT.EDU
Errors-To: krb5-bugs-incoming-bounces at PCH.MIT.EDU
>Submitter-Id: net
>Originator: Nalin Dahyabhai
>Organization: Red Hat
>Confidential: no
>Synopsis: A client can fail to get initial creds if it changes the password while doing so.
>Severity: non-critical
>Priority: low
>Category: krb5-libs
>Class: sw-bug
>Release: 1.6.3
>Environment:
System: Linux blade.bos.redhat.com 2.6.25.4-30.fc9.x86_64 #1 SMP Wed May 21 17:34:18 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
Architecture: x86_64
>Description:
In a master/slave setup, if a client is configured to use a
non-master, a client with an expired password can attempt to get
credentials, receive a key-has-expired error, successfully change
the password, and then fail to get credentials.
>How-To-Repeat:
Point the client to a non-master in a replicating setup and
attempt "kinit" as a client whose key has expired. The client
will attempt to fetch creds from the slave, get a key-expired
error, get password-changing credentials (again, from the slave),
change the user's password (against the master), and then
re-attempt to get initial credentials using the new password
(again, from the slave).
>Fix:
Assume that KRB5_PREAUTH_FAILED is subject to propagation delay
between the master and replicas (this error is only returned by
this implementation when ENC_TIMESTAMP fails), and if we get a
key-expired error right after changing the password, try again
against the master KDC. Proposed patch:
Index: src/lib/krb5/krb/gic_pwd.c
===================================================================
--- src/lib/krb5/krb/gic_pwd.c (revision 20704)
+++ src/lib/krb5/krb/gic_pwd.c (working copy)
@@ -147,10 +147,10 @@
goto cleanup;
/* If all the kdc's are unavailable, or if the error was due to a
- user interrupt, or preauth errored out, fail */
+ user interrupt, or preauth errored out against the master, fail */
if ((ret == KRB5_KDC_UNREACH) ||
- (ret == KRB5_PREAUTH_FAILED) ||
+ ((ret == KRB5_PREAUTH_FAILED) && use_master) ||
(ret == KRB5_LIBOS_PWDINTR) ||
(ret == KRB5_REALM_CANT_RESOLVE))
goto cleanup;
@@ -320,6 +320,25 @@
krb5_get_as_key_password, (void *) &pw0,
&use_master, &as_reply);
+ if ((ret != KRB5KDC_ERR_KEY_EXP) || use_master)
+ goto cleanup;
+ else {
+ /* Okay, we *just* changed the password. Retry against a master KDC,
+ * because either the non-master's using outdated data or the admin
+ * has set an impossibly low maximum password lifetime. */
+ use_master = 1;
+ ret2 = krb5_get_init_creds(context, creds, client, prompter, data,
+ start_time, in_tkt_service, opte,
+ krb5_get_as_key_password, (void *) &pw0,
+ &use_master, &as_reply);
+ if ((ret2 != KRB5_KDC_UNREACH) &&
+ (ret2 != KRB5_REALM_CANT_RESOLVE) &&
+ (ret2 != KRB5_REALM_UNKNOWN))
+ ret = ret2;
+ else
+ use_master = 0;
+ }
+
cleanup:
krb5int_set_prompt_types(context, 0);
/* if getting the password was successful, then check to see if the
More information about the krb5-bugs
mailing list