The use of UCS begins either with a classic operating system installation on a physical server or as a virtual machine. Further information can be found in Chapter 2.

In an IT infrastructure managed with UCS, all servers, clients and users are contained in a common security and trust context, referred to as the UCS domain. Every UCS system is assigned a so-called server role during the installation. Possible system roles are domain controller, member server and client.

§

Figure 1.1. UCS domain concept

Depending on the system role within the domain, such services as Kerberos, OpenLDAP, Samba, modules for domain replication or a Root CA (certification authority) are installed on the computer. These are automatically configured for the selected system role. The manual implementation and configuration of every single service and application is therefore not required. Due to the modular design and extensive configuration interfaces, tailor-made solutions to individual requirements can nevertheless be realized.

The integration of Samba, which provides the domain service for clients and servers operated with Microsoft Windows, makes Univention Corporate Server compatible with Microsoft Active Directory (AD), whereby the system acts as an Active Directory server for Windows-based systems. Consequently, for example, group policies for Microsoft Windows systems can be administrated in the usual way.

UCS can also be operated as part of an existing Microsoft Active Directory domain. This way, users and groups of the Active Directory domain can access applications from the Univention App Center.

Ubuntu or Mac OS X clients can be integrated in a UCS environment, as well (see Section 8.1.1).

The Univention App Center offers additional UCS components and extensions and a broad selection of business IT software, e.g., groupware and collaboration, file exchange, CRM or backup. These applications can be installed in existing environments with a few clicks and are usually ready to use. In most cases they are directly integrated into the UCS management system such that they are available in Univention Management Console. This provides a central management of data on the domain level and obsoletes the separate management of, e.g., user data in multiple places.

With the UCS management system, all the components of the UCS domain can be centrally administrated across computer, operating system and site boundaries. It thus provides a single point of administration for the domain. One primary element of the UCS management system is an LDAP directory in which the data required across the domain for the administration are stored. In addition to the user accounts and similar elements, the data basis of services such as DHCP is also saved there. The central data management in the LDAP directory avoids not only the repeated entry of the same data, but also reduces the probability of errors and inconsistencies.

An LDAP directory has a tree-like structure, the root of which forms the so-called basis of the UCS domain. The UCS domain forms the common security and trust context for its members. An account in the LDAP directory establishes the membership in the UCS domain for users. Computers receive a computer account when they join the domain. Microsoft Windows systems can also join the domain such that users can log in there with their domain passport.

UCS utilizes OpenLDAP as a directory service server. The directory is provided by the master domain controller and replicated on all domain controllers (DCs) in the domain. The complete LDAP directory is also replicated on a DC backup as this can replace the DC master in an emergency. In contrast, the replication on DC slaves can be restricted to certain areas of the LDAP directory using ACLs (access control lists) in order to realize a selective replication. For example, this may be desirable if data should only be stored on as few servers as possible for security reasons. For secure communication of all systems within the domain, UCS integrates a root CA (certification authority).

Further information can be found in Section 3.4.

§

Figure 1.2. Univention Management Console

Access to the LDAP directory is performed via the web-based user interface Univention Management Console (UMC). In addition to this, Univention Directory Manager allows the realization of all domain-wide administrative tasks via a command line interface. This is particularly suitable for the integration in scripts or automated administrative steps.

Univention Management Console allows to display, edit, delete, and search the data in the LDAP directory via various filter criteria. The web interface offers a range of wizards for the administration of user, groups, networks, computers, directory shares and printers. The administration of computers also comprises comprehensive functions for distributing and updating software. The integrated LDAP directory browser can be used to make further settings and add customer-specific object classes or attributes.

Further information can be found in Chapter 4.

Univention Management Console allows not only the access to the LDAP directory, but also the web-based configuration and administration of individual computers. These include the adaptation of configuration data, the installation of software as well as the monitoring and control of services and the operating system itself. With the UCS management system, domain administration as well as computer and server configuration is possible from any place via a comfortable graphic web interface.

The tree-like structure of LDAP directories is similar to that of a file system It ensures that objects (such as users, computers, etc.) are in one container which itself can be adopted by other containers. The root container is also called the LDAP base object.

Policies describe certain administrative settings which are applied to more than one object. Linked to containers, they facilitate the administration as they are effective for all objects in the container in question as well as the objects in subfolders.

For example, users can be organized in different containers or organizational units (which are a form of containers) depending on which department they belong to. Settings such as the desktop background or accessible programs can then be connected to these organizational units using policies. Subsequently, they apply for all users within the organizational unit in question.

Further information can be found in Section 4.6.

The listener/notifier mechanism is an important technical component of the UCS management system. With this, the creation, editing or deleting of entries in the LDAP directory triggers defined actions on the computers in question. For example, the creation of a directory share with Univention Management Console leads to the share firstly being entered in the LDAP directory. The listener/notifier mechanism then ensures that the NFS and Samba configuration files are also expanded accordingly on the selected server and that the directory is created in the file system of the selected server if it does not already exist.

The listener/notifier mechanism can be easily expanded with modules for further - also customer-specific - procedures. Consequently, it is used by numerous technology partners for the integration of their products in the LDAP directory service and the UCS management system for example.

Further information can be found in Section 3.5.

With the UMC module UCS Virtual Machine Manager (UVMM), UCS offers an extensive, powerful tool for the administration of hybrid cloud environments virtualization servers registered in the UCS domain and virtual machines operated on it can be centrally monitored and administrated. In addition UVMM offers the possibility to manage virtual machines in OpenStack or EC2 environments.

Further information can be found in Chapter 16.

Once the Create a new UCS domain mode has been selected, an organization name, an e-mail address, a fully qualified domain name and an LDAP base are requested in the following two steps.

Specification of an organization name is optional and it is used in the second step to generate a domain name and the LDAP base automatically.

If a valid e-mail address is specified, this is used to activate a personalized license, which is required for the use of the Univention App Center. The license is generated automatically and sent to the specified e-mail address immediately. The license can then be imported via the Univention Management Console license dialog.

The name of the UCS system to be configured and the name of the DNS domain are determined from the fully qualified domain name (host name including domain name) entered here. A suggestion is generated automatically from the organization name entered in the previous step. It is recommended not to use a publicly available DNS domain, as this can result in problems during the name resolution.

A LDAP base needs to be specified for the initialization of the directory service. A suggestion is also derived here automatically from the fully qualified domain name. This value can usually be adopted without any changes.

§

Figure 2.12. Specification of host name and LDAP base

If the DNS server of an Active Directory domain was specified during the network configuration, the name of the Active Directory domain controller is suggested automatically in the Active Directory account information step. If the suggestion is incorrect, the name of another Active Directory domain controller or another Active Directory domain can be entered here.

The specification of an Active Directory account and the corresponding password is required for joining the Active Directory domain. The user account must possess the right to join new systems in the Active Directory domain.

In addition, a host name must be entered for the UCS system to be configured. The suggested host name can be adopted or a new host name entered. The domain name of the computer is derived automatically from the domain DNS server. In some scenarios (e.g., a public mail server) it can prove necessary to use a specific fully qualified domain name. The UCS system will join the Active Directory domain with the host name specified here. Once set up, the domain name cannot be changed again once the configuration is completed.

In a UCS domain, systems can be installed in different system roles. The first UCS system, that joins an Active Directory domain, is automatically installed with the master domain controller system role. If this mode is selected during installation of additional UCS systems, the system role selection dialogue is shown. The system roles are described within the following section.

§

Figure 2.13. Information on the Active Directory domain join

In a UCS domain, systems can be installed in different system roles. The first system in a UCS domain is always installed with the master domain controller system role. Additional UCS systems can join the domain at a later point in time and can be configured with one of the following system roles.

Once the UCS system role has been selected, further information on the domain join is requested. If the domain join is not intended to occur automatically during the installation, the Start join at the end of the installation option can be disabled. If the correct DNS server was selected during the network configuration, Univention Installer can determine the name of the master domain controller system automatically. If the decision is taken to join another UCS domain, the Search Domain controller master in DNS option can be disabled and the fully qualified domain name of the preferred master domain controller entered in the input field below. The access information required for the domain join must be entered in the Administrator account and Administrator password input fields.

§

Figure 2.14. Information on the domain join

In addition, a host name must be entered for the UCS system to be configured in the next step. The suggested host name can be adopted or a new host name entered. The domain name of the computer is derived automatically from the domain DNS server. In some scenarios (e.g., a public mail server) it can prove necessary to use a certain fully qualified domain name. Once set up, the domain name cannot be changed again once the configuration is completed.

The configuration of the Do not use any domain mode requires the specification of a host name for the UCS system to be configured. The suggested host name can be adopted or a new host name entered. The domain name of the computer is derived automatically from the domain DNS server.

There are three possibilities for a UCS system to join an existing domain; directly after installation in the Univention Installer (see Section 2.9.3) or subsequently using the command univention-join or using Univention Management Console.

The master domain controller should always be installed at the most up-to-date release stand of the domains, as problems can arise with an outdated domain control master when a system using the current version joins.

When a computer joins, a computer account is created, the SSL certificates are synchronized and an LDAP copy is initiated if necessary. The join scripts are also run at the end of the join process. These register further objects, etc., in the directory service using the software packages installed on the system (see Section 3.2.1.3).

The joining of the domain is registered on the client side in the /var/log/univention/join.log log file, which can be used for reference in error analysis. Actions run on the domain controller master are stored in the /home/Join-Account/.univention-server-join.log log file.

The joining process can be repeated at any time. Systems may even be required to rejoin following certain administrative steps (such as changes to important system features on the master domain controller).

The procedure for joining a Windows system to a UCS domain made available via Samba is now described as an example for Windows 7/8/10 and Windows 2012. The process is similar for other Windows versions. In addition to the client versions, Windows server systems can also join the domain. Windows servers join the domain as member servers; joining a Windows systems as a domain controller is not supported. Further information can be found in Section 9.1

Only domain-compatible Windows versions can join the UCS domain, i.e., it is not possible for the Home versions of Windows to join a domain.

A host account is created for the Windows client automatically when it joins the domain (see Section 8.1). Information concerning MAC and IP addresses, the network, DHCP or DNS can be configured in Univention Management Console prior to or after joining the domain.

Domain joining is usually performed with the local Administrator account on the Windows system.

Joining the domain takes some time and the process must not be canceled prematurely. After successful joining a small window appears with the message Welcome to the domain domain name. This should be confirmed with [OK]. The computer must then be restarted for the changes to take effect.

§

Figure 3.1. Domain join of a Windows 7 system

Domain names must be limited to 13 characters as they are otherwise truncated at the Windows client and this can lead to log-in errors.

For a domain join against a domain controller based on Samba 4, the DNS configuration of the client must be set up in such a way that DNS entries from the DNS zone of the UCS domain can also be resolved. In addition, the time on the client system must also be synchronized with the time on the domain controller.

Univention provides the Univention Domain Join Assistant to integrate Ubuntu clients into a UCS domain. Documentation and installation instructions are available at Github.

UCS supports domain joins of Mac OS X clients into a UCS environment using Samba 4. This documentation refers to Mac OS X 10.8.2.

The domain join can be performed using the system preferences menu or the dsconfigad command line tool.

After the domain join it is possible to automatically mount CIFS shares to subfolders in /Volumes when logging in with a domain user. For that, the following line has to be added to the file /etc/auto_master:

/Volumes    auto_custom

In addition, the file /etc/auto_custom needs to be created and the shares which should be mounted have to be listed in it in the following way:

subfolder name    -fstype=smbfs    ://fqdn/sharename

Note that the automounted shares are not displayed in the finder's sidebar.

§3.2.4.1. Domain join using the system preferences GUI

In the System Preferences via the Users & Groups entry, the Login menu can be reached. After authenticating by clicking on the lock in the lower left corner and providing credentials of a local Administrator account, the Network Account Server: Join button needs to be clicked. From that menu it is possible to open the Directory Utility.

§

Figure 3.2. Domain join of a Mac OS X system

In the advanced options section, the option Create mobile account at login should be activated. A mobile account has the advantage that, when the domain is not available, the user can log into the Mac OS X system with the same account used for logging into the domain.

After filling in the domain name in the field Active Directory Domain and the hostname of the Mac OS X client in the field Computer ID, the join process is initiated after clicking the button Bind.... The username and password of an account in the Domain Admins group needs to be entered, e.g., Administrator.

dsconfigad -a mac hostname -domain fqdn -ou "CN=Computers,ldap_base" \
  -u Domain Administrator -mobile enable

A system with the master domain controller role (DC master for short) is the primary domain controller of a UCS domain and is always installed as the first system. The domain data (such as users, groups, printers) and the SSL security certificates are saved on the DC master.

Copies of these data are automatically transferred to all servers with the backup domain controller role.

All the domain data and SSL security certificates are saved as read-only copies on servers with the backup domain controller role (backup DC for short).

The backup domain controller is the fallback system for the master domain controller. If the latter should fail, a backup domain controller can take over the role of the master domain controller permanently (see Section 3.9).

All the domain data are saved as read-only copies on servers with the slave domain controller role (slave DC for short). In contrast to the backup domain controller, however, not all security certificates are synchronized.

As access to the services running on a slave domain controller are performed against the local LDAP server, slave DC systems are ideal for site servers and the distribution of load-intensive services.

A slave DC system cannot be promoted to a master DC.

member server are server systems without a local LDAP server. Access to domain data here is performed via other servers in the domain.

A base system is an autonomous system which is not a member of the domain. It is not connected to any LDAP server. It still provides the UCS update mechanism and Univention Configuration Registry for configuration, but not the graphical administration interface Univention Management Console.

A basic system is thus suitable for services which are operated outside of the trust context of the domain, such as a web server or a firewall.

Ubuntu clients can be managed with this system role, see Section 8.1.1.

This system role is used for the integration of other Linux systems than UCS and Ubuntu, e.g., for Debian or CentOS systems. The integration is documented in [ext-doc-domain].

A Univention Corporate Client is a desktop or thin client system based on Univention Corporate Client.

Mac OS X systems can be joined into a UCS domain using Samba 4. Additional information can be found in Section 3.2.4.

A domain trust account is set up for trust relationships between Windows and UCS domains.

An IP managed client allows the integration of non-UCS systems into the IP management (DNS/DHCP), e.g., for network printers or routers.

Windows domain controllers in a Samba 4 environment are operated with this system role.

Windows clients and Windows member servers are managed with this system role.

Schema definitions specify which object classes exist and which attributes they include, i.e., which data can be stored in a directory service. Schema definitions are saved as text files and included in the OpenLDAP server's configuration file.

UCS uses standard schemas where possible in order to allow interoperability with other LDAP applications. Schema extensions are supplied for Univention-specific attributes - such as for the policy mechanism.

The univention-directory-logger package allows the logging of all changes in the LDAP directory service. As each data record contains the hash value of the previous data record, manipulations of the log file - such as deleted entries - can be uncovered.

Individual areas of the directory service can be excluded from the logging. These branches can be configured using the Univention Configuration Registry variables ldap/logging/exclude1, ldap/logging/exclude2, etc. As standard, the container is excluded in which the temporary objects are stored (cn=temporary,cn=univention). The LDAP changes are logged by a Univention directory listener module. The Univention directory listener service must be restarted if changes are made to the Univention Configuration Registry variables.

The logging is made in the /var/log/univention/directory-logger.log file in the following format:

START
Old Hash: Hash sum of the previous data record
DN: DN of the LDAP object
ID: Listener/notifier transaction ID
Modifier: DN of the modifying account
Timestamp: Time stamp in format dd.mm.yyyy hh:mm:ss
Action: add, modify or delete

Old Values:
 List of old attributes, empty when an object is added
New Values:
 List of new attributes, empty when an object is deleted
END

A hash sum is calculated for each logged data record and also logged in the daemon.info section of the Syslog service.

The Univention Configuration Registry variable ldap/idletimeout is used to configure a time period in seconds after which the LDAP connection is cut off on the server side. When the value is set to 0, no expiry period is in use. The timeout period has been set at six minutes as standard.

In addition to the UMC web interface, there are also a range of programs with which one can access the LDAP directory from the command line.

The univention-ldapsearch tool simplifies the authenticated search in the LDAP directory. A search filter needs to be specified as an argument; in the following example, the administrator is searched for using the user ID:

univention-ldapsearch uid=Administrator

The slapcat command makes it possible to save the current LDAP data in a text file in LDIF format, e.g.:

slapcat > ldapdata.txt

Access to the information contained in the LDAP directory is controlled by Access Control Lists (ACLs) on the server side. The ACLs are defined in the central configuration file /etc/ldap/slapd.conf and managed using Univention Configuration Registry. The slapd.conf is managed using a multifile template; further ACL elements can be added below /etc/univention/templates/files/etc/ldap/slapd.conf.d/ between the 60univention-ldap-server_acl-master and 70univention-ldap-server_acl-master-end files or the existing templates expanded upon.

If LDAP ACL extensions are to be delivered as part of software packages, there is also the possibility of packaging them and distributing them to all the LDAP servers in the domain using a Univention Directory listener module. Further information is available in [packaging-acl-extensions].

The default setting of the LDAP server after new installations with UCS does not allow anonymous access to the LDAP directory. This behavior is configured with the Univention Configuration Registry variable ldap/acl/read/anonymous. Individual IP addresses can be granted anonymous read permissions via Univention Configuration Registry variable ldap/acl/read/ips.

Following successful authentication on the LDAP server, all attributes of a user account can be read out by this user.

In addition, an extra, internal account, the root DN, also has full write access.

In addition, UCS offers a number of further ACLs installed as standard which suppress access to sensitive files (e.g., the user password) and establish rules which are necessary for operation (e.g., necessary accesses to computer accounts for log-ins). The read and write access to this sensitive information if only intended for members of the Domain Admins group. Nested groups are also supported. The Univention Configuration Registry variable ldap/acl/nestedgroups can be used to deactivate the nested groups function for LDAP ACLs, which will result in a speed increase for directory requests.

With the Name Service Switch, the GNU C standard library (glibc) used in Univention Corporate Server offers a modular interface for resolving the names of users, groups and hosts.

The LDAP NSS module is used on UCS systems for access to the domain data (e.g., users) as standard. The module queries the LDAP server specified in the Univention Configuration Registry variable ldap/server/name (and if necessary the ldap/server/addition).

What measures should be taken if the LDAP server cannot be reached can be specified by the Univention Configuration Registry variable nssldap/bindpolicy. As standard, if the server cannot be reached, a new connection attempt is made. If the variable is set to soft, then no new attempt is made to connect. This can considerably accelerate the boot of a system if the LDAP server cannot be reached, e.g., in an isolated test environment.

The syncrepl replication service can also be activated parallel to the notifier service for the synchronization of OpenLDAP servers not installed on UCS systems. Syncrepl is a component of OpenLDAP, monitors changes in the local directory service and transmits them to other OpenLDAP servers.

As standard, the OpenLDAP server is configured in such a way that it also accepts requests from ports 7389 and 7636 in addition to the standard ports 389 and 636.

If Samba 4 is used, the Samba domain controller service occupies the ports 389 and 636. In this case, OpenLDAP is automatically reconfigured so that only ports 7389 and 7636 are used. This must be taken into account during the configuration of syncrepl in particular (see Section 3.4.7). univention-ldapsearch uses the standard port automatically.

The content of the LDAP directory is backed up daily on the master domain controller and all backup domain controller systems via a Cron job.

The LDAP data are stored in the /var/univention-backup/ directory in the naming scheme ldap-backup_DATE.ldif.gz in LDIF format. They can only be read by the root user.

Replication of the directory data within a UCS domain occurs via the Univention Directory Listener/Notifier mechanism:

§

Figure 3.3. Listener/Notifier mechanism

The active Univention Directory Listener instances in the domain connect to a Univention Directory Notifier service. If an LDAP change is performed on the master domain controller (all other LDAP servers in the domain are read-only), this is registered by the Univention Directory Notifier and notified to the listener instances.

Each Univention Directory Listener instance uses a range of Univention Directory Listener modules. These modules are shipped by the installed applications; the print server package includes, for example, listener modules which generate the CUPS configuration.

Univention Directory Listener modules can be used to communicate domain changes to services which are not LDAP-compatible. The print server CUPS is an example of this: The printer definitions are not read from the LDAP, but instead from the /etc/cups/printers.conf file. Now, if a printer is saved in the UMC printer management, it is stored in the LDAP directory. This change is detected by the Univention Directory Listener module cups-printers and an entry added to, modified or deleted in /etc/cups/printers.conf based on the data in the LDAP.

Additional information on the setup of Univention Directory Listener modules and developing your own modules can be found in [developer-reference].

LDAP replication is also performed by a listener module. If the LDAP server to be replicated to is not accessible, the LDAP changes are temporarily stored in the /var/lib/univention-directory-replication/failed.ldif file. The contents of the file are automatically transferred to the LDAP when the LDAP server is available again.

The listener/notifier mechanism works based on transactions. A transaction ID is increased for every change in the LDAP directory of the master domain controller. A Univention Directory Listener instance which has missed several transactions - for example, because the computer was switched off - automatically requests all the missing transactions once the connection is available again until its local transaction ID corresponds to that of the master domain controller.

The single sign-on is the default login for Univention Management Console, as long as ucs-sso.domainname can be reached. To login the domain credentials must be provided. For the login directly at the UCS system (i.e., without single sign-on), follow the link Login without Single Sign On.

Other web services will redirect to the UCS identity provider login page in a similar fashion in order to carry out a single sign-on. After authenticating, the user will be forwarded back to the web service itself. These services need to be registered as described in Section 3.8.2.

The single sign-on for a particular service can be initiated from the UCS identity provider, as well. This saves an extra visit at the external web service which redirects to the authentication site. To do so, a link to the UCS identity provider page needs to be provided in the form of https://ucs-sso.domainname/simplesamlphp/saml2/idp/SSOService.php?spentityid=[Service provider identifier].

The Univention Management Console domain module SAML identity provider allows to manage all service providers that are registered at the UCS identity provider. Users have to be activated for a service provider, to be able to authenticate for it at the UCS identity provider. On the user's Account tab, the service provider has to be added under SAML settings.

To register the UCS identity provider at an external service provider, the public part of the SAML certificate is required by the service provider. The certificate can be downloaded via a link in the UMC module. Some service providers may require the UCS identity provider XML metadata as a file upload. In the default configuration, the XML file can be downloaded from the URL https://ucs-sso.domainname/simplesamlphp/saml2/idp/metadata.php.

The following attributes can be configured when adding a new service provider.

The UCS web interface can be opened on any UCS system via the URL https://servername/. Alternatively, access is also possible via the server's IP address. Under certain circumstances it may be necessary to access the services over an insecure connection (e.g., if no SSL certificates have been created for the system yet). In this case, http must be used instead of https in the URL. In this case, passwords are sent over the network in plain text!

The UCS web interface uses numerous JavaScript and CSS functions. Cookies need to be permitted in the browser. The following browsers are supported:

Users with older browsers may experience display problems.

The UCS web interface is available in German and English (and French if it is chosen as language during the installation from DVD); the language to be used can be changed via the entry Switch language of the user menu in the upper right corner.

By choosing the Help -> Feedback option in the upper right user menu, you can provide feedback on UCS via a web form.

Anonymous usage statistics on the use of the UCS web interface are collected when using the core edition version of UCS (which is generally used for evaluating UCS). Further information can be found in SDB 1318.

Univention Management Console (UMC) is the central tool for web-based administration of the UCS domain. It can be launched from the portal page (Section 4.3) via the link System and domain settings or System settings, respectively. Depending on the system role, different UMC modules are provided for administrating UCS. These may be complemented with new modules when installing additional software components.

UMC modules for the administration of all the data included in the LDAP directory (such as users, groups and computer accounts) are only provided on master domain controller and backup domain controller. Changes made in these modules are applied to the whole domain.

UMC modules for the configuration and administration of the local system are provided on all system roles. These modules can be used to install additional applications and updates, adapt the local configuration via Univention Configuration Registry or start/stop services, for example.

During the first login, an introduction wizard is shown, which informs the user of the collection of usage statistics (see Section 4.1.4) and allows license activation (see Section 4.4.2) among other things.

The current license status can be shown on a master domain controller of a domain by clicking on the user menu in the top right line of the screen. Below the menu item License the entry License information can be selected to open a corresponding information dialogue.

§

Figure 4.4. Displaying the UCS license

The menu entry Import new license opens a dialogue in which a new license key can be activated (otherwise the core edition license is used as default license). A license file can be selected and imported via the button Import from file.... Alternatively, the license key can also be copied into the input field below and activated with Import from text field.

Installation of most of the applications in the Univention App Center requires a personalized license key. UCS core edition licenses can be converted by clicking Activation of UCS. The current license key is sent to Univention and the updated key returned to a specified e-mail address within a few minutes. The new key can be imported directly. The conversion does not affect the scope of the license.

If the number of licensed user or computer objects is exceeded, it is not possible to create any additional objects in Univention Management Console or edit any existing ones unless an extended license is imported or no longer required users or computers are deleted. A corresponding message is displayed on the UMC start page if the license is exceeded.

All UMC modules for managing LDAP directory objects such as user, group and computer accounts or configurations for printers, shares, mail, Nagios and policies are controlled identically from a structural perspective. The following examples are presented using the user management but apply equally for all modules. The operation of the DNS and DHCP modules is slightly different. Further information can be found in Section 11.2.2 and Section 11.3.2.

§

Figure 4.5. Module overview

The configuration properties/possibilities of the modules are described in the following chapters:

The use of policies (Section 4.6) and the LDAP navigation (Section 4.5) are described separately.

§4.4.3.1. Searching for objects

The module overview lists all the objects managed by this module. Search performs a search for a selection of important attributes (e.g., for user objects by first and last name, primary e-mail address, description, employee number and user name). A wildcard search is also possible, e.g., m*.

Clicking on Advanced options displays additional search options:

• The Search in field can be used to select whether the complete LDAP directory or only individual LDAP containers/OUs are searched. Further information on the structure of the LDAP directory service can be found in Section 4.8.
• The Property field can be used to search for a certain attribute directly.
• The majority of the modules administrate a range of types of LDAP objects; the computer management for example administrates different objects for the individual system roles. The search can be limited to one type of LDAP object.
• Some of the internally used user groups and groups (e.g., for domain joins) are hidden in the default setting. If the Include hidden objects option is enabled, these objects are also shown.

§

Figure 4.6. Searching for users

Commonly used UMC modules are shown in the category Favorites. Clicking on a UMC module with the right mouse button opens a context menu. Add to favorites and Remove from favorites can be used to mark a UMC module as a favorite or remove it again.

UMC modules can deploy system messages to alert the user to potential errors - e.g., join scripts which have not been run - or necessary actions such as available updates. The messages are shown on the right side and can be dismissed with a mouse click.

Policies can be managed via the UMC module Policies. The operation is the same as for the functions described in Section 4.4.

The attributes and properties of the policies are described in the corresponding chapters, e.g. the DHCP policies in the network chapter.

The names of policies must not contain any umlauts.

Referencing objects provides a list of all containers or LDAP objects for which this policy currently applies.

The expanded settings host some general policy options which are generally only required in special cases.

Policies can be assigned in two ways:

The Policies configuration dialogue is functionally identical; however, all policy types are offered when assigning policies to a LDAP container, whilst only the policy types applicable for the object type in question are offered when assigning policies to an LDAP object.

A policy can be assigned to the LDAP object or container under Policies. The values resulting from this policy are displayed directly. The Inherited setting means that the settings are adopted from a superordinate policy again - when one exists.

If an object is linked to a policy, or inherits policy settings which cannot be applied to the object, the settings remain without effect for the object. This makes it possible, for example, to assign a policy to the base entry of the LDAP directory, which is then valid for all the objects of the domain which can apply this policy. Objects which cannot apply to this policy are not affected.

Policies can be edited and deleted in the UMC module Policies. The interface is described in Section 4.4.

The policy tab of the individual LDAP objects also includes the edit option, which can be used to edit the policy currently applicable for this object.

A complete list of available modules is displayed if the udm is run with the modules parameter:

# univention-directory-manager modules
Available Modules are:
  computers/managedclient
  computers/computer
  computers/domaincontroller_backup
  computers/domaincontroller_master
  computers/domaincontroller_slave
 [...]

There are up to five operations for every module:

The possible options of a UDM module and the operations which can be used on it can be output by specifying the operation name, e.g.,

univention-directory-manager users/user move
[...]
create options:
  --binddn                         bind DN
  --bindpwd                        bind password
[...]
modify options:
  --binddn                         bind DN
  --bindpwd                        bind password
  --dn                             Edit object with DN
[...]
remove options:
  --binddn                         bind DN
  --bindpwd                        bind password
  --dn                             Remove object with DN
  --arg                            Remove object with ARG
[...]
list options:
  --filter                         Lookup filter
[...]
move options:
  --binddn                         bind DN
  --bindpwd                        bind password
[...]

The following command outputs further information, the operations and the options for every module. This also displays all attributes of the module:

univention-directory-manager category/modulename

With the create operation, the attributes marked with (*) must be specified when creating a new object.

Some attributes can be assigned more than one value (e.g., mail addresses to user objects). These multi-value fields are marked with [] behind the attribute name. Some attributes can only be set if certain options are set for the object. This is performed for the individual attributes by entering the option name:

users/user variables:
  General:
    username (*)                             Username
[...]
  Contact:
    e-mail (person,[])                       E-Mail Address

Here, username (*) signifies that this attribute must always be set when creating user objects. If the person option is set for the user account (this is the standard case), one or more e-mail addresses can be added to the contact information.

A range of standard parameters are defined for every module:

The following examples for the command line front end of Univention Directory Manager can be used as templates for your own scripts:

univention-directory-manager users/user create \
    --position "cn=users,dc=example,dc=com" \
    --set username="user01" \
    --set firstname="Random" \
    --set lastname="User" \
    --set organisation="Example company LLC" \
    --set mailPrimaryAddress="mail@example.com" \
    --set password="secretpassword"

univention-directory-manager users/user modify \
    --dn "uid=user01,cn=users,dc=example,dc=com" \
    --set street="Exemplary Road 42" \
    --set postcode="28239" \
    --set city="Bremen"

univention-directory-manager users/user list \
    --filter uid=user*

univention-directory-manager users/user list \
    --filter uid="user*" \
    --position "cn=bremen,cn=users,dc=example,dc=com"

univention-directory-manager users/user remove \
    --dn "uid=user04,cn=users,dc=example,dc=com"

univention-directory-manager users/user move \
    --dn "uid=user03,cn=hamburg,cn=users,dc=example,dc=com" \
    --position "cn=bremen,cn=users,dc=example,dc=com"

univention-directory-manager groups/group create \
    --position "cn=groups,dc=example,dc=com" \
    --set name="Example Users" \
    --set users="uid=user01,cn=users,dc=example,dc=com"

univention-directory-manager groups/group modify \
    --dn "cn=Example Users,cn=groups,dc=example,dc=com" \
    --append users="uid=user02,cn=users,dc=example,dc=com"

univention-directory-manager groups/group modify \
    --dn "cn=Example Users,cn=groups,dc=example,dc=com" \
    --remove users="uid=user01,cn=users,dc=example,dc=com"

univention-directory-manager container/cn create \
    --position "cn=computers,dc=example,dc=com" \
    --set name="bremen" \
    --set computerPath=1

univention-directory-manager policies/share_userquota create \
    --position "cn=policies,dc=example,dc=com" \
    --set name="Default quota" \
    --set softLimitSpace=5GB \
    --set hardLimitSpace=10GB

univention-directory-manager container/cn modify \
    --dn "cn=users,dc=example,dc=com" \
    --policy-reference "cn=Default quota,cn=policies,dc=example,dc=com"

univention-directory-manager policies/registry create \
    --position "cn=config-registry,cn=policies,dc=example,dc=com" \
    --set name="default UCR settings" \
    --set registry="logrotate/rotate/count 52"

univention-directory-manager policies/registry modify \
    --dn "cn=default UCR settings,cn=config-registry,"\
"cn=policies,dc=example,dc=com" \
    --append registry='"logrotate/compress" "no"'

univention-directory-manager computers/windows create \
    --position "cn=computers,dc=example,dc=com" \
    --set name=WinClient01 \
    --set mac=aa:bb:cc:aa:bb:cc \
    --set ip=192.168.0.10

univention-directory-manager shares/share create \
    --position "cn=shares,dc=example,dc=com" \
    --set name="Documentation" \
    --set host="fileserver.example.com" \
    --set path="/var/shares/documentation"

univention-directory-manager shares/printer create \
    --position "cn=printers,dc=example,dc=com" \
    --set name="LaserPrinter01"  \
    --set spoolHost="printserver.example.com" \
    --set uri="ipp:// 192.168.0.100" \
    --set model="foomatic-rip/HP-Color_LaserJet_9500-Postscript.ppd" \
    --set location="Head office" \
    --set producer="producer: "\
"cn=HP,cn=cups,cn=univention,dc=example,dc=com"

univention-directory-manager shares/printergroup create \
    --set name=LaserPrinters \
    --set spoolHost="printserver.example.com" \
    --append groupMember=LaserPrinter01 \
    --append groupMember=LaserPrinter02

univention-directory-manager dhcp/host create \
    --superordinate "cn=example.com,cn=dhcp,dc=example,dc=com" \
    --set host="Client222" \
    --set fixedaddress="192.168.0.110" \
    --set hwaddress="ethernet 00:11:22:33:44:55"

univention-directory-manager dns/host_record create \
    --superordinate "zoneName=example.com,cn=dns,dc=example,dc=com" \
    --set name="Client222" \
    --set a="192.168.0.110"

univention-directory-manager dns/ptr_record create \
    --superordinate "zoneName=0.168.192.in-addr.arpa,cn=dns,"\
"dc=example,dc=com" \
    --set address="110" \
    --set ptr_record="Client222.example.com."

univention-directory-manager settings/extended_attribute create \
    --position "cn=custom attributes,cn=univention,dc=example,dc=com" \
    --set name="CarLicense" \
    --set module="users/user" \
    --set ldapMapping="univentionFreeAttribute1" \
    --set objectClass="univentionFreeAttributes" \
    --set longDescription="License plate number of the company car" \
    --set tabName="Company car" \
    --set multivalue=0 \
    --set syntax="string" \
    --set shortDescription="Car license"

To create a report, you need to switch to the UMC module for users, groups or hosts. Then all the objects covered by the report must be selected (you can select all objects by clicking the button on the left of Name). Clicking on more -> Create report allows to choose between the Standard Report in PDF format and the Standard CSV Report in CSV format.

§

Figure 4.10. Creating a report

The reports created via Univention Management Console are stored for 12 hours and then deleted by a cron job. The settings for when the cron job should run and how long the reports should be stored for can be defined via two Univention Configuration Registry variables:

Reports can also be created via the command line with the univention-directory-reports program. Information on the use of the program can be viewed using the --help option.

The following command can be used to list the report templates available to users, for example:

univention-directory-reports -m users/user -l

Existing reports can be created directly with the presettings. Some presettings can be adapted using Univention Configuration Registry. For example, it is possible to replace the logo that appears in the header of each page of a PDF report. To do so, the value of the Univention Configuration Registry variable directory/reports/logo can include the name of an image file. The usual image formats such as JPEG, PNG and GIF can be used. The image is automatically adapted to a fixed width of 5.0 cm.

In addition to the logo, the contents of the report can also be adapted by defining new report templates.

In environments with more than one UCS system, the update order of the UCS systems must be borne in mind:

The authoritative version of the LDAP directory service is maintained on the master domain controller and replicated on all the remaining LDAP servers of the UCS domain. As changes to the LDAP schemes (see Section 3.4.1) can occur during release updates, the master domain controller must always be the first system to be updated during a release update.

It is generally advisable to update all UCS systems in one maintenance window whenever possible. If this is not possible, all not-updated UCS systems should only be one release version older compared with the master domain controller.

The Software update module allows the installation of release updates and errata updates.

Figure Figure 5.4 shows the overview page of the module. The currently installed version is displayed under Release updates in the upper part of the dialogue box.

§

Figure 5.4. Updating a UCS system in UMC

If a newer UCS version is available, a select list is displayed. After clicking on Install release updates and confirmation all updates up to the respective version are installed. Before the installation process is started, a message will be displayed informing the user of possible restrictions of the server services during the update. Any intermediate versions are also installed automatically.

Clicking on Install available errata updates installs all the available errata updates for the current release and all installed components.

Check for package updates activates an update of the package sources currently entered. This can be used, for example, if an updated version is provided for a component.

The messages created during the update are written to the file /var/log/univention/updater.log

The following steps must be performed with root rights.

An individual UCS system can be updated using the univention-upgrade command in the command line. A check is performed to establish whether new release or application updates are available and these are then installed if a prompt is confirmed. In addition, package updates are also performed (e.g., in the scope of an errata update).

In the basic setting, the packages to be updated are loaded from a repository via the network. If a local repository is used (see Section 5.5.4), release updates can alternatively also be installed via update DVD images, which are either imported as ISO files or from a drive. This is done by running univention-upgrade with the parameters --iso=ISOIMAGEFILE or --cdrom=DRIVE.

Remote updating over SSH is not advisable as this may result in the update procedure being aborted. If updates should occur over a network connection nevertheless, it must be verified that the update continues despite disconnection from the network. This can be done, for example, using the tools screen and at, which are installed on all system roles.

The messages created during the update are written to the file /var/log/univention/updater.log

An update for more than one computer can be configured with an Automatic updates policy in the UMC modules for computer and domain management (see Section 4.6).

§

Figure 5.5. Updating UCS systems using an update policy

A release update is only run when the Activate release updates selection field is activated.

The Update to this UCS version input field includes the version number up to which the system should be updated, e.g., 4.3-1. If no entry is made, the system continues updating to the highest available version number.

The point at which the update should be performed is configured via a Maintenance policy (see Section 5.7).

The messages created during the update are written to the file /var/log/univention/updater.log.

Once a release update has been performed successfully, a check should be made for whether new or updated join scripts need to be run.

Either the Domain join UMC module or the command line program univention-run-join-scripts is used for checking and starting the join scripts (see Section 3.2.1).

The messages generated during updates are written to the /var/log/univention/updater.log file, which can be used for more in-depth error analysis.

The status of the Univention Configuration Registry variables before the release update is saved in the /var/univention-backup/update-to-TARGETRELEASEVERSION/ directory. This can then be used to check whether and which variables have been changed during the update.

The Repository server and the use of the maintained and unmaintained sections can be specified in the UMC module Repository Settings.

The repository server to be used can be entered in the Univention Configuration Registry variable repository/online/server and is preset to updates.software-univention.de for a new installation.

The unmaintained repository can be integrated by setting the Univention Configuration Registry variable repository/online/unmaintained to yes.

The repository server to be used can also be specified using the Repository server policy in the computer management of the Univention Management Console. Only UCS server systems for which a DNS entry has been configured are shown in the selection field (see Section 4.6).

Package installations and updates can either be performed from the Univention update server or from a locally maintained repository. A local repository is practical if there are a lot of UCS systems to update as the updates only need to be downloaded once in this case. As repositories can also be updated offline, a local repository also allows the updating of UCS environments without Internet access.

There is also the possibility of synchronizing local repositories, which means, for example, a main repository is maintained at the company headquarters and then synchronized to local repositories at the individual locations.

To set up a repository, the univention-repository-create command must be run as the root user. The initial package inventory is imported from an installation DVD. The parameter --iso allows importing from an ISO image. UCS is only available as a 64-bit DVD. The repository is created by univention-repository-create with the architecture of the specified installation medium. If an environment is operated in which both 32-bit and 64-bit packages are needed, the following commands must be executed on the repository server:

ucr set repository/online/architectures="i386 amd64"
univention-repository-update net

Access to the Univention online repository is cryptographically secured via the use of Secure APT employing signatures. This feature is not currently available for local repositories and so a message appears when creating a repository explaining how Secure APT can be deactivated using the Univention Configuration Registry variable update/secure_apt. This setting must be set on all UCS systems that access the repository.

The packages in the repository can be updated using the univention-repository-update tool. It supports two modes:

An overview of the possible options is displayed with the following command:

univention-repository-update -h

The repository is stored in the /var/lib/univention-repository/mirror/ directory.

The local repository can be activated/deactivated using the Univention Configuration Registry variable local/repository.

All software components offered in the Univention Installer can also be installed and removed at a later point in time via the Univention App Center. This is done by selecting the UCS components package category. Further information on the Univention App Center can be found in Section 5.3.

§

Figure 5.6. Selection of UCS components in the App Center

The UMC module Package Management can be used to install and uninstall individual software packages.

§

Figure 5.7. Installing the package univention-squid in Univention Management Console

A search mask is displayed on the start page in which the user can select the package category or a search filter (name or description). The results are displayed in a table with the following columns:

Clicking an entry in the result list opens a detailed information page with a comprehensive description of the package.

In addition, one or more buttons will be displayed: Install is displayed if the software package is not installed yet; Uninstall is displayed if the software package is installed and Upgrade is displayed if the software package is installed but not updated. Close can be used for returning to the previous search request.

The following steps must be performed with root rights.

Individual packages are installed using the command

univention-install PACKAGENAME

Packages can be removed with the following command:

univention-remove PACKAGENAME

If the name of a package is unknown, the command apt-cache search can be used to search for the package. Parts of the name or words which appear in the description of the package are listed, e.g.:

apt-cache search fax

Package lists can be used to install and remove software using policies. This allows central software deployment for a large number of computer systems.

Each system role has its own package policy type.

Package policies are managed in the UMC module Policies with the Policy: Packages + system role.

The software packages defined in a package list are installed/uninstalled at the time defined in the Maintenance policy (for the configuration see Section 5.7).

The software assignable in the package policies are also registered in the LDAP.

In Univention Management Console, every user can reset his password via the Change password module. The module can also be opened by selecting the Settings -> Change password entry in the top right user menu. To change the password, the current password must be entered first. The change is performed directly via the PAM stack (see Section 8.4.4) and is then available centrally for all services.

By installing the UCS component Self Service via the App Center, users are enabled to take care of their password management without administrator interaction.

The Self Service app registers one web service on the portal which can be accessed via a dedicated web page: "Change Password". It allows users to update their password given their old password as well as to reset their lost password by requesting a token to be sent to a previously registered contact e-mail address. The token has to be entered on the dedicated password reset web page.

In Samba Active Directory environments, various services are provided by Samba, such as Kerberos. To lockout users after too many failed log-in attempts, the tool samba-tool can be used.

The manual unlocking of a user is done in the user administration on the tab Account by activating the checkbox Unlock account.

The automatic locking of users after failed logons in the PAM stack can be enabled by setting the Univention Configuration Registry variable auth/faillog to yes. The upper limit of failed log-in attempts at which an account lockout is configured in the Univention Configuration Registry variable auth/faillog/limit. The counter is reset each time the password is entered correctly.

The lockout is activated locally per system by default. In other words, if a user enters her password incorrectly too many times on one system, she can still login on another system. Setting the Univention Configuration Registry variable auth/faillog/lock_global will make the lock effective globally and register it in the LDAP directory. The global lock can only be set on master domain controller/Backup systems as other system roles do not have the necessary permissions in the LDAP directory. On all systems with any of these system roles, the lockout gets automatically activated locally or deactivated again via the listener module, depending on the current lock state in the LDAP directory.

As standard, the lockout is not subject to time limitations and must be reset by the administrator. However, it can also be reset automatically after a certain time interval has elapsed. This is done by specifying a time period in seconds in the Univention Configuration Registry variable auth/faillog/unlock_time. If the value is set to 0, the lock is reset immediately.

By default, the root user is excluded from the password lock, but can also be subjected to it by setting the Univention Configuration Registry variable auth/faillog/root to yes.

If accounts are only locked locally, the administrator can unlock a user account by entering the command faillog -r -u USERNAME. If the lock occurs globally in the LDAP directory, the user can be reset in Univention Management Console on the tab Account in the user options Unlock account.

On domain controllers, automatic account locking can be enabled for too many failed LDAP server logon attempts. The MDB LDAP backend must be used. This is the default backend since UCS 4, previous systems must be migrated to the MDB LDAP backend, see [ucs-performance-guide].

Automatic account locking must be enabled for each domain controller. To do this, the Univention Configuration Registry variables ldap/ppolicy and ldap/ppolicy/enabled must be set to yes and the OpenLDAP server must be restarted:

ucr set ldap/ppolicy=yes ldap/ppolicy/enabled=yes
/etc/init.d/slapd restart

The default policy is designed so that five repeated failed LDAP server logon attempts within five minutes cause the lockout. A locked account can only be unlocked by a domain administrator via Univention Management Console.

The number of repeated failed LDAP server logon attempts can be adjusted in the configuration object with the objectClass pwdPolicy:

univention-ldapsearch objectclass=pwdPolicy

The pwdMaxFailure attribute determines the number of LDAP authentication errors before locking. The pwdMaxFailureCountInterval attribute determines the time interval in seconds that is considered. Failed logon attempts outside this interval are ignored in the count.

The following command can be used to block the account after 10 attempts:

ldapmodify -x -D cn=admin,$(ucr get ldap/base) -y /etc/ldap.secret <<__EOT__
dn: cn=default,cn=ppolicy,cn=univention,$(ucr get ldap/base)
changetype: modify
replace: pwdMaxFailure
pwdMaxFailure: 10
__EOT__

The manual unlocking of a user is done in the user administration on the tab Account by activating the checkbox Unlock account.

Ubuntu clients can be managed in Univention Management Console with their own system role. The network properties for DNS/DHCP can also be managed via Univention Management Console.

The use of policies is not supported.

Some configuration adjustments need to be performed on Ubuntu systems; these are documented in the extended documentation [ext-doc-domain].

The standard kernel in UCS 4.3 is based on the Linux kernel 4.9. In principle, there are three different types of kernel packages:

Normally, the operation of a UCS system only requires the installation of one kernel image package.

The default kernel in UCS for i386-based systems is the so-called bigmem kernel for processors with PAE support, which supports 64 GB RAM. For older i386-based systems a second kernel without PAE support is provided, which only supports up to 4 GB RAM. The standard kernel for amd64 systems has no such limits.

Several kernel versions can be installed in parallel. This makes sure that there is always an older version available to which can be reverted in case of an error. So-called meta packages are available which always refer to the kernel version currently recommended for UCS. In case of an update, the new kernel version will be installed, making it possible to keep the system up to date at any time.

The following meta packages are available under i386 / 32 bit:

The following meta packages are available under amd64 / 64 bit:

The boot process occurs in two steps using an initial ramdisk ('initrd' for short). This is composed of an archive with further drivers and programs.

The GRUB boot manager (see Section 8.2.3) loads the kernel and the initrd into the system memory, where the initrd archive is extracted and mounted as a temporary root file system. The real root file system is then mounted from this, before the temporary archive is removed and the system start implemented.

The drivers to be used are recognized automatically during system start and loaded via the udev device manager. At this point, the necessary device links are also created under /dev/. If drivers are not recognized (which can occur if no respective hardware IDs are registered or hardware is employed which cannot be recognized automatically, e.g., ISA boards), kernel modules to be loaded can be added via Univention Configuration Registry variable kernel/modules. If more than one kernel module is to be loaded, these must be separated by a semicolon. The Univention Configuration Registry variable kernel/blacklist can be used to configure a list of one or more kernel modules for which automatic loading should be prevented. Multiple entries must also be separated by a semicolon.

Unlike other operating systems, the Linux kernel (with very few exceptions) provides all drivers for hardware components from one source. For this reason, it is not normally necessary to install drivers from external sources subsequently.

However, if external drivers / kernel modules are required, they can be integrated via the DKMS framework (Dynamic Kernel Module Support). This provides a standardized interface for kernel sources, which are then built automatically for every installed kernel (insofar as the source package is compatible with the respective kernel). For this to happen, the kernel header package univention-kernel-headers must be installed in addition to the dkms package. Please note that not all the external kernel modules are compatible with all kernels.

In Univention Corporate Server GNU GRUB 2 is used as the boot manager. GRUB provides a menu which allows the selection of a Linux kernel or another operating system to be booted. GRUB can also access file systems directly and can thus, for example, load another kernel in case of an error.

§

Figure 8.3. GRUB menu

GRUB gets loaded in a two-step procedure; in the Master Boot Record of the hard drive, the Stage 1 loader is written which refers to the data of Stage 2, which in turn manages the rest of the boot procedure.

The selection of kernels to be started in the boot menu is stored in the file /boot/grub/grub.cfg. This file is generated automatically; all installed kernel packages are available for selection. The memory test program Memtest86+ can be started by selecting the option Memory test and performs a consistency check for the main memory.

There is a five second waiting period during which the kernel to be booted can be selected. This delay can be changed via the Univention Configuration Registry variable grub/timeout.

By default a screen of 800x600 pixels size and 16 Bit color depth is pre-set. A different value can be set via the Univention Configuration Registry variable grub/gfxmode. Only resolutions are supported which can be set via VESA BIOS extensions. A list of available modes can be found at https://en.wikipedia.org/wiki/VESA_BIOS_Extensions. The input must be specified in the format HORIZONTALxVERTICAL@COLOURDEPTHBIT, so for example 1024x768@16.

Kernel options for the started Linux kernel can be passed with the Univention Configuration Registry variable grub/append. Univention Configuration Registry variable grub/xenhopt can be used to pass options to the Xen hypervisor.

The graphic representation of the boot procedure - the so-called splash screen - can be deactivated by setting Univention Configuration Registry variable grub/bootsplash to nosplash.

Older Xen environments might use a version of PyGrub, which still requires the GRUB 1 configuration file /goot/grub/menu.lst to boot paravirtualized Xen systems. This file is generated automatically if it does not yet exist. This behavior can be deactivated by setting the Univention Configuration Registry variable grub/generate-menu-lst to no.

The configuration of the graphic resolutions and monitor parameters is performed via automatic detection of the graphics card and the monitor in the default setting. When this is done, the best available driver for the graphics card is selected automatically and the monitor resolution set to the highest value supported by the monitor.

The settings can be set with a Univention Configuration Registry policy. Manual configuration is also necessary if dual monitor operation is to be used. The following provides a selection of the important settings and the corresponding UCR variables in parentheses:

The NFS mounts policy of the UMC computer management can be used to configure NFS shares, which are mounted on the system. There is a NFS share for selection, which is mounted in the file path specified under Mount point.

§

Figure 8.5. Mounting a NFS share

Univention maintains a list of the hardware [hardwarelist] which is compatible with UCS and in use by customers. The information processed for this are gathered by the UMC module System information.

All files are forwarded to Univention anonymously and only transferred once permission has been received from the user.

The start dialogue contains the entry fields Manufacturer and Model, which must be completed with the values determined from the DMI information of the hardware. The fields can also be adapted and an additional Descriptive comment added.

If the system information is transferred as part of a support request, the This is related to a support case option should be activated. A ticket number can be entered in the next field; this facilitates assignment and allows quicker processing.

Clicking on Next offers an overview of the transferred system information. In addition, a compressed .tar archive is created, which contains a list of the hardware components used in the system and can be downloaded via Archive with system information.

Clicking on Next again allows you to select the way the data are transferred to Univention. Upload transmits the data via HTTPS, Send mail) opens a dialogue, which lists the needed steps to send the archive via e-mail.

Univention Configuration Registry is the central tool for managing the local system configuration of a UCS-based system. Direct editing of the configuration files is usually not necessary.

Settings are specified in a consistent format in a registry mechanism, the so-called Univention Configuration Registry variables. These variables are used to generate the configuration files used effectively by the services/programs from the configuration templates (the so-called Univention Configuration Registry templates).

This procedure offers a range of advantages:

Univention Configuration Registry variables can be configured in the command line using the univention-config-registry command (short form: ucr or via Univention Management Console.

As the majority of packages perform their configuration via Univention Configuration Registry and the corresponding basic settings need to be set up during the installation, hundreds of Univention Configuration Registry variables are already set after the installation of a UCS system.

UCR variables can also be used efficiently in shell scripts for accessing current system settings.

The variables are named according to a tree structure with a forward slash being used to separate components of the name. For example, Univention Configuration Registry variables beginning with ldap are settings which apply to the local directory service.

A description is given for the majority of variables explaining their use.

If a configuration file is administrated by a UCR template and the required setting has not already been covered by an existing variable, the UCR template should be edited instead of the configuration file. If the configuration were directly adapted, the next time the file is regenerated - e.g., when a registered UCR variable is set - the local modification will be overwritten again. Adaptation of UCR templates is described in Section 8.3.5.

Part of the settings configured in Univention Configuration Registry are system-specific (e.g., the computer name); many settings can, however, be used on more then one computer. The Univention Configuration Registry policy in the domain administration of Univention Management Console can be used to compile variables and apply them on more than one computer.

The evaluation of the Univention Configuration Registry variables on a UCS system comprises four stages:

If a variable is set which is overwritten by a superordinate policy, a warning message is given.

The use of the Univention Configuration Registry policy is documented in the Section 8.3.4.

The UMC module Univention Configuration Registry can be used to display and adjust the variables of a system. There is also the possibility of setting new variables using Add new variable.

A search mask is displayed on the start page. All variables are classified using a Category, for example all LDAP-specific settings.

The Search attribute can be entered as a filter in the search mask, which can refer to the variable name, value or description.

Following a successful search, the variables found are displayed in a table with the variable name and the value. A detailed description of the variable is displayed when moving the mouse cursor over the variable name.

Clicking on the icon with the stylized pen edits the setting of a variable. The icon with the stylized minus sign allows the deletion of a variable.

The command line interface of Univention Configuration Registry is run using the univention-config-registry command. Alternatively, the short form ucr can be used.

univention-config-registry get ldap/server/ip

univention-config-registry dump