Created attachment 6846 [details]
Logs Level 100 and smb.conf file

Created attachment 6847 [details]
Network Capture for failure

I tested samba-3.5.10 with latest kernel as per bug #8212 and sirish-sir comment
samba file share is still not opening 

kernel version is 
[root@localhost startScript]# uname -a
Linux localhost.localdomain <B>3.0.4</B> #1 SMP Thu Sep 1 17:09:47 JST 2011 i686 i686 i386 GNU/Linux

I have also confirmed that Patch given by  Sirish-sir is applied in linux kernel 3.4.0 


        if (ses->server->sec_mode &
           (SECMODE_SIGN_REQUIRED | SECMODE_SIGN_ENABLED)) {
                flags |= NTLMSSP_NEGOTIATE_SIGN;
                if (!ses->server->session_estab)
                        flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
        }


in build_ntlmssp_auth_blob(..) and build_ntlmssp_negotiate_blob(..)

I request to verify this issue again.

I have also used below parameter in my conf file as marked in #8212


Please let me know if I am doing something wrong.

Regards,
Manoj

Dear Samba Team,

If I am using samba 3.5.15 below setting is working fine for me

   server signing = auto 
   client signing = auto

However if I use 3.5.0, above setting is not working.

Is It a Degrade? 

Regards,
Manoj

Sorry I mean If I am using samba 3.4.15 below setting is working fine for me

While debugging I found in older samba 3.4.x we are adding tmp sign 
memcpy(&outbuf[smb_ss_field], "BSRSPYL ", 8);  and setting flags2 sign bit inside srv_set_signing_negotiated(void) and temp_sign_outgoing_message()

However we are not adding any sign in current samba 3.5.x.   
srv_set_signing_negotiated () and smb_signing_set_negotiated()

Due to above SMB:Flags2 "Security signature" and "Signature" fields are empty. 

This is also clear in network capture. 

Regards, 
Manoj

Created attachment 6875 [details]
Patch for smb server signing

While debugging i found we are not updating 
smb_signing_state.bsrspyl in file share operation due to which below code is always returning without adding sign flags and signature (even tough it is hard coded as per windows behavior)


void smb_signing_sign_pdu(struct smb_signing_state *si,
                          uint8_t *outbuf, uint32_t seqnum)
{
        uint8_t calc_md5_mac[16];
        uint16_t flags2;

        if (si->mac_key.length == 0) {
                if (!si->bsrspyl) {
                        return;
                }
        }



I tried to make patch for this, and tested all the modes auto, mandatory and disable and signing flags in SMB header (Flags2) [0x0004] and Security mode  (i.e Signatures and Sig req) are added properly

I request for patch review and let me know your comments.


Best Regards
Manoj

Does the client requires signing?

The client sends the SMB_FLAGS2_SMB_SECURITY_SIGNATURE_REQUIRED (0x0010)
bit in the flags2 field in the negprot request.

Currently we're ignoring this flag, which might one part of the bug.

Thanks got your comment,
Currently I have tested only server signing. 
Just now I saw in client it is ignored.


(In reply to comment #8)
> Does the client requires signing?
> 
> The client sends the SMB_FLAGS2_SMB_SECURITY_SIGNATURE_REQUIRED (0x0010)
> bit in the flags2 field in the negprot request.
> 
> Currently we're ignoring this flag, which might one part of the bug.

According to the docs SMB_FLAGS2_SMB_SECURITY_SIGNATURE_REQUIRED (0x0010) only matters in the Sessionsetup request, not the negprot. Still, of course we're ignoring it in there as well...
Jeremy.

Ah - the problem is (looking in your capture file) you're being logged on as guest. The current code in 3.5.x (and possibly 3.6.x) won't turn on signing on a guest connection. But if signing was mandatory we should refuse to continue at this point.

Jeremy.

Ok, the real question is what should we do in the case of "server signing = mandatory" and connections that authenticate as guest - which disqualifies server signing with our current 3.5.x and above codebase ?

Should we just disconnect ? If so at what point ? At the end of the second sessionsetupX when we know we're guest (that's easy to do by making register_existing_vuid() return UID_FIELD_INVALID in the guest=true,"server signing = mandatory" case) ?

The current behavior is non-optimal (IMHO).

Metze/Volker, what are your thoughts on this ?

Jeremy.

(In reply to comment #12)
> Ok, the real question is what should we do in the case of "server signing =
> mandatory" and connections that authenticate as guest - which disqualifies
> server signing with our current 3.5.x and above codebase ?
> 
> Should we just disconnect ? If so at what point ? At the end of the second
> sessionsetupX when we know we're guest (that's easy to do by making
> register_existing_vuid() return UID_FIELD_INVALID in the guest=true,"server
> signing = mandatory" case) ?
> 
> The current behavior is non-optimal (IMHO).
> 
> Metze/Volker, what are your thoughts on this ?

If the session is done as guest, then we just should not do signing,
which matches windows 2k8r2.

I'm in progress to take captures of w2k sp4 against w2k8r2
with both as client and server, with all combinations
of disables, enabled and required.

When I'm finished with that I'll propose some patches to
match the windows behavior completely.

Yes, I agree with a guest connection we should not do signing. If "server signing = mandatory" though, should we then terminate - that's the question ?

I was planning to do the Windows tests on this on Monday, but if you get there first I'm happy with that :-).

Jeremy.

Created attachment 6878 [details]
Captures between w2k8r2 and w2ksp4

(In reply to comment #14)
> Yes, I agree with a guest connection we should not do signing. If "server
> signing = mandatory" though, should we then terminate - that's the question ?

I don't think so, if someone wants to avoid that, guest support could be disabled.

> I was planning to do the Windows tests on this on Monday, but if you get there
> first I'm happy with that :-).

I think I understand how all this is supposed to work, but I need to cleanup
my patches...

Created attachment 6879 [details]
Patches for master

Jeremy, can you take a look at this patches?

They also allows us have 'client signing = auto',
causing no signing unless the server requires it.
'client signing = yes' uses signing if the server supports it.

(In reply to comment #17)
> Created attachment 6879 [details]
> Patches for master
> 
> Jeremy, can you take a look at this patches?
> 
> They also allows us have 'client signing = auto',
> causing no signing unless the server requires it.
> 'client signing = yes' uses signing if the server supports it.

Hi Samba Team,

I tried merging the above patch with samba 3.5.10, I am not able to open the file share at all now with server signing as 'auto/mandatory/disabled'. My scenario is the same as mentioned above, I am also logging in as guest.

Let me know if i will have to change anything else also with this.

Regards,
Adarsh

(In reply to comment #18)
> I tried merging the above patch with samba 3.5.10, I am not able to open the
> file share at all now with server signing as 'auto/mandatory/disabled'. My
> scenario is the same as mentioned above, I am also logging in as guest.
> 
> Let me know if i will have to change anything else also with this.

I guess if you want to have guest access you need to disable signing
(at least on the client)

Comment on attachment 6879 [details]
Patches for master

Similar patches are in master

Closing this as invalid, as it's not possible to do signing as guest user.

As a logger I would like to close this issue, as the patch worked for me....Thank you