Hi Rowland, thanks for the quick response! -<| Quoting Rowland Penny via samba <rpenny at samba.org>, on Thursday, 2019-05-02 11:41:15 AM |>-> On Thu, 2 May 2019 11:59:45 +0200 > Philipp Gesang via samba <samba at lists.samba.org> wrote: > > > Hey guys, > > > > on a machine with the role “member server”, joining AD requires > > setting “security = ads”. > > This would make your computer a Unix domain member of an active > directory domain > > > Access to shares using local users set up through smbpasswd requires > > “security = user”. > > You cannot have 'local' users in an AD domain, they are are either > domain users or they are unknown to the domain. > > > As I understand the man page, these are mutually exclusive. > > Yes. > > > 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.> > Share access for domain users is not desirable as clients are mostly > > automated remote services that needn’t be AD aware. > > Might not be desirable, but you might have to do it. > > > > > I guess handing net a different smb.conf to perform the join is > > the obvious quick'n'dirty fix. > > I cannot see how this would work, yes you could use a very small > smb.conf to join the domain and then expand on it, but you would still > have local users that would not be known to the domain.That is the goal, yes.> > I’m wondering though if there is a parameter that would make this > > unnecessary. > > No, there is nothing you can do that would allow what you want to do. > > 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. 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/62147dc5/signature.sig>
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.> > 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. 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. Rowland
-<| 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>
Not tested, just brain farts ;-) Setup a member, Allow guest access. ( in global : guest ok = yes ) This allow local users to access the server ( not shares ) On the shares Deny "domain users" and/or authenticated users. Allow the local group for local users. Not tested but technicaly is could work. Which is almost the same as a standalone with and without user authentication. Greetz, Louis> -----Oorspronkelijk bericht----- > Van: samba [mailto:samba-bounces at lists.samba.org] Namens > Philipp Gesang via samba > Verzonden: donderdag 2 mei 2019 14:28 > Aan: Rowland Penny > CC: samba at lists.samba.org > Onderwerp: Re: [Samba] username map with “security = ads” > > -<| 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 > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >