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

On 2/17/2016 9:43 AM, Rowland penny wrote:
> On 17/02/16 17:27, Ian wrote:
>>
>> On 2/17/2016 5:00 AM, Rowland penny wrote:
>>> On 17/02/16 00:03, Ian wrote:
>>>> I've recently attempted to migrate some windows server
files over to
>>>> samba 4 hosted on a FreeNAS server.
>>>>
>>>> Using robocopy with the /copyall switch, I expected everything,
>>>> including ACL's and ownership information to transfer over.
For the
>>>> most part they have.  The one problem I've ran into
however, is
>>>> that I'm
>>>> getting errors any time I or robocopy attempt to change the
>>>> ownership to
>>>> BUILTIN\Administrators.
>>>>
>>>> I've brought this up with the FreeNAS community, but so far
it's
>>>> unclear
>>>> if this is by design, there is a configuration issue somewhere,
or
>>>> there's a bug.
>>>>
https://forums.freenas.org/index.php?threads/ownership-issues-migrating-data-from-windows-to-freenas.41478/#post-265384
>>>>
>>>>
>>>>
>>>> When I attempt to change ownership to Builtin\Administrators, I
get an
>>>> error that I don't have the Restore Privilege required, or
if I have
>>>> inheritance enabled when changing ownership, "This
security ID may not
>>>> be assigned as the owner of this object."
>>>>
>>>> As mentioned in that thread I linked to (lots more details
there), I
>>>> verified that I do have the Restore Privilege right.  I also
verified
>>>> that I can assign any other owner successfully -- it's just
>>>> Builtin\Administrators that's giving me trouble.
>>>>
>>>> After turning up the logging in the samba configuration file
and
>>>> restarting the service, this was the output when I attempted to
change
>>>> ownership:
>>>>
>>>>
>>>> [2016/02/16 15:33:02.077685,  3]
>>>> ../source3/smbd/vfs.c:1137(check_reduced_name)
>>>>     check_reduced_name [CoreLib] [/mnt/trunk/MM/deploy]
>>>> [2016/02/16 15:33:02.077890,  3]
>>>> ../source3/smbd/vfs.c:1267(check_reduced_name)
>>>>     check_reduced_name: CoreLib reduced to
>>>> /mnt/trunk/MM/deploy/CoreLib
>>>> [2016/02/16 15:33:02.078111,  3]
>>>> ../source3/smbd/dosmode.c:163(unix_mode)
>>>>     unix_mode(CoreLib) returning 0666
>>>> [2016/02/16 15:33:02.080039,  3]
>>>> ../source3/smbd/posix_acls.c:1204(unpack_nt_owners)
>>>>     unpack_nt_owners: unable to validate owner sid for
S-1-5-32-544
>>>> [2016/02/16 15:33:04.251911,  3]
>>>> ../source3/smbd/service.c:1130(close_cnum)
>>>>     192.168.0.119 (ipv4:192.168.0.119:58406) closed connection
to
>>>> service IPC$
>>>>
>>>> Googling for "unable to validate owner sid for
S-1-5-32-544" brings
>>>> up a
>>>> thread a decade old:
>>>>
https://lists.samba.org/archive/samba-technical/2006-October/050007.html
>>>>
>>>>
>>>> There was some discussion about sid/gid conflicts and ACLs with
some
>>>> futher discussion about fixing it.   Since there's so
little found
>>>> when
>>>> Googling, I have to believe that this has been fixed since I
would
>>>> expect there to be a lot more complaints from people like
myself
>>>> who are
>>>> migrating files from windows to samba.
>>>>
>>>> Any feedback is welcome, even if the advice is to change
ownership to
>>>> something other than builtin\Administrators because that's
broken.  :)
>>>>
>>> Does 'getent group BUILTIN\\Administrators'  give any
result ?
>>> If smb.conf is setup correctly, you should get something like:
>>>
>>> BUILTIN\administrators:x:2001:
>>>
>>> If you do not get anything, then you need to change smb.conf, in
which
>>> case, can you post your smb.conf.
>>>
>>> Rowland
>>>
>>>
>> Rowland,
>>
>> 'getent group BUILTIN\Administrators' returns nothing.  Yes,
this is a
>> domain member, not AD.
>
> Well, I think that explains it, on a domain member in my domain, it
> returns a result and I (as root) can chgrp a file to
> 'BUILTIN\Administrators'
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.
>
> I know very little about freebsd (I think freenas runs on freebsd) but
> does it use PAM ? because I think this is your problem, winbind isn't
> returning the BUILTIN info, is libnss_winbind setup ? does freenas use
> libnss_winbind ?
>
Yes Freebsd.  uname -a shows: "FreeBSD 9.3-RELEASE-p31"
smbstatus shows Samba version 4.1.21

I know it's using LDAP to talk to the DC since
/usr/local/etc/openldap.ldap.conf contains my DC's info. /etc/krb5.conf
also contains my domain's info, and inside of that is a setting for pam
(forwardable = true). /etc/nsswitch.conf shows:
group: files winbind
passwd: files winbind

there is a /etc/pam.d/samba file, so I'd have to say, yes pam is part of
the system here, and winbind is tied into that.
> Rowland
>
>>
>> My /usr/local/etc/smb4.conf file should be "default" for
FreeNAS
>> FreeNAS-9.3-STABLE-201602031011.  I believe the gui is the only
>> recommended way to alter it ( think any hand editing gets wiped at
>> reboot?). The only changes I've made through the GUI is to disable
>> oplocks for one of the shares [applied]. The share I've been
testing
>> from however is [deploy].
>>
>> If it helps, 'net groupmap list verbose' returns this:
>>
>> Administrators
>>          SID       : S-1-5-32-544
>>          Unix gid  : 90000001
>>          Unix group: BUILTIN\administrators
>>          Group type: Local Group
>>          Comment   :
>> Users
>>          SID       : S-1-5-32-545
>>          Unix gid  : 90000002
>>          Unix group: BUILTIN\users
>>          Group type: Local Group
>>          Comment   :
>>
>> Here's the smb4.conf file contents:
>> [global]
>>      server max protocol = SMB2
>>      encrypt passwords = yes
>>      dns proxy = no
>>      strict locking = no
>>      oplocks = yes
>>      deadtime = 15
>>      max log size = 51200
>>      max open files = 942185
>>      load printers = no
>>      printing = bsd
>>      printcap name = /dev/null
>>      disable spoolss = yes
>>      getwd cache = yes
>>      guest account = nobody
>>      map to guest = Bad User
>>      obey pam restrictions = yes
>>      directory name cache size = 0
>>      kernel change notify = no
>>      panic action = /usr/local/libexec/samba/samba-backtrace
>>      nsupdate command = /usr/local/bin/samba-nsupdate -g
>>      server string = FreeNAS Server
>>      ea support = yes
>>      store dos attributes = yes
>>      lm announce = yes
>>      hostname lookups = yes
>>      acl allow execute always = true
>>      acl check permissions = true
>>      dos filemode = yes
>>      multicast dns register = yes
>>      domain logons = no
>>      idmap config *: backend = tdb
>>      idmap config *: range = 90000001-100000000
>>      server role = member server
>>      netbios name = FREENAS
>>      workgroup = MMIA
>>      realm = INTRANET.MITCHELLANDMITCHELL.COM
>>      security = ADS
>>      client use spnego = yes
>>      cache directory = /var/tmp/.cache/.samba
>>      local master = no
>>      domain master = no
>>      preferred master = no
>>      ads dns update = yes
>>      winbind cache time = 7200
>>      winbind offline logon = yes
>>      winbind enum users = yes
>>      winbind enum groups = yes
>>      winbind nested groups = yes
>>      winbind use default domain = no
>>      winbind refresh tickets = yes
>>      idmap config MMIA: backend = rid
>>      idmap config MMIA: range = 20000-90000000
>>      allow trusted domains = no
>>      client ldap sasl wrapping = plain
>>      template shell = /bin/sh
>>      template homedir = /home/%D/%U
>>      pid directory = /var/run/samba
>>      create mask = 0666
>>      directory mask = 0777
>>      client ntlmv2 auth = yes
>>      dos charset = CP437
>>      unix charset = UTF-8
>>      log level = 1
>>
>>
>> [applied]
>>      path = /mnt/trunk/MM/applied
>>      printable = no
>>      veto files = /.snapshot/.windows/.mac/.zfs/
>>      writeable = yes
>>      browseable = yes
>>      shadow:snapdir = .zfs/snapshot
>>      shadow:sort = desc
>>      shadow:localtime = yes
>>      shadow:format = auto-%Y%m%d.%H%M-1w
>>      shadow:snapdirseverywhere = yes
>>      vfs objects = shadow_copy2 zfs_space zfsacl aio_pthread
>> streams_xattr
>>      hide dot files = yes
>>      guest ok = no
>>      nfs4:mode = special
>>      nfs4:acedup = merge
>>      nfs4:chown = true
>>      zfsacl:acesort = dontcare
>>      veto oplock files = /*.dbf/*.DBF/*.ndx/*.NDX/
>>
>>
>> [deploy]
>>      path = /mnt/trunk/MM/deploy
>>      printable = no
>>      veto files = /.snapshot/.windows/.mac/.zfs/
>>      writeable = yes
>>      browseable = yes
>>      shadow:snapdir = .zfs/snapshot
>>      shadow:sort = desc
>>      shadow:localtime = yes
>>      shadow:format = auto-%Y%m%d.%H%M-1w
>>      shadow:snapdirseverywhere = yes
>>      vfs objects = shadow_copy2 zfs_space zfsacl aio_pthread
>> streams_xattr
>>      hide dot files = yes
>>      guest ok = no
>>      nfs4:mode = special
>>      nfs4:acedup = merge
>>      nfs4:chown = true
>>      zfsacl:acesort = dontcare
>>
>>
>> [eim]
>>      path = /mnt/trunk/MM/applied/EIM
>>      printable = no
>>      veto files = /.snapshot/.windows/.mac/.zfs/
>>      writeable = yes
>>      browseable = yes
>>      shadow:snapdir = .zfs/snapshot
>>      shadow:sort = desc
>>      shadow:localtime = yes
>>      shadow:format = auto-%Y%m%d.%H%M-1w
>>      shadow:snapdirseverywhere = yes
>>      vfs objects = shadow_copy2 zfs_space zfsacl aio_pthread
>> streams_xattr
>>      hide dot files = yes
>>      guest ok = no
>>      nfs4:mode = special
>>      nfs4:acedup = merge
>>      nfs4:chown = true
>>      zfsacl:acesort = dontcare
>>
>>
>> [home]
>>      path = /mnt/trunk/MM/home
>>      printable = no
>>      veto files = /.snapshot/.windows/.mac/.zfs/
>>      writeable = yes
>>      browseable = yes
>>      shadow:snapdir = .zfs/snapshot
>>      shadow:sort = desc
>>      shadow:localtime = yes
>>      shadow:format = auto-%Y%m%d.%H%M-1w
>>      shadow:snapdirseverywhere = yes
>>      vfs objects = shadow_copy2 zfs_space zfsacl aio_pthread
>> streams_xattr
>>      hide dot files = yes
>>      guest ok = no
>>      nfs4:mode = special
>>      nfs4:acedup = merge
>>      nfs4:chown = true
>>      zfsacl:acesort = dontcare
>>
>>
>> [profiles]
>>      path = /mnt/trunk/MM/profiles
>>      printable = no
>>      veto files = /.snapshot/.windows/.mac/.zfs/
>>      writeable = yes
>>      browseable = yes
>>      shadow:snapdir = .zfs/snapshot
>>      shadow:sort = desc
>>      shadow:localtime = yes
>>      shadow:format = auto-%Y%m%d.%H%M-1w
>>      shadow:snapdirseverywhere = yes
>>      vfs objects = shadow_copy2 zfs_space zfsacl aio_pthread
>> streams_xattr
>>      hide dot files = yes
>>      guest ok = no
>>      nfs4:mode = special
>>      nfs4:acedup = merge
>>      nfs4:chown = true
>>      zfsacl:acesort = dontcare
>>
>>
>> [shared]
>>      path = /mnt/trunk/MM/shared
>>      printable = no
>>      veto files = /.snapshot/.windows/.mac/.zfs/
>>      writeable = yes
>>      browseable = yes
>>      shadow:snapdir = .zfs/snapshot
>>      shadow:sort = desc
>>      shadow:localtime = yes
>>      shadow:format = auto-%Y%m%d.%H%M-1w
>>      shadow:snapdirseverywhere = yes
>>      vfs objects = shadow_copy2 zfs_space zfsacl aio_pthread
>> streams_xattr
>>      hide dot files = yes
>>      guest ok = no
>>      nfs4:mode = special
>>      nfs4:acedup = merge
>>      nfs4:chown = true
>>      zfsacl:acesort = dontcare
>>
>>
>> Appreciate any insight.  Note that this server is not "live"
yet, so I'm
>> game to experiment with any ideas you may have.
>>
>>
>
>

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:

chown foo:somegroup somefile

this would make 'foo' the owner of the file and possibly allow 
'somegroup' access to it, this would depend on whatever permissions you 
set with 'chmod'

So, as far as Unix is concerned, you shouldn't be able to chown a file 
to 'BUILTIN\Administrators' because it is a group (g) and not a user (u)

Rowland

> 
> Normally a group cannot 'own' files etc, Unix uses ugo permissions
and
> when you chown a file you would use something like this:
> 
> chown foo:somegroup somefile
> 
> this would make 'foo' the owner of the file and possibly allow 
> 'somegroup' access to it, this would depend on whatever permissions
you
> set with 'chmod'
> 
> So, as far as Unix is concerned, you shouldn't be able to chown a file 
> to 'BUILTIN\Administrators' because it is a group (g) and not a
user (u)
> 
On my Samba 4 AD Domain Controler I can chown to
'BUILTIN\Administrators'
alright. Not on my member servers, though.

> Normally a group cannot 'own' files etc, Unix uses ugo permissions
and
> when you chown a file you would use something like this:
> 
> chown foo:somegroup somefile
> 
> this would make 'foo' the owner of the file and possibly allow 
> 'somegroup' access to it, this would depend on whatever permissions
you
> set with 'chmod'
> 
> So, as far as Unix is concerned, you shouldn't be able to chown a file 
> to 'BUILTIN\Administrators' because it is a group (g) and not a
user (u)
> 
As a matter of fact, I can chown to any group, including AD ones, on the AD 
DC and member servers. On members servers not to BUILTIN groups, though. 

Using Samba 4.2.8 on CentOS 6 and CentOS 7.

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?