When adding a user to a domain the group is blank and not a Domain User? And Domain User is not in the groups.
The first several times when I was installing Samba AD/DC and adding users I was lost. I was trying to add “Domain Users” in the groups but it will not allow me. So I added domainusers but they made another group and not “Domain Users”.
But now I know it is there by default but not showing. It should be there.
The same applies for Administrators group.
We can display both groups inside the web interface, but the groups will be not editable and without the list of members (due to sssd limitations).
Is this acceptable? What do you think?
I’d prefer listing those elements even if they are not editable. At least I can see they actually exist!
I agree too.
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
Administrators
Domain Computers
Cert Publishers
DnsUpdateProxy
Domain Admins
Domain Guests
Schema Admins
Domain Users
Replicator
IIS_IUSRS
DnsAdmins
Guests
Users
I rather display no default groups or all default groups, not only few of them.
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.
Horrible but a necessary evil!
IMO
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 users@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 
But displaying groups inside the the user creation form (as @JeffBales correctly asks), it’s way too hard 
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?
https://www.ldap-account-manager.org/lamcms/
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.
