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.
I think this is a 64-bit vs 32-bit time -1 issue. Investigating... Jeremy.
9223372036854775807 == 0x7FFFFFFF I'm guessing this isn't being correctly checked as "max time". More investigation to come.
I meant : 9223372036854775807 == 0x7FFFFFFFFFFFFFFF :-).
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.
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.
Created attachment 2705 [details] Working patch :-) Arg. This patch actually compiles. Sorry.
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
I have applied for the patch but nothing changes. Is there something missing to be modified?
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
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.
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?
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
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) ?
Ah, i've recreated it on my 64-bit system too.
(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.
Created attachment 2714 [details] updates for special cases of TIME_T_MAX
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.
(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.
Created attachment 2719 [details] Complete patch Cumulative patch which includes the force group, object picker, and pw expiration fixes.
*** Bug 4647 has been marked as a duplicate of this bug. ***
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
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?
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.
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.
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.