Bug 4630 - Endless Password Expiration in 3.0.25
Endless Password Expiration in 3.0.25
Status: RESOLVED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: Domain Control
3.0.25
Other Windows XP
: P3 major
: 3.0.25
Assigned To: Jim McDonough
Samba QA Contact
:
: 4647 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-17 10:29 UTC by imacat
Modified: 2007-05-29 06:04 UTC (History)
3 users (show)

See Also:


Attachments
Possible patch (5.82 KB, patch)
2007-05-18 18:39 UTC, Jeremy Allison
no flags Details
Working patch :-) (5.82 KB, patch)
2007-05-18 20:03 UTC, Jeremy Allison
no flags Details
updates for special cases of TIME_T_MAX (630 bytes, patch)
2007-05-21 10:59 UTC, Jim McDonough
no flags Details
Complete patch (10.59 KB, patch)
2007-05-22 07:20 UTC, Gerald (Jerry) Carter
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description imacat 2007-05-17 10:29:57 UTC
Hi.  This is imacat from Taiwan.  I saw no one has filed this bug yet.

    I have just upgraded from Samba 3.0.24 to 3.0.25.  My environment is x86_64, Debian 4.0 r0 Etch, kernel 2.6.18-4-amd64, gcc 4.1.2, glibc 2.3.6.  We are running Samba as our PDC and only server.  After upgrade, all of our users are prompt that their password is expired and they should update their password.  No matter they update it or not, they are still prompt next time.  I have run "pdbedit user -c '[X ]' for each user, but it does not work.  I have checked my /etc/samba/private/smbpasswd.  Everyone's flag is [UX ].  I run "pdbedit -Lv user".  Everyone is:

...
Password last set:    Sun, 08 Apr 2007 04:53:35 CST
Password can change:  Sun, 08 Apr 2007 04:53:35 CST
Password must change: 9223372036854775807 seconds since the Epoch
...

    Which does not seem to have any problem.  But our users are still prompted for password expiration every time they log in.

    Is there any hint on this issue?  Thank you very much.  Please tell me if you need any more information.
Comment 1 Jeremy Allison 2007-05-18 12:28:12 UTC
I think this is a 64-bit vs 32-bit time -1 issue. Investigating...
Jeremy.
Comment 2 Jeremy Allison 2007-05-18 12:34:40 UTC
9223372036854775807 == 0x7FFFFFFF
I'm guessing this isn't being correctly checked as "max time".
More investigation to come.
Comment 3 Jeremy Allison 2007-05-18 12:35:25 UTC
I meant : 9223372036854775807 == 0x7FFFFFFFFFFFFFFF :-).
Comment 4 Jeremy Allison 2007-05-18 16:42:05 UTC
Can you send me a ethereal/wireshark trace of a logon being denied. I'd really like to see the error messages here please.

Thanks,

Jeremy.
Comment 5 Jeremy Allison 2007-05-18 18:39:41 UTC
Created attachment 2704 [details]
Possible patch

Can you try applying this patch please and then resetting the passwords.
This was definately a bug in 3.0.25, but I'm not sure if it's the bug you're
seeing.
Jeremy.
Comment 6 Jeremy Allison 2007-05-18 20:03:09 UTC
Created attachment 2705 [details]
Working patch :-)

Arg. This patch actually compiles. Sorry.
Comment 7 Christian Perrier 2007-05-19 02:31:53 UTC
From the user who reported this in Debian:

>
>
> Ralph, what architecture do you use?

Hi Christian,

no, I don't use 64bit on this system. It is quite a standard i386 based Debian
Sid System (running for at least 5 years now).

Linux services 2.6.20-1-k7 #1 SMP Tue Apr 24 22:37:29 UTC 2007 i686 GNU/Linux


Comment 8 Sky Lau 2007-05-19 21:10:18 UTC
I have applied for the patch but nothing changes.
Is there something missing to be modified?
Comment 9 Gerald (Jerry) Carter 2007-05-19 22:08:32 UTC
Make sure you do a clean build

$ cd samba-3.0.25/source/
....apply patch.....
$ make distclean
$ ./autogen.sh
$ ./configure <add any additional options here>
$ make && make install
Comment 10 Jeremy Allison 2007-05-20 00:07:07 UTC
This patch doesn't look like it's a fix for the issue. In order to fix this I need an ethereal/wireshark trace of a logon being denied as well as a debug level 10 trace from the smbd denying the user logon.

I can't make progress on fixing this bug without these from someone who is suffering from the problem.

Jeremy.
Comment 11 imacat 2007-05-20 00:39:06 UTC
Patch#2705 does not solve this problem.  I may submit a level 10 debug log in, should you need one.  Which version do you need?  Samba 3.0.25, or Samba 3.0.25+patch#2705?
Comment 12 Ralph Passgang 2007-05-20 18:38:10 UTC
Hi,

I am having the same problem on debian (i386) with samba 3.0.25.

Maybe this information helps you to understand the problem, because I think a tcpdump of the traffic will not help a lot. It seems to be a bug somewhere in samba causing to have a wrong password expire timeout.

With Samba 3.0.25 pdbedit show this (with similiar times) for all my domain users:

Password last set:    Fri, 18 May 2007 20:57:21 CEST
Password can change:  Fri, 18 May 2007 20:57:21 CEST
Password must change: Fri, 18 May 2007 21:03:17 CEST

If I downgrade to 3.0.24 (without setting the password again), pdbedit shows this:

Password last set:    Fri, 18 May 2007 20:57:21 CEST
Password can change:  Fri, 18 May 2007 20:57:21 CEST
Password must change: Tue, 19 Jan 2038 04:14:07 CET

So something seems to be broken within the samba code to calculate/set the password expire time and thats why domain logons fail and users are forced to change their password over and over again (each new password is only valid for 6 minutes).

I have reported this within the debian bug tracking system. Please see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425083 for more information (config options and so on).

hope this helps a bit.

--Ralph
Comment 13 Jim McDonough 2007-05-21 07:57:10 UTC
Please do include a trace.  I'm curious as to why you would get 64-bit time_t on a 32-bit system.  Can you include a 'net sam policy show "max password age"', or on the older samba a 'pdbedit -C "max password age"' (the latter should work on the newer one as well) ?
Comment 14 Jim McDonough 2007-05-21 07:57:44 UTC
Ah, i've recreated it on my 64-bit system too.
Comment 15 imacat 2007-05-21 10:27:24 UTC
(In reply to comment #13)
> Please do include a trace.  I'm curious as to why you would get 64-bit time_t
> on a 32-bit system.  Can you include a 'net sam policy show "max password
> age"', or on the older samba a 'pdbedit -C "max password age"' (the latter
> should work on the newer one as well) ?

Jim,

    I'm not quite sure who you are talking to.  I have made a test you said, in case it may help.  And I suppose you mean "pdbedit -P" instead of "pdbedit -C", and "maximum password age" instead of "max password age".  Here is the result of Samba 3.0.25:

root@rinse:~# net sam policy show "maximum password age"
Account policy "maximum password age" description: Maximum password age, in seconds (default: -1 => never expire passwords)
Account policy "maximum password age" value is: -1
root@rinse:~# pdbedit -P "maximum password age"
account policy "maximum password age" description: Maximum password age, in seconds (default: -1 => never expire passwords)
account policy "maximum password age" value is: 4294967295
root@rinse:~#

    And here is the test on Samba 3.0.24:

root@rinse:~# net sam policy show "maximum password age"                        net sam createbuiltingroup Create a new BUILTIN group
net sam createlocalgroup Create a new local group
net sam mapunixgroup    Map a unix group to a domain group
net sam addmem          Add a member to a group
net sam delmem          Delete a member from a group
net sam listmem         List group members
net sam list            List users, groups and local groups
net sam show            Show details of a SAM entry
net sam set             Set details of a SAM account
root@rinse:~# pdbedit -P "maximum password age"
account policy "maximum password age" description: Maximum password age, in seconds (default: -1 => never expire passwords)
account policy "maximum password age" value is: 4294967295
root@rinse:~#

    My environment is in the first post.  Hope that this helps.  Please tell me if you need any information.
Comment 16 Jim McDonough 2007-05-21 10:59:47 UTC
Created attachment 2714 [details]
updates for special cases of TIME_T_MAX
Comment 17 Jim McDonough 2007-05-21 11:02:00 UTC
Ok, I checked in that last patch (after trying it out on 64-bit systems where I had recreated the problem) with revision 23041.  Please try again and verify.
Comment 18 imacat 2007-05-21 11:52:21 UTC
(In reply to comment #17)
> Ok, I checked in that last patch (after trying it out on 64-bit systems where I
> had recreated the problem) with revision 23041.  Please try again and verify.

    Hi.  This is imacat from Taiwan.  I have tried this patch#2714.  It seems to work till now.

    I shall keep watching.  Thank you very much for this effort.
Comment 19 Gerald (Jerry) Carter 2007-05-22 07:20:42 UTC
Created attachment 2719 [details]
Complete patch

Cumulative patch which includes the force group, object picker, 
and pw expiration fixes.
Comment 20 Gerald (Jerry) Carter 2007-05-22 07:20:56 UTC
*** Bug 4647 has been marked as a duplicate of this bug. ***
Comment 21 franck pignard 2007-05-22 10:17:01 UTC
Hi all, i had the same problem with a Novell SuSe SLES10 3.025 (x64 version)

1) Users were asked to change password at each log-on (but they can ignore the message fortunately)
2) No others (Windows 2003 R2 entreprise) servers directory sharing was possible

The only thing i have done is to back to 3.0.24 (x64)version
Because i always take the official RPM package from Samba FTP site.
In my personal case, i will wait for the next 3.026 offical x64 version !
Regards
Comment 22 Christian Perrier 2007-05-28 12:48:33 UTC
Apparently, we have users in Debian who *still* experience the bug with 3.0.25a:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425083;msg=26

Full bug report in Debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425083

Should I open a new bug report for that?
Comment 23 Jim McDonough 2007-05-28 12:57:08 UTC
Ok, in this case I'm wondering what this user has for a "maximum password age" setting.  Please run  

pdbedit -P "maximum password age"

and report the findings back.
Comment 24 Christian Perrier 2007-05-29 03:58:42 UTC
Jim (and others), comment from our user:


First with version 3.0.24:
# pdbedit -P "maximum password age"
account policy "maximum password age" description: Maximum password age, in 
seconds (default: -1 => never expire passwords)
account policy "maximum password age" value is: 356

The password expire time is 356 seconds? But on 3.0.24 and before my user has 
a expire time of 30 years and I never had any problems with this. So upstream 
seems to have a none working password expire validation check for e very long 
time. My debian sid box with samba is running for at least 4 years!

Now to 3.0.25a:

pdbedit -P "maximum password age"
account policy "maximum password age" description: Maximum password age, in 
seconds (default: -1 => never expire passwords)
account policy "maximum password age" value is: 356

Still 356 seconds, but this time the user really has just password that is 
valid for 5:56 minutes (356 seconds). pdbedlit -L -n -v <username> shows 
exactly this!

Knowing that 3.0.24 and before seems to ignore the max password age and simply 
using 30 years for all users, and 3.0.25 for the first time really uses this 
value I changed that with pdbedit:

pdbedit -P "maximum password age" -C -1
account policy "maximum password age" description: Maximum password age, in 
seconds (default: -1 => never expire passwords)
account policy "maximum password age" value was: 356
account policy "maximum password age" value is now: 4294967295

Now pdbedit -L -n -v <username> show this:
...
Logon time:           0
Logoff time:          never
Kickoff time:         never
Password last set:    Mon, 28 May 2007 02:10:58 CEST
Password can change:  Mon, 28 May 2007 02:10:58 CEST
Password must change: never
...

I am not sure where (my) default of 356 seconds came from, but when it's the 
default on every debian machine with samba, then you probably should change 
that to "never" / -1 for samba >= 3.0.25.

Comment 25 Jim McDonough 2007-05-29 06:04:41 UTC
We now have the correct behavior.  Before, the value was calculated at password creation/change time, but still based on the policy.  So this means that your "356" value came _after_ any users that have this problem were created or changed their passwords.  

I have read the later updates on the debian bug report as well, and it sounds like it is not the default on debian installations (including mine).  Please just update your policy, and the problem will be gone.