SMB signing problem w/3.0.10

[Joe Meadows]

Hello,

I'm not sure if the technical list is the best place for this, but since 
there's a brief code snippet I figured 'why not.' :)

Anyhow, I've run into a problem using the 3.0.10 code that I did not 
have using 3.0.0 when joining an ADS domain.  The problem first showed 
up as an inability to list trusted domains (wbinfo -m).  I noticed that 
the log had an entry saying that STATUS_ACCESS_DENIED was returned when 
attempting to tree connect to the IPC$ service of the DC.  I compared 
network traces from the 3.0.0 and 3.0.10 transactions and noticed that 
the session setup was different.  In 3.0.0 I get:

        Flags2: 0xc801
            1... .... .... .... = Unicode Strings: Strings are Unicode
            .1.. .... .... .... = Error Code Type: Error codes are NT error codes
            ..0. .... .... .... = Execute-only Reads: Don't permit reads if execute-only
            ...0 .... .... .... = Dfs: Don't resolve pathnames with Dfs
            .... 1... .... .... = Extended Security Negotiation: Extended security negotiation is supported
            .... .... .0.. .... = Long Names Used: Path names in request are not long file names
*            .... .... .... .0.. = Security Signatures: Security signatures are not supported
*            .... .... .... ..0. = Extended Attributes: Extended attributes are not supported
            .... .... .... ...1 = Long Names Allowed: Long file names are allowed in the response

And in 3.0.10 I get:

        Flags2: 0xc805
            1... .... .... .... = Unicode Strings: Strings are Unicode
            .1.. .... .... .... = Error Code Type: Error codes are NT error codes
            ..0. .... .... .... = Execute-only Reads: Don't permit reads if execute-only
            ...0 .... .... .... = Dfs: Don't resolve pathnames with Dfs
            .... 1... .... .... = Extended Security Negotiation: Extended security negotiation is supported
            .... .... .0.. .... = Long Names Used: Path names in request are not long file names
*            .... .... .... .1.. = Security Signatures: Security signatures are supported
*            .... .... .... ..0. = Extended Attributes: Extended attributes are not supported
            .... .... .... ...1 = Long Names Allowed: Long file names are allowed in the response


The difference is the 'Security Signatures' bit.  I traced this down to 
the following difference in the source code at libsmb/cliconnect.c line 
1133 in the 3.0.10 version of this file:

1133                 } else if (cli->sec_mode & NEGOTIATE_SECURITY_SIGNATURES_ENABLED) {
1134                         */cli->sign_info.negotiated_smb_signing = True;/*
1135                 }

If I comment out line 1134 everything again seems to work as before.  I 
have tried setting 'client signing' and 'server signing' both to 
disabled in smb.conf but that did not help as this bit still gets set.  
The only place that I found where NEGOTIATE_SECURITY_SIGNATURES_ENABLED 
is explicitely set is in smbd/negprot.c:reply_nt1() and I made sure that 
smbd wasn't setting the flag there and still it gets set in the session 
setup request.  Perhaps the DC is setting the flag and it is getting 
picked up from a reply and carried through?

I found that the extra code above first appears in SVN version 15 of 
this file.  I was wondering if anyone knows why the extra test was 
added, how NEGOTIATE_SECURITY_SIGNATURES_ENABLED and what's the right 
way for me to solve this problem (as opposed to chopping out this line 
;)).  BTW, the DC in this case is Win2000 mixed mode DC if that 
matters.  I'll be glad to provide any more info, logs, etc upon request.

Thanks in advance,
Joe Meadows