On Mon, 2016-11-07 at 08:27 +0000, johnnykimble(a)gmail.com wrote:
I've posted a thread about this on the Samba mailing list and been redirected to the
SSSD experts here (see https://lists.samba.org/archive/samba/2016-November/204371.html
I'm using a Samba file server as a domain member in a Windows 2012 AD domain.
Everything works correctly as a pre-Windows 10 user (8.1 and 7), with authentication of
domain users being handled by SSSD, as well as resolution of the SIDs on the Samba share.
However, when Windows 10 connects to the Samba share, it presents (or selects) only 1
GSS-API mechanism, NTLMSSP.
My preference for SSSD over Winbind was because I don't need to support NTLM and
prefer the most secure KRB5.
Is it possible to configure SSSD (if indeed it's SSSDs responsibility...) so that
NTLMSSP is not presented as a GSS-API mechanism? Any ideas why Windows 10 would be
behaving in what looks to be a less secure fashion to previous Windows versions?
In the vast majority of cases when Krb5 auth is not even attempted it
means there is a naming issue, and the client can't obtain a ticket for
the server it is trying to connect to.
Verify that the correct name for the server is being used.
Simo Sorce * Red Hat, Inc * New York