[Samba] Can one set the owner of a folder to BUILTIN\Administrators?

[Ian]

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. :)

--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

[Rowland penny]

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

[L.P.H. van Belle]

Rowland,
If this is a DC.. and like me with config :
idmap config * : range = 2000-9999

getent group BUILTIN\\Administrators
BUILTIN\Administrators:*:3000000:


Looks like about the same problem.

Greetz

Louis




> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-...@lists.samba.org] Namens Rowland penny
> Verzonden: woensdag 17 februari 2016 14:00
> Aan: sa...@lists.samba.org
> Onderwerp: Re: [Samba] Can one set the owner of a folder to
> BUILTIN\Administrators?

[Rowland penny]

On 17/02/16 13:14, L.P.H. van Belle wrote:
> Rowland,
> If this is a DC.. and like me with config :
> idmap config * : range = 2000-9999
>
> getent group BUILTIN\\Administrators
> BUILTIN\Administrators:*:3000000:
>
>
> Looks like about the same problem.
>
> Greetz
>
> Louis
>

That is what I get on a DC, but what you have to understand is, idmap on
a DC works differently from a domain member.

A domain member asks winbind for 'BUILTIN\Administrators' ID, this is
obtained from AD, assigned a local ID and stored in a .tdb file, the
number that is assigned is based on the low range in 'idmap config *:'

A DC is slightly different, IDs are stored in idmap.ldb and are based on
a range that starts at 3000000.

As far as I am aware, the idmap lines that you use on DC have no affect,
I know that 'windbind use default domain' did work on a 4.2.x DC, but I
think this was the only one of your lines that did. I will have to check
my test DC to find out.

[Andrew Walker]

My apologies. I initially responded to Rowland's email address rather than
the list address.

Based on original email, this is a FreeNAS server configured as an AD
member server. I believe the default smb.conf for a FreeNAS AD member
server contains the following:
[global]
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
unix extensions = no
acl allow execute always = true
acl check permissions = true
dos filemode = yes
domain logons = no
idmap config *: backend = tdb
idmap config *: range = 90000001-100000000
server role = member server
netbios name = FREENAS
workgroup = DOMAIN
realm = DOMAIN.COM <http://domain.com/>
security = ADS
client use spnego = yes
cache directory = /var/tmp/.cache/.samba
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 = yes
winbind refresh tickets = yes
idmap config DOMAIN: backend = rid
idmap config DOMAIN: range = 20000-90000000
allow trusted domains = no
client ldap sasl wrapping = plain
pid directory = /var/run/samba
client ntlmv2 auth = yes

Never noticed this behavior before, but I never tried to change ownership
of files through windows explorer to BUILTIN\Administrators. On my my AD
member server there are no entries for BUILTIN groups in the "getent group"
output.

However, "net groupmap list verbose" outputs the following:
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 :

There aren't any groupmap entries for the remaining BUILTIN groups. There
are no entries for BUILTIN groups in "getent group" output. Don't know if
this helps identify the problem.

[Ian]

Rowland,

'getent group BUILTIN\Administrators' returns nothing. Yes, this is a
domain member, not AD.

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.

[Rowland penny]

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'

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 ?

Rowland

[Ian]

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@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 penny]

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@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

[Miguel Medalha]

> 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.

[Rowland penny]

On 17/02/16 19:28, Miguel Medalha wrote:
>> 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.

I can understand this on DC, if you look in idmap.ldb , some groups are
identified as 'ID_TYPE_BOTH'. This means they are both a user and a group.
On a domain member this doesn't work i.e. chown BUILTIN\\Administrators
testdir/testfile returns:

chown: invalid user: `BUILTIN\\Administrators'

Rowland

[Ian]

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@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?

[Miguel Medalha]

>
> 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.

[Rowland penny]

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

[Ian]

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.

[Ian]

No reply?

Maybe I should mention why this is even a "thing."

Microsoft's default behavior is to assign "Administrators" as the owner
of any file or folder when that file or folder is created with an
administrative account (Any member of Administrators). In an AD
environment, this includes the "Domain Admins" group and all of its
members too because any time a computer account is joined to the domain,
one of the things that happens during this process is to add "Domain
Admins" to the local computer's Administrator's group. (Source:
https://technet.microsoft.com/en-us/library/cc961992.aspx)

This behavior is the reason why we have a large number of files and
folders that are owned by that builtin\Administrators group.

Samba, while happy to replace mapped group ID's with user ID's when
assigning ownership of non-builtin groups, refuses to do so for the
builtin groups, but it's not clear why.

Can anyone explain what is tying Samba's hands behind its back here? Or
was there a policy decision against this behavior?