I'm running 3.0.3 on an s390 with security = ADS, joining the domain shows no error (net ads join (-U administrator)) wbinfo -u shows a list of users from the AD wbinfo -g shows a list of groups from the AD wbinfo -t fails with the following message : checking the trust secret via RPC calls failed error code was NT_STATUS_UNSUCCESSFUL (0xc0000001) Could not check secret id MY_DOMAIN\\myuser says "No such user" although nsswitch is configured for winbind. A look in the winbind log reveals the following info for this particulat command (which may be useful for the generel problem as well) : rpc_client/cli_pipe.c:rpc_auth_pipe(336) rpc_auth_pipe: wrong schannel auth len 24 I did try to clean out private and locks dirs and re-join the AD domain but the result is the same. Problem was the same(or similar) on 3.0.3rc1, problem did NOT exist or did not show on 3.0.3pre2.
Created attachment 483 [details] winbindd level 10 logfile of the problem This is what's in the level 10 log... start winbindd, do wbinfo -t (fails), do id SU_DOMAIN_03\\test (this is a known valid user - fails), kill winbindd
please retest this against 3.0.4 since I have reason to believe that it may be fixed now.
At least 2 confirmed reports of this. The cause of the issue is an schannel failure. rpc_auth_pipe: pkt_type: 2 len: 72 auth_len: 24 NTLMSSP No schannel Yes sign Yes seal No rpc_auth_pipe: packet: 000000 smb_io_rpc_hdr_auth auth_hdr 0000 auth_type : 44 0001 auth_level : 05 0002 padding : 04 0003 reserved : 00 0004 auth_context : 00000001 rpc_auth_pipe: wrong schannel auth len 24 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cli_nt_setup_creds: request challenge failed I'm still unable to reproduce this. Any drtails that you could provide to reproduce it would be appreciated.
Could you also perhaps attach smb.conf? I had similar weird errors a while ago and it was a simple mistake in my smb.conf file.
Created attachment 506 [details] level 10 log for 3.0.4 This log covers startup of winbindd, wbinfo -t (failed), wbinfo -u (failed) and shut down of winbindd. wbinfo -g was working. Note, I have idmap mappings in LDAP (though I don't think it has any bearing). (If it were a mistake in the config file, why does it work fine on 3.0.2a and nothing later? Then it would be a documentation bug ...).
reproduced this using a Win2k DC with no SP. Apparently it is an issue with DC's that don't support 128 bit encryption in the NTLMSSP negotiate flags.
Apparently the nonce/confounder in the RPC_AUTH_NETSEC_CHK is not included unless 128 encrpytion is negotiated. And apparently you can't negotiate AUTH_PIPE_SEAL without 128 bit encryption. (could be wrong here). The counfounder is not used in Samba from what i can tell unless we negotiate AUTH_PIPE_SEAL (which we don't in cli_pipe.c I tested this by changing the the check on the auth_len to allow for 32 or 24 bytes. and other than some spurious errors about trying to parse the nonce, wbinfo -t is working again. This needs some more investigation and a proper check for the negotiated encryption before we can release a patch.
Created attachment 509 [details] deal with schannel verifier that does not include the nonce Please test this fix and let me know. It applies cleanly to 3.0.4.
Created attachment 510 [details] new version of patch; I missed last a few lines in the last one so it wouldn't compile after make clean.
built 3.0.4 with Jerry's latest patch (patch #510)... wbinfo -t success, wbinfo -u success, wbinfo -g success, id DOMAIN\\user success, getent passwd success, getent group success. Patch seems to work in my environment!
Kewl. Thanks for the update. I'm pretty confident in the patch then (works for both of us). Will check the changes into 3.0/trunk and mark this as fixed.
*** Bug 1348 has been marked as a duplicate of this bug. ***
Works for me too, Mandrake packages for 3.0.4 will have this (already in cooker).
additional late info... just tried the patch on an intel system that was actually working on a plain 3.0.4. The patch does not break anything here, that I can tell... The same testes performed here all succeeded :-)
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.
database cleanup