Re: [Samba] Domain Administrator and shares problems
- Date: Wed, 10 Oct 2018 11:08:44 +0200
- From: Peter Milesson via samba <samba@xxxxxxxxxxxxxxx>
- Subject: Re: [Samba] Domain Administrator and shares problems
On 10/10/18 10:43 AM, Christian Naumer via samba wrote:
Am 10.10.18 um 10:27 schrieb Peter Milesson via samba:
On 10/9/18 10:41 PM, Rowland Penny via samba wrote:
On Tue, 9 Oct 2018 22:16:41 +0200
Peter Milesson <miles@xxxxxxxx> wrote:
On 09.10.2018 21:25, Rowland Penny via samba wrote:
On Tue, 9 Oct 2018 19:44:55 +0200
Peter Milesson via samba <samba@xxxxxxxxxxxxxxx> wrote:
I made a fresh install of the AD DC, a member server, and a Windows
10 PC that was never part of any domain. Authentication works,
Active Directory works, DNS works, the Administrator can add,
edit, and delete entries. The AD DC running CentOS 7.5, with a
self compiled Samba 4.9.1. The member server using CentOS 7.5 with
Samba 4.7.1 from standard distribution packages. I have also
tested a self compiled Samba 4.9.1 as domain member. The
configurations are identical to the ones used in production.
Firewalls disabled, as is SeLinux on both Linux boxes.
However, file sharing is a complete disaster. The Samba member
server automatically uses ACLs when creating files and folders,
which the production server doesn't. Everything positive ends
here. The rest of the process using Windows Computer Manager for
setting up the share parameters, is completely derailed.
If the domain Administrator, Domain Admins, or any account with
Administrator privileges figure anywhere, everything is completely
When you say blocked, do you mean you get an error message like this
when you click on the 'security' tab:
You do not have permission to view to view or edit this object’s
I set up a totally new centos 7 VM and installed Samba, but somehow
I missed out the user.map line and I got that error. Added the line:
username map = /etc/samba/user.map
created the user.map:
!root = SAMDOM\Administrator SAMDOM\administrator Administrator
Restarted Samba and it now works.
Unix permissions before attempting any changes from windows:
[root@cen7member ~]# ls -lad /data/samba/profiles
drwxrwx--- 2 root unix admins 6 Oct 9 19:13 /data/samba/profiles
After adding a user to the share from windows 'Security' tab:
Edit -> Add -> Advanced -> Find Now -> select user (Rowland Penny)
-> OK -> OK -> standard permissions: Read & execute, List folder
[root@cen7member ~]# ls -lad /data/samba/profiles
drwxrwx---+ 2 root unix admins 6 Oct 9 19:13 /data/samba/profiles
And the extend ACLs now set:
[root@cen7member ~]# getfacl /data/samba/profiles
getfacl: Removing leading '/' from absolute path names
# file: data/samba/profiles
# owner: root
# group: unix\040admins
I'll get on my bike and take a trip in the countryside tomorrow,
instead of fighting wind mills...
Yes, I always find walking away and returning later usually
Thanks a lot for your support Rowland. I've tried those steps, but no
success. On the contrary. Just not possible to change anything. The
security object list is displayed, but no changes are possible.
Windows complaining about insufficient permissions. I have not forgot
the username map in the smb.conf file, neither did I forget to set
I'll put it on the shelf for some time. At least I've got a working
setup in the production server for now. Nothing will probably change
there for at least a couple of years. But I've got very strong doubts
about the current security level, with the Everyone group working as
a stand in for Domain Admins, and a domain Administrator that's seems
to have got privileges just north of the Guest account.
You seem to be fixated on the 'share' tab, ignore this and concentrate
on the 'security' tab (would it help if I said a better name for the
tab would 'NTFS permissions' ?). You should also be aware (From a Unix
perspective) that there are three permissions storages in play:
the standard 'ugo'
Extend ACLs as shown by getfacl
Extended attributes stored in security.NTACL on the directory or
I'll give Samba a try under Slackware. I've set up a bunch of Samba
servers under Slackware since around 2002, or so. But the previous
ones were always PDCs. That path seems now closed, however, with MS
probably scrapping the NT1 protocol in the immediate future.
Slackware had very quirky support for LDAP, and pam integration
impossible, making any kind of AD stuff extremely tricky. But the
recent Samba versions have got most of the parts that were missing
from Slackware built in. So I'll give it a try, but in a few weeks
There is a GUY who posts on here regularly who uses Slackware, he is
probably one you need here.
However, if you are considering a different OS, how about Debian (or
Devuan), you could the use Louis's packages and get the most up to date
I will sort out my notes and send you a copy, I feel you must have a
simple mistake that is causing your problem.
I tried Debian as Samba member server as a test a few days ago.
Functionally no difference to CentOS. So I just continued with CentOS
for the production server.
About my problems. I follow the instructions for setting up a share.
This time I assigned myself as a testuser to the Domain Admins group,
and after that, there is no way to get any further. In the shares list,
the Domain Users, and Domain Admins groups are displayed. Switching over
to the security tab, different groups and users are displayed. Yes, they
are displayed, which would be considered a great step forward. But
trying to change anything there it just don't work. It just complains
that I have got insufficient permissons to make any changes. Any changes
The folder looks the following:
drwxr-xr-x. 3 root root 4096 Oct 9 15:55 .
drwxr-xr-x. 3 root root 4096 Oct 9 15:54 ..
drwxr-xr-x. 2 root domain admins 4096 Oct 9 15:55 wandafishand
# file: wandafish
# owner: root
# group: domain\040admins
Having the "wrong" users or groups in the share tab, gives a blank
security tab. On the production server group Everyone with full
permissions is required, otherwise the security tab does not show up. In
my test environment, I assigned myself to the Domain Admins group. After
that I really don't get anywhere.
As I told you, I will put it on ice for a few weeks, and consider
alternatives. IMHO, the choice of OS probably plays a big role here.
CentOS has got far too much stuff running in the background, interfering
if it considers necessary. Even with SeLinux and the firewall disabled.
I need to have something with better control of the running processes.
Slackware has precisely got that. I'll report back.
It looks like you gave Domain Admins a gid. This is considered a bad
idea as the group needs to own files on the DC in Sysvol. Rowland works
around this by creating a group Unix Admins and adds this group to the
Domain Admins group. This way you can work on the filesystem with "unix
Admins" (which has a gid) and still have the privileges of Domain Admins.
In our setup (also classic upgraded) I try to avoid Administrator and
Domain Admins in file security operations. Have you tried using a
"normal" group giving this the rights you want on the cli and tried to
set security i´on Windows with a user in that group?
No, I did not give Domain Admins a gid. Nobody in the AD has got neither
a gid, nor uid. What you describe is similar what is working on my
production server. There I gave the Administrator account a uid, and a
gid (both 0). Didn't solve anything. The Administrator account is
completly dysfunctional. And user mapping just plain not working, or
works in ways that either are not documented, or what I misinterpret.
I will leave it as it is for a while, and return back later. From and
administrators point of view, I'm extremely dissatisfied with the
Thanks for your input.
To unsubscribe from this list go to the following URL and read the