[Samba] Rights issue on GPO
lingpanda101 at gmail.com
lingpanda101 at gmail.com
Mon Jun 27 12:53:31 UTC 2016
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
More information about the samba
mailing list