[Samba] Domain Administrator and shares problems

Rowland Penny rpenny at samba.org
Mon Oct 8 19:02:09 UTC 2018


On Mon, 8 Oct 2018 18:53:45 +0200
Peter Milesson via samba <samba at lists.samba.org> wrote:

> Hi folks,

> Problem
> =======
> Setting up and managing the shares on the Samba member server differs 
> significantly from the Samba Wiki documentation. It seems that the 
> domain Administrator account, and the Domain Admins group haven't got 
> any elevated privileges whatsoever. On the contrary, it seems the 
> privileges are even lower than for the Anyone group. This resulted in
> a very quirky and non standard way of share setup and management.
> 
> The different steps I have gone through are described below.
> 
> I follow the step-by-step description in the Wiki 
> (https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs)
> 
> - The folder for the share is created
> - The Linux ownership and permissions of the folder are set 
> (root:"Domain Admins" and 0770)
> - The share is defined in smb.conf on the member server
> - Restarting the daemons (nmbd winbindd smbd)

Try running this on the Unix domain member:
net rpc rights list privileges SeDiskOperatorPrivilege -S $(hostname
-f) -k -P

It should give you something like this:

SeDiskOperatorPrivilege:
  BUILTIN\Administrators

If you then run this on a DC:

samba-tool group listmembers Administrators

You should get this:

Domain Admins
Enterprise Admins
Administrator

This shows that both 'Domain Admins' & 'Administrator' both have the
required privileges.

> - Logging in as domain Administrator on a Windows PC
> - Opening up Computer Management in Windows
> - Connecting to the samba member server
> - Clicking on Shared folders, a long error message about DCOM is 
> displayed, but the shares on the member server is displayed anyway.

You can ignore the message, as you have found out, it is meaningless.

> - Selecting the share, right click and selecting Properties, and
> Share Permissions tab
> - Setting Domain Users having Read & Change permissions, and Domain 
> Admins Full Control, removing Everyone from the list

Don't remove anything, in fact, ignore the share permissions tab.

> - Switching to the Security tab, which is blank, which effectively

Now here is a problem, it shouldn't be blank, is a firewall running on
the Unix domain member holding the 'Profiles' share ?

> means that anything that deals with security is not available to the
> accounts Domain Users and Domain Admins. Which in turn implies that
> none of those groups can do anything with the share (i.e. lacking
> administrative permissions).

It should work, check that smbd, nmbd & winbind are running and not
being blocked by anything.

> - It could stop here. But...
> 
> - Going back to the Share Permissions tab and adding Everyone with
> full share permissions
> - Once again going to the Security tab, which now displays all the 
> default permissions. One of the users in the list is for example Unix
> root
> - Now it is possible to add different security objects and set 
> permissions. But adding the domain Administrator to the security
> objects list is almost a guarantee to get into trouble, no matter
> what permissions the Administrator is given.
> 
> I succeeded to setup working shares on the Samba member server this
> way, but it feels wrong, and it's definitely not the standard way to
> do things.
> 
> Besides, on the Samba member server also, the domain Administrator 
> account behaves like a normal user account, not like the root

I think you may be operating under a misapprehension, Windows users are
just Windows users and Unix users are just Unix users. You can map
Windows users to Unix users or make them Unix users by giving them a
uidNumber attribute or using the winbind 'rid' backend, but making a
Windows user a Unix user, just gives it the same rights as any other
Unix user.
When you map 'Administrator' to the Unix user 'root', Administrator
becomes root, with all the rights that root has, this means
Administrator can do anything on Unix.
The Windows user Administrator shouldn't really log into a Unix
machine, just as the Unix user root shouldn't be able to log into a
Windows machine.

> account, like this on the folder grulf:
> 
> (using root)  drwxrwx---   2 root domain admins 4096 Oct  8 18:19
> grulf
> 
> (using adminstrator) drwxrwx---   2 administrator domain admins 4096 
> Oct  8 18:19 grulf

Yes, it does show it isn't working for you, but not for the reason you
think ;-)

[root at cen1804 ~]# ls -la /data/samba
total 4
drwxr-xr-x  4 root root        41 Oct  8 18:37 .
drwxr-xr-x  3 root root        19 Oct  8 18:37 ..
drwxr-xr-x  2 root root         6 Oct  8 18:37 common_docs
drwxrwxr-x+ 2 root unix admins  6 Oct  8 18:37 profiles

If you look carefully at the line that ends in 'profiles', you will see
a '+' sign, this means that ACL's are set on the share.

[root at cen1804 ~]# getfacl /data/samba/profiles/
getfacl: Removing leading '/' from absolute path names
# file: data/samba/profiles/
# owner: root
# group: unix\040admins
user::rwx
user:root:rwx
user:12122:rwx
group::r-x
group:root:r-x
group:unix\040admins:rwx
mask::rwx
other::r-x
default:user::rwx
default:user:root:rwx
default:user:12122:rwx
default:group::r-x
default:group:root:r-x
default:group:unix\040admins:rwx
default:mask::rwx
default:other::r-x

and if I return to my Win7 VM running ADUC and add myself to the
security tab:

[root at cen1804 ~]# getfacl /data/samba/profiles/
getfacl: Removing leading '/' from absolute path names
# file: data/samba/profiles/
# owner: root
# group: unix\040admins
user::rwx
user:root:rwx
user:rowland:r-x
user:12122:rwx
group::rwx
group:root:r-x
group:rowland:r-x
group:unix\040admins:rwx
mask::rwx
other::r-x
default:user::rwx
default:user:root:rwx
default:user:rowland:r-x
default:user:12122:rwx
default:group::r-x
default:group:rowland:r-x
default:group:unix\040admins:rwx
default:mask::rwx
default:other::r-x

So, you can see that it does work.

What filesystem are you using ?

> 
> smb.conf AD DC
> =============
> [global]
>          netbios name = KONADC
>          realm = SAMDOM.LOCAL
>          server role = active directory domain controller
>          workgroup = SAMDOM
>          idmap_ldb:use rfc2307 = yes
>          username map = /etc/samba/user.map

You do not use a 'user.map' on a DC, it uses idmap.ldb instead

Rowland




More information about the samba mailing list