The Samba-Bugzilla – Bug 1315
wbinfo -t unsuccessful on 3.0.3
Last modified: 2005-11-14 09:25:57 UTC
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
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
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.