[Samba] Samba4, idmap.ldb & ID_TYPE_BOTH

[Rowland Penny]

On 22/02/15 01:02, Andrew Bartlett wrote:
> On Sat, 2015-02-21 at 21:37 +0000, Rowland Penny wrote:
>> On 21/02/15 19:26, Andrew Bartlett wrote:
>>
>>> On Thu, 2015-02-19 at 17:15 +0000, Rowland Penny wrote:
>>>> This all leads me to my questions, why, when it comes to idmap.ldb,
>>>> can
>>>> a user also be a group and a group can also be a user and why was it
>>>> setup like this in the first place ? , there must be a reason for it.
>>> It goes like this:
>>>
>>>   - Groups can own files (there are groups like domain administrators
>>> that own files in sysvol)
>> Does domain administrators own the files ? as I posted earlier, trying
>> to reset sysvol is failing for me and the relevant part of the ACL is
>> this:
>>
>> O:LAG:DAD:P(A;OICI
> I don't recall exactly which ACL on which file, but yes, an instance of
> a group owning a file does exist in sysvol.  That group is deliberately
> left as having an ID assigned in idmap.ldb, not mapped to a system group
> (if that is ever a good idea is another thread), for this reason.

OK Andrew, I have examined every file and directory under sysvol on my 
second DC and cannot find anything that is not owned by 'Administrator' 
(this shows as 'root' on the DC). This setup is exactly the same as when 
I joined it to the other DC, I have not changed anything. Can you please 
try and remember what the file is that must belong to a group? or does 
anybody else know what this file is?
If I can find out what this file is, I can investigate it to try and 
understand why it must be owned by a group, an idea I am struggling to 
understand.

Rowland

>
>> This is the start of the ACL and if we expand it for better reading
>> 'O:LA' 'G:DA 'D:P(A;OICI'. The first part is the owner, the second is
>> the group and the third is the start of the ACEs. So the owner (O) is
>> LA which is 'Local Administrator' and the group (G) is DA which is
>> 'Domain Administrators' , as I read it, Domain Administrators doesn't
>> own the files, or am I missing something?
>>    
>>>   - We don't (eg in sidHistory, or when files are migrated, preserving
>>> permissions, from a workstation or from a domain that is not trusted)
>>> always know if an incoming SID is a user or group.
>> does windows know from the SID what the object is? and if not, what
>> does windows do?
> In Windows, a SID is a SID, and there is no need to translate it to
> anything else for access checking.
>
>>>   - Working out if an arbitrary SID is a user or group takes time and
>>> network operations, which may fail.  ID_TYPE_BOTH is both fast and
>>> deterministic in this respect.
>> And in my opinion (which is worth very little) it is a kludge, also
>> does a group actually try to connect (note, I do not know if this
>> happens, which is why I am asking) and if so how ? a group doesn't
>> have a password so how can it authenticate?
> At the large scale, everything that can happen, will happen, and it will
> generate a support call.  Better not to have situations where random
> network issues can change the on-disk behaviour.  A group can't
> authenticate, but a user is of course members of groups, and groups can
> be assigned ownership of files.
>
>>> My view is that we should always have mapped SIDs to both a UID and GID,
>>> and I understand that in general, we are doing that now in new backends.
>>> See for example idmap_rid and idmap_autorid.
>>>
>>> The only tricky bit is that while a user can be put in an extra group to
>>> pick up any permissions assigned to it as a group, a group can't get
>>> user-based permissions, so can't obtain the extra rights associated with
>>> file ownership.
>> Again I ask, what file ownership? can you please name a file that a
>> windows group owns, sorry if I am coming across as negative here, but
>> I am struggling to understand just how a group can own files, I am
>> used to files belonging to a user and members of a group being allowed
>> access to them.
> You can, for instance, change the owner of a file to a group.
>
> Andrew Bartlett
>