Quantcast

Windows ACL clarification for Roaming Profiles share

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Windows ACL clarification for Roaming Profiles share

Samba - General mailing list
The following wiki pages have varying suggestions on what to use for
Windows ACLs on a Samba share.

https://wiki.samba.org/index.php/Implementing_roaming_profiles
https://wiki.samba.org/index.php/User_Home_Folders
https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs

The different suggestions on the referenced wiki pages, without explanation
of the choices, causes a lot of confusion. Most importantly, they reference
each other without clarifying exactly what parts to use from the other
pages.

The goal here is Roaming Profiles and Folder Redirection, each with its own
share. Samba 4.3.11 on Ubuntu 16.04.2 with Windows 7 clients for now,
Windows 10 eventually.

What I've managed to come up with for share permissions:

Authenticated Users
 - Read
 - Change (can't create directory without)

Domain Admins
 - Full control

For the ACLs on the root folder of the share:

CREATOR OWNER - Subfolders and files only
 - Full Control

Domain Admins - This folder, subfolders, and files
 - Full Control

Authenticated Users - This folder only
 - Traverse folder/execute file, List folder/read data, Create
folder/append data

The majority of the guides outside of the wiki suggest Windows wants to see
SYSTEM in the ACL list with Full Control. So far, in isolated testing, my
permissions work fine. Is there any need for this extra ACL that may not be
obvious currently?
-Lenard
--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Windows ACL clarification for Roaming Profiles share

Samba - General mailing list
Hi Lenard,

Am 15.02.2017 um 23:47 schrieb Lenard Fudala via samba:
> The majority of the guides outside of the wiki suggest Windows wants to see
> SYSTEM in the ACL list with Full Control. So far, in isolated testing, my
> permissions work fine. Is there any need for this extra ACL that may not be
> obvious currently?
> -Lenard


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.

Regards,
Marc


--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Windows ACL clarification for Roaming Profiles share

Samba - General mailing list
Thanks Marc. That's the assumption I was leaning towards, just couldn't
find any validation. Much appreciated.

-Lenard

On Thu, Feb 16, 2017 at 12:30 AM, Marc Muehlfeld <[hidden email]>
wrote:

> Hi Lenard,
>
> Am 15.02.2017 um 23:47 schrieb Lenard Fudala via samba:
> > The majority of the guides outside of the wiki suggest Windows wants to
> see
> > SYSTEM in the ACL list with Full Control. So far, in isolated testing, my
> > permissions work fine. Is there any need for this extra ACL that may not
> be
> > obvious currently?
> > -Lenard
>
>
> 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.
>
> Regards,
> Marc
>
>
--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Windows ACL clarification for Roaming Profiles share

Samba - General mailing list
In reply to this post by Samba - General mailing list
On Thu, 16 Feb 2017 07:30:03 +0100
Marc Muehlfeld via samba <[hidden email]> 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


--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Windows ACL clarification for Roaming Profiles share

Samba - General mailing list
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Windows ACL clarification for Roaming Profiles share

Samba - General mailing list
On Thu, 16 Feb 2017 17:13:25 +0100
Marc Muehlfeld <[hidden email]> 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

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Windows ACL clarification for Roaming Profiles share

Samba - General mailing list
Am 16.02.2017 um 17:27 schrieb Rowland Penny via samba:
>> What uses the SYSTEM principal on the Sysvol share?
>
> Not sure if anything actually uses SYSTEM on Unix, probably not.

It's a Samba DC built-in account, thus I'm sure nothing outside Samba
uses it. Neither does Samba. Samba uses root privileges to access files,
if necessary.



> However, SYSTEM is used in sysvol and Windows expects it.

Clients, who are accessing the share, do not require it to be set on the
local filesystem the share uses on the server, because SYSTEM is a local
principal on each host (in this case, the DC that hosts the sysvol share).

The sysvol share works also if you remove the SYSTEM principal. The
principal is used, as everywhere else, to enable e. g. local services
that use the SYSTEM account, to access the content on the local file
system. That's why it is usually added to file system ACLs everywhere on
Windows, but it's nothing Windows expects nor requires.

For this reason, if you remove SYSTEM from the Sysvol's file system
ACLs, the share works completely the same. Regardless if you do this on
a Windows or on a Samba DC.


Regards,
Marc

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Windows ACL clarification for Roaming Profiles share

Samba - General mailing list
In reply to this post by Samba - General mailing list
> 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:[hidden email]] Namens Marc Muehlfeld
> via samba
> Verzonden: donderdag 16 februari 2017 17:13
> Aan: Rowland Penny; [hidden email]
> 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





--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Windows ACL clarification for Roaming Profiles share

Samba - General mailing list
In reply to this post by Samba - General mailing list
On Fri, 17 Feb 2017 07:58:58 +0100
Marc Muehlfeld <[hidden email]> wrote:

> Am 16.02.2017 um 17:27 schrieb Rowland Penny via samba:
>
> > However, SYSTEM is used in sysvol and Windows expects it.
>
> Clients, who are accessing the share, do not require it to be set on
> the local filesystem the share uses on the server, because SYSTEM is
> a local principal on each host (in this case, the DC that hosts the
> sysvol share).
>
> The sysvol share works also if you remove the SYSTEM principal. The
> principal is used, as everywhere else, to enable e. g. local services
> that use the SYSTEM account, to access the content on the local file
> system. That's why it is usually added to file system ACLs everywhere
> on Windows, but it's nothing Windows expects nor requires.
>
> For this reason, if you remove SYSTEM from the Sysvol's file system
> ACLs, the share works completely the same. Regardless if you do this
> on a Windows or on a Samba DC.
>

So, I give you a link to a Microsoft page that shows what accounts are
required for the profiles share and you choose to ignore it ????

Rowland

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Windows ACL clarification for Roaming Profiles share

Samba - General mailing list
Am 17.02.2017 um 10:28 schrieb Rowland Penny via samba:
> So, I give you a link to a Microsoft page that shows what accounts are
> required for the profiles share and you choose to ignore it ????

Yes, because
1.) It might be necessary _locally_ on the Windows DC
     because some _local_ services (e. g. Virus scanners,
     etc) may access the files _locally_ _on the DC itself_.
     However if anything on the client (the OS or a user)
     would access the share using the SYSTEM privilege,
     then "full control" is surely not the permission
     you grant to the SYSTEM account to all files including
     subfolders. :-)
2.) This page justs list a bunch of accounts without
     explaining why it should be a requirement. Nor it
     says that it won't work without.
3.) If SYSTEM would be a requirement on the profiles
     or any other share for a Windows client, then
     shares using POSIX ACLs would not work at all.


My profile share hosted on my DC works perfectly without SYSTEM account
here. I never added the account to the ACLs because it makes no sense
(at least not on a Samba host). And the share works like expected,
because nothing on the client access the share using the SYSTEM account,
nor does Samba locally on the server.


If you still don't believe me, try it:
- Remove the SYSTEM account from the ACLs on your profiles share.
- Log in using a new domain user account that has a profile path set.
- Log out. The user's profile folder is uploaded to the share.
- Log in again.
- Create a file on the desktop
- Logout. You see the file is uploaded to the server.
If you want to extend this exercise:
- Log in using a local account, delete the local copy of
   the profile (System properties / User profile settings.
   Do not just delete the folder. This won't work since Vista)
- Log out
- Log in using the domain account you used before.
- You see the profile was downloaded again from the server,
   including the file you stored on the desktop.

Regards,
Marc

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Windows ACL clarification for Roaming Profiles share

Samba - General mailing list
In reply to this post by Samba - General mailing list
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


--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Windows ACL clarification for Roaming Profiles share

Samba - General mailing list
In reply to this post by Samba - General mailing list
On Sat, 18 Feb 2017 00:28:14 +0100
Marc Muehlfeld <[hidden email]> wrote:

>
> Yes, because
> 1.) It might be necessary _locally_ on the Windows DC
>      because some _local_ services (e. g. Virus scanners,
>      etc) may access the files _locally_ _on the DC itself_.
>      However if anything on the client (the OS or a user)
>      would access the share using the SYSTEM privilege,
>      then "full control" is surely not the permission
>      you grant to the SYSTEM account to all files including
>      subfolders. :-)

What you say has some validity, but people have been known to run a
virus scanner on Linux machines, just to scan windows files.

> 2.) This page justs list a bunch of accounts without
>      explaining why it should be a requirement. Nor it
>      says that it won't work without.

You could say the same about the Samba wiki page.

> 3.) If SYSTEM would be a requirement on the profiles
>      or any other share for a Windows client, then
>      shares using POSIX ACLs would not work at all.

I fail to see why they wouldn't

>
> If you still don't believe me, try it:

I believe it works for you without SYSTEM, but I thought that the Samba
AD DC was supposed to be compatible with a Windows DC and as such, it
should be set up in the same way.

Rowland


--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Windows ACL clarification for Roaming Profiles share

Samba - General mailing list
Am 18.02.2017 um 10:50 schrieb Rowland Penny via samba:

>> Yes, because
>> 1.) It might be necessary _locally_ on the Windows DC
>>      because some _local_ services (e. g. Virus scanners,
>>      etc) may access the files _locally_ _on the DC itself_.
>>      However if anything on the client (the OS or a user)
>>      would access the share using the SYSTEM privilege,
>>      then "full control" is surely not the permission
>>      you grant to the SYSTEM account to all files including
>>      subfolders. :-)
>
> What you say has some validity, but people have been known to run a
> virus scanner on Linux machines, just to scan windows files.

The virus scanner can use _any_ account on the local machine. If it must
access all files, start the job as "root". Or you create a new account
that is part of the ACLs and use this one.

I would avoid using a Samba internal account for that. If Samba is down,
NSS not configured correctly, etc. the job would fail.

However, and this is the main reason, you can't use the SYSTEM account
in the OS. Have you tried to "su" to this account? Maybe it's possible
with some hack after you manually edit the database and assigned a UID,
etc., but this account appears nowhere in the user account management,
like on Windows.




>> 2.) This page justs list a bunch of accounts without
>>      explaining why it should be a requirement. Nor it
>>      says that it won't work without.
>
> You could say the same about the Samba wiki page.

Yes I know, but I haven't rewritten the Profiles page yet.

When I rewrote the "User Home Folder" page, I omitted SYSTEM in the list
of Windows ACLs (and of course it was never part of the POSIX ACLs in
this guide). However, I saw no reason to explain things that I don't
tell the user to set and what not necessary. If you follow the guide,
you get everything you need for a fully working share.




>> 3.) If SYSTEM would be a requirement on the profiles
>>      or any other share for a Windows client, then
>>      shares using POSIX ACLs would not work at all.
>
> I fail to see why they wouldn't

If you argue that the SYSTEM account must exist in the ACLs of a profile
share's file system, then the following shared folder would fail,
because only root and "Domain Users" are part of the ACLs:

$ ls -la /srv/samba/profiles -d
drwxr-s--- 21 root "Domain Users" 4096 15. Feb 19:10 /srv/samba/profiles

However, it works.





>> If you still don't believe me, try it:
>
> I believe it works for you without SYSTEM, but I thought that the Samba
> AD DC was supposed to be compatible with a Windows DC and as such, it
> should be set up in the same way.

That's why it is part of the Sysvol share's file system ACLs. To be
consistent. However, this is only to be _consistent_. It has nothing to
do with being _compatible in this case.



Regards,
Marc

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Windows ACL clarification for Roaming Profiles share

Samba - General mailing list
On Sat, 18 Feb 2017 12:08:01 +0100
Marc Muehlfeld <[hidden email]> wrote:

> The virus scanner can use _any_ account on the local machine. If it
> must access all files, start the job as "root". Or you create a new
> account that is part of the ACLs and use this one.
>
> I would avoid using a Samba internal account for that. If Samba is
> down, NSS not configured correctly, etc. the job would fail.
>
> However, and this is the main reason, you can't use the SYSTEM
> account in the OS. Have you tried to "su" to this account? Maybe it's
> possible with some hack after you manually edit the database and
> assigned a UID, etc., but this account appears nowhere in the user
> account management, like on Windows.

You can 'map' SYSTEM on a domain member, couldn't seem to get it to
work on a DC, though I didn't try hard ;-)

>
>
>
>
> >> 2.) This page justs list a bunch of accounts without
> >>      explaining why it should be a requirement. Nor it
> >>      says that it won't work without.
> >
> > You could say the same about the Samba wiki page.
>
> Yes I know, but I haven't rewritten the Profiles page yet.
>
> When I rewrote the "User Home Folder" page, I omitted SYSTEM in the
> list of Windows ACLs (and of course it was never part of the POSIX
> ACLs in this guide). However, I saw no reason to explain things that
> I don't tell the user to set and what not necessary. If you follow
> the guide, you get everything you need for a fully working share.

I think 'SYSTEM' should be mentioned, if only to say why you don't need
it.

>
> If you argue that the SYSTEM account must exist in the ACLs of a
> profile share's file system, then the following shared folder would
> fail, because only root and "Domain Users" are part of the ACLs:
>
> $ ls -la /srv/samba/profiles -d
> drwxr-s--- 21 root "Domain Users" 4096 15. Feb
> 19:10 /srv/samba/profiles
>

It appears you don't have any ACLs set there, just Unix permissions, I
have:

ls -lad /home/SAMDOM/profiles/
drwxrwx--T+ 2 root root 4096 Nov 28 12:12 /home/SAMDOM/profiles/


> That's why it is part of the Sysvol share's file system ACLs. To be
> consistent. However, this is only to be _consistent_. It has nothing
> to do with being _compatible in this case.

Not going to argue over a word, but we should be consistent about being
consistent ;-)

Rowland



--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Windows ACL clarification for Roaming Profiles share

Samba - General mailing list
Am 18.02.2017 um 12:27 schrieb Rowland Penny via samba:
> You can 'map' SYSTEM on a domain member, couldn't seem to get it to
> work on a DC, though I didn't try hard ;-)

But mapping is applied when a user connects to a resource. Then the
connecting Samba account is mapped to a local unix account and the file
system is accessed using the Unix account's permissions. It does not
work the other way around. You can't map the "local" (built-in) SYSTEM
to a local/domain user and then "su - SYSTEM".



>> When I rewrote the "User Home Folder" page, I omitted SYSTEM in the
>> list of Windows ACLs (and of course it was never part of the POSIX
>> ACLs in this guide). However, I saw no reason to explain things that
>> I don't tell the user to set and what not necessary. If you follow
>> the guide, you get everything you need for a fully working share.
>
> I think 'SYSTEM' should be mentioned, if only to say why you don't need
> it.

I can write a short page describing what the SYSTEM account is used for
on Windows and why it does not apply to Samba on Unix. And we can link
it from the pages talking about setting Windows ACLs.



Regards,
Marc

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Windows ACL clarification for Roaming Profiles share

Samba - General mailing list
In reply to this post by Samba - General mailing list
Marc Muehlfeld via samba wrote:
>
> 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 the share is hosting a roaming profile -- what user updates
the profile and what user updates the registry on the remote-roaming
profile?
Is it SYSTEM or the user?

    2nd Q: if you use offline files to allow modifying local content even
though a server is down -- what USER is used to push those changes to the
remote system, or merge remote changes to a local user profile?  (I think
it may be SYSTEM, but can't say for sure).

    There may be some other cases where SYSTEM is used to do I/O --
if you defrag your disk,  you'll see a SYSTEM process showing as
the I/O initiator.  Some shadow copy stuff and backup stuff might need
SYSTEM to perform the I/O... (again, not sure, but...)

    If everything works in your setup...great!  just be aware
MS makes changes w/o telling users so SYSTEM might be used for something
else tomorrow.  I hear you when you say nothing is justifying it.
So... go ahead, ask MS to justify something and let us know how that
goes... ;-)  MS doesn't listen to users these days, or haven't you noticed?

-l

   

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Windows ACL clarification for Roaming Profiles share

Samba - General mailing list
In reply to this post by Samba - General mailing list
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:[hidden email]]
> Verzonden: zaterdag 18 februari 2017 1:15
> Aan: L.P.H. van Belle; [hidden email]
> 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



--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Windows ACL clarification for Roaming Profiles share

Samba - General mailing list
On Mon, 20 Feb 2017 09:08:56 +0100
L.P.H. van Belle <[hidden email]> wrote:


> 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.

Not as far as I am concerned.
 
> Posted problems like this long ago already.

Yes, but have you reported a bug ?
 
>
> 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.
>

Which was what I was trying to get across, we English have a saying:

When in Rome, do as the Romans do.

Which could be re-written as:

When using something that emulates a Windows product, do as Windows
expects.

Just because 'SYSTEM' does nothing on Linux, doesn't mean you
shouldn't add its ACE to profiles.

Rowland
 

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Windows ACL clarification for Roaming Profiles share

Samba - General mailing list
Hai, see below.


> -----Oorspronkelijk bericht-----
> Van: samba [mailto:[hidden email]] Namens Rowland Penny via
> samba
> Verzonden: maandag 20 februari 2017 10:41
> Aan: [hidden email]
> Onderwerp: Re: [Samba] Windows ACL clarification for Roaming Profiles
> share
>
> On Mon, 20 Feb 2017 09:08:56 +0100
> L.P.H. van Belle <[hidden email]> wrote:
>
>
> > 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.
>
> Not as far as I am concerned.
>
> > Posted problems like this long ago already.
>
> Yes, but have you reported a bug ?
There are multiple reports about this or related with this.

Which i think are related bugs to missing/incorrect use of SYSTEM ( and LOCAL and NETWORK )
https://bugzilla.samba.org/show_bug.cgi?id=12164 
https://bugzilla.samba.org/show_bug.cgi?id=12410
https://bugzilla.samba.org/show_bug.cgi?id=12257
https://bugzilla.samba.org/show_bug.cgi?id=11677
https://bugzilla.samba.org/show_bug.cgi?id=3350 
https://bugzilla.samba.org/show_bug.cgi?id=12243 
a snap, there are more related to this problem.
There are more, bit im always haveing a hard time finding them. :-(

Its really not a small thing here, lots uses the 3 sids (S-1-5-18 -19 -20)
These all work on the member servers ( tested 4.5.3 and 4.5.5 )
wbinfo -s S-1-5-18
NT AUTHORITY\SYSTEM 5
wbinfo -s S-1-5-19
NT AUTHORITY\Local Service 5
wbinfo -s S-1-5-20
NT AUTHORITY\Network Service 5
wbinfo -s S-1-5-21

but these all also DONT work on a DC. ( 4.5.3 tested )
All report..
failed to call wbcLookupSid: WBC_ERR_DOMAIN_NOT_FOUND
Could not lookup sid S-1-5-18
Could not lookup sid S-1-5-19
Could not lookup sid S-1-5-20

If sort of "made a workaround" by abusing :
acl_xattr:ignore system acls = yes

which works for me, but its nice to get above fixed.

>
> >
> > 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.
> >
>
> Which was what I was trying to get across, we English have a saying:
>
> When in Rome, do as the Romans do.
>
> Which could be re-written as:
>
> When using something that emulates a Windows product, do as Windows
> expects.
>
> Just because 'SYSTEM' does nothing on Linux, doesn't mean you
> shouldn't add its ACE to profiles.

Totaly agree.

>
> Rowland
>
>
Greetz,

Louis


--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Loading...