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>