-<| Quoting Rowland Penny via samba <rpenny at samba.org>, on Thursday, 2019-05-02 01:12:41 PM |>-> On Thu, 2 May 2019 13:34:01 +0200 > Philipp Gesang <philipp.gesang at intra2net.com> wrote: > > > Hi Rowland, > > > > > > > > Now our use case requires for the machine to be joined but also > > > > grant access to shares to local users. > > > > > > Not going to happen, because your local users will be unknown to the > > > domain. > > > > That’s the point: The shares aren’t intended for domain users to > > access. > > If this is a domain member, then ONLY the domain users will be allowed > access to the shares.with server role = member server security = user I can logon with smbclient as local user using username%password. With server role = member server security = ads and all other things being equal, I can’t (“session setup failed: NT_STATUS_NO_LOGON_SERVERS”). This is from a client without any domain awareness whatsoever.> > > Have you considered setting Samba up a standalone server ? > > > > Samba is currently functioning as a standalone server. > > Additionally we wish to leverage the AD member functionality to > > join those boxes to AD domains. The credentials acquired that way > > (keytabs) are then used by other services to have domain accounts > > (people and hosts) authenticate against AD. The shares however > > have a different purpose and can’t be switched to require AD > > without breaking existing deployments. > > > > A second smb.conf is an acceptable workaround, I think. > > The only thing that I think that might work is not just one > smb.conf, but double everything (except nmbd), one joined to the > domain and one not.Namspacing the two sambas could be an option.> I personally wouldn't do anything like this, it is fraught with > potential problems and dangers. > > Whilst you do not want to put your local users into AD, this might be > your easiest and best way out of your problem. Create an AD group and > add all your 'local unix users' to this group, then only allow access > to the Samba shares to members of this group.Wouldn’t that also imply that accesses need to authenticate against AD? Philipp -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.samba.org/pipermail/samba/attachments/20190502/d41109be/signature.sig>
On Thu, 2 May 2019 14:27:32 +0200 Philipp Gesang <philipp.gesang at intra2net.com> wrote:> with > > server role = member server > security = userThe 'security = user' overrides the 'server role = member server' It is a 'standalone server' What is more, unless you have changed the workgroup, you now have a 'workgroup' and a 'domain' with the same name.> > I can logon with smbclient as local user using username%password.Well, yes, you would be able to, because it is a standalone server.> With > > server role = member server > security = ads > > and all other things being equal, I can’t (“session setup failed: > NT_STATUS_NO_LOGON_SERVERS”). This is from a client without any > domain awareness whatsoever.Just adding 'security = ads' doesn't make a computer a domain member, you have to join it to the domain and if it isn't a domain member, it wouldn't be able to find the DC.> > Whilst you do not want to put your local users into AD, this might > > be your easiest and best way out of your problem. Create an AD > > group and add all your 'local unix users' to this group, then only > > allow access to the Samba shares to members of this group. > > Wouldn’t that also imply that accesses need to authenticate > against AD?Yes, but why would this be a problem ? Rowland
-<| Quoting Rowland Penny via samba <rpenny at samba.org>, on Thursday, 2019-05-02 02:04:14 PM |>-> On Thu, 2 May 2019 14:27:32 +0200 > Philipp Gesang <philipp.gesang at intra2net.com> wrote: > > > with > > > > server role = member server > > security = user > > The 'security = user' overrides the 'server role = member server' > It is a 'standalone server'I wasn’t aware of that, makes sense though.> What is more, unless you have changed the workgroup, you now have a > 'workgroup' and a 'domain' with the same name.They’re distinct values.> > I can logon with smbclient as local user using username%password. > > Well, yes, you would be able to, because it is a standalone server. > > > With > > > > server role = member server > > security = ads > > > > and all other things being equal, I can’t (“session setup failed: > > NT_STATUS_NO_LOGON_SERVERS”). This is from a client without any > > domain awareness whatsoever. > > Just adding 'security = ads' doesn't make a computer a domain member, > you have to join it to the domain and if it isn't a domain member, it > wouldn't be able to find the DC. > > > > Whilst you do not want to put your local users into AD, this might > > > be your easiest and best way out of your problem. Create an AD > > > group and add all your 'local unix users' to this group, then only > > > allow access to the Samba shares to members of this group. > > > > Wouldn’t that also imply that accesses need to authenticate > > against AD? > > Yes, but why would this be a problem ?These clients may not even know about AD and should be able to access the shares from other networks behind VPN tunnels without talking to some DC. Plus backward compatibility trumps everything, I’m afraid. Anyways, thanks for your input. This was very helpful! Best regards, Philipp -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.samba.org/pipermail/samba/attachments/20190502/3b20e005/signature.sig>