Hai,
After lots of testing and checking today im must concluded that achim and
mathias are right.
There are "BUILDIN\" security groups which make some GPOs are going
wrong.
Also, im getting errors again with sysvolcheck. .. i was in the understanding
this was resolved.. but im but off with all info, very buzy at the office atm.
samba-tool ntacl sysvolcheck
ERROR(<class 'samba.provision.ProvisioningError'>): uncaught
exception - ProvisioningError: DB ACL on GPO directory
/home/samba/sysvol/domain/Policies/{EAF212FE-4718-4693-BD18-6B4FC8A0513A}
O:LAG:DAD:PAR(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED)
does not match expected value
O:DAG:DAD:PAR(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED)
from GPO object
File "/usr/lib/python2.7/dist-packages/samba/netcmd/__init__.py",
line 175, in _run
return self.run(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/samba/netcmd/ntacl.py", line
270, in run
lp)
File "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py",
line 1732, in checksysvolacl
direct_db_access)
File "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py",
line 1683, in check_gpos_acl
domainsid, direct_db_access)
File "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py",
line 1630, in check_dir_acl
raise ProvisioningError('%s ACL on GPO directory %s %s does not match
expected value %s from GPO object' % (acl_type(direct_db_access), path,
fsacl_sddl, acl))
running debian samba 4.4.3 jessie.
I was running without problems with 4.2.9 and 4.3.6.
I can tell about the higher versions after the badlock bug i've updated to
4.4.3 on all machines.
Rowland, can you make a custom policy, apply a own defined group the security
filter. ( any random user policy )
Run gpupdate /force
Run gpresult /h:Path/Yourresult.html
Now check the result.html
Im getting lots of..
{CLID} domain.test.tld/Office/Locaiotn Not accessable
And these where working fine for more then a year now.
Greetz,
Louis
> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens Rowland penny
> Verzonden: maandag 27 juni 2016 14:08
> Aan: samba at lists.samba.org
> Onderwerp: Re: [Samba] Rights issue on GPO
>
> On 26/06/16 12:43, Achim Gottinger wrote:
> > Created an feature request
> >
> > "add resolving for well known security principals"
> >
> > https://bugzilla.samba.org/show_bug.cgi?id=11997
> >
> > Am 25.06.2016 um 12:35 schrieb Achim Gottinger:
> >>
> >>
> >> Am 25.06.2016 um 02:21 schrieb Achim Gottinger:
> >>>
> >>>
> >>> Am 24.06.2016 um 23:16 schrieb Achim Gottinger:
> >>>>
> >>>>
> >>>> Am 24.06.2016 um 22:57 schrieb Rowland penny:
> >>>>> On 24/06/16 21:35, Achim Gottinger wrote:
> >>>>>>
> >>>>>>
> >>>>>> Am 24.06.2016 um 21:24 schrieb Rowland penny:
> >>>>>>> On 24/06/16 19:47, lingpanda101 at gmail.com
wrote:
> >>>>>>>> On 6/24/2016 11:40 AM, mathias dufresne
wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> 2016-06-24 15:24 GMT+02:00
lingpanda101 at gmail.com
> >>>>>>>>> <mailto:lingpanda101 at
gmail.com> <lingpanda101 at gmail.com
> >>>>>>>>> <mailto:lingpanda101 at
gmail.com>>:
> >>>>>>>>>
> >>>>>>>>> On 6/22/2016 12:21 PM, mathias
dufresne wrote:
> >>>>>>>>>
> >>>>>>>>> 2016-06-22 16:37 GMT+02:00
L.P.H. van Belle
> >>>>>>>>> <belle at bazuin.nl
> >>>>>>>>> <mailto:belle at
bazuin.nl>>:
> >>>>>>>>>
> >>>>>>>>> @Mathias,
> >>>>>>>>>
> >>>>>>>>> Pretty strange then,
running some years like this
> >>>>>>>>> without
> >>>>>>>>> any problem.
> >>>>>>>>> Yes we had few problems
with "rights" in sysvol,
> >>>>>>>>> but i
> >>>>>>>>> fixed this all
> >>>>>>>>> outside linux, and with
that i mean. Changed
> >>>>>>>>> rights from
> >>>>>>>>> within windows or
> >>>>>>>>> added registry changes or
patches, or a local
> >>>>>>>>> clean up of
> >>>>>>>>> the policies.
> >>>>>>>>>
> >>>>>>>>> At the install of my DC2 i
also synced the
> >>>>>>>>> idmap.ldb, and
> >>>>>>>>> then a
> >>>>>>>>> net idmap flush on both
servers to make my both
> >>>>>>>>> dc's in sync.
> >>>>>>>>> And i keep it in sync with
my rsync/unison setup.
> >>>>>>>>>
> >>>>>>>>> All new added, but
i'll keep an eye also in this
> >>>>>>>>> and i'll
> >>>>>>>>> recheck my logs.
> >>>>>>>>> But i dont think i'll
find anything here.
> >>>>>>>>> I'll keep notice on
your "workaround".
> >>>>>>>>>
> >>>>>>>>> Which backend are you
using matias?
> >>>>>>>>> Mine : (idmap config
NTDOMAIN : backend = ad)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Gr.
> >>>>>>>>>
> >>>>>>>>> Louis
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> OK you keep idmap.ldb synched,
that's what I missed
> >>>>>>>>> until few
> >>>>>>>>> days and was
> >>>>>>>>> the reason that is was not
working.
> >>>>>>>>> Our choice to give each and
users and groups into AD
> >>>>>>>>> some xID
> >>>>>>>>> is only to
> >>>>>>>>> avoid usage of mapping. I
expect the synchronization of
> >>>>>>>>> idmap.ldb (if done
> >>>>>>>>> often enough) would be
sufficient. But I don't always
> >>>>>>>>> like
> >>>>>>>>> magic : )
> >>>>>>>>>
> >>>>>>>>> Thank you for precisions !
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Cheers all
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -----Oorspronkelijk
bericht-----
> >>>>>>>>> Van: samba
[mailto:samba-bounces at lists.samba.org
> >>>>>>>>> <mailto:samba-bounces at
lists.samba.org>] Namens mathias
> >>>>>>>>>
> >>>>>>>>> dufresne
> >>>>>>>>>
> >>>>>>>>> Verzonden: woensdag 22
juni 2016 15:31
> >>>>>>>>> Aan: lingpanda101 at
gmail.com
> >>>>>>>>> <mailto:lingpanda101 at
gmail.com>
> >>>>>>>>> CC: samba
> >>>>>>>>> Onderwerp: Re: [Samba]
Rights issue on GPO
> >>>>>>>>>
> >>>>>>>>> @LPH van Belle
> >>>>>>>>> I did tried (and still
use) "acl_xattr:ignore
> >>>>>>>>> system
> >>>>>>>>> acls = yes" as
shown
> >>>>>>>>> on the first mail of
that thread. And even
> >>>>>>>>> using that
> >>>>>>>>> rights errors on
> >>>>>>>>>
> >>>>>>>>> GPO
> >>>>>>>>>
> >>>>>>>>> files _are_ an issue.
Otherwise that thread
> >>>>>>>>> won't have
> >>>>>>>>> been opened of
> >>>>>>>>> course : )
> >>>>>>>>>
> >>>>>>>>> Regarding how we
decided to workaround almost
> >>>>>>>>> definitively with that
was
> >>>>>>>>> to
> >>>>>>>>> give every users and
groups in AD some xID,
> >>>>>>>>> also those
> >>>>>>>>> in CN=Builtin and
> >>>>>>>>> CN=Users. We also
cleaned our idmap.ldb to
> >>>>>>>>> keep inside
> >>>>>>>>> only special users
> >>>>>>>>> /
> >>>>>>>>> groups (as "local
system" / S-1-5-18, "guests" /
> >>>>>>>>> S-1-5-32-546...).
> >>>>>>>>> We also add some rsync
to keep idmap.ldb
> >>>>>>>>> synchronized
> >>>>>>>>> on all our DC, for
> >>>>>>>>> these special items
have same mapped xID in
> >>>>>>>>> case they
> >>>>>>>>> are used (and so
> >>>>>>>>> mapped).
> >>>>>>>>>
> >>>>>>>>> Doing that id mapper
has no reason to define
> >>>>>>>>> by itself
> >>>>>>>>> some xID to users
> >>>>>>>>> and groups contained
into AD as they already
> >>>>>>>>> have some
> >>>>>>>>> xID.
> >>>>>>>>>
> >>>>>>>>> Until now it seems to
work fine...
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> 2016-06-22 15:09
GMT+02:00
> lingpanda101 at gmail.com
> >>>>>>>>> <mailto:lingpanda101 at
gmail.com>
> >>>>>>>>> <lingpanda101 at
gmail.com
> >>>>>>>>> <mailto:lingpanda101 at
gmail.com>>:
> >>>>>>>>>
> >>>>>>>>> On 6/22/2016 8:53
AM, mj wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 06/22/2016
02:44 PM,
> >>>>>>>>> lingpanda101 at gmail.com
> >>>>>>>>> <mailto:lingpanda101 at
gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>> Why is is
when I do a getfacl I do
> >>>>>>>>> not see
> >>>>>>>>> the
mapping of BUILTIN
> >>>>>>>>>
> >>>>>>>>> like
> >>>>>>>>>
> >>>>>>>>> others?
> >>>>>>>>>
> >>>>>>>>> do you have
winbind in
> >>>>>>>>> /etc/nsswitch.conf?
> >>>>>>>>>
> >>>>>>>>> mj
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I also thought
winbind was only necessary on
> >>>>>>>>> member servers.
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> -James
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> 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
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> To unsubscribe from this
list go to the following
> >>>>>>>>> URL and
> >>>>>>>>> read the
> >>>>>>>>> instructions:
> >>>>>>>>>
https://lists.samba.org/mailman/options/samba
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> If I assign every user a UID and
select groups a GID by
> >>>>>>>>> utilizing
> >>>>>>>>> rfc2307 on my DC's. Would I
still benefit from keeping
> >>>>>>>>> idmap.ldb
> >>>>>>>>> synchronized? I'm thinking
XID's are obsolete at that point?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Only users and groups in AD will avoid
id mapper by that
> >>>>>>>>> workaround. But there are others
accounts ("local system",
> >>>>>>>>> "guest", "local
administrator"...) all these accounts exist on
> >>>>>>>>> MS Windows clients, and so they can
all do stuff on Sysvol and
> >>>>>>>>> so they can all go through id mapper.
> >>>>>>>>>
> >>>>>>>>> So no. There no way (for me at least
:) to totally avoid id
> >>>>>>>>> mapper and so you should keep
idmap.ldb synched.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -- -James
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -- To unsubscribe from this
list go to the following
> >>>>>>>>> URL and read the
> >>>>>>>>> instructions:
https://lists.samba.org/mailman/options/samba
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> I'm in the process now of creating a
script to sync idmap.ldb.
> >>>>>>>> Does anyone have one at the moment? Is it
best practice to stop
> >>>>>>>> samba before replacing idmap.ldb on the
additional DC's? My
> >>>>>>>> script will currently watch for any
idmap.ldb changes and
> >>>>>>>> create a hot backup if a change is
detected. It will then send
> >>>>>>>> to the other DC's via rsync. I'm
thinking starting and stopping
> >>>>>>>> samba isn't ideal during production
hours.
> >>>>>>>>
> >>>>>>>
> >>>>>>> If you are running Samba >= 4.2.0 with the
separate 'winbindd'
> >>>>>>> binary, there is no reason to sync idmap.ldb.
Syncing idmap
> >>>>>>> was/is only required if you use
'winbind' that is built into the
> >>>>>>> 'samba' binary.
> >>>>>>>
> >>>>>>> Rowland
> >>>>>>>
> >>>>>>>
> >>>>>> Hello Rowland,
> >>>>>>
> >>>>>> If you take an look on your sysvol rights there
are two still
> >>>>>> unresoved groups SECURITY\Local System and
SECURITY\Autheticated
> >>>>>> Users. These show up with gid's from idmap.ldb
in the acl list
> >>>>>> and therefore can not be mapped during rsync. So
at least these
> >>>>>> two groups need idntical mapping on all dc's.
It is however not
> >>>>>> neccessary to keep idmap in sync as long as no
ther security
> >>>>>> groups are used.
> >>>>>>
> >>>>>> achim~
> >>>>>>
> >>>>>
> >>>>> Yes I know, but each DC knows who they are and as they
are members
> >>>>> of the 'SECURITY' domain, they aren't
mapped to the DOMAIN or
> >>>>> BUILTIN.
> >>>>>
> >>>>> Rowland
> >>>>>
> >>>>>
> >>>> If the gid used for "Authenticated Users" on the
source server
> >>>> (dc1) ist used for some "random group" on the
target server (dc2),
> >>>> the read right on sysvol for authenticated users will
instead be
> >>>> given to "random group". This can result in
users not a member of
> >>>> "random group" will not be able to access
content on sysvol.
> >>>> Therefore it is mandatory that these security groups are
mapped to
> >>>> the same gid on all dc's the sysvol conted is
replicated.
> >>>>
> >>> This was an issue i ran into back on samba 4.0/4.1. Mapping
BUILTIN
> >>> in 4.2 has no impact but I assume the ACL's are read from
the
> >>> security.NTACL xattr so "Authenticated Users" should
always have
> >>> access because the xattr stores SID's and not the
xid's. xattrs
> >>> should be replicated with rsync without any mapping required.
> >> Did an short test if proper posix uid/gid mapping is required for
> >> sysvol to work.
> >> Since vfs_acl_xattr is in use samba is said to keep the posix
acl's
> >> in sync with the acl's stored in the security.NTACL xattr
object.
> >>
(https://www.samba.org/samba/docs/man/manpages/vfs_acl_xattr.8.html)
> >> If i sync from an dc with different mappings in idmap.ldb the
posix
> >> acl's seem to have precedence over the xattr values, so they
can mess
> >> up things in an way that some security groups can gain read or
ever
> >> write rights because of the different mappings.
> >> An easy fix is adding
> >> acl_xattr:ignore system acls = Yes
> >> to the sysvol section in smb.conf. Posix ACL's are now ignored
and
> >> only the ACL's from the xattr are used.
> >>
> >>
> >>
> >
> >
>
>
> OK, I finally got round to installing win10 in a VM on my new computer,
> so I have been able to fully test 'sysvol' on both DCs.
>
> If I run getfacl on sysvol on DC1, I get this:
>
> root at dc1:~# getfacl /usr/local/samba/var/locks/sysvol/
> getfacl: Removing leading '/' from absolute path names
> # file: usr/local/samba/var/locks/sysvol/
> # owner: root
> # group: BUILTIN\134administrators
> # flags: -s-
> user::rwx
> user:root:rwx
> user:BUILTIN\134administrators:rwx
> group::rwx
> group:BUILTIN\134administrators:rwx
> group:BUILTIN\134server\040operators:r-x
> group:3000002:rwx
> group:3000003:r-x
> mask::rwx
> other::---
> default:user::rwx
> default:user:root:rwx
> default:user:BUILTIN\134administrators:rwx
> default:group::---
> default:group:BUILTIN\134administrators:rwx
> default:group:BUILTIN\134server\040operators:r-x
> default:group:3000002:rwx
> default:group:3000003:r-x
> default:mask::rwx
> default:other::---
>
> If run it on DC2, I get this:
>
> root at dc2:~# getfacl /usr/local/samba/var/locks/sysvol/
> getfacl: Removing leading '/' from absolute path names
> # file: usr/local/samba/var/locks/sysvol/
> # owner: root
> # group: BUILTIN\134administrators
> # flags: -s-
> user::rwx
> user:root:rwx
> user:BUILTIN\134administrators:rwx
> user:BUILTIN\134server\040operators:r-x
> user:3000014:r-x
> user:3000030:rwx
> group::rwx
> group:BUILTIN\134administrators:rwx
> group:BUILTIN\134server\040operators:r-x
> group:3000014:r-x
> group:3000030:rwx
> mask::rwx
> other::---
> default:user::rwx
> default:user:root:rwx
> default:user:BUILTIN\134administrators:rwx
> default:user:BUILTIN\134server\040operators:r-x
> default:user:3000014:r-x
> default:user:3000030:rwx
> default:group::---
> default:group:BUILTIN\134administrators:rwx
> default:group:BUILTIN\134server\040operators:r-x
> default:group:3000014:r-x
> default:group:3000030:rwx
> default:mask::rwx
> default:other::---
>
> As you can see, each DC shows numbers for two groups:
>
> On DC1:
> group:3000002:rwx
> group:3000003:r-x
>
> The first is for the SID 'CN=S-1-5-18' , this is 'Local
System', the
> second is for the SID 'CN=S-1-5-11', this is 'Authenticated
Users'
>
> On DC2:
> group:3000014:r-x
> group:3000030:rwx
>
> The first is for the SID 'CN=S-1-5-11' this is 'Authenticated
Users',
> the second is for the SID 'CN=S-1-5-18' , this is 'Local
System'
>
> So, as far as I can see, the owners of 'sysvol' are:
>
> On DC1:
> Administrators
> Server Operators
> Local System
> Authenticated Users
>
> On DC2:
> Administrators
> Server Operators
> Authenticated Users
> Local System
>
> So, from the Unix point of view, 'sysvol' belongs to the correct
> users/groups, but what about windows ?
>
> If I navigate to each DC on win10, select the 'sysvol' share and
> right-click it, then select the security tab, I find this:
>
> Authenticated Users
> SYSTEM
> Administrators
> Server Operators
>
> The same as on the DCs.
>
> I do not 'sync' idmap.ldb and the DCs are both running 4.4.3
>
> Bearing in mind the above, why are people still syncing 'idmap.ldb'
if
> they are using the separate 'winbindd' binary ??
>
> The only slight 'problem' that I can see, getfacl seems to return
> different results depending on which DC it is run on, the same basic
> result, but on one it is a user and on the other it is a group.
>
> Rowland
>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/mailman/options/samba
On 27/06/16 13:26, L.P.H. van Belle wrote:> Hai, > > > After lots of testing and checking today im must concluded that achim and mathias are right. > There are "BUILDIN\" security groups which make some GPOs are going wrong. > > Also, im getting errors again with sysvolcheck. .. i was in the understanding this was resolved.. but im but off with all info, very buzy at the office atm. > > samba-tool ntacl sysvolcheck > ERROR(<class 'samba.provision.ProvisioningError'>): uncaught exception - ProvisioningError: DB ACL on GPO directory /home/samba/sysvol/domain/Policies/{EAF212FE-4718-4693-BD18-6B4FC8A0513A} O:LAG:DAD:PAR(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED) does not match expected value O:DAG:DAD:PAR(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED) from GPO object > File "/usr/lib/python2.7/dist-packages/samba/netcmd/__init__.py", line 175, in _run > return self.run(*args, **kwargs) > File "/usr/lib/python2.7/dist-packages/samba/netcmd/ntacl.py", line 270, in run > lp) > File "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", line 1732, in checksysvolacl > direct_db_access) > File "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", line 1683, in check_gpos_acl > domainsid, direct_db_access) > File "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", line 1630, in check_dir_acl > raise ProvisioningError('%s ACL on GPO directory %s %s does not match expected value %s from GPO object' % (acl_type(direct_db_access), path, fsacl_sddl, acl)) > > running debian samba 4.4.3 jessie. > I was running without problems with 4.2.9 and 4.3.6. > I can tell about the higher versions after the badlock bug i've updated to 4.4.3 on all machines. > > Rowland, can you make a custom policy, apply a own defined group the security filter. ( any random user policy ) > Run gpupdate /force > Run gpresult /h:Path/Yourresult.html > Now check the result.html > > Im getting lots of.. > {CLID} domain.test.tld/Office/Locaiotn Not accessable > > And these where working fine for more then a year now. > > Greetz, > > Louis > > >> -----Oorspronkelijk bericht----- >> Van: samba [mailto:samba-bounces at lists.samba.org] Namens Rowland penny >> Verzonden: maandag 27 juni 2016 14:08 >> Aan: samba at lists.samba.org >> Onderwerp: Re: [Samba] Rights issue on GPO >> >> On 26/06/16 12:43, Achim Gottinger wrote: >>> Created an feature request >>> >>> "add resolving for well known security principals" >>> >>> https://bugzilla.samba.org/show_bug.cgi?id=11997 >>> >>> Am 25.06.2016 um 12:35 schrieb Achim Gottinger: >>>> >>>> Am 25.06.2016 um 02:21 schrieb Achim Gottinger: >>>>> >>>>> Am 24.06.2016 um 23:16 schrieb Achim Gottinger: >>>>>> >>>>>> Am 24.06.2016 um 22:57 schrieb Rowland penny: >>>>>>> On 24/06/16 21:35, Achim Gottinger wrote: >>>>>>>> >>>>>>>> Am 24.06.2016 um 21:24 schrieb Rowland penny: >>>>>>>>> On 24/06/16 19:47, lingpanda101 at gmail.com wrote: >>>>>>>>>> On 6/24/2016 11:40 AM, mathias dufresne wrote: >>>>>>>>>>> >>>>>>>>>>> 2016-06-24 15:24 GMT+02:00 lingpanda101 at gmail.com >>>>>>>>>>> <mailto:lingpanda101 at gmail.com> <lingpanda101 at gmail.com >>>>>>>>>>> <mailto:lingpanda101 at gmail.com>>: >>>>>>>>>>> >>>>>>>>>>> On 6/22/2016 12:21 PM, mathias dufresne wrote: >>>>>>>>>>> >>>>>>>>>>> 2016-06-22 16:37 GMT+02:00 L.P.H. van Belle >>>>>>>>>>> <belle at bazuin.nl >>>>>>>>>>> <mailto:belle at bazuin.nl>>: >>>>>>>>>>> >>>>>>>>>>> @Mathias, >>>>>>>>>>> >>>>>>>>>>> Pretty strange then, running some years like this >>>>>>>>>>> without >>>>>>>>>>> any problem. >>>>>>>>>>> Yes we had few problems with "rights" in sysvol, >>>>>>>>>>> but i >>>>>>>>>>> fixed this all >>>>>>>>>>> outside linux, and with that i mean. Changed >>>>>>>>>>> rights from >>>>>>>>>>> within windows or >>>>>>>>>>> added registry changes or patches, or a local >>>>>>>>>>> clean up of >>>>>>>>>>> the policies. >>>>>>>>>>> >>>>>>>>>>> At the install of my DC2 i also synced the >>>>>>>>>>> idmap.ldb, and >>>>>>>>>>> then a >>>>>>>>>>> net idmap flush on both servers to make my both >>>>>>>>>>> dc's in sync. >>>>>>>>>>> And i keep it in sync with my rsync/unison setup. >>>>>>>>>>> >>>>>>>>>>> All new added, but i'll keep an eye also in this >>>>>>>>>>> and i'll >>>>>>>>>>> recheck my logs. >>>>>>>>>>> But i dont think i'll find anything here. >>>>>>>>>>> I'll keep notice on your "workaround". >>>>>>>>>>> >>>>>>>>>>> Which backend are you using matias? >>>>>>>>>>> Mine : (idmap config NTDOMAIN : backend = ad) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Gr. >>>>>>>>>>> >>>>>>>>>>> Louis >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> OK you keep idmap.ldb synched, that's what I missed >>>>>>>>>>> until few >>>>>>>>>>> days and was >>>>>>>>>>> the reason that is was not working. >>>>>>>>>>> Our choice to give each and users and groups into AD >>>>>>>>>>> some xID >>>>>>>>>>> is only to >>>>>>>>>>> avoid usage of mapping. I expect the synchronization of >>>>>>>>>>> idmap.ldb (if done >>>>>>>>>>> often enough) would be sufficient. But I don't always >>>>>>>>>>> like >>>>>>>>>>> magic : ) >>>>>>>>>>> >>>>>>>>>>> Thank you for precisions ! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Cheers all >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Oorspronkelijk bericht----- >>>>>>>>>>> Van: samba [mailto:samba-bounces at lists.samba.org >>>>>>>>>>> <mailto:samba-bounces at lists.samba.org>] Namens mathias >>>>>>>>>>> >>>>>>>>>>> dufresne >>>>>>>>>>> >>>>>>>>>>> Verzonden: woensdag 22 juni 2016 15:31 >>>>>>>>>>> Aan: lingpanda101 at gmail.com >>>>>>>>>>> <mailto:lingpanda101 at gmail.com> >>>>>>>>>>> CC: samba >>>>>>>>>>> Onderwerp: Re: [Samba] Rights issue on GPO >>>>>>>>>>> >>>>>>>>>>> @LPH van Belle >>>>>>>>>>> I did tried (and still use) "acl_xattr:ignore >>>>>>>>>>> system >>>>>>>>>>> acls = yes" as shown >>>>>>>>>>> on the first mail of that thread. And even >>>>>>>>>>> using that >>>>>>>>>>> rights errors on >>>>>>>>>>> >>>>>>>>>>> GPO >>>>>>>>>>> >>>>>>>>>>> files _are_ an issue. Otherwise that thread >>>>>>>>>>> won't have >>>>>>>>>>> been opened of >>>>>>>>>>> course : ) >>>>>>>>>>> >>>>>>>>>>> Regarding how we decided to workaround almost >>>>>>>>>>> definitively with that was >>>>>>>>>>> to >>>>>>>>>>> give every users and groups in AD some xID, >>>>>>>>>>> also those >>>>>>>>>>> in CN=Builtin and >>>>>>>>>>> CN=Users. We also cleaned our idmap.ldb to >>>>>>>>>>> keep inside >>>>>>>>>>> only special users >>>>>>>>>>> / >>>>>>>>>>> groups (as "local system" / S-1-5-18, "guests" / >>>>>>>>>>> S-1-5-32-546...). >>>>>>>>>>> We also add some rsync to keep idmap.ldb >>>>>>>>>>> synchronized >>>>>>>>>>> on all our DC, for >>>>>>>>>>> these special items have same mapped xID in >>>>>>>>>>> case they >>>>>>>>>>> are used (and so >>>>>>>>>>> mapped). >>>>>>>>>>> >>>>>>>>>>> Doing that id mapper has no reason to define >>>>>>>>>>> by itself >>>>>>>>>>> some xID to users >>>>>>>>>>> and groups contained into AD as they already >>>>>>>>>>> have some >>>>>>>>>>> xID. >>>>>>>>>>> >>>>>>>>>>> Until now it seems to work fine... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2016-06-22 15:09 GMT+02:00 >> lingpanda101 at gmail.com >>>>>>>>>>> <mailto:lingpanda101 at gmail.com> >>>>>>>>>>> <lingpanda101 at gmail.com >>>>>>>>>>> <mailto:lingpanda101 at gmail.com>>: >>>>>>>>>>> >>>>>>>>>>> On 6/22/2016 8:53 AM, mj wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 06/22/2016 02:44 PM, >>>>>>>>>>> lingpanda101 at gmail.com >>>>>>>>>>> <mailto:lingpanda101 at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> Why is is when I do a getfacl I do >>>>>>>>>>> not see >>>>>>>>>>> the mapping of BUILTIN >>>>>>>>>>> >>>>>>>>>>> like >>>>>>>>>>> >>>>>>>>>>> others? >>>>>>>>>>> >>>>>>>>>>> do you have winbind in >>>>>>>>>>> /etc/nsswitch.conf? >>>>>>>>>>> >>>>>>>>>>> mj >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I also thought winbind was only necessary on >>>>>>>>>>> member servers. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> -James >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> To unsubscribe from this list go to the following >>>>>>>>>>> URL and >>>>>>>>>>> read the >>>>>>>>>>> instructions: >>>>>>>>>>> https://lists.samba.org/mailman/options/samba >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> If I assign every user a UID and select groups a GID by >>>>>>>>>>> utilizing >>>>>>>>>>> rfc2307 on my DC's. Would I still benefit from keeping >>>>>>>>>>> idmap.ldb >>>>>>>>>>> synchronized? I'm thinking XID's are obsolete at that point? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Only users and groups in AD will avoid id mapper by that >>>>>>>>>>> workaround. But there are others accounts ("local system", >>>>>>>>>>> "guest", "local administrator"...) all these accounts exist on >>>>>>>>>>> MS Windows clients, and so they can all do stuff on Sysvol and >>>>>>>>>>> so they can all go through id mapper. >>>>>>>>>>> >>>>>>>>>>> So no. There no way (for me at least :) to totally avoid id >>>>>>>>>>> mapper and so you should keep idmap.ldb synched. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- -James >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- To unsubscribe from this list go to the following >>>>>>>>>>> URL and read the >>>>>>>>>>> instructions: https://lists.samba.org/mailman/options/samba >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> I'm in the process now of creating a script to sync idmap.ldb. >>>>>>>>>> Does anyone have one at the moment? Is it best practice to stop >>>>>>>>>> samba before replacing idmap.ldb on the additional DC's? My >>>>>>>>>> script will currently watch for any idmap.ldb changes and >>>>>>>>>> create a hot backup if a change is detected. It will then send >>>>>>>>>> to the other DC's via rsync. I'm thinking starting and stopping >>>>>>>>>> samba isn't ideal during production hours. >>>>>>>>>> >>>>>>>>> If you are running Samba >= 4.2.0 with the separate 'winbindd' >>>>>>>>> binary, there is no reason to sync idmap.ldb. Syncing idmap >>>>>>>>> was/is only required if you use 'winbind' that is built into the >>>>>>>>> 'samba' binary. >>>>>>>>> >>>>>>>>> Rowland >>>>>>>>> >>>>>>>>> >>>>>>>> Hello Rowland, >>>>>>>> >>>>>>>> If you take an look on your sysvol rights there are two still >>>>>>>> unresoved groups SECURITY\Local System and SECURITY\Autheticated >>>>>>>> Users. These show up with gid's from idmap.ldb in the acl list >>>>>>>> and therefore can not be mapped during rsync. So at least these >>>>>>>> two groups need idntical mapping on all dc's. It is however not >>>>>>>> neccessary to keep idmap in sync as long as no ther security >>>>>>>> groups are used. >>>>>>>> >>>>>>>> achim~ >>>>>>>> >>>>>>> Yes I know, but each DC knows who they are and as they are members >>>>>>> of the 'SECURITY' domain, they aren't mapped to the DOMAIN or >>>>>>> BUILTIN. >>>>>>> >>>>>>> Rowland >>>>>>> >>>>>>> >>>>>> If the gid used for "Authenticated Users" on the source server >>>>>> (dc1) ist used for some "random group" on the target server (dc2), >>>>>> the read right on sysvol for authenticated users will instead be >>>>>> given to "random group". This can result in users not a member of >>>>>> "random group" will not be able to access content on sysvol. >>>>>> Therefore it is mandatory that these security groups are mapped to >>>>>> the same gid on all dc's the sysvol conted is replicated. >>>>>> >>>>> This was an issue i ran into back on samba 4.0/4.1. Mapping BUILTIN >>>>> in 4.2 has no impact but I assume the ACL's are read from the >>>>> security.NTACL xattr so "Authenticated Users" should always have >>>>> access because the xattr stores SID's and not the xid's. xattrs >>>>> should be replicated with rsync without any mapping required. >>>> Did an short test if proper posix uid/gid mapping is required for >>>> sysvol to work. >>>> Since vfs_acl_xattr is in use samba is said to keep the posix acl's >>>> in sync with the acl's stored in the security.NTACL xattr object. >>>> (https://www.samba.org/samba/docs/man/manpages/vfs_acl_xattr.8.html) >>>> If i sync from an dc with different mappings in idmap.ldb the posix >>>> acl's seem to have precedence over the xattr values, so they can mess >>>> up things in an way that some security groups can gain read or ever >>>> write rights because of the different mappings. >>>> An easy fix is adding >>>> acl_xattr:ignore system acls = Yes >>>> to the sysvol section in smb.conf. Posix ACL's are now ignored and >>>> only the ACL's from the xattr are used. >>>> >>>> >>>> >>> >> >> OK, I finally got round to installing win10 in a VM on my new computer, >> so I have been able to fully test 'sysvol' on both DCs. >> >> If I run getfacl on sysvol on DC1, I get this: >> >> root at dc1:~# getfacl /usr/local/samba/var/locks/sysvol/ >> getfacl: Removing leading '/' from absolute path names >> # file: usr/local/samba/var/locks/sysvol/ >> # owner: root >> # group: BUILTIN\134administrators >> # flags: -s- >> user::rwx >> user:root:rwx >> user:BUILTIN\134administrators:rwx >> group::rwx >> group:BUILTIN\134administrators:rwx >> group:BUILTIN\134server\040operators:r-x >> group:3000002:rwx >> group:3000003:r-x >> mask::rwx >> other::--- >> default:user::rwx >> default:user:root:rwx >> default:user:BUILTIN\134administrators:rwx >> default:group::--- >> default:group:BUILTIN\134administrators:rwx >> default:group:BUILTIN\134server\040operators:r-x >> default:group:3000002:rwx >> default:group:3000003:r-x >> default:mask::rwx >> default:other::--- >> >> If run it on DC2, I get this: >> >> root at dc2:~# getfacl /usr/local/samba/var/locks/sysvol/ >> getfacl: Removing leading '/' from absolute path names >> # file: usr/local/samba/var/locks/sysvol/ >> # owner: root >> # group: BUILTIN\134administrators >> # flags: -s- >> user::rwx >> user:root:rwx >> user:BUILTIN\134administrators:rwx >> user:BUILTIN\134server\040operators:r-x >> user:3000014:r-x >> user:3000030:rwx >> group::rwx >> group:BUILTIN\134administrators:rwx >> group:BUILTIN\134server\040operators:r-x >> group:3000014:r-x >> group:3000030:rwx >> mask::rwx >> other::--- >> default:user::rwx >> default:user:root:rwx >> default:user:BUILTIN\134administrators:rwx >> default:user:BUILTIN\134server\040operators:r-x >> default:user:3000014:r-x >> default:user:3000030:rwx >> default:group::--- >> default:group:BUILTIN\134administrators:rwx >> default:group:BUILTIN\134server\040operators:r-x >> default:group:3000014:r-x >> default:group:3000030:rwx >> default:mask::rwx >> default:other::--- >> >> As you can see, each DC shows numbers for two groups: >> >> On DC1: >> group:3000002:rwx >> group:3000003:r-x >> >> The first is for the SID 'CN=S-1-5-18' , this is 'Local System', the >> second is for the SID 'CN=S-1-5-11', this is 'Authenticated Users' >> >> On DC2: >> group:3000014:r-x >> group:3000030:rwx >> >> The first is for the SID 'CN=S-1-5-11' this is 'Authenticated Users', >> the second is for the SID 'CN=S-1-5-18' , this is 'Local System' >> >> So, as far as I can see, the owners of 'sysvol' are: >> >> On DC1: >> Administrators >> Server Operators >> Local System >> Authenticated Users >> >> On DC2: >> Administrators >> Server Operators >> Authenticated Users >> Local System >> >> So, from the Unix point of view, 'sysvol' belongs to the correct >> users/groups, but what about windows ? >> >> If I navigate to each DC on win10, select the 'sysvol' share and >> right-click it, then select the security tab, I find this: >> >> Authenticated Users >> SYSTEM >> Administrators >> Server Operators >> >> The same as on the DCs. >> >> I do not 'sync' idmap.ldb and the DCs are both running 4.4.3 >> >> Bearing in mind the above, why are people still syncing 'idmap.ldb' if >> they are using the separate 'winbindd' binary ?? >> >> The only slight 'problem' that I can see, getfacl seems to return >> different results depending on which DC it is run on, the same basic >> result, but on one it is a user and on the other it is a group. >> >> Rowland >> >> >> -- >> To unsubscribe from this list go to the following URL and read the >> instructions: https://lists.samba.org/mailman/options/samba > >Two things Louis: if you look very closely at the differences in the 'ERROR' message, you will find the only difference is this: O:LAG:DAD:PAR( against the expected: O:DAG:DAD:PAR( The returned ACL is owned by the 'Local Admins', but it should be owned by 'Domain Admins'. As far as I can see, windows doesn't really care who owns an object, as long as the ACEs are correct and they are! Secondly, more than happy to try adding a GPO, only problem is, I have never really added one, can you point me at a good howto ? Rowland
On 6/27/2016 8:42 AM, Rowland penny wrote:> On 27/06/16 13:26, L.P.H. van Belle wrote: >> Hai, >> >> >> After lots of testing and checking today im must concluded that achim >> and mathias are right. >> There are "BUILDIN\" security groups which make some GPOs are going >> wrong. >> >> Also, im getting errors again with sysvolcheck. .. i was in the >> understanding this was resolved.. but im but off with all info, very >> buzy at the office atm. >> >> samba-tool ntacl sysvolcheck >> ERROR(<class 'samba.provision.ProvisioningError'>): uncaught >> exception - ProvisioningError: DB ACL on GPO directory >> /home/samba/sysvol/domain/Policies/{EAF212FE-4718-4693-BD18-6B4FC8A0513A} >> O:LAG:DAD:PAR(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED) >> does not match expected value >> O:DAG:DAD:PAR(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED) >> from GPO object >> File "/usr/lib/python2.7/dist-packages/samba/netcmd/__init__.py", >> line 175, in _run >> return self.run(*args, **kwargs) >> File "/usr/lib/python2.7/dist-packages/samba/netcmd/ntacl.py", >> line 270, in run >> lp) >> File >> "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", line >> 1732, in checksysvolacl >> direct_db_access) >> File >> "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", line >> 1683, in check_gpos_acl >> domainsid, direct_db_access) >> File >> "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", line >> 1630, in check_dir_acl >> raise ProvisioningError('%s ACL on GPO directory %s %s does not >> match expected value %s from GPO object' % >> (acl_type(direct_db_access), path, fsacl_sddl, acl)) >> >> running debian samba 4.4.3 jessie. >> I was running without problems with 4.2.9 and 4.3.6. >> I can tell about the higher versions after the badlock bug i've >> updated to 4.4.3 on all machines. >> >> Rowland, can you make a custom policy, apply a own defined group the >> security filter. ( any random user policy ) >> Run gpupdate /force >> Run gpresult /h:Path/Yourresult.html >> Now check the result.html >> >> Im getting lots of.. >> {CLID} domain.test.tld/Office/Locaiotn Not accessable >> >> And these where working fine for more then a year now. >> >> Greetz, >> >> Louis >> >> >>> -----Oorspronkelijk bericht----- >>> Van: samba [mailto:samba-bounces at lists.samba.org] Namens Rowland penny >>> Verzonden: maandag 27 juni 2016 14:08 >>> Aan: samba at lists.samba.org >>> Onderwerp: Re: [Samba] Rights issue on GPO >>> >>> On 26/06/16 12:43, Achim Gottinger wrote: >>>> Created an feature request >>>> >>>> "add resolving for well known security principals" >>>> >>>> https://bugzilla.samba.org/show_bug.cgi?id=11997 >>>> >>>> Am 25.06.2016 um 12:35 schrieb Achim Gottinger: >>>>> >>>>> Am 25.06.2016 um 02:21 schrieb Achim Gottinger: >>>>>> >>>>>> Am 24.06.2016 um 23:16 schrieb Achim Gottinger: >>>>>>> >>>>>>> Am 24.06.2016 um 22:57 schrieb Rowland penny: >>>>>>>> On 24/06/16 21:35, Achim Gottinger wrote: >>>>>>>>> >>>>>>>>> Am 24.06.2016 um 21:24 schrieb Rowland penny: >>>>>>>>>> On 24/06/16 19:47, lingpanda101 at gmail.com wrote: >>>>>>>>>>> On 6/24/2016 11:40 AM, mathias dufresne wrote: >>>>>>>>>>>> >>>>>>>>>>>> 2016-06-24 15:24 GMT+02:00 lingpanda101 at gmail.com >>>>>>>>>>>> <mailto:lingpanda101 at gmail.com> <lingpanda101 at gmail.com >>>>>>>>>>>> <mailto:lingpanda101 at gmail.com>>: >>>>>>>>>>>> >>>>>>>>>>>> On 6/22/2016 12:21 PM, mathias dufresne wrote: >>>>>>>>>>>> >>>>>>>>>>>> 2016-06-22 16:37 GMT+02:00 L.P.H. van Belle >>>>>>>>>>>> <belle at bazuin.nl >>>>>>>>>>>> <mailto:belle at bazuin.nl>>: >>>>>>>>>>>> >>>>>>>>>>>> @Mathias, >>>>>>>>>>>> >>>>>>>>>>>> Pretty strange then, running some years like this >>>>>>>>>>>> without >>>>>>>>>>>> any problem. >>>>>>>>>>>> Yes we had few problems with "rights" in sysvol, >>>>>>>>>>>> but i >>>>>>>>>>>> fixed this all >>>>>>>>>>>> outside linux, and with that i mean. Changed >>>>>>>>>>>> rights from >>>>>>>>>>>> within windows or >>>>>>>>>>>> added registry changes or patches, or a local >>>>>>>>>>>> clean up of >>>>>>>>>>>> the policies. >>>>>>>>>>>> >>>>>>>>>>>> At the install of my DC2 i also synced the >>>>>>>>>>>> idmap.ldb, and >>>>>>>>>>>> then a >>>>>>>>>>>> net idmap flush on both servers to make my both >>>>>>>>>>>> dc's in sync. >>>>>>>>>>>> And i keep it in sync with my rsync/unison setup. >>>>>>>>>>>> >>>>>>>>>>>> All new added, but i'll keep an eye also in this >>>>>>>>>>>> and i'll >>>>>>>>>>>> recheck my logs. >>>>>>>>>>>> But i dont think i'll find anything here. >>>>>>>>>>>> I'll keep notice on your "workaround". >>>>>>>>>>>> >>>>>>>>>>>> Which backend are you using matias? >>>>>>>>>>>> Mine : (idmap config NTDOMAIN : backend = ad) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Gr. >>>>>>>>>>>> >>>>>>>>>>>> Louis >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> OK you keep idmap.ldb synched, that's what I missed >>>>>>>>>>>> until few >>>>>>>>>>>> days and was >>>>>>>>>>>> the reason that is was not working. >>>>>>>>>>>> Our choice to give each and users and groups into AD >>>>>>>>>>>> some xID >>>>>>>>>>>> is only to >>>>>>>>>>>> avoid usage of mapping. I expect the >>>>>>>>>>>> synchronization of >>>>>>>>>>>> idmap.ldb (if done >>>>>>>>>>>> often enough) would be sufficient. But I don't always >>>>>>>>>>>> like >>>>>>>>>>>> magic : ) >>>>>>>>>>>> >>>>>>>>>>>> Thank you for precisions ! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Cheers all >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Oorspronkelijk bericht----- >>>>>>>>>>>> Van: samba >>>>>>>>>>>> [mailto:samba-bounces at lists.samba.org >>>>>>>>>>>> <mailto:samba-bounces at lists.samba.org>] Namens mathias >>>>>>>>>>>> >>>>>>>>>>>> dufresne >>>>>>>>>>>> >>>>>>>>>>>> Verzonden: woensdag 22 juni 2016 15:31 >>>>>>>>>>>> Aan: lingpanda101 at gmail.com >>>>>>>>>>>> <mailto:lingpanda101 at gmail.com> >>>>>>>>>>>> CC: samba >>>>>>>>>>>> Onderwerp: Re: [Samba] Rights issue on GPO >>>>>>>>>>>> >>>>>>>>>>>> @LPH van Belle >>>>>>>>>>>> I did tried (and still use) "acl_xattr:ignore >>>>>>>>>>>> system >>>>>>>>>>>> acls = yes" as shown >>>>>>>>>>>> on the first mail of that thread. And even >>>>>>>>>>>> using that >>>>>>>>>>>> rights errors on >>>>>>>>>>>> >>>>>>>>>>>> GPO >>>>>>>>>>>> >>>>>>>>>>>> files _are_ an issue. Otherwise that thread >>>>>>>>>>>> won't have >>>>>>>>>>>> been opened of >>>>>>>>>>>> course : ) >>>>>>>>>>>> >>>>>>>>>>>> Regarding how we decided to workaround almost >>>>>>>>>>>> definitively with that was >>>>>>>>>>>> to >>>>>>>>>>>> give every users and groups in AD some xID, >>>>>>>>>>>> also those >>>>>>>>>>>> in CN=Builtin and >>>>>>>>>>>> CN=Users. We also cleaned our idmap.ldb to >>>>>>>>>>>> keep inside >>>>>>>>>>>> only special users >>>>>>>>>>>> / >>>>>>>>>>>> groups (as "local system" / S-1-5-18, >>>>>>>>>>>> "guests" / >>>>>>>>>>>> S-1-5-32-546...). >>>>>>>>>>>> We also add some rsync to keep idmap.ldb >>>>>>>>>>>> synchronized >>>>>>>>>>>> on all our DC, for >>>>>>>>>>>> these special items have same mapped xID in >>>>>>>>>>>> case they >>>>>>>>>>>> are used (and so >>>>>>>>>>>> mapped). >>>>>>>>>>>> >>>>>>>>>>>> Doing that id mapper has no reason to define >>>>>>>>>>>> by itself >>>>>>>>>>>> some xID to users >>>>>>>>>>>> and groups contained into AD as they already >>>>>>>>>>>> have some >>>>>>>>>>>> xID. >>>>>>>>>>>> >>>>>>>>>>>> Until now it seems to work fine... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2016-06-22 15:09 GMT+02:00 >>> lingpanda101 at gmail.com >>>>>>>>>>>> <mailto:lingpanda101 at gmail.com> >>>>>>>>>>>> <lingpanda101 at gmail.com >>>>>>>>>>>> <mailto:lingpanda101 at gmail.com>>: >>>>>>>>>>>> >>>>>>>>>>>> On 6/22/2016 8:53 AM, mj wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 06/22/2016 02:44 PM, >>>>>>>>>>>> lingpanda101 at gmail.com >>>>>>>>>>>> <mailto:lingpanda101 at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Why is is when I do a getfacl >>>>>>>>>>>> I do >>>>>>>>>>>> not see >>>>>>>>>>>> the mapping of BUILTIN >>>>>>>>>>>> >>>>>>>>>>>> like >>>>>>>>>>>> >>>>>>>>>>>> others? >>>>>>>>>>>> >>>>>>>>>>>> do you have winbind in >>>>>>>>>>>> /etc/nsswitch.conf? >>>>>>>>>>>> >>>>>>>>>>>> mj >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I also thought winbind was only >>>>>>>>>>>> necessary on >>>>>>>>>>>> member servers. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> -James >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> To unsubscribe from this list go to the following >>>>>>>>>>>> URL and >>>>>>>>>>>> read the >>>>>>>>>>>> instructions: >>>>>>>>>>>> https://lists.samba.org/mailman/options/samba >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> If I assign every user a UID and select groups a GID by >>>>>>>>>>>> utilizing >>>>>>>>>>>> rfc2307 on my DC's. Would I still benefit from keeping >>>>>>>>>>>> idmap.ldb >>>>>>>>>>>> synchronized? I'm thinking XID's are obsolete at that >>>>>>>>>>>> point? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Only users and groups in AD will avoid id mapper by that >>>>>>>>>>>> workaround. But there are others accounts ("local system", >>>>>>>>>>>> "guest", "local administrator"...) all these accounts exist on >>>>>>>>>>>> MS Windows clients, and so they can all do stuff on Sysvol and >>>>>>>>>>>> so they can all go through id mapper. >>>>>>>>>>>> >>>>>>>>>>>> So no. There no way (for me at least :) to totally avoid id >>>>>>>>>>>> mapper and so you should keep idmap.ldb synched. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- -James >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- To unsubscribe from this list go to the following >>>>>>>>>>>> URL and read the >>>>>>>>>>>> instructions: >>>>>>>>>>>> https://lists.samba.org/mailman/options/samba >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> I'm in the process now of creating a script to sync idmap.ldb. >>>>>>>>>>> Does anyone have one at the moment? Is it best practice to stop >>>>>>>>>>> samba before replacing idmap.ldb on the additional DC's? My >>>>>>>>>>> script will currently watch for any idmap.ldb changes and >>>>>>>>>>> create a hot backup if a change is detected. It will then send >>>>>>>>>>> to the other DC's via rsync. I'm thinking starting and stopping >>>>>>>>>>> samba isn't ideal during production hours. >>>>>>>>>>> >>>>>>>>>> If you are running Samba >= 4.2.0 with the separate 'winbindd' >>>>>>>>>> binary, there is no reason to sync idmap.ldb. Syncing idmap >>>>>>>>>> was/is only required if you use 'winbind' that is built into the >>>>>>>>>> 'samba' binary. >>>>>>>>>> >>>>>>>>>> Rowland >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Hello Rowland, >>>>>>>>> >>>>>>>>> If you take an look on your sysvol rights there are two still >>>>>>>>> unresoved groups SECURITY\Local System and SECURITY\Autheticated >>>>>>>>> Users. These show up with gid's from idmap.ldb in the acl list >>>>>>>>> and therefore can not be mapped during rsync. So at least these >>>>>>>>> two groups need idntical mapping on all dc's. It is however not >>>>>>>>> neccessary to keep idmap in sync as long as no ther security >>>>>>>>> groups are used. >>>>>>>>> >>>>>>>>> achim~ >>>>>>>>> >>>>>>>> Yes I know, but each DC knows who they are and as they are members >>>>>>>> of the 'SECURITY' domain, they aren't mapped to the DOMAIN or >>>>>>>> BUILTIN. >>>>>>>> >>>>>>>> Rowland >>>>>>>> >>>>>>>> >>>>>>> If the gid used for "Authenticated Users" on the source server >>>>>>> (dc1) ist used for some "random group" on the target server (dc2), >>>>>>> the read right on sysvol for authenticated users will instead be >>>>>>> given to "random group". This can result in users not a member of >>>>>>> "random group" will not be able to access content on sysvol. >>>>>>> Therefore it is mandatory that these security groups are mapped to >>>>>>> the same gid on all dc's the sysvol conted is replicated. >>>>>>> >>>>>> This was an issue i ran into back on samba 4.0/4.1. Mapping BUILTIN >>>>>> in 4.2 has no impact but I assume the ACL's are read from the >>>>>> security.NTACL xattr so "Authenticated Users" should always have >>>>>> access because the xattr stores SID's and not the xid's. xattrs >>>>>> should be replicated with rsync without any mapping required. >>>>> Did an short test if proper posix uid/gid mapping is required for >>>>> sysvol to work. >>>>> Since vfs_acl_xattr is in use samba is said to keep the posix acl's >>>>> in sync with the acl's stored in the security.NTACL xattr object. >>>>> (https://www.samba.org/samba/docs/man/manpages/vfs_acl_xattr.8.html) >>>>> If i sync from an dc with different mappings in idmap.ldb the posix >>>>> acl's seem to have precedence over the xattr values, so they can mess >>>>> up things in an way that some security groups can gain read or ever >>>>> write rights because of the different mappings. >>>>> An easy fix is adding >>>>> acl_xattr:ignore system acls = Yes >>>>> to the sysvol section in smb.conf. Posix ACL's are now ignored and >>>>> only the ACL's from the xattr are used. >>>>> >>>>> >>>>> >>>> >>> >>> OK, I finally got round to installing win10 in a VM on my new computer, >>> so I have been able to fully test 'sysvol' on both DCs. >>> >>> If I run getfacl on sysvol on DC1, I get this: >>> >>> root at dc1:~# getfacl /usr/local/samba/var/locks/sysvol/ >>> getfacl: Removing leading '/' from absolute path names >>> # file: usr/local/samba/var/locks/sysvol/ >>> # owner: root >>> # group: BUILTIN\134administrators >>> # flags: -s- >>> user::rwx >>> user:root:rwx >>> user:BUILTIN\134administrators:rwx >>> group::rwx >>> group:BUILTIN\134administrators:rwx >>> group:BUILTIN\134server\040operators:r-x >>> group:3000002:rwx >>> group:3000003:r-x >>> mask::rwx >>> other::--- >>> default:user::rwx >>> default:user:root:rwx >>> default:user:BUILTIN\134administrators:rwx >>> default:group::--- >>> default:group:BUILTIN\134administrators:rwx >>> default:group:BUILTIN\134server\040operators:r-x >>> default:group:3000002:rwx >>> default:group:3000003:r-x >>> default:mask::rwx >>> default:other::--- >>> >>> If run it on DC2, I get this: >>> >>> root at dc2:~# getfacl /usr/local/samba/var/locks/sysvol/ >>> getfacl: Removing leading '/' from absolute path names >>> # file: usr/local/samba/var/locks/sysvol/ >>> # owner: root >>> # group: BUILTIN\134administrators >>> # flags: -s- >>> user::rwx >>> user:root:rwx >>> user:BUILTIN\134administrators:rwx >>> user:BUILTIN\134server\040operators:r-x >>> user:3000014:r-x >>> user:3000030:rwx >>> group::rwx >>> group:BUILTIN\134administrators:rwx >>> group:BUILTIN\134server\040operators:r-x >>> group:3000014:r-x >>> group:3000030:rwx >>> mask::rwx >>> other::--- >>> default:user::rwx >>> default:user:root:rwx >>> default:user:BUILTIN\134administrators:rwx >>> default:user:BUILTIN\134server\040operators:r-x >>> default:user:3000014:r-x >>> default:user:3000030:rwx >>> default:group::--- >>> default:group:BUILTIN\134administrators:rwx >>> default:group:BUILTIN\134server\040operators:r-x >>> default:group:3000014:r-x >>> default:group:3000030:rwx >>> default:mask::rwx >>> default:other::--- >>> >>> As you can see, each DC shows numbers for two groups: >>> >>> On DC1: >>> group:3000002:rwx >>> group:3000003:r-x >>> >>> The first is for the SID 'CN=S-1-5-18' , this is 'Local System', the >>> second is for the SID 'CN=S-1-5-11', this is 'Authenticated Users' >>> >>> On DC2: >>> group:3000014:r-x >>> group:3000030:rwx >>> >>> The first is for the SID 'CN=S-1-5-11' this is 'Authenticated Users', >>> the second is for the SID 'CN=S-1-5-18' , this is 'Local System' >>> >>> So, as far as I can see, the owners of 'sysvol' are: >>> >>> On DC1: >>> Administrators >>> Server Operators >>> Local System >>> Authenticated Users >>> >>> On DC2: >>> Administrators >>> Server Operators >>> Authenticated Users >>> Local System >>> >>> So, from the Unix point of view, 'sysvol' belongs to the correct >>> users/groups, but what about windows ? >>> >>> If I navigate to each DC on win10, select the 'sysvol' share and >>> right-click it, then select the security tab, I find this: >>> >>> Authenticated Users >>> SYSTEM >>> Administrators >>> Server Operators >>> >>> The same as on the DCs. >>> >>> I do not 'sync' idmap.ldb and the DCs are both running 4.4.3 >>> >>> Bearing in mind the above, why are people still syncing 'idmap.ldb' if >>> they are using the separate 'winbindd' binary ?? >>> >>> The only slight 'problem' that I can see, getfacl seems to return >>> different results depending on which DC it is run on, the same basic >>> result, but on one it is a user and on the other it is a group. >>> >>> Rowland >>> >>> >>> -- >>> To unsubscribe from this list go to the following URL and read the >>> instructions: https://lists.samba.org/mailman/options/samba >> >> > > > Two things Louis: > > if you look very closely at the differences in the 'ERROR' message, > you will find the only difference is this: > > O:LAG:DAD:PAR( > > against the expected: > > O:DAG:DAD:PAR( > > The returned ACL is owned by the 'Local Admins', but it should be > owned by 'Domain Admins'. As far as I can see, windows doesn't really > care who owns an object, as long as the ACEs are correct and they are! > > Secondly, more than happy to try adding a GPO, only problem is, I have > never really added one, can you point me at a good howto ? > > Rowland >Sysvolcheck will always fail for me if I give my 'Domain Admins' group a gid number other than the expected value of 3000000. -- -James
> > Two things Louis: > > if you look very closely at the differences in the 'ERROR' message, you > will find the only difference is this: > > O:LAG:DAD:PAR( > > against the expected: > > O:DAG:DAD:PAR( > > The returned ACL is owned by the 'Local Admins', but it should be owned > by 'Domain Admins'. As far as I can see, windows doesn't really care who > owns an object, as long as the ACEs are correct and they are! > > Secondly, more than happy to try adding a GPO, only problem is, I have > never really added one, can you point me at a good howto ? > > Rowland > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/sambaHai Rowland, I just checked on a windows 2008 R2 server. Sysvol security rights should be. DOMAIN\Server Operators Creator Owner Authenticated Users SYSTEM DOMAIN\Administrators contains : "Domain Admins",Adminstrator and "Enterprise Admins" And the "DOMAIN\Adminstrators" is in the Buildin OU. And same for "DOMAIN\Users" contains: Authenticated Users, Domain Users, INTERACTIVE) So imo this is a bug as Achim told. Alle local security groups must map correctly. And but must try to not mix BUILDIN\localgroup and DOMAIN\localgroup So imo, if samba is uses as standalone server all Security groups map to BUILDIN\localgroups. And when its a domain AD DC server. BUILDIN maps to OU=Buildin and here are the correct groups like DOMAIN\localgroups Greetz, Louis
A good howto per exampl.e http://www.itingredients.com/how-to-disable-usb-ports-using-group-policy/ Only i did not do this as computer policy but as user policy. In short, 1) create 2 groups: USB-Allowed USB-Denied 2) create 2 policies objects, USB-Allowed USB-Denied And set in the allow polices ( as shown in the link but under the user polcies ) 3) add correct group to the same GPO object. ( allowed with allowed , etc ) 3) link the polcies objects in a OU where you can test and where the user is. 4) set the order of these policies to Allowed above the Denied. Order 123 , is applied as 3 2 1. 1 is highest so.. This is bit like i have ... Domain users, alle external devices are denied. And based on group memberships : DVD-Read DVD-Write USB-.. . etc etc. And alle these are failing. I noticed all security groups which are not "Authenticated Users" are failing. Which is a problem for me since all my policies are group right based. I also noticed that in my Samba 4 AD DC domain i have 4 groups in " ForeignSecurityPrincipals (CN=ForeignSecurityPrincipals ) S-1-5-4 ( Member of : Users in CN=Buildin ) S-1-5-11 ( member of : Users and Pre-windows 2000... ) in CN=Buildin S-1-5-17 ( member of : IIS_IUSRS ) in CN=Buildin S-1-5-9 ( member of : Windows Authorization Access Group ) in CN=Buildin I dont see any in ForeignSecurityPrincipals on my 2008R2 Greetz, Louis> > > Two things Louis: > > if you look very closely at the differences in the 'ERROR' message, you > will find the only difference is this: > > O:LAG:DAD:PAR( > > against the expected: > > O:DAG:DAD:PAR( > > The returned ACL is owned by the 'Local Admins', but it should be owned > by 'Domain Admins'. As far as I can see, windows doesn't really care who > owns an object, as long as the ACEs are correct and they are! > > Secondly, more than happy to try adding a GPO, only problem is, I have > never really added one, can you point me at a good howto ? > > Rowland > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba
Am 27.06.2016 um 15:37 schrieb L.P.H. van Belle:> A good howto per exampl.e > > http://www.itingredients.com/how-to-disable-usb-ports-using-group-policy/ > > Only i did not do this as computer policy but as user policy. > > In short, > 1) create 2 groups: > USB-Allowed > USB-Denied > > 2) create 2 policies objects, > USB-Allowed > USB-Denied > > And set in the allow polices > ( as shown in the link but under the user polcies ) > > 3) add correct group to the same GPO object. ( allowed with allowed , etc ) > > 3) link the polcies objects in a OU where you can test and where the user is. > > 4) set the order of these policies to Allowed above the Denied. > Order 123 , is applied as 3 2 1. > 1 is highest so.. > > This is bit like i have ... > > Domain users, alle external devices are denied. > And based on group memberships : > DVD-Read > DVD-Write > USB-.. . etc etc. > > And alle these are failing. > I noticed all security groups which are not "Authenticated Users" are failing. > > Which is a problem for me since all my policies are group right based. > > I also noticed that in my Samba 4 AD DC domain i have 4 groups in " > ForeignSecurityPrincipals (CN=ForeignSecurityPrincipals ) > S-1-5-4 ( Member of : Users in CN=Buildin ) > S-1-5-11 ( member of : Users and Pre-windows 2000... ) in CN=Buildin > S-1-5-17 ( member of : IIS_IUSRS ) in CN=Buildin > S-1-5-9 ( member of : Windows Authorization Access Group ) in CN=Buildin > > I dont see any in ForeignSecurityPrincipals on my 2008RHi Louis, I created an USB-Denied Policy and granted rights to an Domain Group called "USB-Denied". In the test environment i do not assign uid's and gid's and completely rely on winbindd. Here are the acl's. The policy applies for an normal user being a memeber of "USB-Denied". root at dc1:~# getfacl /var/lib/samba/sysvol/domain.local/Policies/\{8C47B4C4-5084-43CB-BF32-999436E90283\}/ getfacl: Removing leading '/' from absolute path names # file: var/lib/samba/sysvol/domain.local/Policies/{8C47B4C4-5084-43CB-BF32-999436E90283}/ # owner: DOMAIN\134domain\040admins # group: DOMAIN\134domain\040admins user::rwx user:3000002:rwx user:DOMAIN\134enterprise\040admins:rwx user:3000010:r-x user:DOMAIN\134usb\040denied:r-x group::rwx group:3000002:rwx group:DOMAIN\134enterprise\040admins:rwx group:DOMAIN\134domain\040admins:rwx group:3000010:r-x group:DOMAIN\134usb\040denied:r-x mask::rwx other::--- default:user::rwx default:user:3000002:rwx default:user:DOMAIN\134enterprise\040admins:rwx default:user:DOMAIN\134domain\040admins:rwx default:user:3000010:r-x default:user:DOMAIN\134usb\040denied:r-x default:group::--- default:group:3000002:rwx default:group:DOMAIN\134enterprise\040admins:rwx default:group:DOMAIN\134domain\040admins:rwx default:group:3000010:r-x default:group:DOMAIN\134usb\040denied:r-x default:mask::rwx default:other::--- Replicated to dc2 with root at dc2:~# rsync -XAavz -e ssh root at dc1:/var/lib/samba/sysvol/ /var/lib/samba/sysvol/ These are the acl's on dc2. root at dc2:~# getfacl /var/lib/samba/sysvol/domain.local/Policies/\{8C47B4C4-5084-43CB-BF32-999436E90283\}/ getfacl: Removing leading '/' from absolute path names # file: var/lib/samba/sysvol/domain.local/Policies/{8C47B4C4-5084-43CB-BF32-999436E90283}/ # owner: domain\040admins # group: domain\040admins user::rwx user:guest:rwx user:enterprise\040admins:rwx user:denied\040rodc\040password\040replication\040group:r-x user:usb\040denied:r-x group::rwx group:guest:rwx group:domain\040admins:rwx group:enterprise\040admins:rwx group:denied\040rodc\040password\040replication\040group:r-x group:usb\040denied:r-x mask::rwx other::--- default:user::rwx default:user:guest:rwx default:user:domain\040admins:rwx default:user:enterprise\040admins:rwx default:user:denied\040rodc\040password\040replication\040group:r-x default:user:usb\040denied:r-x default:group::--- default:group:guest:rwx default:group:domain\040admins:rwx default:group:enterprise\040admins:rwx default:group:denied\040rodc\040password\040replication\040group:r-x default:group:usb\040denied:r-x default:mask::rwx default:other::--- In this case the gid 3000002 is mapped to the "Guest" group on dc2 and 30000010 to "denied rodc password replication group". As an normal user i can not access sysvol on dc2 because the mapping /var/lib/samba/sysvol/domain.local is messed up (no Authenticated Users ACL). root at dc2:~# getfacl /var/lib/samba/sysvol getfacl: Removing leading '/' from absolute path names # file: var/lib/samba/sysvol # owner: root # group: BUILTIN\134administrators user::rwx user:root:rwx user:BUILTIN\134administrators:rwx group::rwx group:BUILTIN\134administrators:rwx group:guest:rwx group:domain\040guests:r-x group:BUILTIN\134server\040operators:r-x mask::rwx other::--- default:user::rwx default:user:root:rwx default:user:BUILTIN\134administrators:rwx default:group::--- default:group:BUILTIN\134administrators:rwx default:group:guest:rwx default:group:domain\040guests:r-x default:group:BUILTIN\134server\040operators:r-x default:mask::rwx default:other::--- achim~
On 27/06/16 14:13, L.P.H. van Belle wrote:>> Two things Louis: >> >> if you look very closely at the differences in the 'ERROR' message, you >> will find the only difference is this: >> >> O:LAG:DAD:PAR( >> >> against the expected: >> >> O:DAG:DAD:PAR( >> >> The returned ACL is owned by the 'Local Admins', but it should be owned >> by 'Domain Admins'. As far as I can see, windows doesn't really care who >> owns an object, as long as the ACEs are correct and they are! >> >> Secondly, more than happy to try adding a GPO, only problem is, I have >> never really added one, can you point me at a good howto ? >> >> Rowland >> >> -- >> To unsubscribe from this list go to the following URL and read the >> instructions: https://lists.samba.org/mailman/options/samba > Hai Rowland, > > I just checked on a windows 2008 R2 server. > > Sysvol security rights should be. > > DOMAIN\Server Operators > Creator Owner > Authenticated Users > SYSTEM > DOMAIN\Administrators contains : > "Domain Admins",Adminstrator and "Enterprise Admins"Hi Louis, I have been doing some checking and found this microsoft page: https://technet.microsoft.com/en-us/library/cc816750%28v=ws.10%29.aspx It lists the default settings and it doesn't match either your list or what Samba uses, it uses: Authenticated Users Server Operators Built-in administrators SYSTEM Creator Owner Samba uses this: SYSVOL_ACL = "O:LAG:BAD:P(A;OICI;0x001f01ff;;;BA)(A;OICI;0x001200a9;;;SO)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)" Which boils down to: Built-in administrators Server Operators SYSTEM Authenticated Users There is no 'Creator Owner' The ACL for the Policies directory doesn't have 'Creator Owner' either and according to the microsoft page, it should. Rowland> > And the "DOMAIN\Adminstrators" is in the Buildin OU. > > And same for "DOMAIN\Users" contains: > Authenticated Users, Domain Users, INTERACTIVE) > > So imo this is a bug as Achim told. > Alle local security groups must map correctly. > And but must try to not mix BUILDIN\localgroup and DOMAIN\localgroup > > So imo, if samba is uses as standalone server all Security groups map to BUILDIN\localgroups. > > And when its a domain AD DC server. > BUILDIN maps to OU=Buildin and here are the correct groups like DOMAIN\localgroups > > > Greetz, > > Louis > > > >