[Samba] Domain Administrator and shares problems

Peter Milesson miles at atmos.eu
Mon Oct 8 16:53:45 UTC 2018 

Hi folks,

Hardware/OS
===========

- Samba AD DC ver. 4.9.1 (compiled using standard CentOS tools and 
libraries) functions only as AD server (authentication, AD services), 
migrated from old Samba NT PDC through classicupgrade, OS CentOS 7.5, 
kernel 4.9.40 (elrepo-lt), VM under Xen 4.9.0

- Samba AD member server ver. 4.7.1 (from distribution) with different 
shares for different user groups,  OS CentOS 7.5, kernel 3.10.0 (latest 
CentOS 7 kernel), winbind works, authentication to the AD DC works, 
SeDiskOperatorPrivilege is set for the Domain Admins group, a username 
map entry exists in smb.conf, and pointing to the correct map file, 
testparm does not complain about anything, the member server is 
successfully joined to the domain.

- Windows PCs of different origin with Windows 10 Professional (1803), 
connect to the shares on the Samba member server above. One of the PCs 
has got the RSAT tool installed for management of the domain AD. The 
Computer Management snap-in is also used for managing the shares on the 
Samba member server above.

The smb.conf for the AD DC and the member server are last in this post.


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)
- 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.
- 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
- Switching to the Security tab, which is blank, which effectively 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 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 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

AFAIK, the Administrator account, or Domain Admins group do not seem to 
have any special privileges on the Samba member server:
#getent group "Domain Admins"
domain admins:x:10512:administrator,miles
#getent passwd Administrator
administrator:*:10500:10513::/home/administrator:/sbin/nologin

which at least shows that assigning homeDirectory in the ADUC tool works...

the implication here is, that neither the "Domain Admins" group, nor the 
Administrator user have got any special privileges in the Samba box. And 
that's the case under Windows also.


Solutions?
========
I have tried different ideas ad nauseam and is quite stuck at present. 
It does work, sort of, but I am not really happy about it, as the steps 
differ significantly from standard behavior. I would be really grateful 
for any ideas what is wrong here, and what steps are possible to correct it.

Best regards,

Peter


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
         dns forwarder = 192.168.0.221

[netlogon]
         path = /var/lib/samba/sysvol/samdom.local/scripts
         read only = No

[sysvol]
         path = /var/lib/samba/sysvol
         read only = No


smb.conf member server (with example share)
====================
[global]
    workgroup = SAMDOM
    realm = SAMDOM.LOCAL
    security = ads
    netbios name = KONSRV
    server string = Samdom member server %h

    username map = /etc/samba/user.map

#   template homedir = /dev/null
    template homedir = /home/%U
    template shell = /sbin/nologin
#   template shell = /bin/bash
    winbind use default domain = true
    winbind offline logon = true
#   winbind normalize names = Yes

    idmap config * : backend = tdb
    idmap config * : range = 3000-9999
    idmap config SAMDOM:backend = rid
    idmap config SAMDOM:range = 10000-99999

    local master = no
    domain master = no
    preferred master = no
    os level = 20
    map to guest = bad user
    host msdfs = no


    dedicated keytab file = /etc/krb5.keytab
    kerberos method = secrets and keytab
    winbind refresh tickets = Yes
    client signing = mandatory

    winbind enum users = yes
    winbind enum groups = yes
    winbind expand groups = 4

    printing = bsd
    printcap name = /dev/null
    load printers = no
    disable spoolss = yes

    vfs objects = acl_xattr
    map acl inherit = yes
    store dos attributes = yes
    inherit acls = yes
    acl group control = yes

    hide unreadable = yes
    veto files = /.bash_logout/.bash_profile/.bash_history/.bashrc/
    unix extensions = yes
    reset on zero vc = yes

[Profiles$]
         readonly = no
         path = /data/samba/profiles

[Users$]
         readonly = no
         path = /home

[Docs]
         readonly = no
         path = /data/samba/common_docs

More information about the samba mailing list