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
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. > > mathiasWell, blow me down, it sort of works, 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). I cannot suggest that this method is used in production, there is too much chance for error. 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. Rowland
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