I don't enter bug tickets regularly, but after a week, I cannot locate fix/answer. I'm running samba 3.3.2. WE're mostly using it to authenticate NT users through the squid proxy. Squid 3.0.STABLE13. On a daily basis, everything runs fine. But like clockwork on a weekly basis, (7 days exactly). On the 7th day, my log.wb.$DOMAIN file grows out of hand and kills the server. It fills up with these messages. [2009/07/09 07:11:24, 0] rpc_client/cli_netlogon.c:rpccli_netlogon_set_trust_password(597) rpccli_netr_ServerPasswordSet2 failed: NT_STATUS_WRONG_PASSWORD If I shutdown winbind, issue a net ads join -U Administrator%password restart winbind Everything returns to normal for 7 days. Then again on the 7th day past the issuing of the net ads command, it happens again. I've took a look at the code that generated the message. Not sure what the issue is. Hopefully someone that is more familiar with the code can point me in the correct position to correct this issue. if (!NT_STATUS_IS_OK(result)) { + DEBUG(0,("rpccli_netr_ServerPasswordSet2 failed: %s\n", + nt_errstr(result))); + return result; Again, I have no idea why after a week it falls over. Thanks
Ok, every week winbindd is trying to change it's own machine account password (good security practice). It's failing and I'd need a debug level 10 log of this to know why. In the meantime you can stop winbindd changing its password by setting the parameter : machine password timeout = 0 in the [global] section of your smb.conf and restarting winbindd. Jeremy.
*** Bug 6580 has been marked as a duplicate of this bug. ***
*** Bug 6581 has been marked as a duplicate of this bug. ***
Not with 3.3.x yet but tested with master and used a timeout of 10 seconds and all worked fine (changed password was fine after every 10 second change).
(In reply to comment #4) > Not with 3.3.x yet but tested with master and used a timeout of 10 seconds and > all worked fine (changed password was fine after every 10 second change). now tested with the 10 second interval and 3.3.5 and it worked fine.
What are your domain controllers running? Volker
The reporter probably runs either a Win2k, 2k3 or 2k8 DC. In that case - we just found out - Samba is using an encryption routine for the new password that does not deal with the 128bit based session key it has negotiated with the DC.
Could you please try the patch from here: https://bugzilla.samba.org/attachment.cgi?id=4602 ?
I am pretty sure this bug is resolved with the patch mentioned in comment #8, that fix went into 3-3-test and 3-4-test and will be part of the next releases. Please reopen if still an issue.