Why is the Groups blank when adding users to a domain?

I have a working patch, but I’m wondering: why you should display groups which are not editable?
For example, if we display the Administrators group, how can you add to it new users if the web interface doesn’t have the edit button?
Also, what about “Domain Admins” and other Active Directory well-known groups?

This is a list of well-known groups (from /etc/nethserver/system-groups):

Allowed RODC Password Replication Group
Enterprise Read-Only Domain Controllers
Denied RODC Password Replication Group
Pre-Windows 2000 Compatible Access
Windows Authorization Access Group
Certificate Service DCOM Access
Network Configuration Operators
Terminal Server License Servers
Incoming Forest Trust Builders
Read-Only Domain Controllers
Group Policy Creator Owners
Performance Monitor Users
Cryptographic Operators
Distributed COM Users
Performance Log Users
Remote Desktop Users
Account Operators
Event Log Readers
RAS and IAS Servers
Backup Operators
Domain Controllers
Server Operators
Enterprise Admins
Print Operators
Domain Computers
Cert Publishers
Domain Admins
Domain Guests
Schema Admins
Domain Users

I rather display no default groups or all default groups, not only few of them.

(/cc @filippo_carletti @davidep @flatspin @GG_jr)

If I see it exists, I avoid to create it and get the “already exists” error.

Maybe I’m wrong but I on some systems I saw some “well-known” group names “localised”. For instance Pre-Windows 2000 Compatible Access was

accesso compatibile precedente a windows 2000@adtest.it:*:1541411170:

The builtin list might not work?

My opinion is that if the groups are listed (even if not editable) then the user will not try to create the group because it sees that the group exists already.

It is a method to remove the unnecessary failed steps like "I’ve tried to create X group but I got the error … "


So, we should display all (38!) builtin groups, right?

I think that It could be in a list box so it will not take too much space on page

Yep! That’s horrible, isn’t it?

Can we get the inspiration from other projects to see how they solved this kind of problem ?
An maybe adapt something to NS ?

Maybe we should spit this question to another question

My original blog "why is the Groups blank when adding a user’, meaning the Administrator group should say Domain Admins and all the other users should say Domain Users since they are, even though they are not editable.

Take this example. jbales should say Domain Users with acct Groups, but it’s only states the acct@bales.lan Group. I added to the ‘acct’ Group to show the the Group list. Without it, the list is not there.

If we’re talking adding more Groups in the Groups section, then that is a different question.

1 Like

Horrible but a necessary evil!

1 Like

Right it’s a different (but similar) problem. For instance on my AD the user administrator by default is member of the following groups:

[root@vm4 ~]# id -z -n -G administrator@adnethesis.it | sed 's/\x00/\n/g'
domain users@adnethesis.it
proprietari autori criteri di gruppo@adnethesis.it
enterprise admins@adnethesis.it
domain admins@adnethesis.it
schema admins@adnethesis.it
ogg. non autoriz. a replica passw. in controller sola lettura@adnethesis.it

IMO to list all groups will result in a very unclear list in GUI. If it is necessary, they should be sorted somehow, maybe even in a separated tab only fpr the builtin groups. Would this be possible?

It might be a workaround, different tab?
But the question is, are we able to filter system groups?

I agree with this proposal.

Yes we are, we already do it :wink:

But displaying groups inside the the user creation form (as @JeffBales correctly asks), it’s way too hard :frowning:

With seperate tab I though something like that:

Inside this “Tab” there could be a message that they are not editable and only for systemuse.


We did some analysis and we are thinking to fill the gap after the final release.

What do you think if we ship this interface instead of writing a new one?


What about a checkbox “show system groups” in the Groups tab? The system groups could be rendered as gray text to mark them uneditable. Or there could be a third column “group type”, so that one can sort by name or type.

Sounds good. But put in the manual about the missing groups who are not showing, but they are really there though.

1 Like

Hi guys,

I’m still confused regarding Users and Groups, I will explain why and I know you will enlighten me! For this, TIA!

Let’s talk about the “administrator” user account.
Here is written:
“After installing Samba Active Directory, the Users and groups page has one default entry: administrator. This account is granted special privileges on some specific services, such as joining a workstation in Samba Active Directory domain.”

Here is written:
“A user can be added to one or more group from the Users page or from the Groups one.”

Here is written:
"A group of user can be used to assign special permissions to some users or to create email distribution lists.

As for the users, a group can be enabled to some (or all) services.

Tip: For delegating permissions to the Server Manager, use the groups managers or administrators.

Two special groups can be created, the users who belong in one of these groups are granted access to the panels of the Server Manager

_administrators_: Users of this group have the same permissions as the root user.
_manager_s: Users of this group are granted access to the Management section."

After all this from above, I understand that:

  • a user can be added to one or more group.
  • if I want that the administrator account (or any other user account) to have root privileges, it must belong to the administrators group.
  • the administrators group can be created (“Two special groups can be created, …”).

But if I want to create the administrators group, the system tell me that the administrators group already exist. Of course, as @giacomo said here.
How can I add a user, no matter who that user is, to a group if I cannot select and edit that group?

If I check to see to which groups belong the administrator, as @davidep said, I obtain this:

[root@pdc-ad ~]# id -z -n -G administrator@abt.ro | sed 's/\x00/\n/g’
domain users@abt.ro
group policy creator owners@abt.ro
enterprise admins@abt.ro
domain admins@abt.ro
schema admins@abt.ro
denied rodc password replication group@abt.ro
[root@pdc-ad ~]#

So, the administrator belong to the administrators group. That means that the administrator is root. But is not, as @davidep said here.

As I said: I am confused! Please help!


For now, you can’t do it from the web interface. We must implement something, I hope as soon as the final is released. I will try gather more requirements before starting to write it.

A user inside the administrators group is an admin but not root. Currently the administrator account is not mapped to root.
At this time, root is a special account which doesn’t belong to any user provider.

Next weekend, the company will organize an internal hackaton (called NethCamp), I hope we will have time to update the manual which is a bit confusing right now :frowning:


We are working on an UI enhancement for the “administrators” group. Also “Domain Admins” will be fixed.

On the contrary the “Domain Users” group is special: every domain user is implicitly member of it, so it cannot be handled by our UI.

1 Like