[Samba] File server questions

mathias dufresne infractory at gmail.com
Sun Jun 7 19:15:20 UTC 2020


Le ven. 5 juin 2020 à 19:53, Rowland penny via samba <samba at lists.samba.org>
a écrit :

> On 05/06/2020 14:33, mathias dufresne via samba wrote:
> > Le jeu. 4 juin 2020 à 15:43, Rowland penny via samba <
> samba at lists.samba.org>
> > a écrit :
> >
> >> On 04/06/2020 14:13, mathias dufresne via samba wrote:
> >> [...]
> >>> smbd: the file server, at least for modern usage. It can also grab user
> >>> information from AD but not for system users, only for Samba users (the
> >>> applicative users, used to authenticate when accessing Samba and later,
> >> to
> >>> shares)
> >>> Is that true or not?
> >> Not any more, smbd used to be able to fallback to AD, but this was
> >> removed at 4.8.0
> >>
> >> 'smbd' is the fileserver component of Samba and requires winbind when
> >> running with 'security = ADS'
> >>
> >> [...]
> >
> > I was very surprised to read that as on CentOS 7 using Samba
> 4.10.4-10.el7
> > and on Debian 10 using Samba 4.9.5+dfsg-5+deb10u1 I was able to get a
> > working configuration were:
> > - only smbd is running
> > - Windows clients are using their AD account (and SSO mechanism)
> > - once connected users can access to shares and contained files and
> > directories for modification.
> >
> > Used smb.conf in both cases:
> >
> ----------------------------------------------------------------------------
> > [global]
> >    # AD access
> >    realm = AD.DOMAIN.TLD
> >    workgroup = AD
> >    security = ads
> >    kerberos method = secrets and keytab
> >    log level = 3
> >    username map = /etc/samba/usermap
> >    server string = serveur
> > #============================ Share Definitions
> > ==============================
> > [sharename]
> >          path = /sharename
> >          writeable = yes
> >          browseable = yes
> >          guest ok = yes
> >          create mask = 0644
> >
> ----------------------------------------------------------------------------
> >
> > These two test systems are using /etc/passwd and /etc/group as users and
> > groups databases.
> >
> > It seems the "requirement" is not so required and so I'm kind of puzzled.
> >
> > mathias
>
> Well, blow me down, it sort of works,


Sure, I claimed it worked, it was because it is working.


> I can connect via smbclient, but
> not from a Linux GUI client. It appears that 'smbd' is using kerberos.
> You have to create the AD users as local Unix users on the semi-AD
> machine, probably with the same password and there is no way to get the
> same ID's on multiple machines (not unless you created the users and
> groups in exactly the same order).
>

It seems only Kerberos is allowed: I tried using Windows and a local user
to connect, no access to the server at all.
When using AD user from WIndows, it works like a charm.

I do speak about Windows clients as they reflect real entreprise life,
which is what most of us work for.


> I cannot suggest that this method is used in production, there is too
> much chance for error.
>

These kinds of configurations are normally not new solutions (or there's
something with the solution's designer :p), they are "historical"
configurations. A short term to say too-expensive-to-change-right-now. Then
we have to deal with.


>
> I personally will not support using this method, Samba in the past
> supported some bad ways of working, there is no need to continue
> supporting bad ideas.
>

No support was asked I believe. Or my English is worse than expected.

mathias


More information about the samba mailing list