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 at lists.samba.org> 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 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... > 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
On Tue, 9 Oct 2018 19:44:55 +0200 Peter Milesson via samba <samba at lists.samba.org> wrote:> 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.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 permission settings. 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 administrator Restarted Samba and it now works. Unix permissions before attempting any changes from windows: [root at 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 contents, Read [root at 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 at cen7member ~]# 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:rowland:r-x group:unix\040admins:rwx mask::rwx other::--- default:user::rwx default:user:root:rwx default:user:rowland:r-x default:group::r-x default:group:rowland:r-x default:group:unix\040admins:r-x default:mask::rwx default:other::r-x> > 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 works ;-) Rowland
On Tue, 9 Oct 2018 22:16:41 +0200 Peter Milesson <miles at atmos.eu> 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 at lists.samba.org> wrote: > > > >> 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. > > 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 > > permission settings. > > > > 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 > > administrator > > > > Restarted Samba and it now works. > > > > Unix permissions before attempting any changes from windows: > > > > [root at 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 > > contents, Read > > > > [root at 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 at cen7member ~]# 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:rowland:r-x > > group:unix\040admins:rwx > > mask::rwx > > other::--- > > default:user::rwx > > default:user:root:rwx > > default:user:rowland:r-x > > default:group::r-x > > default:group:rowland:r-x > > default:group:unix\040admins:r-x > > default:mask::rwx > > default:other::r-x > > > >> 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 > > works ;-) > > > > Rowland > > > 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 > SeDiskOperatorPrivileges. > > 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 file.> > 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 > time.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 Samba versions.> > Until then... >I will sort out my notes and send you a copy, I feel you must have a simple mistake that is causing your problem. Rowland
On 10/9/18 10:41 PM, Rowland Penny via samba wrote:> On Tue, 9 Oct 2018 22:16:41 +0200 > Peter Milesson <miles at atmos.eu> 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 at lists.samba.org> wrote: >>> >>>> 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. >>> 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 >>> permission settings. >>> >>> 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 >>> administrator >>> >>> Restarted Samba and it now works. >>> >>> Unix permissions before attempting any changes from windows: >>> >>> [root at 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 >>> contents, Read >>> >>> [root at 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 at cen7member ~]# 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:rowland:r-x >>> group:unix\040admins:rwx >>> mask::rwx >>> other::--- >>> default:user::rwx >>> default:user:root:rwx >>> default:user:rowland:r-x >>> default:group::r-x >>> default:group:rowland:r-x >>> default:group:unix\040admins:r-x >>> default:mask::rwx >>> default:other::r-x >>> >>>> 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 >>> works ;-) >>> >>> Rowland >>> >> 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 >> SeDiskOperatorPrivileges. >> >> 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 > file. > >> 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 >> time. > 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 > Samba versions. > >> Until then... >> > I will sort out my notes and send you a copy, I feel you must have a > simple mistake that is causing your problem. > > RowlandHi Rowland, 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 at all. The folder looks the following: ls -al total 12 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 getfacl wandafish # file: wandafish # owner: root # group: domain\040admins user::rwx group::r-x other::r-x 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. Best regards, Peter