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
>