All versions of samba 3.3 below 3.3.9 fall out of the domain with a samba 3.4.3 PDC. Also 3.2 versions are affected but I did not figure out from which version on this is fixed in 3.2. In 3.3.9 there is no hint in the release notes which change might have fixed this. The problem starts to show up as soon as the client tries to change its machine account password for the first time. By setting "machine account timeout = 60" it's easy to trigger fast. The passwords do mismatch after the password change. net rpc testjoin will fail immediately. This was not a problem with Samba 3.0.28 running as PDC. If possible the current Samba release should work also with samba release below 3.3.9 and not lead to password mismatches. In any case we should mention this version interoperability pitfall in the release notes in capital letters :-).
(In reply to comment #0) > The problem starts to show up as soon as the client tries to change its machine > account password for the first time. By setting "machine account timeout = 60" > it's easy to trigger fast. The passwords do mismatch after the password change. The parameter is called "machine password timeout", not "machine account timeout".
*** This bug has been marked as a duplicate of bug 6664 ***
Karolin, I can't see why this is a dup of 6664. Maybe the fix from that bug introduced the problem that samba 3.3 releases <3.3.9 now silenty fall out of the domain. As long as this happens this is definetely still a blocker bug.
This will take a while to fix. We will have to add code to the all servers that we have out there to store two versions of the machine password. One encrypted with the correct and one encrypted with the wrong hash. If a machine wants to authenticate, we have to try against both. Very ugly but if this is a blocker then inevitable. We would also have to work with Microsoft to do the same. Volker
This is why I think this is a blocker: Imagine an administrator updates the DCs to a samba release that contains the patch from #6664. First everything seems to be fine. Then, in the course of the next 7 days Samba 3.2 and 3.3 member servers stop working. There is no obvious reason why that hapens. There has not even been a mentioning of a machine password code change which might cause or fix the problem in the release notes. Our user are just left in the dark. Maybe an advisory sent via the samba annunce list telling which samba member servers will stop working with which Samba PDC versions would be adequate to "fix" this bug, too. But we cannot just let samba administrators out there in the world walk straight up into that trap while we know about that problem.
Right now this bug is blocking a 3.4 release, and it will FOREVER. So shall we stop shipping Samba now? Volker
This is a notification problem. We can't go back to the incorrect code. Maybe add a debug level 0 log message when a machine password missmatch is detected pointing the admin at a wiki site with the fix (disable machine password changing for Samba versions < 3.3.9). Jeremy.
Please correct me if I am wrong, but as far as I understand, this is a client side problem which is fixed in all current Samba versions. Samba members fail to change the machine password if the client does not contain the fix attached to bug #6664 (or do not change the machine password at all in very old versions). So I think this is not a bug in 3.4.3 at all, but a bug in older Samba version (which has been fixed meanwhile). That's why I don't think this is a showstopper for 3.4.4. So I will lower severity now.
Basically I agree, Karolin. But we should publish an explicit errata pointing out VERY CLEAR: - which versions of Samba (as member server) stop working if Samba versions with the fix from #6444 are running on Domain Controlers - which versions are not affected even if the fir from #6444 is in the DC's Samba version - and which workaround can be done if people can't update older Samba versions (e.g. increase machine password timeout to mulitple years and rejoin the members). That's what was my proposal in comment #5. It simply damages Samba's image if we introduce major incompatibilities with older versions of our own product and don't clearly point that out. Such an errata should be published as soon as possible - preferably before the next release.
To my understanding, this is a bug in the client side of samba (machine password change). It is fixed since many weeks in the releases. We have other bugs in older samba releases; this is the reason that we ship bugfix releases, right? :-) And we don't start creating workarounds in new samba releases for bugs in older samba versions. After all, samba is not windows - or is it? So I'd say that we simply close this bug. Again, it is not a 3.4 dc bug but a client bug that was uncovered by a change in the dc code. And the client side is already fixed. Vendors can easily backport the fix to their shipped version. Maybe we could send a mail to samba-announce with a hint, but generally, I think samba has all it can and should do in this respect. Cheers - Michael
Günther (or anyone else), could you please provide exact information which versions/combinations are affected and which are not? Thanks!
I don't get enough information for writing a summary. Closing out bug report. Björn (or anyone else), if you would like to provide a text, please feel free to reopen.
a bug report about a serious lack of information which needs to be closed cannot be silently closed. When no one can tell which versions are now incaompatible then we need to make an announcement that anybody *must* update to the current version of his preferred release tree.
it seems everyone thinks we need nothing to do here. I also give up my struggles and close it as WONTFIX.
*** Bug 7585 has been marked as a duplicate of this bug. ***