[Samba] Win10 forcing NTLMSSP when KRB5 desired

Sat Nov 5 11:39:29 UTC 2016

On Fri, Nov 4, 2016 at 6:24 PM, Jeremy Allison <jra at samba.org> wrote:

> On Thu, Nov 03, 2016 at 04:58:56PM +0000, J K via samba wrote:
> > Hi all,
> >
> > I've 4.5.1 Samba on a machine with SSSD 1.13.4 setup and joined with a
> > Windows Server 2012 domain. Everything works great for Windows 8.1 - I
> can
> > connect to the Samba share and get authenticated as a domain user and
> files
> > are created with the correct Windows domain username and group.
> >
> > With a Windows 10 client, I get an 'Access Denied'. After some debugging,
> > I'm putting this down to the fact that, with the Windows 8 client, the
> > GSS-API SPNGEO KRB5 mechanism is selected, which is what I (and SSSD
> > wants). However, looking at the Windows 10 sequence of events, I see that
> > it attempts to use the NTLMSSP mechtype.
> >
> > I choose winbind over SSSD, and if anything would have expected the
> > behaviour above to be the other way around with Windows 8 maybe using
> NTLM.
> >
> > Is anyone aware of this issue with Windows 10, or is it possible to
> disable
> > the advertising of the NTLMSSP mechanism, or force Windows to use KRB5?
>
> Can you explain the problem more please. What does "I choose winbind over
> SSSD"
> mean ? Above you say "4.5.1 Samba on a machine with SSSD 1.13.4 setup".
> Which
> are you using ? Does it work with one and not the other ?
>

Thanks for getting back to me Jeremy. I meant to say 'I choose SSSD over
Winbind'. I'm using SSSD for authentication and am NOT using winbind at all.

Connections to the share from Win10 give access denied, while Win 8.1 works
with the same username.

After some investigation, I noticed that Samba was presenting 3 GSS
mechanisms in the session setup. On Win 8.1, KRB5 is agreed upon, whereas
in Win10 it selects NTLMSSP (as that is all Win10 presents in the mechtype
list).

AFAIK, NTLM isn't supported by SSSD, and it's not something I particularly
want to support in my environment. I am surprised by the Windows 10
behaviour here, as I would have expected it would be choosing KRB5 in the
same way Windows 8.1 does (and Windows 7).

I've included what I think are the relevant log messages from smbd and key
parts of the capture. With 8.1, you can see that the 'gsr_krb5'
sub-mechanism finds the user as expected and from capture, you can see that
Windows 8.1 has agreed on using the KRB5 mechanism presented.

Any ideas why Windows 10 would be behaving this way? I'm guessing this is a
Windows 10 issue rather than a Samba issue. I'm tempted to rebuild Samba so
that the NTLMSSP mechtype isn't presented (I presume from the code there's
no configuration option to disable the advertising of NTLMSSP?) but I fear
that Windows 10 will simply reset the connection when it finds that NTLMSSP
isn't supported.

Win 8.1 capture and logs:

Starting GENSEC submechanism gse_krb5
...
Finding user bgates at solar.local
Trying _Get_Pwnam(), username as lowercase is bgates at solar.local
Get_Pwnam_internals did find user [bgates at solar.local]!

SMB2 (Server Message Block Protocol version 2)
    Negotiate Protocol Response (0x00)
        Security Blob: 605e06062b0601050502a0543052a024302206092a864882...
            Offset: 0x00000080
            Length: 96
            GSS-API Generic Security Service Application Program Interface
                OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
                Simple Protected Negotiation
                    negTokenInit
                        mechTypes: 3 items
                            MechType: 1.2.840.48018.1.2.2 (MS KRB5 -
Microsoft Kerberos 5)
                            MechType: 1.2.840.113554.1.2.2 (KRB5 - Kerberos
5)
                            MechType: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP -
Microsoft NTLM Security Support Provider)
                        negHints
        NegotiateContextOffset: 0x0000
...
SMB2 (Server Message Block Protocol version 2)
    Session Setup Request (0x01)
        Security Blob: 6082064f06062b0601050502a08206433082063fa030302e...
            Offset: 0x00000058
            Length: 1619
            GSS-API Generic Security Service Application Program Interface
                OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
                Simple Protected Negotiation
                    negTokenInit
                        mechTypes: 4 items
                            MechType: 1.2.840.48018.1.2.2 (MS KRB5 -
Microsoft Kerberos 5)
                            MechType: 1.2.840.113554.1.2.2 (KRB5 - Kerberos
5)
                            MechType: 1.3.6.1.4.1.311.2.2.30 (NEGOEX -
SPNEGO Extended Negotiation Security Mechanism)
                            MechType: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP -
Microsoft NTLM Security Support Provider)
                        mechToken:
6082060106092a864886f71201020201006e8205f0308205...
                        krb5_blob:
6082060106092a864886f71201020201006e8205f0308205...
                            KRB5 OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos
5)
                            krb5_tok_id: KRB5_AP_REQ (0x0001)
                            Kerberos
...
SMB2 (Server Message Block Protocol version 2)
    Session Setup Response (0x01)
        StructureSize: 0x0009
        Session Flags: 0x0000
        Security Blob: a1819f30819ca0030a0100a10b06092a864882f712010202...
            Offset: 0x00000048
            Length: 162
            GSS-API Generic Security Service Application Program Interface
                Simple Protected Negotiation
                    negTokenTarg
                        negResult: accept-completed (0)
                        supportedMech: 1.2.840.48018.1.2.2 (MS KRB5 -
Microsoft Kerberos 5)
                        responseToken:
60818106092a864886f71201020202006f723070a0030201...
                        krb5_blob:
60818106092a864886f71201020202006f723070a0030201...
                            KRB5 OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos
5)
                            krb5_tok_id: KRB5_AP_REP (0x0002)
                            Kerberos

For the Windows 10 capture, the Samba server presents the same list of
mechs in the negotiate response but Windows 10 lists only 1 mechtype in the
session setup request, NTLMSSP. I suspect this will not work with SSSD.

Starting GENSEC submechanism ntlmssp
Got NTLMSSP neg_flags=0xe2088297
Got user=[bgates] domain=[SOLAR] workstation=[DEIMOS] len1=24 len2=264
...
check_sam_security: Couldn't find user 'bgates' in passdb.
check_ntlm_password: sam authentication for user [bgates] FAILED with error
NT_S TATUS_NO_SUCH_USER
check_ntlm_password:  Authentication for user [bgates] -> [bgates] FAILED
with e rror NT_STATUS_NO_SUCH_USER
Checking NTLMSSP password for SOLAR\bgates failed: NT_STATUS_NO_SUCH_USER
No such user bgates [SOLAR] - using guest account

SMB2 (Server Message Block Protocol version 2)
    SMB2 Header
    Session Setup Request (0x01)
        StructureSize: 0x0019
        Flags: 0
        Security mode: 0x01, Signing enabled
        Capabilities: 0x00000001, DFS
        Channel: None (0x00000000)
        Previous Session Id: 0x0000000000000000
        Security Blob: 604806062b0601050502a03e303ca00e300c060a2b060104...
            Offset: 0x00000058
            Length: 74
            GSS-API Generic Security Service Application Program Interface
                OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
                Simple Protected Negotiation
                    negTokenInit
                        mechTypes: 1 item
                            MechType: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP -
Microsoft NTLM Security Support Provider)
                        mechToken:
4e544c4d5353500001000000978208e20000000000000000...
                        NTLM Secure Service Provider