7. Group management

Permissions in UCS are predominantly differentiated between on the basis of groups. Groups are stored in the LDAP and are thus identical on all systems. Groups can contain not only user accounts, but can also optionally accept computer accounts.

In addition, there are also local user groups on each system, which are predominantly used for hardware access. These are not managed through the UCS Management System, but saved in the /etc/group file.

Note

The group management is part of Univention Nubus in the Directory Manager component. For more information about Nubus, refer to What is Univention Nubus?

7.1. User group assignments

The assignment of users to groups is performed in two ways:

• A selection of groups can be assigned to a user in the user management, see User management through Univention Management Console module.

• A selection of users can be assigned to a group in the group management, see Managing groups via Univention Management Console module.

7.2. Recommendation for group name definition

One very important and required attribute for groups is the group name. To avoid conflicts with the different tools handling groups in UCS, adhere to the following recommendations for the definition of group names:

• Only use upper and lower case letters (A-Za-z), digits (0-9) the hyphen (-) and space from the ASCII character set for group names.

• The group name starts with a letter from the ASCII character set. The space is not allowed as first or last character. The hyphen is not allowed as last character.

• In UCS the group name has at least a length of 4 characters and at most 20 characters.

The recommendation results in the following regular expression:

^[A-Za-z][A-Za-z0-9 -]{2,18}[A-Za-z0-9]$

Consider the recommendation as a guideline and not a rule and keep potential side-effects in mind when defining group names outside the recommendation.

7.3. Managing groups via Univention Management Console module

Groups are managed in the UMC module Groups (see Univention Management Console modules).

Fig. 7.1 Creating a group via UMC module

7.3.1. Group management module - General tab

Table 7.1 General tab

Attribute	Description
Name (*)	Defines the name of the group. For recommended characters for the group name, see Recommendation for group name definition. By default it is not possible to create a group with the same name as an existing user. If the Univention Configuration Registry Variable directory/manager/user_group/uniqueness is set to false, this check is removed.
Description	A description of the group can be entered here.
Users	This input field can be used for adding users as members to the group.
Groups	On this input field, other groups can be added as members of the current group (groups in groups).

7.3.2. Group management module - Advanced settings tab

Table 7.2 Advanced settings tab

Attribute	Description
Mail	These options define a mail group and are documented in the Management of mail groups.
Host members	This field can be used for accepting computers as members of the group.
Nested groups	The current group can be added as a member to other groups here (groups in groups).
Group ID	If a group is to be assigned a certain group ID, the ID in question can be entered in this field. Otherwise the next available group ID will be automatically assigned when adding the group. The group ID cannot be subsequently changed. When editing the group, the group ID will be represented in gray. The group ID may consist of integers between 1000 and 59999 and between 65536 and 100000.
Windows ‣ Relative ID	The relative ID (RID) is the local part of the Security ID (SID) and is used in Windows and Samba domains. If a group is to be assigned a certain RID, the ID in question can be entered in this field. Otherwise a RID will be automatically assigned. The RID cannot be subsequently changed. When editing the group, the group ID will be represented in gray. The RIDs below 1000 are reserved for standard groups and other special objects. When Samba/AD is used, the RID is generated by Samba and cannot be specified.
Windows ‣ group type	This group type is evaluated when the user logs in to a Samba/AD-based domain. Three types of Windows groups can be distinguished: Domain Groups are known across the domain. This is the default group type. Local groups are only relevant on Windows servers. If a local group is created on a Windows server, this group is known solely to the server; it is not available across the domain. UCS, in contrast, does not differentiate between local and global groups. After taking over an AD domain, local groups in UCS can be handled in the same way as global groups. Well-known group This group type covers groups preconfigured by Samba/Windows servers which generally have special privileges, e.g., Power Users.
Windows ‣ AD group type	This group type is only evaluated when the user logs in to a Samba/AD-based domain (which offers Active Directory domain services). These groups are described in Synchronization of Active Directory groups when using Samba/AD.
Windows ‣ Samba privileges	This input mask can be used to assign Windows system rights to a group, e.g., the right to join a Windows client in the domain. This function is documented in User management through Univention Management Console module.

7.3.3. Group management module - Options settings tab

This tab is only available when adding groups, not when editing groups. Certain LDAP object classes for the group can be de-selected here. The entry fields for the attributes of these classes can then no longer be filled in.

Table 7.3 Options tab

Attribute	Description
Samba group	This checkbox indicates whether the group contains the object class sambaGroupMapping.
POSIX group	This checkbox indicates whether the group contains the object class posixGroup.

7.4. Group nesting with groups in groups

UCS supports group nesting (also known as “groups in groups”). This simplifies the management of the groups. For example, if two locations are managed in one domain, two groups can be formed IT staff location A and IT staff location B, to which the user accounts of the location’s IT staff can be assigned respectively.

To create a cross-location group, it is then sufficient to define the groups IT staff location A and IT staff location B as members.

Cyclic dependencies of nested groups are automatically detected and refused. This check can be disabled with the Univention Configuration Registry Variable directory/manager/web/modules/groups/group/checks/circular_dependency. Cyclic memberships must also be avoided in direct group changes without the UCS Management System.

The resolution of nested group memberships is performed during the generation of the group cache (see Local group cache) and is thus transparent for applications.

7.5. Local group cache

The user and computer information retrieved from the LDAP is cached by the Name Server Cache Daemon (NSCD), see Name service cache daemon.

Since UCS 3.1, the groups are no longer cached via the NSCD for performance and stability reasons; instead they are now cached by the NSS module libnss-extrausers. The group information is automatically exported to the /var/lib/extrausers/group file by the /usr/lib/univention-pam/ldap-group-to-file.py script and read from there by the NSS module.

In the basic setting, the export is performed once a day by a cron job and is additionally started if the Univention Directory Listener has been inactive for 15 seconds. The interval for the cron update is configured in Cron syntax (see Defining local cron jobs in /etc/cron.d/) by the Univention Configuration Registry Variable nss/group/cachefile/invalidate_interval. This listener module can be activated/deactivated via the Univention Configuration Registry Variable nss/group/cachefile/invalidate_on_changes (true/false).

When the group cache file is being generated, the script can verify whether the group members are still present in the LDAP directory. If not only UMC modules are used for user management, this additional check can be can be enabled by setting the Univention Configuration Registry Variable nss/group/cachefile/check_member to true.

7.6. Synchronization of Active Directory groups when using Samba/AD

If Samba/AD is used, the group memberships are synchronized between the Samba/AD directory service and the OpenLDAP directory service by the Univention S4 connector, i.e., each group on the UCS side is associated with a group in Active Directory. General information on the Univention S4 connector can be found in Univention S4 connector.

Some exceptions are formed by the pseudo groups, sometimes also called system groups. These are only managed internally by Active Directory/Samba, e.g., the Authenticated Users group includes a list of all the users currently logged on to the system. Pseudo groups are stored in the UCS directory service, but they are not synchronized by the Univention S4 connector and should usually not be edited. This applies to the following groups:

• Anonymous Logon

• Authenticated Users

• Batch

• Creator Group

• Creator Owner

• Dialup

• Digest Authentication

• Enterprise Domain Controllers

• Everyone

• IUSR

• Interactive

• Local Service

• NTLM Authentication

• Network Service

• Network

• Nobody

• Null Authority

• Other Organization

• Owner Rights

• Proxy

• Remote Interactive Logon

• Restricted

• SChannel Authentication

• Self

• Service

• System

• Terminal Server User

• This Organization

• World Authority

In Active Directory/Samba, a distinction is made between the following four AD group types. These group types can be applied to two types of groups; security groups configure permissions (corresponding to the UCS groups), whilst distribution groups are used for mailing lists:

Local

Local groups only exist locally on a host. A local group created in Samba/AD is synchronized by the Univention S4 Connector and thus also appears in the UMC module Groups. There is no need to create local groups in the UMC module.

Global

Global groups are the standard type for newly created groups in the UMC module Groups. A global group applies for one domain, but it can also accept members from other domains. If there is a trust relationship with a domain, the groups there are displayed and permissions can be assigned. However, the current version of UCS does not support multiple domains/forests or outgoing trust relationships.

Domain local

Domain local groups can also adopt members of other domains (insofar as there is a trust relationship in place or they form part of a forest). Local domain groups are only shown in their own domain though. However, the current version of UCS does not support multiple domains/forests or outgoing trust relationships.

Universal

Universal groups can adopt members from all domains and these members are also shown in all the domains of a forest. These groups are stored in a separate segment of the directory service, the so-called global catalog. Domain forests are currently not supported by Samba/AD.

7.7. Overlay module for displaying the group information on user objects

In the UCS directory service, group membership properties are only saved in the group objects and not in the respective user objects. However, some applications expect group membership properties at the user objects (e.g., in the attribute memberOf). An optional overlay module in the LDAP server makes it possible to present these attributes automatically based on the group information. The additional attributes are not written to the LDAP, but displayed on the fly by the overlay module if a user object is queried.

Caution

Before using this feature, please read KB 6439 - memberOf attribute: Group memberships of user and computer objects about activating the OpenLDAP memberOf overlay module.

To this end, the univention-ldap-overlay-memberof package must be installed on all LDAP servers. Afterwards /usr/share/univention-ldap-overlay-memberof/univention-update-memberof must be invoked on all servers.

By default the user attribute memberOf is shown. The Univention Configuration Registry Variable ldap/overlay/memberof/memberof can be used to configure a different attribute.