[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