[Samba] username map with “security = ads”

Philipp Gesang philipp.gesang at intra2net.com
Thu May 2 12:27:32 UTC 2019


-<| 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>


More information about the samba mailing list