samba - Jun 2019 - ADS security mode - authenticating non-domain Linux users

Hi All,

We've been beating our heads against a problem here with a new Samba 
server that we're trying to bring into production, and I'm hoping that 
the members of this list can provide some insight.

Our server is on a Linux CentOS 7.6, Samba version 4.8.3 installed from 
distribution packages. Our clients are a mixture of Windows, Mac, and 
Linux systems. Most of these clients are joined to the enterprise 
domain, as is the server (smb.conf has "server role = member server"
and
"security = auto"; we've also set "security = ADS"
explicitly).

Users on domain joined systems, regardless of OS, can successfully map 
the exports from the server, assumedly using their Kerberos tickets from 
the domain controller.  However, non-domain joined clients (various 
Linux systems) cannot use username/password authenticate to map the 
network drives - they always get permission denied.

If I go and get Kerberos tickets for the problem clients (using kinit 
and friends against the domain controller), mount.cifs with sec=krb5i 
works. But we cannot get sec=ntlmsspi to work. This was working on an 
older server (CentOS 6.10, Samba 3.6.23), and I think the key is that 
the "map untrusted to domain" option was deprecated and eventually 
removed in Samba 4.8. Otherwise, the configurations between the older 
and newer server are identical.

For non-domain joined clients without Kerberos tickets , I'm guessing 
that "map untrusted to domain" was allowing the Samba server to accept
username/password credentials, authenticate them with the domain 
controller, and allow access accordingly. However, I can't seem to find 
an equivalent way of doing this under Samba 4.8. I found one other user 
who seems to be having an identical issue (see 
https://unix.stackexchange.com/questions/513169/linux-clients-cant-login-on-samba-share-while-windows-and-mac-can-active-direc
for details), but there does not appear to be a solution.

My questions are:

1. Is my diagnosis of the situation correct, based on the information 
that I've given?

2. Is there any way to mimic the behavior of the "map untrusted to 
domain" option or otherwise allow username/password authentication 
against the domain joined Samba server to work against non-domain joined 
systems?

On 04/06/2019 20:17, Tim Miller via samba wrote:
> Hi All,
>
> We've been beating our heads against a problem here with a new Samba 
> server that we're trying to bring into production, and I'm hoping
that
> the members of this list can provide some insight.
>
> Our server is on a Linux CentOS 7.6, Samba version 4.8.3 installed 
> from distribution packages. Our clients are a mixture of Windows, Mac, 
> and Linux systems. Most of these clients are joined to the enterprise 
> domain, as is the server (smb.conf has "server role = member
server"
> and "security = auto"; we've also set "security =
ADS" explicitly).
>
> Users on domain joined systems, regardless of OS, can successfully map 
> the exports from the server, assumedly using their Kerberos tickets 
> from the domain controller.  However, non-domain joined clients 
> (various Linux systems) cannot use username/password authenticate to 
> map the network drives - they always get permission denied.
They would do, they are unknown to the domain
>
> If I go and get Kerberos tickets for the problem clients (using kinit 
> and friends against the domain controller), mount.cifs with sec=krb5i 
> works. But we cannot get sec=ntlmsspi to work. This was working on an 
> older server (CentOS 6.10, Samba 3.6.23), and I think the key is that 
> the "map untrusted to domain" option was deprecated and
eventually
> removed in Samba 4.8. Otherwise, the configurations between the older 
> and newer server are identical.
>
This is very probably for the same reason, the user is unknown to the 
domain.
> For non-domain joined clients without Kerberos tickets , I'm guessing 
> that "map untrusted to domain" was allowing the Samba server to
accept
> username/password credentials, authenticate them with the domain 
> controller, and allow access accordingly. However, I can't seem to 
> find an equivalent way of doing this under Samba 4.8. I found one 
> other user who seems to be having an identical issue (see 
>
https://unix.stackexchange.com/questions/513169/linux-clients-cant-login-on-samba-share-while-windows-and-mac-can-active-direc
> for details), but there does not appear to be a solution.
'map untrusted to domain' made 'UNKNOWNDOMAIN\fred' become 
'LOCALDOMAIN\fred' and if 'fred' is a member of
'LOCALDOMAIN' and has
the correct password, then access will be allowed. The parameter 'map 
untrusted to domain was removed at Samba 4.8.0, it was deprecated at
4.7.0
>
> My questions are:
>
> 1. Is my diagnosis of the situation correct, based on the information 
> that I've given?
>
Yes
> 2. Is there any way to mimic the behavior of the "map untrusted to 
> domain" option or otherwise allow username/password authentication 
> against the domain joined Samba server to work against non-domain 
> joined systems?
>
Yes, it is called 'join the machine to the domain' or if the machine is 
joined to another domain, use trusts.

Rowland

Hi Rowland,

Thanks very much for the reply and confirming what I suspected. One 
quick questions in-line, if I may:

On 6/4/19 4:00 PM, Rowland penny via samba wrote:
> 'map untrusted to domain' made 'UNKNOWNDOMAIN\fred' become 
> 'LOCALDOMAIN\fred' and if 'fred' is a member of
'LOCALDOMAIN' and has
> the correct password, then access will be allowed. The parameter 'map 
> untrusted to domain was removed at Samba 4.8.0, it was deprecated at 
> 4.7.0
I found the patch that deprecated the option, with the comment (quoting 
from Volker Lendecke in 
https://lists.samba.org/archive/samba-technical/2017-March/119417.html):

 > In an active directory environment, we don't know of
 >a good way to enumerate all domains that we have to accept as trusted,
 >in particular with multiple forests, one-way and external trusts. We
 >hope to replace this parameter in the future with something that matches
 >Windows behaviour better, after the deprecation phase of this parameter
 >is over and we can remove it.

Any notion of whether such a replacement is on the horizon at present? 
If not, we'll live with the behavior as-is.

Regards,
Tim