[Samba] Rights issue on GPO

Achim Gottinger achim at ag-web.biz
Mon Jun 27 12:30:18 UTC 2016



Am 27.06.2016 um 14:08 schrieb Rowland penny:
> 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
>
>
Thank you for the test. Do you run samba-tool ntacl sysvolreset after 
rsync on dc2? What command are you using to synchronize the sysvol folders?
I tried it on debian jessie with debian an  sernet samba 4.2 and 
backported 4.3. Synchronisation happend with rsync/ssh and no 
sysvolreset was run here. There is no way rsync can map the different 
gid's for groups and users whom do not resolve to names.
If i run sysvolreset after rsync propper mappings are restored on dc2 
and the folders can be accessed from windows.

achim~



More information about the samba mailing list