Our Samba domain trusts a Windows Server 2003 R2 domain, after upgrading from 3.0.X to 3.4.5, users are incorrectly receiving the error message "Your Password expires today. Do you want to change it now ?" winbind is correctly retrieving the expiry date (which is not today), i.e.: query_user: [Cached] - doing backend query for info for domain MASSEY ads: query_user netsamlogon_cache_get: SID [S-1-5-21-95318837-410984162-318601546-6466] &r: struct netsamlogoncache_entry timestamp : Wed 27 Jan 2010 01:16:16 PM NZDT NZDT info3: struct netr_SamInfo3 base: struct netr_SamBaseInfo last_logon : Wed 27 Jan 2010 01:11:55 PM NZDT NZDT last_logoff : Tue 19 Jan 2038 04:14:07 PM NZDT NZDT acct_expiry : Tue 19 Jan 2038 04:14:07 PM NZDT NZDT last_password_change : Thu 05 Feb 2009 04:58:13 PM NZDT NZDT allow_password_change : Thu 05 Feb 2009 04:58:13 PM NZDT NZDT force_password_change : Tue 19 Jan 2038 04:14:07 PM NZDT NZDT This issue has been reported by another user - see http://www.mail-archive.com/samba@lists.samba.org/msg105013.html Regards, Patrick Rynhart
Interestingly, I have observed this same issue previously (when moving between releases of 3.0.X). The earlier bug report is at: https://bugzilla.samba.org/show_bug.cgi?id=4613 with a fix supplied by Volker :-) I'm not sure if this current issue is related to this earlier bug. The Samba DC should pass-through data from the trusted Windows domain, so I can't see how any configuration issue could result in this symptom.
Quick question - is the PDC running on a 64-bit machine ? If so there might be a fix I have just committed to master for this. Jeremy.
Hi Jeremy, Many thanks for having a look into this. No - the Server is running 32-bit CentOS 5.3: # uname -a Linux seat-dc1 2.6.18-128.1.6.el5 #1 SMP Wed Apr 1 09:19:18 EDT 2009 i686 i686 i386 GNU/Linux Cheers, Patrick
Ok, it's not the problem I thought then. I'll try and find time to take a look later this week.
Please let me know if we can be of assistance in tracking down this issue. I tried downgrading to an earlier version (3.4.2) but the same symptom is apparent. Thanks, Patrick
(In reply to comment #4) > Ok, it's not the problem I thought then. I'll try and find time to take a look > later this week. > Hi Jeremy, we have this problem too. I have tested it on a debian etch with samba 3.4.3 and samba 3.4.5 (sernet packets). We are using a ldap backend (openldap). The trust is a Two-Way trust between a samba and an old NT4 domain. There is also another problem, but I don't know if this is related to the "passwort expired" problem. If a user do a logon from a WINXP or WIN7 workstation (which has the machine account in the samba domain) to the NT4 domain, then the logonscript isn't executed. In all other variants the correct logon script is executed. I tell this because the "password expired" problem appears in the same way like the logon script problem (only on workstations with samba machine accounts and logons to the trusted NT4 domain). If you need more/other informations and data please let me know. Thanks and regards Michael
Hello, we are using Samba 3.2.14 with three trusted domains and two member Server(3.5.0rc2 and 3.2.5). I have written about this bug since Version 3.4.1, so i'am still waiting for a bug fix. ;-) After an Upgrade from 3.2.14 to 3.4.6 the first thing what a user will see is an "End of File" Message at Login - Just the First Login. So the login will abort, after the next login it will work, but now the user gets on every login a "Your Password expires today" at login, this is only over trusted domains. server1:/# pdbedit -r -u user1 Unix username: user1 NT username: user1 Account Flags: [U ] User SID: S-1-5-21-1801630100-1912888146-724944298-4422 Primary Group SID: S-1-5-21-1801630100-1912888146-724944298-513 Full Name: Hans Wurst Home Directory: \\server1\user1 HomeDir Drive: H: Logon Script: default.bat Profile Path: \\server1\profiles Domain: DOMAIN1 Account desc: Workstations: Munged dial: Logon time: 0 Logoff time: Die, 19 Jän 2038 04:14:07 CET Kickoff time: Die, 19 Jän 2038 04:14:07 CET Password last set: Mon, 15 Feb 2010 09:08:24 CET Password can change: Mon, 15 Feb 2010 09:08:24 CET Password must change: never Last bad password : 0 Bad password count : 0 Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF There stands "Password must change: never" Never? ;-) Now the next thing: After some weeks, or some days the Member Servers don't work. Restarting the Member Server(s) brings nothing, but Restarting the PDC brings the Member Servers back to work. Well with Linux VServer and a samba compile prefix a up- and downgrade don't need much time or makes problems, but i'am hopping someone will fix it. Kind Regards, Richi
I have the same issue after upgrading from 3.2.14 to 3.4.9. I have two mutually trusting domains and I get the erroneous message. Could it be something to do with the PWDMust/Can change on the trust account? Thanks Alex
(In reply to comment #8) > I have the same issue after upgrading from 3.2.14 to 3.4.9. I have two mutually > trusting domains and I get the erroneous message. > > Could it be something to do with the PWDMust/Can change on the trust account? > > Thanks > > Alex > Tried changing the relevant fields to far in the future in the LDAP "machine" account for the domain with no luck. Regs Alex
Any news? We have the same problem.
Created attachment 6152 [details] Patch for 3.4 This fixes it for me
Comment on attachment 6152 [details] Patch for 3.4 This patch also applies to 3.5 and fixes the issue for me there.
Created attachment 6153 [details] Patch for master and 3.6
Comment on attachment 6153 [details] Patch for master and 3.6 Wow. How *ever* did you find that... Great work ! Jeremy.
Comment on attachment 6152 [details] Patch for 3.4 LGTM !
Re-assigning to Karolin. Karolin, please pull attachement 6152 (Patch for 3.4) for 3.5.7. Thanks, Jeremy.
(In reply to comment #16) > Re-assigning to Karolin. > > Karolin, please pull attachement 6152 (Patch for 3.4) for 3.5.7. > > Thanks, > > Jeremy. > Pushed to v3-5-test and v3-4-test. Will be included in the next releases. Closing out bug report. Thanks!