[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