samba - May 2017 - Problems with samba and profile syncing from various windows versions

Hi!

I've got an old samba installation, now thanks to you all - successfully
upgraded to ubuntu 16.04. Samba is the packaged version
4.3.11+dfsg-0ubuntu0.16.04.6.

The problem I have is that for some users their profiles do not sync
properly. They seem to upload onto the server, and then at the next logon
some files that were deleted by the user come back. It is more per user
basis or per workstation basis - this is hard to diagnose right now. For
most of the users everything works very fine. The problem can pop up on a
windows 10 workstation, 7 or even an XP (yes, we have some crap like this
still running).

I cannot seem to find anything relevant in the logs. My smb.conf goes
below. The profiles go into [profiles].

Question: How can I analyse and diagnose such issue? What should I look at?
Are windows workstations to blame or some setting on the server?

smb.conf:

[global]
workgroup = CUT
realm = CUT
netbios name = CUT
server role = active directory domain controller
dns forwarder = 192.168.0.252
max open files = 57000


full_audit:prefix = %u|%I|%m|%S
full_audit:success = mkdir rename unlink rmdir pwrite
full_audit:failure = none
full_audit:facility = local7
full_audit:priority = NOTICE

log level = 1
tls enabled  = yes
tls keyfile  = /var/lib/samba/private/tls/key.pem
tls certfile = /var/lib/samba/private/tls/cert.pem
tls cafile   = /var/lib/samba/private/tls/ca.pem
tls verify peer = no_check
ldap server require strong auth = no

winbind enum groups = yes
winbind enum users = yes


[netlogon]
  path = /var/local/samba/var/lib/samba/netlogon
read only = No
guest ok = yes

[sysvol]
path = /var/lib/samba/sysvol
read only = No

[profiles]
 path = /var/local/samba/var/lib/samba/profiles
 read only = no
 browseable = no
 create mask = 0600
 directory mask = 0700
 profile acls = yes
        vfs objects = full_audit

[and then come lot's of different shares]

On Wed, 3 May 2017 09:15:30 +0200
Jakub Kulesza via samba <samba at lists.samba.org> wrote:
> 
> [profiles]
>  path = /var/local/samba/var/lib/samba/profiles
>  read only = no
>  browseable = no
>  create mask = 0600
>  directory mask = 0700
>  profile acls = yes
>         vfs objects = full_audit
> 
Sorry, but this doesn't work on a Samba AD DC, you will have to use
windows ACL's, see here:

https://wiki.samba.org/index.php/Roaming_Windows_User_Profiles

Rowland

Hai, 

I just saw the new site for the profiles :-) didnt notice that. 
Looks nice. 

Now i saw the link to : 
https://wiki.samba.org/index.php/The_SYSTEM_Account 
This is very very disturbing.... 

Especially these lines: 
"The SYSTEM account is never sent to a remote host to authenticate and for
this reason never used to access a remote file system"

"For this reasons, you can omit the SYSTEM account in file system ACLs on
Samba shares."
Now this is not ok in my believe. 

And the funny part, first reference link. 
https://support.microsoft.com/en-us/help/120929/how-the-system-account-is-used-in-windows
Which states : 

. On the other hand, the system account does show up on an NTFS volume in File
Manager in the Permissions portion of the Security menu.
By default, the system account is granted full control to all files on an NTFS
volume.
And ...    
>>>    The system account's permissions can be removed from a file
but it is not recommended.
The last line on the wiki.
>  For this reasons, you can omit the SYSTEM account in file system ACLs on
Samba shares.
Now when it goes wrong if you remove SYSTEM from the samba shares... 

Example 1: 
Try to do the following. 
Add the Administrators security group to roaming user profiles in Computer
Configuration \ Administrative Templates \ System \ User Profiles

This happens. 
 When a new roaming profile directory is created, Windows disables permission
inheritance and grants SYSTEM and the profile’s user account full control.
.... Grants who... Yes SYSTEM! 

Example 2
If you see something like: 
The Application Event Viewer indicates errors that the MSI package installation
failed with an error ‘Package source not located’.

1)	On the target computer, log in as an administrator.
2)	Schedule an AT job for 1 minute ahead of the current time to launch a command
prompt as NT Authority\System:
a.	C:\> at 1:00pm /interactive cmd.exe
3)	After the command prompt window to appear, you will have "NT
Authority\System access."
4)	Attempt to list the contents of the share using the UNC path:
a.	C:\> dir \\server\share   - You should receive a directory listing of the
files on the share

Remove system and this wont work. 

Example 3. 
A program that runs under the NT Authority\System, but the software is on a
samba share.
For example, software updaters with packages. My zarafa updater runs as user
SYSTEM.
My packages are on the samba shares.. ...


Example 4.
Last one, lunch time.
Install a virusscanner, ( which mostly runs as system ) and set it to scan you
network shares.


Anyone else comments on above. I dont know everything so shoot me if im wrong
here.
But removing user SYSTEM from the shares is really bad advice,
Yes, its an option, but NOT for sysvol and profiles or shares where you deploy
files.


Greetz, 

Louis

Hi Louis,

it seems we are both right:

I talked with Volker about the necessity of SYSTEM in ACLs on a Samba 
server: From Samba side, SYSTEM is not required in ACLs. It's important 
that the domain user or machine account, that is used to authenticate to 
the share, is able to access the content.

SYSTEM is a local security principal on the client and not sent over the 
network to authenticate. When a local service on a domain member uses 
SYSTEM to access a domain network share, it authenticates as 
computername$. To access the content, it is necessary that this machine 
account is allowed to access the content. For example, because it is 
listed explicitely, as member of a group, or allowed by a general 
principal, such as "Authenticated Users". If the local SYSTEM account 
accesses the server using the computername$ account, the SYSTEM account 
in the ACLs is not used on the server to validate if computername$ is 
allowed to access the content - computername$ must somehow have access.

On the other side, there are be some Windows services that may require 
that some ACLs are present on the remote server. For example, a service 
might not work if the ACLs on the remote server do not contain the 
SYSTEM account - even if it is not used on the server to access the 
content itself. This is what you discovered.

I will update the docs accordingly.

Regards,
Marc




Am 03.05.2017 um 12:22 schrieb L.P.H. van Belle via
samba:
> Hai,
> 
> I just saw the new site for the profiles :-) didnt notice that.
> Looks nice.
> 
> Now i saw the link to :
> https://wiki.samba.org/index.php/The_SYSTEM_Account
> This is very very disturbing....
> 
> Especially these lines:
> "The SYSTEM account is never sent to a remote host to authenticate and
for this reason never used to access a remote file system"
> 
> "For this reasons, you can omit the SYSTEM account in file system ACLs
on Samba shares."
> Now this is not ok in my believe.
> 
> And the funny part, first reference link.
>
https://support.microsoft.com/en-us/help/120929/how-the-system-account-is-used-in-windows
> Which states :
> 
> . On the other hand, the system account does show up on an NTFS volume in
File Manager in the Permissions portion of the Security menu.
> By default, the system account is granted full control to all files on an
NTFS volume.
> And ...
>>>>     The system account's permissions can be removed from a
file but it is not recommended.
> 
> The last line on the wiki.
>>   For this reasons, you can omit the SYSTEM account in file system ACLs
on Samba shares.
> 
> Now when it goes wrong if you remove SYSTEM from the samba shares...
> 
> Example 1:
> Try to do the following.
> Add the Administrators security group to roaming user profiles in Computer
Configuration \ Administrative Templates \ System \ User Profiles
> 
> This happens.
>   When a new roaming profile directory is created, Windows disables
permission inheritance and grants SYSTEM and the profile’s user account full
control.
> .... Grants who... Yes SYSTEM!
> 
> Example 2
> If you see something like:
> The Application Event Viewer indicates errors that the MSI package
installation failed with an error ‘Package source not located’.
> 
> 1)	On the target computer, log in as an administrator.
> 2)	Schedule an AT job for 1 minute ahead of the current time to launch a
command prompt as NT Authority\System:
> a.	C:\> at 1:00pm /interactive cmd.exe
> 3)	After the command prompt window to appear, you will have "NT
Authority\System access."
> 4)	Attempt to list the contents of the share using the UNC path:
> a.	C:\> dir \\server\share   - You should receive a directory listing of
the files on the share
> 
> Remove system and this wont work.
> 
> Example 3.
> A program that runs under the NT Authority\System, but the software is on a
samba share.
> For example, software updaters with packages. My zarafa updater runs as
user SYSTEM.
> My packages are on the samba shares.. ...
> 
> 
> Example 4.
> Last one, lunch time.
> Install a virusscanner, ( which mostly runs as system ) and set it to scan
you network shares.
> 
> 
> Anyone else comments on above. I dont know everything so shoot me if im
wrong here.
> But removing user SYSTEM from the shares is really bad advice,
> Yes, its an option, but NOT for sysvol and profiles or shares where you
deploy files.
> 
> 
> Greetz,
> 
> Louis
> 
>

Hai Marc, 

Great to have that clear now.

Now, ... Sorry about this one but.. Ping;.... ;-) 
https://bugzilla.samba.org/show_bug.cgi?id=12257   Windows 10 unable to update
group policy.
https://bugzilla.samba.org/show_bug.cgi?id=12263   unable to edit / create GPO  

Fixed when you apply system on the sysvol folder.  ;-) 
2 bugs less ;-) 


Greetz, 

Louis
> -----Oorspronkelijk bericht-----
> Van: Marc Muehlfeld [mailto:mmuehlfeld at samba.org] 
> Verzonden: woensdag 3 mei 2017 15:44
> Aan: L.P.H. van Belle; samba
> Onderwerp: Re: [Samba] Samba-wiki info about profiles and 
> SYSTEM account.
> 
> Hi Louis,
> 
> it seems we are both right:
> 
> I talked with Volker about the necessity of SYSTEM in ACLs on a Samba
> server: From Samba side, SYSTEM is not required in ACLs. It's 
> important that the domain user or machine account, that is 
> used to authenticate to the share, is able to access the content.
> 
> SYSTEM is a local security principal on the client and not 
> sent over the network to authenticate. When a local service 
> on a domain member uses SYSTEM to access a domain network 
> share, it authenticates as computername$. To access the 
> content, it is necessary that this machine account is allowed 
> to access the content. For example, because it is listed 
> explicitely, as member of a group, or allowed by a general 
> principal, such as "Authenticated Users". If the local SYSTEM 
> account accesses the server using the computername$ account, 
> the SYSTEM account in the ACLs is not used on the server to 
> validate if computername$ is allowed to access the content - 
> computername$ must somehow have access.
> 
> On the other side, there are be some Windows services that 
> may require that some ACLs are present on the remote server. 
> For example, a service might not work if the ACLs on the 
> remote server do not contain the SYSTEM account - even if it 
> is not used on the server to access the content itself. This 
> is what you discovered.
> 
> I will update the docs accordingly.
> 
> Regards,
> Marc
> 
> 
> 
> 
> Am 03.05.2017 um 12:22 schrieb L.P.H. van Belle via samba:
> > Hai,
> > 
> > I just saw the new site for the profiles :-) didnt notice that.
> > Looks nice.
> > 
> > Now i saw the link to :
> > https://wiki.samba.org/index.php/The_SYSTEM_Account
> > This is very very disturbing....
> > 
> > Especially these lines:
> > "The SYSTEM account is never sent to a remote host to 
> authenticate and for this reason never used to access a 
> remote file system"
> > 
> > "For this reasons, you can omit the SYSTEM account in file 
> system ACLs on Samba shares."
> > Now this is not ok in my believe.
> > 
> > And the funny part, first reference link.
> > 
> https://support.microsoft.com/en-us/help/120929/how-the-system-account
> > -is-used-in-windows
> > Which states :
> > 
> > . On the other hand, the system account does show up on an 
> NTFS volume in File Manager in the Permissions portion of the 
> Security menu.
> > By default, the system account is granted full control to 
> all files on an NTFS volume.
> > And ...
> >>>>     The system account's permissions can be removed
from
> a file but it is not recommended.
> > 
> > The last line on the wiki.
> >>   For this reasons, you can omit the SYSTEM account in 
> file system ACLs on Samba shares.
> > 
> > Now when it goes wrong if you remove SYSTEM from the samba shares...
> > 
> > Example 1:
> > Try to do the following.
> > Add the Administrators security group to roaming user profiles in 
> > Computer Configuration \ Administrative Templates \ System \ User 
> > Profiles
> > 
> > This happens.
> >   When a new roaming profile directory is created, Windows 
> disables permission inheritance and grants SYSTEM and the 
> profile’s user account full control.
> > .... Grants who... Yes SYSTEM!
> > 
> > Example 2
> > If you see something like:
> > The Application Event Viewer indicates errors that the MSI 
> package installation failed with an error ‘Package source not 
> located’.
> > 
> > 1)	On the target computer, log in as an administrator.
> > 2)	Schedule an AT job for 1 minute ahead of the current 
> time to launch a command prompt as NT Authority\System:
> > a.	C:\> at 1:00pm /interactive cmd.exe
> > 3)	After the command prompt window to appear, you will 
> have "NT Authority\System access."
> > 4)	Attempt to list the contents of the share using the UNC path:
> > a.	C:\> dir \\server\share   - You should receive a 
> directory listing of the files on the share
> > 
> > Remove system and this wont work.
> > 
> > Example 3.
> > A program that runs under the NT Authority\System, but the 
> software is on a samba share.
> > For example, software updaters with packages. My zarafa 
> updater runs as user SYSTEM.
> > My packages are on the samba shares.. ...
> > 
> > 
> > Example 4.
> > Last one, lunch time.
> > Install a virusscanner, ( which mostly runs as system ) and 
> set it to scan you network shares.
> > 
> > 
> > Anyone else comments on above. I dont know everything so 
> shoot me if im wrong here.
> > But removing user SYSTEM from the shares is really bad advice, Yes, 
> > its an option, but NOT for sysvol and profiles or shares 
> where you deploy files.
> > 
> > 
> > Greetz,
> > 
> > Louis
> > 
> > 
> 
>

Thanks for pointing this out.

I have read that again, now my profiles do not have "vfs objects
full_audit" and disabled the csc policy. I have verified that I have set up
my profiles share properly and that it has all the right entitlements. I
have reset the entitlements for the users that have issues (as
Administrator right click on the folder and do the dance there with
Windows). We'll see tomorrow.

Is "profile acls" required anymore on Samba 4.3? What effect will it
have
on Windows 10?


2017-05-03 9:52 GMT+02:00 Rowland Penny <rpenny at samba.org>:
> On Wed, 3 May 2017 09:15:30 +0200
> Jakub Kulesza via samba <samba at lists.samba.org> wrote:
>
> >
> > [profiles]
> >  path = /var/local/samba/var/lib/samba/profiles
> >  read only = no
> >  browseable = no
> >  create mask = 0600
> >  directory mask = 0700
> >  profile acls = yes
> >         vfs objects = full_audit
> >
>
> Sorry, but this doesn't work on a Samba AD DC, you will have to use
> windows ACL's, see here:
>
> https://wiki.samba.org/index.php/Roaming_Windows_User_Profiles
>
> Rowland
>
>
>

Small sidenote in regards to the wiki, there is also an V6 since windows 
10 aniversary.

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


Am 03.05.2017 um 09:52 schrieb Rowland Penny via samba:
> On Wed, 3 May 2017 09:15:30 +0200
> Jakub Kulesza via samba <samba at lists.samba.org> wrote:
>
>> [profiles]
>>   path = /var/local/samba/var/lib/samba/profiles
>>   read only = no
>>   browseable = no
>>   create mask = 0600
>>   directory mask = 0700
>>   profile acls = yes
>>          vfs objects = full_audit
>>
> Sorry, but this doesn't work on a Samba AD DC, you will have to use
> windows ACL's, see here:
>
> https://wiki.samba.org/index.php/Roaming_Windows_User_Profiles
>
> Rowland
>
>
>