Hi all,
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?
Many thanks, JK
On Mon, Nov 07, 2016 at 08:27:43AM -0000, johnnykimble@gmail.com wrote:
Hi all,
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?
Maybe it is similar as in https://fedorahosted.org/sssd/ticket/3228?
HTH
bye, Sumit
Many thanks, JK _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Mon, 2016-11-07 at 08:27 +0000, johnnykimble@gmail.com wrote:
Hi all,
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?
Many thanks, JK
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.
Sumit, Simo, thank you very much for your response, it was indeed name related. I hadn't actually attempted to connect via the FQDN and given that works it very much looks like the issue you are referring to.
Thanks again, you've saved me going down a lot of rabbit holes :)
sssd-users@lists.fedorahosted.org
-
johnnykimble＠gmail.com -
Simo Sorce -
Sumit Bose