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
On 07/06/2020 20:15, mathias dufresne wrote:> > Sure, I claimed it worked, it was because it is working.I never said it wouldn't work, I said it was a BAD idea.> 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 repeat, it only works with kerberos and whilst it may 'reflect real enterprise life' where you come from, it is a stupid idea where I come from.> > > 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.No, they are not new solutions, that is one of the problems, a lot of 'historical' ways of using Samba were not very clever and your 'too-expensive-to-change-right-now' is likely to become 'ultra-too-expensive-to-change-right-now' when you do come to change it. the first cost is usually the least cost.> > > 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.No, you didn't ask for support, but i just wanted to get it out there that I will not support this abortion. You can do what you like with Samba, just do not push your bad ideas here. Rowland
Le dim. 7 juin 2020 ? 21:57, Rowland penny via samba <samba at lists.samba.org> a ?crit :> On 07/06/2020 20:15, mathias dufresne wrote: > > > > Sure, I claimed it worked, it was because it is working. > I never said it wouldn't work, I said it was a BAD idea. > > 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 repeat, it only works with kerberos and whilst it may 'reflect real > enterprise life' where you come from, it is a stupid idea where I come > from. >I would have wrote that I'll tell them but that's the first thing I did, along explaining how to switch to winbindd usage to get AD users on system side.> > > > > > 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. > No, they are not new solutions, that is one of the problems, a lot of > 'historical' ways of using Samba were not very clever and your > 'too-expensive-to-change-right-now' is likely to become > 'ultra-too-expensive-to-change-right-now' when you do come to change it. > the first cost is usually the least cost. >Let's say it's not my place to decide if my clients have to change their ways or not. I give advices, they chose to follow my recommendations or not. And I advised them to switch their system users from flat files to AD/Winbindd weeks ago, at the very beginning of that mission.> > > > > > 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. > No, you didn't ask for support, but i just wanted to get it out there > that I will not support this abortion. You can do what you like with > Samba, just do not push your bad ideas here. > > Please, I never "pushed" that Samba usage as the right way to use Sambaand AD. Never ever. In fact my initial questions have nothing to do with that discussion. At one moment I explained how my client's solution is designed and you wrote that way does not work when it is working. That's all. Sorry to have corrected you, sorry that made so much useless noise.