samba - Feb 2017 - Windows ACL clarification for Roaming Profiles share

On Thu, 16 Feb 2017 07:30:03 +0100
Marc Muehlfeld via samba <samba at lists.samba.org> wrote:
> 
> On Windows, the SYSTEM account is used by services on the local host
> (in your case, the local host is your Samba server). For example,
> virus scanners might use it to get access to all files. However,
> there is nothing on your Samba server that uses the SYSTEM account.
> Thus it makes no difference if you add it or not.
> 
Marc, You might want to re-consider that statement, SYSTEM is used
extensively in sysvol.

Rowland

Am 16.02.2017 um 15:47 schrieb Rowland Penny via samba:
>> On Windows, the SYSTEM account is used by services on the local host
>> (in your case, the local host is your Samba server). For example,
>> virus scanners might use it to get access to all files. However,
>> there is nothing on your Samba server that uses the SYSTEM account.
>> Thus it makes no difference if you add it or not.
>>
> 
> Marc, You might want to re-consider that statement, SYSTEM is used
> extensively in sysvol.

What uses the SYSTEM principal on the Sysvol share?

Is it really used (by what?) or do we just have this princial in the
ACLs to be consistent with a Windows DC?


Regards,
Marc

On Thu, 16 Feb 2017 17:13:25 +0100
Marc Muehlfeld <mmuehlfeld at samba.org> wrote:

> 
> What uses the SYSTEM principal on the Sysvol share?
Not sure if anything actually uses SYSTEM on Unix, probably not.
However, SYSTEM is used in sysvol and Windows expects it.
> 
> Is it really used (by what?) or do we just have this princial in the
> ACLs to be consistent with a Windows DC?
The pages the OP referred to, including the profiles page, don't seem
to agree with what the windows machines expect, see here for profiles:

https://technet.microsoft.com/en-us/library/jj649079%28v=ws.11%29.aspx

Rowland

> What uses the SYSTEM principal on the Sysvol share? 
Every computer or user the has a GPO set.

Do read: 
https://technet.microsoft.com/en-us/library/dd851678(v=ws.11).aspx
And see here, Security options : 
Computer Configuration , by default the task is run in the security context of
the SYSTEM account.


i noticed 
wbinfo --sid-to-name=S-1-5-18 on a 4.5.3 ADDC does not work
but 
wbinfo --sid-to-name=S-1-5-18 on a 4.5.5 member does work.

Im still testing my 4.5.5. samba deb packages, so can someone confirm above
that. This is resolved in 4.5.5. on the AD also?
Then i'll have to speedup my testing and deploy 4.5.5 i really really need
the system to get correct.
Info about that getting correct, see these on the list: 

https://lists.samba.org/archive/samba/2016-December/thread.html#204945

All info you need and steps to reproduces are found in subject : 
"Security Principals, and SID's mapping bug"
https://lists.samba.org/archive/samba/2017-January/206112.html



Greetz, 

Louis

> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens Marc Muehlfeld
> via samba
> Verzonden: donderdag 16 februari 2017 17:13
> Aan: Rowland Penny; samba at lists.samba.org
> Onderwerp: Re: [Samba] Windows ACL clarification for Roaming Profiles
> share
> 
> Am 16.02.2017 um 15:47 schrieb Rowland Penny via samba:
> >> On Windows, the SYSTEM account is used by services on the local
host
> >> (in your case, the local host is your Samba server). For example,
> >> virus scanners might use it to get access to all files. However,
> >> there is nothing on your Samba server that uses the SYSTEM
account.
> >> Thus it makes no difference if you add it or not.
> >>
> >
> > Marc, You might want to re-consider that statement, SYSTEM is used
> > extensively in sysvol.
> 
> 
> What uses the SYSTEM principal on the Sysvol share?
> 
> Is it really used (by what?) or do we just have this princial in the
> ACLs to be consistent with a Windows DC?
> 
> 
> Regards,
> Marc
> 
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba

Hi Louis,

Am 17.02.2017 um 09:26 schrieb L.P.H. van Belle via
samba:
>> What uses the SYSTEM principal on the Sysvol share?
 >
> Every computer or user the has a GPO set.
You may be right that "computer" GPOs are applied locally using the 
SYSTEM account. However, this is _local_ and the computer does not 
access the Sysvol share using the SYSTEM account. To download the 
computer GPOs, the machine account is used to connect to the share. 
Per-user GPOs are downloaded using the user's permissions and applied to 
the user's files and registry (HKCU).


However, I gave it a try, to see if my knowledge is meanwhile outdated:
- I removed the SYSTEM account from the Sysvol share including from all 
subfolders.
- I created two GPOs in the "Default domain policy":
   - I set a different background for the logon screen (computer)
   - I removed the "change password" entry from the
     CTRL+ALT+DEL menu (user)
   - I mapped the Sysvol share using GPO preferences (user)
- I rebooted my Win10 client.

After the reboot, the background was changed and after I logged in, the 
entry was hidden in the menu and the share connected. The Sysvol share 
works without SYSTEM account in the ACLs locally on the share.

Give it a try if you don't believe me. :-)


> Do read:
> https://technet.microsoft.com/en-us/library/dd851678(v=ws.11).aspx
> And see here, Security options :
> Computer Configuration , by default the task is run in the security context
of the SYSTEM account.
This is about tasks that run locally. And locally on a Windows machine 
is where the SYSTEM account is usually used. If the local SYSTEM Account 
tries to access a network resource, it uses the machine account to 
authenticate.

That's why it is not necessary to add SYSTEM to the file system ACLs on 
a Samba share: SYSTEM is just an account that exists _locally_ and is 
not used when connecting to network resources.

If you have anything (a service, a task job, etc.) running on your 
_local_ computer that uses the SYSTEM account, then SYSTEM must be of 
course added to the local file system ACLs if this task, etc. should be 
able to access _local_ files.


Here's a nice explanation of the SYSTEM account:
https://abhijitw.wordpress.com/2012/03/03/the-local-system-account/

See also:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms684190%28v=vs.85%29.aspx
https://support.microsoft.com/en-us/help/120929/how-the-system-account-is-used-in-windows


Regards,
Marc

Hello Marc, 

First of all.
https://abhijitw.wordpress.com/2012/03/03/the-local-system-account/ 
is really outdated. 

The Explanation is simply incomplete.
Yes, localy there is SYSTEM. But due to some i think sid/rid whatever wrong
mapping its not working correctly in samba when you use GPO settings also.
Per example. And its the last time im telling it. 
I beleave that, somewhere somehow, the explanation of the above link is used in
samba coding. And the result is a not good.

For you this link: 
> > https://technet.microsoft.com/en-us/library/dd851678(v=ws.11).aspx 
Says : 
Its token includes the NT AUTHORITY\SYSTEM and BUILTIN\Administrators SIDs;
these accounts have access to most system objects. The name of the account in
all locales is .\LocalSystem. The name, LocalSystem or ComputerName\LocalSystem
can also be used

Can you explain why i only can use system as "DOMAIN\system" here? 
When i set the user SYSTEM in my GPO and why this never works. 

So if you dont believe me.
Create a Scheduled task and try to make it run as user NT AUTHORITY\SYSTEM 

1.Viewing/Edit a GPO,
go to Computer Configuration > Control Panel Settings > Scheduled Tasks.
2.Right-click in the window and choose
New > Scheduled Task (At least Windows 7).
3.On the General tab:
a.Set the name to TestSchedule.
b.Run the task as NT AUTHORITY\System. Check Run with highest privileges.
c.Click OK.

3b, try, klik change user/group.
Next window, type : system, klik ok.
It changes to NTDOM\system which should be BUILTIN\SYSTEM

3b, again, change user/group,
Next window, type : Server Operators, and klik ok.
That reports correcty : BUILTIN\Server Operators

Resulting error: 
The computer 'Administrators (built-in)' preference item in the
'LocalAdminPolicy {77E77E2C-DD41-4BE8-BCA3-9D729ED51F98}' Group Policy
object did not apply because it failed with error code '0x80070534
No mapping between account names and security IDs was done.' This error was
suppressed


Key here is :
No mapping between account names and security IDs was done. 

Conclusion for me is. 
Sure, i beleave all your saying and everything your saying works. 
BUT 
If you going to set more advanced GPO settings, it wil end up in errors,
Not working GPOs etc. 

Just my saying, said already to much here.
Posted problems like this long ago already. 

Samba DC : ( 4.5.3) 
wbinfo --lookup-sids=S-1-5-18
wbcLookupSids failed: WBC_ERR_INVALID_SID
Could not lookup SIDs S-1-5-18

Samba Member 4.5.3 and 4.5.5


For a correct windows 10 profiles share, you need the following. 
https://technet.microsoft.com/en-us/library/jj649079(v=ws.11).aspx
which clearly shows systems with Full control. 



Greetz, 

Louis
> -----Oorspronkelijk bericht-----
> Van: Marc Muehlfeld [mailto:mmuehlfeld at samba.org]
> Verzonden: zaterdag 18 februari 2017 1:15
> Aan: L.P.H. van Belle; samba at lists.samba.org
> Onderwerp: Re: [Samba] Windows ACL clarification for Roaming Profiles
> share
> 
> Hi Louis,
> 
> Am 17.02.2017 um 09:26 schrieb L.P.H. van Belle via samba:
> >> What uses the SYSTEM principal on the Sysvol share?
>  >
> > Every computer or user the has a GPO set.
> 
> You may be right that "computer" GPOs are applied locally using
the
> SYSTEM account. However, this is _local_ and the computer does not
> access the Sysvol share using the SYSTEM account. To download the
> computer GPOs, the machine account is used to connect to the share.
> Per-user GPOs are downloaded using the user's permissions and applied
to
> the user's files and registry (HKCU).
> 
> 
> However, I gave it a try, to see if my knowledge is meanwhile outdated:
> - I removed the SYSTEM account from the Sysvol share including from all
> subfolders.
> - I created two GPOs in the "Default domain policy":
>    - I set a different background for the logon screen (computer)
>    - I removed the "change password" entry from the
>      CTRL+ALT+DEL menu (user)
>    - I mapped the Sysvol share using GPO preferences (user)
> - I rebooted my Win10 client.
> 
> After the reboot, the background was changed and after I logged in, the
> entry was hidden in the menu and the share connected. The Sysvol share
> works without SYSTEM account in the ACLs locally on the share.
> 
> Give it a try if you don't believe me. :-)
> 
> 
> 
> > Do read:
> > https://technet.microsoft.com/en-us/library/dd851678(v=ws.11).aspx
> > And see here, Security options :
> > Computer Configuration , by default the task is run in the security
> context of the SYSTEM account.
> 
> This is about tasks that run locally. And locally on a Windows machine
> is where the SYSTEM account is usually used. If the local SYSTEM Account
> tries to access a network resource, it uses the machine account to
> authenticate.
> 
> That's why it is not necessary to add SYSTEM to the file system ACLs on
> a Samba share: SYSTEM is just an account that exists _locally_ and is
> not used when connecting to network resources.
> 
> If you have anything (a service, a task job, etc.) running on your
> _local_ computer that uses the SYSTEM account, then SYSTEM must be of
> course added to the local file system ACLs if this task, etc. should be
> able to access _local_ files.
> 
> 
> Here's a nice explanation of the SYSTEM account:
> https://abhijitw.wordpress.com/2012/03/03/the-local-system-account/
> 
> See also:
> https://msdn.microsoft.com/en-
> us/library/windows/desktop/ms684190%28v=vs.85%29.aspx
> https://support.microsoft.com/en-us/help/120929/how-the-system-account-is-
> used-in-windows
> 
> 
> Regards,
> Marc