Ticket History #940: Core dump with AD user with funky password settings

From mike.moore@dotspot.com Tue Apr 10 10:36:59 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
by rt-11.mit.edu (8.9.3/8.9.3) with ESMTP id KAA19383
for <bugs@RT-11.mit.edu>; Tue, 10 Apr 2001 10:36:58 -0400 (EDT)
Received: from liilexch01.divine.com (liilexch01.divine.com [208.203.56.157])
by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA03018
for <krb5-bugs@mit.edu>; Tue, 10 Apr 2001 10:36:59 -0400 (EDT)
Received: by liilexch01.dotspot.com with Internet Mail Service (5.5.2653.19)
id <23H0TBXB>; Tue, 10 Apr 2001 09:36:46 -0500
Message-Id: <D36F9D1560DAD311B86D009027DC78B30766C791@liilexch01.dotspot.com>
Date: Tue, 10 Apr 2001 09:36:42 -0500
From: "Moore, Mike" <mike.moore@dotspot.com>
To: "'krb5-bugs@mit.edu'" <krb5-bugs@mit.edu>
Subject: Core dump with AD user with funky password settings

How you doing?

I just ran into an interesting issue with a kerberos client trying to
authenticate an Active Directory user. The user was an admin in my group
who one day (long ago) was frustrated that his password had expired again
and decided to go in and check "password never expires" for his login.
Yesterday I tried to add his to a kerberos client and was getting a core
dump when trying to kinit his login.

After a little more testing, it seems that simply having a user with
"password never expires" checked works fine. It seems that the seg fault
occurs when the user has both a password that has expired already and has
"password never expires" checked.

Please let me know if this is unclear or if you need more info.

Thanks again for your kickass product.

Mike
630-799-7500 x33832

Responsible-Changed-From-To: gnats-admin->krb5-unassigned
Responsible-Changed-By: raeburn
Responsible-Changed-When: Fri Jun 22 23:37:29 2001
Responsible-Changed-Why:

Responsible-Changed-From-To: krb5-unassigned->raeburn
Responsible-Changed-By: raeburn
Responsible-Changed-When: Fri Oct 26 20:56:27 2001
Responsible-Changed-Why:
I'll take it...


From: Ken Raeburn <raeburn@MIT.EDU>
To: mike.moore@dotspot.com
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-misc/940: Core dump with AD user with funky password settings
Date: Wed, 31 Oct 2001 00:10:01 -0500

Hi. I'm trying to reproduce the problem you reported:

I just ran into an interesting issue with a kerberos client trying to
authenticate an Active Directory user. The user was an admin in my group
who one day (long ago) was frustrated that his password had expired again
and decided to go in and check "password never expires" for his login.
Yesterday I tried to add his to a kerberos client and was getting a core
dump when trying to kinit his login.

After a little more testing, it seems that simply having a user with
"password never expires" checked works fine. It seems that the seg fault
occurs when the user has both a password that has expired already and has
"password never expires" checked.

I'm sorry it took us so long to get back to you; we're too
understaffed and bug reports often don't get as much attention as they
should. :-( But we do appreciate people taking the time to notify us
of problems they've encountered, especially ones like this that we
haven't run into ourselves!

Can you tell me more about the specific setup? Is the password
expiration from a group policy setting, or did this come about some
other way? Was it a UNIX or Windows version of kinit on the client
side, and do you know which version of our software it was?

I'll try to set it up here to test, but I'm no Windows expert, and
will have to tell our Windows folks how to set up the AD entries for
me.

Oh -- do you happen to recall if you tried changing the password with
kpasswd? There was a problem we had a while back which might be
related to your problem. As I recall, if krb5.conf didn't have
exactly one listing for kpasswd_server for a realm, there were
circumstances under which the client programs could crash when trying
to change the user's password. A password change should've been
triggered if the password-expired state was reported to the client.
If that was the problem, kpasswd should crash regardless of the AD
settings.

Ken

From: "Moore, Mike" <Mike.Moore@divine.com>
To: "Ken Raeburn" <raeburn@mit.edu>
Cc: <krb5-bugs@mit.edu>
Subject: RE: krb5-misc/940: Core dump with AD user with funky password settings
Date: Wed, 31 Oct 2001 08:36:09 -0600

Hi Ken,

The user's password expired through the default user password expiration
setting (I don't think that's considered a group policy). I was using
the Unix version on the client side running on either Solaris 2.6 or
Redhat 7.0... I can't remember. I'm pretty sure I was using krb5-1.2.2.

I never tried to change the password with kpasswd, that's not something
we normally would do because all of our user administration is typically
done through AD, I don't even have an entry for kpasswd_server in my
krb5.confs.

Here's what our typical krb5.conf looks like:

[libdefaults]
default_realm = DIVINE.COM
default_tkt_enctypes = des-cbc-md5 ; or des-cbc-crc
default_tgs_enctypes = des-cbc-md5 ; or des-cbc-crc

[realms]
DIVINE.COM = {
kdc = liil05.divine.com:88
}

Please let me know if you'd like me to try to re-create the problem on
my end, I'd love to be able to help.

Thanks,

Mike
630-799-7500 x33832