On Tue, 2023-01-31 at 21:01 +0100, Peter Milesson via samba wrote:> On 31.01.2023 20:27, Rowland Penny via samba wrote: > > On 31/01/2023 19:14, Peter Milesson via samba wrote: > > > Hi Michael, > > > I don't see any reason, that the 11025 computer account should > > > have any unix permissions on the server whatsoever. The server is > > > setup using Windows ACLs exclusively, no unix or posix acls or > > > permissions involved at all. There should be no unix access for > > > client machines, not for users either BTW, and if Samba > > > complains, it's a Samba bug. The path is obviously accessible by > > > the domain users through Samba, otherwise their Windows > > > environment wouldn't work (of which I would be very quickly > > > informed). > > > Best regards, > > > Peter > > > > > > > > > > The problem with computers in AD domain is that they are just users > > with an extra objectclass, so, as far as Samba is concerned, they > > are users.In an ldap search you can filter them out, perhaps Samba > > needs to do this as standard, unless they need to be a user (for > > some unknown reason, some people do want this). Of course this may > > be what is supposed to happen (don't ask me about 'C') and > > something has gone wrong. > > Rowland > Hi Rowland, > Yes I know that computer accounts are regarded as users. But no > computer accounts are defined in the security settings of the shares, > only users (and groups). My knowledge of the internal workings of > Windows and Samba is too scant, to assess whether it's OK for Windows > to try to access the share or not. Personally, I would be very > reluctant to allow a machine account to get access to a share, as > there are no guarantees what's up. IMHO, it would impose a huge > security problem.I understand it can often be the virus scanner (which is running in an elevated security context, so gets machine credentials). Andrew Bartlett-- Andrew Bartlett (he/him) https://samba.org/~abartlet/Samba Team Member (since 2001) https://samba.orgSamba Team Lead, Catalyst IT https://catalyst.net.nz/services/samba Samba Development and Support, Catalyst.Net Limited Catalyst.Net Ltd - a Catalyst IT group company - Expert Open SourceSolutions
On 31.01.2023 21:36, Andrew Bartlett via samba wrote:> On Tue, 2023-01-31 at 21:01 +0100, Peter Milesson via samba wrote: >> On 31.01.2023 20:27, Rowland Penny via samba wrote: >>> On 31/01/2023 19:14, Peter Milesson via samba wrote: >>>> Hi Michael, >>>> I don't see any reason, that the 11025 computer account should >>>> have any unix permissions on the server whatsoever. The server is >>>> setup using Windows ACLs exclusively, no unix or posix acls or >>>> permissions involved at all. There should be no unix access for >>>> client machines, not for users either BTW, and if Samba >>>> complains, it's a Samba bug. The path is obviously accessible by >>>> the domain users through Samba, otherwise their Windows >>>> environment wouldn't work (of which I would be very quickly >>>> informed). >>>> Best regards, >>>> Peter >>>> >>>> >>> The problem with computers in AD domain is that they are just users >>> with an extra objectclass, so, as far as Samba is concerned, they >>> are users.In an ldap search you can filter them out, perhaps Samba >>> needs to do this as standard, unless they need to be a user (for >>> some unknown reason, some people do want this). Of course this may >>> be what is supposed to happen (don't ask me about 'C') and >>> something has gone wrong. >>> Rowland >> Hi Rowland, >> Yes I know that computer accounts are regarded as users. But no >> computer accounts are defined in the security settings of the shares, >> only users (and groups). My knowledge of the internal workings of >> Windows and Samba is too scant, to assess whether it's OK for Windows >> to try to access the share or not. Personally, I would be very >> reluctant to allow a machine account to get access to a share, as >> there are no guarantees what's up. IMHO, it would impose a huge >> security problem. > I understand it can often be the virus scanner (which is running in an > elevated security context, so gets machine credentials). > Andrew Bartlett-- > Andrew Bartlett (he/him) https://samba.org/~abartlet/Samba Team Member (since 2001) https://samba.orgSamba Team Lead, Catalyst IT https://catalyst.net.nz/services/samba > Samba Development and Support, Catalyst.Net Limited > Catalyst.Net Ltd - a Catalyst IT group company - Expert Open SourceSolutions >Hi Andrew, Thanks for the hint. I just had that idea somewhere in the back of my head. I will do some experimenting. If it turns out to be the case, I will bring that up with the AV producer. Best regards, Peter
On 31/01/2023 20:36, Andrew Bartlett via samba wrote:> > I understand it can often be the virus scanner (which is running in an > elevated security context, so gets machine credentials). > Andrew Bartlett-- > Andrew Bartlett (he/him) https://samba.org/~abartlet/Samba Team Member (since 2001) https://samba.orgSamba Team Lead, Catalyst IT https://catalyst.net.nz/services/samba > Samba Development and Support, Catalyst.Net Limited > Catalyst.Net Ltd - a Catalyst IT group company - Expert Open SourceSolutions >That is interesting, is there anything that can be done on the Samba side to stop these messages, they seem to be getting out of hand. It also explains why I am not getting them, no antivirus software. Rowland
31.01.2023 23:36, Andrew Bartlett via samba ?????: ..> I understand it can often be the virus scanner (which is running in an > elevated security context, so gets machine credentials).There are various other cases when this can happen, not only due to A/V software. As I noted in the beginning, I don't know *all* cases. Sometimes it happens here on reboot, sometimes it does not. Sometimes I especially run stuff as machine account when I don't need to set up a separate user and store their password somewhere. What I know for sure is that machines didn't try to create files (profiles) in there (so far anyway). But if the parent profiles dir is not accessible on unix to machine "user", samba does complain like this, and if I want to stop it from complaining, a natural thing to do is to let it to "sniff" where it wants. It might get an error that the share itself is not found (or permission were denied, like in this case), or it can be told that its profile directory does not exist, - either way it is fine for the win mcachine. But allowing access to the share itself makes samba less noisy for sure. For profiles share, this discussion is moot really (in my view anyway), because allowing machine account to access the top of the share does is not a security treat. User-specific dirs are inaccessible anyway. And you can restrict writes just to "Domain Users' group (instead of "Everyone"), or sometimes it is much better to restrict writes completely and pre-create individual user profile dirs. /mjt