On 27/06/16 13:30, Achim Gottinger wrote:>
>
> 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?
This may be where the problems come in, let me look into this and report
back
Rowland
> 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~
>