Bug 1315 - wbinfo -t unsuccessful on 3.0.3
wbinfo -t unsuccessful on 3.0.3
Status: CLOSED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: winbind
3.0.3
All Linux
: P2 major
: none
Assigned To: Gerald (Jerry) Carter
:
: 1348 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-03 05:10 UTC by Thomas M Steenholdt
Modified: 2005-11-14 09:25 UTC (History)
4 users (show)

See Also:


Attachments
winbindd level 10 logfile of the problem (42.43 KB, application/x-gzip)
2004-05-03 05:18 UTC, Thomas M Steenholdt
no flags Details
level 10 log for 3.0.4 (416.74 KB, text/plain)
2004-05-11 13:45 UTC, Buchan Milne
no flags Details
deal with schannel verifier that does not include the nonce (5.15 KB, patch)
2004-05-12 13:24 UTC, Gerald (Jerry) Carter
no flags Details
new version of patch; I missed last a few lines in the last one so it wouldn't compile after make clean. (5.82 KB, patch)
2004-05-12 13:31 UTC, Gerald (Jerry) Carter
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas M Steenholdt 2004-05-03 05:10:56 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.
Comment 1 Thomas M Steenholdt 2004-05-03 05:18:55 UTC
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
Comment 2 Gerald (Jerry) Carter 2004-05-11 07:02:29 UTC
please retest this against 3.0.4 since I have reason to believe 
that it may be fixed now.
Comment 3 Gerald (Jerry) Carter 2004-05-11 07:41:49 UTC
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.
Comment 4 Andreas Hasenack 2004-05-11 12:59:07 UTC
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.
Comment 5 Buchan Milne 2004-05-11 13:45:14 UTC
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 ...).
Comment 6 Gerald (Jerry) Carter 2004-05-12 09:24:49 UTC
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.
Comment 7 Gerald (Jerry) Carter 2004-05-12 10:26:23 UTC
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.
Comment 8 Gerald (Jerry) Carter 2004-05-12 13:24:22 UTC
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.
Comment 9 Gerald (Jerry) Carter 2004-05-12 13:31:47 UTC
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.
Comment 10 Thomas M Steenholdt 2004-05-13 02:09:48 UTC
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!
Comment 11 Gerald (Jerry) Carter 2004-05-13 13:31:23 UTC
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.
Comment 12 Gerald (Jerry) Carter 2004-05-13 13:37:32 UTC
*** Bug 1348 has been marked as a duplicate of this bug. ***
Comment 13 Buchan Milne 2004-05-14 01:26:57 UTC
Works for me too, Mandrake packages for 3.0.4 will have this (already in cooker).
Comment 14 Thomas M Steenholdt 2004-05-14 01:52:51 UTC
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 :-)
Comment 15 Gerald (Jerry) Carter 2005-08-24 10:16:36 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.
Comment 16 Gerald (Jerry) Carter 2005-11-14 09:25:57 UTC
database cleanup