Bug 11757 - Cannot set BUILTIN\Administors as owner for files and folders hosted on a Samba member server
Summary: Cannot set BUILTIN\Administors as owner for files and folders hosted on a Sam...
Status: RESOLVED WORKSFORME
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Winbind (show other bugs)
Version: 4.2.8
Hardware: x64 FreeBSD
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-25 18:18 UTC by Ian (mail bounces back)
Modified: 2020-02-14 19:58 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ian (mail bounces back) 2016-02-25 18:18:31 UTC
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.

Example of AD groups being assigned as owner working:

"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 getent sees this is a group, I can use this id for the
owner of a folder:

chown "DOMAIN\Domain Admins" CoreLib/

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

chown is not using the group id, it's using a user id that's the same as the
group id.  I assume Samba does this slight of hand because Windows doesn't differentiate between users and groups the way that nix does.

So lets try with BUILTIN\Administrators instead:

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

However, doing a reverse lookup 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 assigning "DOMAIN\Domain Admins' as both an owner and a group:
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 id internal to Samba.

This breaks the behavior Microsoft documented in that URL above.
Comment 1 Stefan Metzmacher 2016-02-26 12:32:55 UTC
I'm pretty sure this works if you use a idmap backend that
supports ID_TYPE_BOTH. Currently this is only supported
by the "rid", "autorid" and "script" (if the script supports it)
on a member or standalone server. It should always work
on an active directory domain controller.
Comment 2 Stefan Metzmacher 2016-02-26 12:34:44 UTC
(In reply to Stefan Metzmacher from comment #1)

What idmap configuration are you using?
Comment 3 Ian (mail bounces back) 2016-02-26 15:44:25 UTC
It's the default setup used by the FreeNAS folks. I looked for help from the FreeNAS community first, but they were out of ideas:
https://forums.freenas.org/index.php?threads/ownership-issues-migrating-data-from-windows-to-freenas.41478/

I then tried the samba list server, but Andrew just said I couldn't because "sysvol."  When I asked for additional details, he never responded:

https://lists.samba.org/archive/samba/2016-February/197771.html

[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 = DOMAIN
    realm = INTRANET.DOMAIN.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 DOMAIN: backend = rid
    idmap config DOMAIN: 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

[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
Comment 4 Ian (mail bounces back) 2016-02-26 15:51:50 UTC
It looks like I can drop-n replace tdb with autorid?  Leave all the other numbers the same?  As far as I know, we'd only use that configuration for non AD accounts, so really, just BUILTIN\*
Comment 5 Stefan Metzmacher 2016-02-26 16:38:56 UTC
(In reply to Ian from comment #4)

yes, or:

    idmap config BUILTIN: backend = rid
    idmap config BUILTIN: range = 100000000-110000000

If this is a new installation just using autorid as default
and no per DOMAIN config:

    idmap config *: backend = autorid
    idmap config *: range = 20000-100000000
Comment 6 Ian (mail bounces back) 2016-02-26 17:00:53 UTC
Here's my idmap setup now (I incremented the number range you gave so that there wouldn't be any overlap):

    idmap config *: backend = tdb
    idmap config *: range = 90000001-100000000
    idmap config DOMAIN: backend = rid
    idmap config DOMAIN: range = 20000-90000000
    idmap config BUILTIN: backend = rid
    idmap config BUILTIN: range = 100000001-110000000

However, I'm still not able to change the owner, and now it seems I can't even lookup the group id:

id -u 'BUILTIN\Administrators'
id: BUILTIN\Administrators: no such user

id -g 'BUILTIN\Administrators'
id: BUILTIN\Administrators: no such user

getent group 'BUILTIN\Administrators'
BUILTIN\administrators:x:90000001

chown 'BUILTIN\Administrators' CoreLib/
chown: BUILTIN\Administrators: illegal user name
Comment 7 Ian (mail bounces back) 2016-02-26 17:25:13 UTC
I noticed that gentent is still returning an id from the TDB backend:

getent group 'BUILTIN\Administrators'
BUILTIN\administrators:x:90000001

Is this a cache issue?

I tried renaming the winbindd_cache.tb file and restarting the service, but that didn't help so I put it back.

Here's the contents of my /var/db/samba4 folder:

-r--------  1 root  wheel        0 Jan  4 11:38 .usersimported
-rw-------  1 root  wheel   421888 Feb  7 18:13 account_policy.tdb
-rw-r--r--  1 root  wheel    40200 Feb 26 09:22 brlock.tdb
-rw-------  1 root  wheel      696 Feb 26 09:22 dbwrap_watchers.tdb
-rw-r--r--  1 root  wheel      696 Jul 27  2015 gencache.tdb
-rw-r--r--  1 root  wheel   430080 Feb 26 09:23 gencache_notrans.tdb
-rw-------  1 root  wheel   425984 Jul 27  2015 group_mapping.tdb
-rw-r--r--  1 root  wheel    86016 Feb 26 09:23 locking.tdb
-rw-------  1 root  wheel    16384 Feb 26 09:23 messages.tdb
-rw-------  1 root  wheel      696 Feb 26 09:23 mutex.tdb
-rw-r--r--  1 root  wheel     3473 Feb 22 14:56 namelist.debug
-rw-r--r--  1 root  wheel    12288 Feb 26 09:23 notify.tdb
-rw-r--r--  1 root  wheel     8192 Feb 26 09:23 notify_index.tdb
-rw-r--r--  1 root  wheel    12288 Feb 22 14:56 printer_list.tdb
drwx------  2 root  wheel        6 Feb 26 09:22 private/
-rw-------  1 root  wheel   528384 Jul 27  2015 registry.tdb
-rw-r--r--  1 root  wheel     8192 Feb 26 09:23 serverid.tdb
-rw-------  1 root  wheel   421888 Jul 27  2015 share_info.tdb
-rw-------  1 root  wheel    28672 Feb 26 09:23 smbXsrv_open_global.tdb
-rw-------  1 root  wheel    36864 Feb 26 09:23 smbXsrv_session_global.tdb
-rw-------  1 root  wheel    16384 Feb 26 09:23 smbXsrv_tcon_global.tdb
-rw-------  1 root  wheel    16384 Feb 26 09:23 smbXsrv_version_global.tdb
drwxr-xr-x  2 root  wheel        3 Feb 26 09:23 smb_krb5/
-rw-------  1 root  wheel  2527232 Feb 26 09:23 winbindd_cache.tdb
-rw-------  1 root  wheel   630784 Feb 26 09:22 winbindd_cache.tdb.bak
-rw-------  1 root  wheel    28672 Feb 26 09:21 winbindd_cache.tdb.bak.old
-rw-r--r--  1 root  wheel   421888 Sep  9 06:49 winbindd_idmap.tdb
drwxr-x---  2 root  wheel        3 Feb 26 09:22 winbindd_privileged/
Comment 8 Ian (mail bounces back) 2016-03-04 16:48:01 UTC
Stephan,

Is there anything more I can do here for you? Can you confirm that it is indeed possible to assign builtin\groups as owners using backends with ID_TYPE_BOTH?

Also, isn't it still considered a bug if tdb doesn't support this?  I mean if Samba isn't performing like a similarly configured Windows machine, should that be considered a bug?
Comment 9 Stefan Metzmacher 2016-04-13 15:05:27 UTC
(In reply to Ian from comment #8)

Implementing this for the tdb backend would be nice, but it's more a missing feaeture than a bug