[Samba] Rights issue on GPO
L.P.H. van Belle
belle at bazuin.nl
Mon Jun 27 13:04:12 UTC 2016
In addition, Rowland/Achim, did you assign GID to all groups ?
Because i only assigned the groups i use in linux, i didnt change the "windows only" groups, these get a id from the range.
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
More information about the samba
mailing list