Web lists-archives.com

Re: [Samba] Domain Administrator and shares problems






On 09.10.2018 10:23, Rowland Penny via samba wrote:
On Mon, 8 Oct 2018 22:52:05 +0200
Peter Milesson via samba<samba@xxxxxxxxxxxxxxx>  wrote:

On 08.10.2018 21:02, Rowland Penny via samba wrote:
On Mon, 8 Oct 2018 18:53:45 +0200
Peter Milesson via samba<samba@xxxxxxxxxxxxxxx>  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@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@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@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


Hi Rowland,

Plenty of information here...

Essentially...

- Running net rpc rights list ... etc, and  samba-tool group
listmember Administrator returns exactly what you have got.
- The share permissons tab has got one single entry the first time
it's opened, and that's Everyone, with Full control (see below, about
ACLs)
- If I leave Everyone in the share permissions tab with Full control,
the Security tab displays the default security objects, and is
editable and sort of working. Starting to mix in Administrator here,
and things go wrong...

On purpose, getting things straight before stepping up security, I
have turned off firewalld and selinux on both the AD DC, and the
member server. I have made extra sure that no sssd (neither client,
nor daemon), or other irrelevant daemons are installed. Everything is
just plain as plain as possible. I have really stepped down security
as much as possible here, just to get things working. I'm always
using ext4 file systems. The other file systems on offer are too
experimental to my taste ;-)

I am not trying to get any account defined through AD to login into a
Linux machine. The member server I have set up is intended to work
with Windows ACLs only on all shares. No shell logins with AD users.
No Posix ACLs. The only shell accounts allowed will be local root,
and a local user account with sudo permissions. Likewise, no
connections from the member server to Windows machines. I regard the
Samba member server as any Windows file server in this respect. The
only purpose is to supply shares for different purposes. Nothing else.

IMHO, if I manage the shares through AD, except for the small work of
defining a share in smb.conf, I want the rest of the work to be more
or less agnostic when it comes to management. In this respect, I
really don't care if the server supplying shares is running Linux,
Windows, or BananaOS. The domain administrator has got very extensive
privileges in a Windows environment. Mapping this to root on a Samba
member server is just logical on a domain member server running Samba
in this context. That I prefer Linux over Windows is also irrelevant
here. Those points could be debated till the next Big Bang...
I only have Windows in VMs and only start them when needed, so the
debate would probably be very short, Linux is undoubtedly better than
Windows ;-)

When you show the ACLs above, it's ringing a bell. When running mkdir
under CentOS 7.5, the folder is created with plain Linux permissions,
without using any extended attributes, or ACLs at all. When having
been manipulated via Windows Computer Management, ACLs are also
applied. Maybe this is the problem, that CentOS does not apply ACLs
by default when creating a folder?
I sort of thought the computer name (cen1804) would have shown that
Centos does apply ACLs ;-)

I installed Centos 7 in a VM, accepted the defaults and then installed
Samba. One thing I found out, xfs seems to be the default filesystem,
but ext4 works in roughly the same way.

Anyway, it sort of works, I managed to make the migration from a NT4
PDC (from 2011) to AD without loss of user profiles. In the current
state, the behavior is ugly, but it works, differently from setting
up a share on a Windows server, however. But still, it seems that the
Samba member server still does not honor the privileges of the domain
Administrator, and regards it like "ordinary" user "Donald with very
tiny permissions", belonging to the group "Domain Users".
I think your problem is that you expect Administrator to have the same
rights as root on a Unix machine, it doesn't, it is just another use.
If you use the winbind 'rid' backend, then getent will show the
Administrator user, but the 'ad' backend doesn't (unless you give
Administrator a uidNumber and this is definitely not recommended).
This means that the best thing you can do is, ignore Administrator on
Unix and map it in the user.map to root.
Next step, I'm going to try it out on a freshly setup domain, an AD
DC, a member server, and a Windows domain PC, without any historical
ballast. There may have been lots of garbage left, that's giving
trouble. I don't know, until it's tested.
That might be a good idea, as I said, I used a new install and it
worked for me.

Rowland


Hi Rowland,

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 blocked. For Pete's sake, don't let any user account that is trusted make any changes. Here, the Everyone group is your friend. It seems it has taken the role that the Domain Admins group should have on the Samba member server. Windows seems to honor Administrator, and Domain Admins, but Linux does the completely opposite, denying objects that should have some kind of elevated privileges completely, and letting through unprivileged objects. Very frustrating, totally without any logic.

I'll get on my bike and take a trip in the countryside tomorrow, instead of fighting wind mills...

Best regards,

Peter

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