Ticket History #6108: A client can fail to get initial creds if it changes the password while doing so.

From krb5-bugs-incoming-bounces@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@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@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@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@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@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@mit.edu>; Wed, 3 Sep 2008 15:23:28 -0400
Received: (from nalin@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@blade.bos.redhat.com>
To: krb5-bugs@mit.edu
Subject: try to get creds from a master KDC if a non-master denies us right
after a password change
From: nalin@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@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



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

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

Hi, sorry to take so long to look into this, and thanks for your report.
I haven't tried reproducing your problem, so apologies if I'm just
confusing myself, but I don't see how your scenario can pan out. Here
is what I would expect to happen:

1. Client contacts slave KDC, gets KRB5KDC_ERR_KEY_EXP.

2. Client retries with master KDC, setting use_master to 1 (line 159).
It gets back KRB5KDC_ERR_KEY_EXP again. Because that value is not one
of KRB5_KDC_UNREACH, KRB5_REALM_CANT_RESOLVE, or KRB5_REALM_UNKNOWN
(line 178), use_master remains 1.

3. Client gets kadmin/changepw tickets from the master, because
use_master is still 1.

4. Client changes password.

5. Client gets a TGT from the master (use_master is still 1).

Your suggested solution would only take effect in a more unlikely
scenario, where in step 2 the client is unable to contact the master KDC
and thus resets use_master to 0, but is able to change the password.

The other part of your bug report appears to be that preauth can fail
when talking to a slave with an out-of-date key. I can see how that
might be true but want to talk about it with other people first.

On Wed, Apr 01, 2009 at 07:33:27PM +0000, Greg Hudson via RT wrote:

The variation I've seen is that there isn't an explicitly called-out
master, but several kdcs and one or more kpasswd_servers, or more likely
an admin_server.

The client attempts to get creds from a KDC, and fails, noting that the
key is expired. It's not able to resolve a master KDC for the realm, so
it resets use_master to 0. It continues on to get password-changing
creds and changes the password (the password change routine looks for a
kpasswd server, and falls back to an admin server, so this works). The
client then attempts to get creds, and because it's still talking to the
original server, it fails.


Sure, no problem.

Thanks,

Nalin

On Wed, Apr 01, 2009 at 11:21:33PM +0000, Greg Hudson via RT wrote:

Yeah, walking through it again, either I'm missing something now, or I
missed that use_master wasn't being reset when the password was changed
inside of krb5_get_init_creds_password().

The part about continuing on in the face of a preauth-failed error from
a slave KDC still reads right, though. For cases where libkrb5's been
told to not handle the password change internally, the caller gets a
key-expired error, changes the password by calling krb5_change_password()
directly, and subsequently can't get new creds.

Thanks,

Nalin

When getting initial credentials with a password, try the master if
preauth fails on a slave, since preauth can fail due to an out-of-date
key. This removes a snippet added in r14939 which was considering
only hardware preauth.


https://github.com/krb5/krb5/commit/03f73644d9fe650bffd6b6ede1b0598689610876
Commit By: ghudson
Revision: 22182
Changed Files:
U trunk/src/lib/krb5/krb/gic_pwd.c

pull up r22182 from trunk

------------------------------------------------------------------------
r22182 | ghudson | 2009-04-08 11:22:17 -0400 (Wed, 08 Apr 2009) | 9 lines
Changed paths:
M /trunk/src/lib/krb5/krb/gic_pwd.c

ticket: 6108
tags: pullup
target_version: 1.7

When getting initial credentials with a password, try the master if
preauth fails on a slave, since preauth can fail due to an out-of-date
key. This removes a snippet added in r14939 which was considering
only hardware preauth.

https://github.com/krb5/krb5/commit/28048770180d36143b38b6c57fa4fa2d59be7bb2
Commit By: tlyu
Revision: 22252
Changed Files:
U branches/krb5-1-7/src/lib/krb5/krb/gic_pwd.c