NS Samba AD - RSAT Windows 7

Some first observations:

RSAT - Active Directory Users and Computers (RSAT-ADUC)

  • The users which were created in NS GUI:

    • are shown in both side (NS Management -> Users and groups -> Users & RSAT-ADUC -> Users)
    • can be add to the desired group, from both side (NS Management -> Users and groups -> Groups & RSAT-ADUC -> Users) and are shown in both side.
  • The users which were created in RSAT-ADUC -> Users:

    • are shown in both side (NS Management -> Users and groups -> Users & RSAT-ADUC -> Users)
    • can be add to the desired group, from both side (NS Management -> Users and groups -> Groups & RSAT-ADUC -> Users) and are shown only in RSAT-ADUC.
  • The Groups:

    • can be created from both side (NS Management -> Users and groups -> Groups & RSAT-ADUC -> Users)
    • are shown in both side (NS Management -> Users and groups -> Groups & RSAT-ADUC -> Users)
    • the Users can be add as described above

I think it’s an issue regarding how the user “Name” “is seen” or “it means” by the both parts:

In RSAT-ADUC -> Users, the users which are created in NS Management -> Users and groups -> Users are shown as “user.name” and the users which are created in RSAT-ADUC -> Users are shown as User NAME (please see the attached files).


  • The NS DC server can be added as Authorized DHCP Server
  • Cannot connect to the NS DC server (please see the attached files)

Till now, cannot manage NS Samba only from RSAT.

1 Like

Regarding users, what would be interesting is to look at LDAP content with LDAP client, not through RSAT.
Microsoft’s implementation, in term of directory, assumes that cn (used as RDN for user’s entries) is unique, which is stupid enough to prevent any smooth move from open organization to another without facing the risk to change CN due to uniqueness constraint within the branch.
Because of this uniqueness assumption, interfaces are often based on CN attribute, by default “given name + space + last name”.

This said, CN can technically contain whatever you want as long as it is unique within the branch (DIT) :unamused:

I should be able to have a closer look soon as my first Nethserver is now installed.

This aside, I don’t understand how this relates to DHCP? :flushed:

1 Like

Other observations:

RSAT - Computer Management

According this:
I should be able to change the share permissions of a shared folder, but I can’t (please see the attached files).

I am logged into domain with the Administrator account (administrator@abt.ro).

@davidep, @giacomo : There is a chance to use RSAT to be able to use the full advantages of NethServer Samba AD?



I think I put the wrong question.
There is nothing wrong with RSAT.
I think the NS Samba AD version is not fully functional.
Or the admin account has no full rights.
Or …

There is any chance to have NS Samba AD version fully functional, to be able to replace MS AD?

Hi Gabi.
I don’t know if this is the case but from what i know you can’t modify the permissions of the user home drive share.

Try with another share or create some group policy.


Hi Bogdan,

Thank you for your answer.
It seemed to me that nobody is interested by Samba AD on NS!

EDIT: IMO, shared folders and how to access and how to restrict and/or share the access to the shared folders is the first thing that you need into domain!

Is not “user home drive share”.
Is a shared folder created for everyone from "Management → Users and groups → CREATE NEW.

Anyway, from administrator account, should be able to modify anything.

Otherwise, it’s useless. Back to Windows AD or …

Is this bug the same?

Hi Davide,

I just read your response to that post and I think yes.
I want to reboot in Win 7 to use RSAT and check.
I will report back, A.S.A.P.


1 Like

I followed your steps to install sssd-libwclient on NS.

Unfortunately, I have the same error as above when I want to change ACL for a shared folder.

What I forgot to mention is: First time when I want to connect to the NS DC/AD from RSAT-Computer management, I have an error. After I press OK, I can connect to the NS DC/AD. I don’t know if is an issue or it take time to connect. I just want you to know that.

IIUC “Share permissions” are not the same as “Filesystem ACLs”. I don’t know how this type of permissions are configured in Samba :thinking:

I remember share-level permissions were set during the old times of FAT32 filesystem, before NTFS (and ACL) came out.

Will you take a look here?


Maybe is something that must set in samba configuration.


EDIT: Sorry! Is almost the same link as in the other post that you referred.

A shot in the dark: try by adding the following lines add the end of smb.conf:

vfs objects = acl_xattr


systemctl restart smb nmb

See if share-level permissions is fixed…

At the end of [global] or add another [global] at the end of smb.conf? :blush:

It does not matter! Both should be accepted. To verify

testparm -s -v | grep ...

Hi @davidep,

Sorry for my late feedback. Yesterday, just after you gave me the response, I had to go to one of our customers.
Unfortunately, didn’t work.
And what I got after “testparm -s -v | grep …” has 2 Km … :scream:

Another, maybe, stupid thought:
I wonder if it is not an issue between Samba AD and NS File server.
Could be a matter of credentials between the two modules?
As Domain Admin, I can access the shared folder (File server) but I have no rights (Samba AD) to change the ACLs.

I’d like to voice my personal opinion on ACL’s in any situation.
I always set share permissions to full control for ‘everyone’ or if you are in a strict domain environment without any BYOD devices, full control for ‘authenticated users’.
All other permissions are done through filesystem ACL’s. This way you always know exactly what permissions are set for any directory or file.
IMO Share permissions are to avoid whenever possible.


Windows ACLs are mapped to Unix and POSIX ACLs. There can’t be a 1-1 map!

When a shared folder is created from server manager and account provider is AD, the folder owner is administrator. That means he is the only user that can change ACLs.

If account provider is not AD the owner is nobody and only guest access works.

1 Like

It might be a problem with Samba AD using RSAT with Win7 and not with NS to make changes the shared folders. The last time I try to set it up using Samba I was using Samba 4.4.2 on CentOS 7.1511, and I can’t get it work. And the received the same error message as @GG_jr

Changes cannot be saved. Access is denied.

The last time I was able to change the shared permissions of a shared folder using RSAT on Win7 was Samba 4.1.3 on Lubuntu. But setting it up with 4.1.3 was much easier than it’s now.

I will try using Samba 4.5.1 on CentOS 7.1511 using RSAT and I will post my results.

1 Like

Totally agree with you!

To recap: in an AD environment, the administrator, by default, has the full rights/control over all users and all folders that belong to the domain.

So, as Administrator, in an AD environment, I am the only one who is able to change ACLs.

Am I right or wrong?

I will try on Monday to join a Windows 10 ws to the domain to use Win10 RSAT.
I will report back.

Surely you’re right!

But this is not AD, administrator on our Linux systems is not root… He must obey the Linux rules! :laughing:

Only the directory owner (and root) can change ACLs!