Quoting Ralph Passgang ([EMAIL PROTECTED]): > Hello, > > I am sorry, but the bug I reported is not fixed in the latest upstream > version > 3.0.25a. > > I still have the same problem, that passwords are only valid for about 5 to 6 > minutes after setting them. This makes samba more or less useless in my > setup. > > pdbedit still shows something like this for all domain users: > > 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: Mon, 28 May 2007 02:16:54 CEST > > The "must change" date is always the "last set" date + 5-6 minutes, which > makes the account only useable for a very short time. > > If I downgrade to 3.0.24 again, then the password expire is always the "last > set" date + about 30 years. Suprisingly I doesn't even need to set the > password again after downgrading. The "must change" time changes just by > switching the samba version and without that the user sets a new password. I > guess something is wrong in samba's logic to calculate the password > expiration date.
Are you in position to try what Jeremy suggests in upstream bug #4630 ? "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." Also maybe provide what Jim McDonough suggested ; "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) ?" > > --Ralph > > > > > ** CRM114 Whitelisted by: [EMAIL PROTECTED] ** --
signature.asc
Description: Digital signature
