[Samba] Win10 forcing NTLMSSP when KRB5 desired
J K via samba
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?
Thanks,
JK
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
Jeremy Allison via samba
> 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 ?
J K via samba
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 bga...@solar.local
Trying _Get_Pwnam(), username as lowercase is bga...@solar.local
Get_Pwnam_internals did find user [bga...@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
Jeremy Allison via samba
>
> 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.
In that case I'm afraid you're asking on the wrong list.
There are no sssd experts here :-). Try the sssd mailing
list, they're really good and helpful people there !
J K via samba
and helpful people and have pointed me to the fix :) (see
https://lists.fedorahosted.org/archives/list/sssd-...@lists.fedorahosted.org/thread/UJJYWCIJL5AFGV3RACYCBFPHN3NMJMNY/
).
BTW, thanks for all your great contributions to Samba!
Dewayne Geraghty via samba
https://fedorahosted.org/sssd/ticket/3228
which was insightful and does indeed stop the rabbit hunt.
For others the samba logs don't provide reasons for using ntlm over krb
because the decision is performed at the client (eg Win10), worth reading
the links if you're affected.
PS I use nslcd
On 8 November 2016 at 06:17, J K via samba <sa...@lists.samba.org> wrote:
> Thanks for the direction Jeremy - the people of sssd-users are indeed good
> and helpful people and have pointed me to the fix :) (see
> https://lists.fedorahosted.org/archives/list/sssd-users@
> lists.fedorahosted.org/thread/UJJYWCIJL5AFGV3RACYCBFPHN3NMJMNY/
> ).
>
> BTW, thanks for all your great contributions to Samba!
>
> On Sat, Nov 5, 2016 at 4:54 PM, Jeremy Allison <j...@samba.org> wrote:
>
> > On Sat, Nov 05, 2016 at 11:39:29AM +0000, J K wrote:
> > >
> > > 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.
> >
> > In that case I'm afraid you're asking on the wrong list.
> >
> > There are no sssd experts here :-). Try the sssd mailing
> > list, they're really good and helpful people there !
> >
> --
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/mailman/options/samba
>
--
*Disclaimer:*
*As implied by email protocols, the information in this message is not
confidential. Any intermediary or recipient may inspect, modify (add),
copy, forward, reply to, delete, or filter email for any purpose unless
said parties are otherwise obligated. Nothing in this message may be
legally binding without cryptographic evidence of its integrity and/or
confidentiality.*