samba - Jun 2019 - SMB share access for machines which are not joined to the domain?

On 6/25/19 11:21 AM, Gregory Sloop via samba wrote:
> You can always connect to the SMB share using a domain user/password
credential set, even if you're not a member of the domain.
> Something like - Connect as: User: "somedomain\pat" with
Pat's password.
> 

When we try this from a machine that is not connected to the domain, 
authentication fails:


C:\Users\cns-dbr2717>net use * \\cns-bio-krak1.austin.utexas.edu\emtifs 
/user:austin.utexas.edu\dbr2717
System error 1311 has occurred.

We can't sign you in with this credential because your domain isn't 
available. Make sure your device is connected to your organization's 
network and try again. If you previously signed in on this device with 
another credential, you can sign in with that credential.

We experimented, switching between

     security = ADS
and
     security = user

This doesn't seem to matter for domain users connecting from a domain 
host, but neither work for a domain user connecting from a non-domain 
host.  Connecting to a Windows SMB server, this does work.

Some information found online seems to suggest that this (domain user, 
non-domain host) *would* work if we were running winbind, but Rowland 
seems to suggest this isn't the case, either.  In theory it should be 
possible to run sssd and winbind on the SMB server, but we put some 
minimal effort into this and couldn't get it to work.  Likely will work 
in a couple of software iterations.

On 25/06/2019 18:37, Goetz, Patrick G via samba wrote:
>
> On 6/25/19 11:21 AM, Gregory Sloop via samba wrote:
>> You can always connect to the SMB share using a domain user/password
credential set, even if you're not a member of the domain.
>> Something like - Connect as: User: "somedomain\pat" with
Pat's password.
>>
>
> When we try this from a machine that is not connected to the domain,
> authentication fails:
>
>
> C:\Users\cns-dbr2717>net use * \\cns-bio-krak1.austin.utexas.edu\emtifs
> /user:austin.utexas.edu\dbr2717
> System error 1311 has occurred.
>
> We can't sign you in with this credential because your domain isn't
> available. Make sure your device is connected to your organization's
> network and try again. If you previously signed in on this device with
> another credential, you can sign in with that credential.
>
> We experimented, switching between
>
>       security = ADS
> and
>       security = user
>
> This doesn't seem to matter for domain users connecting from a domain
> host, but neither work for a domain user connecting from a non-domain
> host.  Connecting to a Windows SMB server, this does work.
>
> Some information found online seems to suggest that this (domain user,
> non-domain host) *would* work if we were running winbind, but Rowland
> seems to suggest this isn't the case, either.  In theory it should be
> possible to run sssd and winbind on the SMB server, but we put some
> minimal effort into this and couldn't get it to work.  Likely will work
> in a couple of software iterations.
First, what part of 'Red-hat doesn't support the use of sssd with
Samba'
do you not understand ? ;-)

You cannot run sssd and winbind on the same machine.

You must use 'security = ADS' on an AD joined machine

If you are running Samba >= 4.8.0 on an Unix domain member, you must run 
winbind.

The problem with using user from an unjoined machine is probably the 
username. Every computer running Windows or Samba is a member of a 
workgroup unless it is joined to a domain. This means that it will be 
sending WORKGROUP\username and a domain member will be expecting 
DOMAIN\username, so try connecting as DOMAIN\username.

Rowland

Hmmm...

Use the netbios name, instead of a FQDN, perhaps?
i.e.: \\cns-bio-krak1\emtifs 
[I'm assuming the NB name. If I'm wrong, correct it.]

I know I've done this with Windows DC shares, and I'm 99% certain
I've done it with FreeNAS acting as a domain member. [Samba domain member.]

I haven't done it with 18.04 / 4.7.6 - but can't see why it should be
different.

[Though I admit it's been a while, and I'm not sure of the syntax I
used. But I'm quite sure I've mapped drives this way, without having to
join the domain. You won't get GPO or lots of other "goodies" that
domain membership gives, but you should be able to get to the SMB shares.]

-Greg



GPGvs> On 6/25/19 11:21 AM, Gregory Sloop via samba
wrote:
>> You can always connect to the SMB share using a domain user/password
credential set, even if you're not a member of the domain.
>> Something like - Connect as: User: "somedomain\pat" with
Pat's password.


GPGvs> When we try this from a machine that is not connected to the domain, 
GPGvs> authentication fails:


GPGvs> C:\Users\cns-dbr2717>net use *
GPGvs> \\cns-bio-krak1.austin.utexas.edu\emtifs 
GPGvs> /user:austin.utexas.edu\dbr2717
GPGvs> System error 1311 has occurred.

GPGvs> We can't sign you in with this credential because your domain
isn't
GPGvs> available. Make sure your device is connected to your
organization's
GPGvs> network and try again. If you previously signed in on this device with
GPGvs> another credential, you can sign in with that credential.

GPGvs> We experimented, switching between

GPGvs>      security = ADS
GPGvs> and
GPGvs>      security = user

GPGvs> This doesn't seem to matter for domain users connecting from a
domain
GPGvs> host, but neither work for a domain user connecting from a non-domain 
GPGvs> host.  Connecting to a Windows SMB server, this does work.

GPGvs> Some information found online seems to suggest that this (domain user,
GPGvs> non-domain host) *would* work if we were running winbind, but Rowland 
GPGvs> seems to suggest this isn't the case, either.  In theory it should
be
GPGvs> possible to run sssd and winbind on the SMB server, but we put some 
GPGvs> minimal effort into this and couldn't get it to work.  Likely will
work
GPGvs> in a couple of software iterations.





-- 
Gregory Sloop, Principal: Sloop Network & Computer Consulting
Voice: 503.251.0452 x82
EMail: gregs at sloop.net
http://www.sloop.net
---

On 25/06/2019 18:57, Gregory Sloop via samba wrote:
> Hmmm...
>
> Use the netbios name, instead of a FQDN, perhaps?
> i.e.: \\cns-bio-krak1\emtifs
> [I'm assuming the NB name. If I'm wrong, correct it.]
>
> I know I've done this with Windows DC shares, and I'm 99% certain
I've done it with FreeNAS acting as a domain member. [Samba domain member.]
>
> I haven't done it with 18.04 / 4.7.6 - but can't see why it should
be different.
>
> [Though I admit it's been a while, and I'm not sure of the syntax I
used. But I'm quite sure I've mapped drives this way, without having to
join the domain. You won't get GPO or lots of other "goodies" that
domain membership gives, but you should be able to get to the SMB shares.]
>
> -Greg
>
>
>
Yes, it as I said:

adminuser at stand:~$ smbclient \\\\192.168.0.33\\rowland -U
'SAMDOM\rowland'
Enter SAMDOM\rowland's password:
try "help" to get a list of possible commands.
smb: \> pwd
Current directory is \\192.168.0.33\rowland\
smb: \> q
adminuser at stand:~$ smbclient \\\\192.168.0.33\\rowland -U 'rowland'
Enter WORKGROUP\rowland's password:
session setup failed: NT_STATUS_LOGON_FAILURE

Note: using the hostname does not work.

Rowland

On 6/25/19 12:57 PM, Gregory Sloop via samba wrote:
> Hmmm...
> 
> Use the netbios name, instead of a FQDN, perhaps?
> i.e.: \\cns-bio-krak1\emtifs
> [I'm assuming the NB name. If I'm wrong, correct it.]
> 
> I know I've done this with Windows DC shares, and I'm 99% certain
I've done it with FreeNAS acting as a domain member. [Samba domain member.]
> 
I didn't include these examples, but we tried both the NETBIOS name and 
the IP address of the Samba server; neither worked.

I am still unclear on this and would love to get clarification:  Forget 
about sssd.  If I run winbind, can I mount SMB shares from a domain 
member to a non-domain machine using a domain user account?  If so, I 
can try setting up a "pure Samba" machine which NFS mounts the 
appropriate directories and then SMB shares them to the non-domain hosts.

On 6/25/19 12:56 PM, Rowland penny via samba wrote:
>> C:\Users\cns-dbr2717>net use *
\\cns-bio-krak1.austin.utexas.edu\emtifs
>> /user:austin.utexas.edu\dbr2717
>> System error 1311 has occurred.
>>
<snip>
> 
> First, what part of 'Red-hat doesn't support the use of sssd with
Samba'
> do you not understand ? ;-)
>
Hmmm, "support" and "works" are 2 different things.  We do
have Samba
4.8.3 working fine with sssd.

> You cannot run sssd and winbind on the same machine.
>
I don't understand why that would be, though.  This person appears to 
have it working, providing this comment:

"Please check the list archive for config examples. The main idea is to 
add idmap_sss to the Samba configuration to make sure winbind and SSSD 
use the same id-mapping, see man idmap_sss for details as well."  The 
very existence of idmap_sss calls the validity of your statement into 
question, doesn't it?

This URL includes an example, but -- disclaimer -- we were not able to 
get this working with the packaged versions shipped with CentOS 7.6.1810

https://lists.fedoraproject.org/archives/list/sssd-users at
lists.fedorahosted.org/thread/U66MEJBMXVJWJVCBORS2KBP7BIAGZ57H/

> 
> If you are running Samba >= 4.8.0 on an Unix domain member, you must run
> winbind.
See above; we have a fully functionally smbd from 4.8.3 running without 
winbind.

> 
> The problem with using user from an unjoined machine is probably the 
> username. Every computer running Windows or Samba is a member of a 
> workgroup unless it is joined to a domain. This means that it will be 
> sending WORKGROUP\username and a domain member will be expecting 
> DOMAIN\username, so try connecting as DOMAIN\username.
> 
But isn't DOMAIN\username exactly what I'm doing in the example provided
at the top of this message?



> Rowland
> 
> 
>