samba - Feb 2016 - Can one set the owner of a folder to BUILTIN\Administrators?

On 2/17/2016 10:32 AM, Rowland penny wrote:
> On 17/02/16 18:07, Ian wrote:
>> Actually, that works for me too.  I just issued the command 'chgrp
>> "BUILTIN\administrators" CoreLib' and it returned
successfully for that
>> folder.  'ls -la' shows:
>> d---------+ 2 MMIA\domain admins  BUILTIN\administrators  5 Dec  8
11:59
>> CoreLib//
>>
>> Note however, that it fails if I attempt to chown instead:
>> [root at freenas] /mnt/trunk/MM/deploy# chown
"BUILTIN\Administrators"
>> CoreLib
>> chown: BUILTIN\Administrators: illegal user name
>>
>> I can chown to other domain groups successfully.
>
> Normally a group cannot 'own' files etc, Unix uses ugo permissions
and
> when you chown a file you would use something like this:
In unix, yes this is the case, however in Windows a group can.  For
instance, this works:
chown 'DOMAIN\Domain Admins' CoreLib/
ls -lad CoreLib:
d---------+ 2 MMIA\domain admins  BUILTIN\administrators  5 Dec  8 11:59
CoreLib//

Using kerberos and ldap, there doesn't seem to be anything stopping
this.  However, if I understand what you're saying, the BUILTIN\* users
and groups are part of the unix system that Samba runs on, and thus some
type of mapping must occur with "real" unix accounts.  I'm still
not
clear where this mapping occurs though -- which account/group is it
actually mapping to?

What I don't get is why any of the BUILTIN\* users and groups would ever
be assigned to a group in unix.  The group file attribute in unix is
never used by Windows, however the owner is.  If every BUILTIN\* group
mapped to a user in unix, this all would work perfectly, no?

On 17/02/16 19:47, Ian wrote:
> On 2/17/2016 10:32 AM, Rowland penny wrote:
>> On 17/02/16 18:07, Ian wrote:
>>> Actually, that works for me too.  I just issued the command
'chgrp
>>> "BUILTIN\administrators" CoreLib' and it returned
successfully for that
>>> folder.  'ls -la' shows:
>>> d---------+ 2 MMIA\domain admins  BUILTIN\administrators  5 Dec  8
11:59
>>> CoreLib//
>>>
>>> Note however, that it fails if I attempt to chown instead:
>>> [root at freenas] /mnt/trunk/MM/deploy# chown
"BUILTIN\Administrators"
>>> CoreLib
>>> chown: BUILTIN\Administrators: illegal user name
>>>
>>> I can chown to other domain groups successfully.
>> Normally a group cannot 'own' files etc, Unix uses ugo
permissions and
>> when you chown a file you would use something like this:
> In unix, yes this is the case, however in Windows a group can.  For
> instance, this works:
> chown 'DOMAIN\Domain Admins' CoreLib/
> ls -lad CoreLib:
> d---------+ 2 MMIA\domain admins  BUILTIN\administrators  5 Dec  8 11:59
> CoreLib//
>
> Using kerberos and ldap, there doesn't seem to be anything stopping
> this.  However, if I understand what you're saying, the BUILTIN\* users
> and groups are part of the unix system that Samba runs on, and thus some
> type of mapping must occur with "real" unix accounts.  I'm
still not
> clear where this mapping occurs though -- which account/group is it
> actually mapping to?
>
> What I don't get is why any of the BUILTIN\* users and groups would
ever
> be assigned to a group in unix.

One word 'Sysvol'

> The group file attribute in unix is
> never used by Windows, however the owner is.  If every BUILTIN\* group
> mapped to a user in unix, this all would work perfectly, no?
>
>
Yes, it does on a DC.

Rowland

On 2/17/2016 11:53 AM, Rowland penny wrote:
> On 17/02/16 19:47, Ian wrote:
>> On 2/17/2016 10:32 AM, Rowland penny wrote:
>>> On 17/02/16 18:07, Ian wrote:
>>>> Actually, that works for me too.  I just issued the command
'chgrp
>>>> "BUILTIN\administrators" CoreLib' and it returned
successfully for
>>>> that
>>>> folder.  'ls -la' shows:
>>>> d---------+ 2 MMIA\domain admins  BUILTIN\administrators  5 Dec
8
>>>> 11:59
>>>> CoreLib//
>>>>
>>>> Note however, that it fails if I attempt to chown instead:
>>>> [root at freenas] /mnt/trunk/MM/deploy# chown
"BUILTIN\Administrators"
>>>> CoreLib
>>>> chown: BUILTIN\Administrators: illegal user name
>>>>
>>>> I can chown to other domain groups successfully.
>>> Normally a group cannot 'own' files etc, Unix uses ugo
permissions and
>>> when you chown a file you would use something like this:
>> In unix, yes this is the case, however in Windows a group can.  For
>> instance, this works:
>> chown 'DOMAIN\Domain Admins' CoreLib/
>> ls -lad CoreLib:
>> d---------+ 2 MMIA\domain admins  BUILTIN\administrators  5 Dec  8
11:59
>> CoreLib//
>>
>> Using kerberos and ldap, there doesn't seem to be anything stopping
>> this.  However, if I understand what you're saying, the BUILTIN\*
users
>> and groups are part of the unix system that Samba runs on, and thus
some
>> type of mapping must occur with "real" unix accounts. 
I'm still not
>> clear where this mapping occurs though -- which account/group is it
>> actually mapping to?
>>
>> What I don't get is why any of the BUILTIN\* users and groups would
ever
>> be assigned to a group in unix.
>
>
> One word 'Sysvol'
>
Okay, so a domain member needs to directly deal with sysvol somehow, and
this requires using unix groups,
>
>> The group file attribute in unix is
>> never used by Windows, however the owner is.  If every BUILTIN\* group
>> mapped to a user in unix, this all would work perfectly, no?
>>
>>
>
> Yes, it does on a DC.
>
but a DC that has its own sysvol can still use BUILTIN\Administrators as
a user.

Just so I'm clear:

getent group 'DOMAIN\Domain Admins'
returns
DOMAIN\domain admins:x:20512:(along with all the users that are member
of this group.)

Yet, even though unix see this is a group, I can use this id for the
owner of a folder?  Hmm..

ls -lnd CoreLib/
d---------+ 2 20512  90000001  5 Dec  8 11:59 CoreLib//

If I do a reverse lookup of the numeric id as both a user or group, I
see why this works

id -u 'DOMAIN\Domain Admins'
20512
id -g 'DOMAIN\Domain Admins'
20512

It's not using a group id, it's using a user id that's the same as
the
group id.

However, getent group 'BUILTIN\Administrators' returns this:
BUILTIN\administrators:x:90000001

Doing a reverse lookup here shows the problem:
id -u 'BUILTIN\administrators'
id: BUILTIN\administrators: no such user
id -g 'BUILTIN\administrators'
BUILTIN\administrators:x:90000001

So while the system is perfectly fine doing something like this:
 chgrp 'DOMAIN\Domain Admins' CoreLib/
ls -lnd CoreLib/
d---rwx---+ 2 20512  20512  5 Dec  8 11:59 CoreLib//

ls -lad CoreLib/
d---rwx---+ 2 DOMAIN\domain admins  DOMAIN\domain admins  5 Dec  8 11:59
CoreLib//

The same is impossible because there is no mirrored
BUILTIN\administrators user internal to Samba.  However, as has been
show, this doesn't seem to be a unix limitation.