[Samba] Rights issue on GPO

Rowland penny rpenny at samba.org
Mon Jun 27 12:42:05 UTC 2016


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



More information about the samba mailing list