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
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 listDon't remove anything, in fact, ignore the share permissions tab.> - Switching to the Security tab, which is blank, which effectivelyNow 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 rootI 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 grulfYes, 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.mapYou do not use a 'user.map' on a DC, it uses idmap.ldb instead Rowland
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 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 > >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... 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? 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". 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. Thank you very much for your input so far. Really appreciated. Best regards, Peter