[Samba] Rights issue on GPO

Fri Jun 10 14:50:52 UTC 2016

I would say it was simple:
- we gave to all groups a GID and to all users a UID and a GID (existing
GID).
- we edit manually idmap.ldb using "ldbedit -H private/idmap.ldb" to keep
inside only objects with short SID (no domain part of SID, if there is a
domain part into the SID, it is a domain object, we can define in LDAP tree
UID and/or GID)
- we change all ACLs on all sysvol files and directories (getfact -R sysvol
> sysvol.acl; some sed in sysvol.acl to replace old UID/GID coming from old
idmap by the new ones coming from AD; setfacl --restore=sysvol.acl)
- then we had to replace all GID used as UID. Samba seems not to make
difference between uid and gid, at least if they come from idmap.ldb, Samba
set acl for user using groups GID...

That last part is not yet finished, we have to find out if GID used as UID
in ACL has to be replaced or deleted...

Now to explain why I get two lines for the same group in the same ACL
(which normally just can't be) it is because there was one line matching an
entry into idmap.ldb and the other line was GID coming from AD LDAP tree.
This because net cache flush does not change the content of idmap, or not
well enough. No idea yet.

After that, we are almost sure to use UID/GID from AD for every users and
groups, except for very specific users/groups as local system, local
administrator...

That link helped us greatly in that process:
https://support.microsoft.com/en-us/kb/243330
as it shows what "well-know-SID" is meant for.

Best regards,

mathias

2016-06-10 14:12 GMT+02:00 mathias dufresne <infractory at gmail.com>:

> One thing keep us to wonder: we added gidNumber to all groups into BUILTIN
> and Users containers, my own user is in group BUILTIN/Administrators.
>
> When id <my_user> BUILTIN/Administrators is shown with GID 7702, when
> getfacl sysvol GID 3000000 is displayed as BUILTIN/Administrators.
>
> Worst: I manually set group acl for gig 7702 on sysvol:
> setfacl -m g:7702:rwx /var/lib/samba/sysvol
>
> Then getfacl sysvol gave (samba is stopped)
> # file: var/lib/samba/sysvol
> # owner: root
> # group: 3000000
> user::rwx
> user:root:rwx
> user:3000000:rwx
> user:3000015:r-x
> user:3000019:r-x
> user:3000020:rwx
> group::rwx
>
> *group:7702:rwxgroup:3000000:rwx*
> group:3000015:r-x
> group:3000019:r-x
> group:3000020:rwx
> mask::rwx
> other::---
> default:user::rwx
> default:user:root:rwx
> default:user:3000000:rwx
> default:user:3000015:r-x
> default:user:3000019:r-x
> default:user:3000020:rwx
> default:group::---
> default:group:3000000:rwx
> default:group:3000015:r-x
> default:group:3000019:r-x
> default:group:3000020:rwx
> default:mask::rwx
> default:other::---
>
> Samba is running:
> # file: var/lib/samba/sysvol
> # owner: root
> # group: BUILTIN\134administrators
> user::rwx
> user:root:rwx
> user:BUILTIN\134administrators:rwx
> user:3000015:r-x
> user:BUILTIN\134server\040operators:r-x
> user:3000020:rwx
> group::rwx
>
> *group:BUILTIN\134administrators:rwxgroup:BUILTIN\134administrators:rwx*
> group:3000015:r-x
> group:BUILTIN\134server\040operators:r-x
> group:3000020:rwx
> mask::rwx
> other::---
> default:user::rwx
> default:user:root:rwx
> default:user:BUILTIN\134administrators:rwx
> default:user:3000015:r-x
> default:user:BUILTIN\134server\040operators:r-x
> default:user:3000020:rwx
> default:group::---
> default:group:BUILTIN\134administrators:rwx
> default:group:3000015:r-x
> default:group:BUILTIN\134server\040operators:r-x
> default:group:3000020:rwx
> default:mask::rwx
> default:other::---
>
> So one group (BUILTIN\administrators), two GID (3000000 & 7702).
>
> How to get rid of these old GID coming from idmap? I expect I can delete
> idmap entry manually, I'll try that later in the afternoon I hope, but why
> this entry is not removed from idmap when "net cache flush"?
>
> 2016-06-10 12:49 GMT+02:00 mathias dufresne <infractory at gmail.com>:
>
>> Thank you all for these replies.
>>
>> 2016-06-10 9:26 GMT+02:00 Rowland penny <rpenny at samba.org>:
>>
>>> On 10/06/16 07:52, Sébastien Le Ray wrote:
>>>
>>>> Hi
>>>>
>>>>
>>>> Le 09/06/2016 à 20:42, Rowland penny a écrit :
>>>>
>>>>> On 08/06/16 15:34, mathias dufresne wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> [snip]
>>>>>> And we get issue with Linux ACLs: they are not the same because some
>>>>>> BUILTIN users and/or groups do not have same id mapping on all DC.
>>>>>>
>>>>>> How to force all DC to get same id mapping?
>>>>>>
>>>>>> Using "acl_xattr:ignore system acls = yes", are Linux ACLs still
>>>>>> important
>>>>>> or are we supposed to use Windows ACLs only into stored into some
>>>>>> Samba
>>>>>> file? In that case, which file(s)?
>>>>>>
>>>>>
>>>> They're stored in each file xattr as an obscure base64 encoded value
>>>> BUT in all cases unix permissions applies when accessing through samba.
>>>> So disabling ACLs means that you've to set the properties correctly to
>>>> allow "samba" unix users to access files (there's no clear doc on that…)
>>>>
>>>> OK, first you do not need this on a DC: 'winbind nss info = rfc2307'
>>>>>
>>>>> Secondly, your different id mappings for BUILTIN users & groups is a
>>>>> well known problem. The id's are stored in 'idmap.ldb' as 'xidNumber'
>>>>> attributes and seem to be given on a first come basis, only problem is, the
>>>>> groups etc don't connect in the same order on every DC.
>>>>>
>>>>
>>>> Wasn't this supposed to be solved in 4.2?
>>>>
>>>> https://wiki.samba.org/index.php/Join_an_additional_Samba_DC_to_an_existing_Active_Directory#GID_mappings_of_built-in_groups
>>>> The wiki seems to say that Builtin xID are now replicated but there is
>>>> no clear upgrade path (if you've mixed 4.1 & 4.2 DC which mapping will be
>>>> stored in 4.2 winbind? What happens when you upgrade the 4.1 to 4.2?)
>>>>
>>>
>>> Well, it is and it isn't, yes winbindd will display the user & group
>>> names for sysvol, but sysvol still isn't replicated between DCs. I think
>>> this means that when you sync sysvol manually, you will get the ID's from
>>> the first DC applied to sysvol on the second DC and if there is a
>>> difference in ID numbers between the DC's, you will either just get a
>>> number or, even worse, a wrong name returned.
>>>
>>> I could be wrong, but I still think you need to keep idmap.ldb in sync
>>> on all DCs, if you are syncing sysvol.
>>>
>>
>> At least here you were right: without syncing idmap.ldb followed by "net
>> cache flush" Sysvol rights were an awful mess and so GPO were retrieved
>> once on really too few (tests are done for now with around 20 DCs which
>> makes that kind of issue showing really quickly/often).
>>
>> I'm about to add xidNumber to any users and groups in BUILTIN and Users
>> directories (in LDAP tree) to avoid as often as possible that idmap
>> process. I should come back to tell how things went.
>>
>>
>>>
>>> Rowland
>>>
>>>
>>>>
>>>>> To get the same ID's on every DC, you will have to copy idmap.ldb from
>>>>> the first DC to every other DC, run 'net cache flush' and then keep
>>>>> 'idmap.ldb' in sync.
>>>>>
>>>>> Regards
>>>>
>>>
>>>
>>> --
>>> To unsubscribe from this list go to the following URL and read the
>>> instructions:  https://lists.samba.org/mailman/options/samba
>>>
>>
>>
>