UCS 2.4 - Univention

Univention Corporate Server 

Manual for users and administrators

Version 2.4-4 

Revision 11656 

Date: December 22, 2011 

Alle Rechte vorbehalten. / All rights reserved. 

(c) 2002 bis 2011 

Univention GmbH 

Mary-Somerville-Straße 1 

28359 Bremen 

Deutschland 

feedback@univention.de 

Jede aufgeführte Marke und jedes Warenzeichen steht im Eigentum ihrer jeweiligen eingetragenen Rechtsin- 

haber. Linux ist ein eingetragenes Warenzeichen von Linus Torvalds. 

The mentioned brand names and registered trademarks are owned by the respective legal owners in each 

case. Linux is a registered trademark of Linus Torvalds.

Contents 

1 Introduction 11 

1.1 What is Univention Corporate Server? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

1.2 UCS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

1.3 Further documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

1.4 Symbols and conventions used in this manual . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

2 Domain concept 15 

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

2.2 UCS system roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

2.2.1 Domain controller master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

2.2.2 Domain controller backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

2.2.3 Domain controller slave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

2.2.4 Member server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

2.2.5 Base system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

2.2.6 Managed client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

2.2.7 Mobile client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

2.2.8 Thin Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

2.3 System roles in Windows domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

2.3.1 How are these roles integrated in the UCS concept? . . . . . . . . . . . . . . . . . . 18 

2.4 Joining domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

2.4.1 How UCS systems join domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

2.4.2 How to join domains with Windows clients . . . . . . . . . . . . . . . . . . . . . . . . 21 

2.4.3 Rotation of machine account passwords . . . . . . . . . . . . . . . . . . . . . . . . . 23 

3 Installation 25 

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

3.2 Text-based Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

3.2.1 Operating the Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 

3.2.2 The Procedures of Text-based Installation . . . . . . . . . . . . . . . . . . . . . . . . 27 

3.3 Hardware-related Installation problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

3.3.1 Starting the Installation with additional kernel parameters . . . . . . . . . . . . . . . 38 

3.3.2 Additional kernel parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

3.3.3 Adjusting the automatic hardware detection . . . . . . . . . . . . . . . . . . . . . . . 38 

3.4 Installing and Renewing Licences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 

3.5 Subsequent Installation of Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 

4 Univention Directory Manager 41 

3

Contents 

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 

4.2 Instructions for Operating the Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 

4.2.1 Notes on list fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 

4.2.2 Notes on group membership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 

4.3 Univention Directory Manager Wizards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 

4.3.1 The ”Search” submenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 

4.3.2 The ”Add” submenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 

4.4 Navigation in LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 

4.4.1 Navigating the directory tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 

4.4.2 Displaying and editing objects in the LDAP navigation . . . . . . . . . . . . . . . . . 52 

4.5 Univention Directory Manager modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 

4.5.1 User administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 

4.5.2 Group management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 

4.5.3 Network administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 

4.5.4 Host management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 

4.5.5 Shares management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 

4.5.6 Samba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 

4.5.7 Printer management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 

4.5.8 Containers, organisational units, domains . . . . . . . . . . . . . . . . . . . . . . . . 91 

4.5.9 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 

4.5.10 DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 

4.5.11 Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 

4.5.12 Univention Directory Manager settings . . . . . . . . . . . . . . . . . . . . . . . . . . 129 

4.5.13 User-defined attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 

4.5.14 Extended attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 

4.6 Policy-controlled Layouts for the Web Front-End of Univention Directory Manager . . . . . . 146 

5 Univention Management Console 153 

4 

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 

5.2 Layout of the Web Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 

5.2.1 Login Mask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 

5.2.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 

5.3 Standard modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 

5.3.1 System statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 

5.3.2 Kernel modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 

5.3.3 VNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 

5.3.4 System information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 

5.3.5 Univention Configuration Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 

5.3.6 Printer administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 

5.3.7 Process overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 

5.3.8 Filesystem quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 

5.3.9 System services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 

5.3.10 Joining a domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 

5.3.11 Package management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Contents 

5.3.12 Reboot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 

5.3.13 Online update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 

5.4 Wizards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 

5.4.1 Basis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 

5.4.2 Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 

5.4.3 Mail server configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 

6 Univention Virtual Machine Manager (UVMM) 169 

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 

6.1.1 Paravirtualisation / virtIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 

6.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 

6.3 Managing virtual machines with UVMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 

6.3.1 Creating a virtual instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 

6.3.2 Modifying virtual machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 

6.3.3 Migration of virtual machines from failed virtualization servers . . . . . . . . . . . . . 178 

7 UCS Directory service 181 

7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 

7.2 Logging of LDAP changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 

7.2.1 Installation and setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 

7.2.2 Format of the log file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 

7.3 Timeout for inactive LDAP connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 

7.4 Configuration of LDAP ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 

7.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 

7.4.2 Definition of objects for which a rule applies (access to) . . . . . . . . . . . . . . . . 184 

7.4.3 Definition of the access permissions on the objects . . . . . . . . . . . . . . . . . . . 184 

7.4.4 Definition of the permission on the objects . . . . . . . . . . . . . . . . . . . . . . . . 185 

7.4.5 Definition of the handling of further rules with applied rules . . . . . . . . . . . . . . 185 

7.4.6 Delegation of the privilege to reset user passwords . . . . . . . . . . . . . . . . . . . 186 

8 Services for Windows 187 

8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 

8.2 Univention Corporate Server and Samba . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 

8.2.1 Authentication Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 

8.2.2 File server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 

8.2.3 Print server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 

8.2.4 NetBIOS Network Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 

8.3 Building Samba domains with UCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 

8.4 Extended Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 

8.4.1 Trust relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 

8.4.2 WINS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 

8.4.3 NETLOGON share . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 

8.4.4 Creating objects in the LDAP directory using Samba . . . . . . . . . . . . . . . . . . 197 

8.4.5 Configuring Windows user accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 

8.4.6 Configuring Samba servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 

5

Contents 

9 Desktop systems 203 

9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 

9.2 Desktop system roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 

9.2.1 Thin clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 

9.2.2 Managed clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 

9.2.3 Mobile clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 

9.3 Managing desktop systems with Univention Directory Manager . . . . . . . . . . . . . . . . 205 

9.3.1 Graphical user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 

9.3.2 Connection to server systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 

9.3.3 Autostart scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 

9.3.4 NX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 

9.4 VNC desktop sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 

9.4.1 Configuring VNC access for thin clients . . . . . . . . . . . . . . . . . . . . . . . . . 208 

9.4.2 Configuring VNC access for managed/mobile clients . . . . . . . . . . . . . . . . . . 208 

9.5 Thin client environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 

9.5.1 Support for booting from Compact Flash cards or USB sticks . . . . . . . . . . . . . 210 

9.5.2 Thin client components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 

9.6 Home directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 

9.6.1 Creation of new home directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 

9.6.2 Modifying the default content of home directories . . . . . . . . . . . . . . . . . . . . 215 

9.6.3 Setting environment variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 

9.7 Global home directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 

9.7.1 Creating and modifying global home directories . . . . . . . . . . . . . . . . . . . . . 217 

10 Basic System Services 221 

6 

10.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 

10.2 Server Homepage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 

10.3 Packet filter with Univention Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 

10.3.1 Service definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 

10.3.2 Service profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 

10.3.3 Local filter rules by Univention Configuration Registry . . . . . . . . . . . . . . . . . 224 

10.3.4 Local filter rules via iptables commands . . . . . . . . . . . . . . . . . . . . . . . . . 224 

10.3.5 Testing Univention Firewall settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 

10.4 Authentication / PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 

10.4.1 Automatic lockout of users after failed login attempts . . . . . . . . . . . . . . . . . . 227 

10.5 Network configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 

10.5.1 Network interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 

10.5.2 DNS servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 

10.5.3 Proxy configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 

10.6 Logging of system messages and system status . . . . . . . . . . . . . . . . . . . . . . . . 229 

10.6.1 Log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 

10.6.2 Logging the system status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 

10.7 Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 

10.7.1 Available kernel variants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

Contents 

10.7.2 Hardware drivers / kernel modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 

10.8 GRUB boot manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 

10.9 Executing recurring actions with Cron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 

10.9.1 Hourly/daily/weekly/monthly execution of scripts . . . . . . . . . . . . . . . . . . . . 232 

10.9.2 Defining local cron jobs in /etc/cron.d . . . . . . . . . . . . . . . . . . . . . . . . . . 232 

10.9.3 Defining cron jobs in Univention Configuration Registry . . . . . . . . . . . . . . . . 233 

10.10Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 

10.11Name resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 

10.11.1Name Service Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 

10.11.2LDAP NSS module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 

10.11.3Nameserver cache daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 

10.11.4Configuration of /etc/hosts in Univention Configuration Registry . . . . . . . . . . . . 235 

10.12SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 

10.13Time synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 

11 Software maintenance 237 

11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 

11.2 UCS updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 

11.2.1 UCS security updates and hotfixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 

11.2.2 UCS release updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 

11.3 Package maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 

11.3.1 Assigning repository servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 

11.3.2 Updating packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 

11.3.3 Adding component repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 

11.3.4 Managing package lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 

11.3.5 Release updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 

11.3.6 Manual package maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 

11.4 Software monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 

11.5 Repository management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 

11.5.1 Creating a repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 

11.5.2 Adding packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 

11.5.3 Removing packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 

11.5.4 Merging repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 

11.5.5 Repository synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 

12 Mail 255 

12.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 

12.2 Basic mail services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 

12.3 Setting up the mail server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 

12.3.1 SMTP server (Postfix) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 

12.3.2 IMAP/POP3 server (Cyrus) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 

12.3.3 Mail quota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 

12.3.4 Log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 

12.4 Spam filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 

7

Contents 

12.5 Virus filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 

12.6 Configuring mail clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 

12.6.1 Kontact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 

12.6.2 Outlook Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 

13 Print services 265 

13.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 

13.2 Installing print servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 

13.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 

13.2.2 Server systems as print servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 

13.2.3 Windows systems as print servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 

13.2.4 Thin clients as print servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 

13.2.5 Managed/mobile clients as print servers . . . . . . . . . . . . . . . . . . . . . . . . . 267 

13.2.6 Policy-based assignment of a print server . . . . . . . . . . . . . . . . . . . . . . . . 268 

13.3 Configuring printer shares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 

13.3.1 Configuring a locally connected printer . . . . . . . . . . . . . . . . . . . . . . . . . . 268 

13.3.2 Setting up network printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 

13.3.3 Setting up PDF printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 

13.3.4 Setting up printer groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 

13.4 Adding printer shares in Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 

13.5 Print quota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 

13.5.1 Activating the print quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 

13.5.2 Creating a print quota policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 

13.5.3 Analysing the print quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 

13.5.4 Modifying the print quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 

13.6 Univention Configuration Registry variables . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 

13.6.1 Settings for print clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 

13.6.2 Settings for the authentication on printer shares . . . . . . . . . . . . . . . . . . . . . 276 

13.6.3 Settings for printer shares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 

13.6.4 Settings for print quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 

14 Univention Configuration Registry 277 

8 

14.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 

14.2 Displaying current settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 

14.3 Using variables in shell scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 

14.4 Changing Univention Configuration Registry variables . . . . . . . . . . . . . . . . . . . . . 280 

14.5 Creating new Univention Configuration Registry variables . . . . . . . . . . . . . . . . . . . 281 

14.6 Deleting Univention Configuration Registry variables . . . . . . . . . . . . . . . . . . . . . . 281 

14.7 Registering Univention Configuration Registry variables . . . . . . . . . . . . . . . . . . . . 281 

14.8 Regeneration of configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 

14.9 Policy-based configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 

14.9.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 

14.9.2 Configuring the policy in Univention Directory Manager . . . . . . . . . . . . . . . . 284 

14.10Univention Configuration Registry in manually created packages . . . . . . . . . . . . . . . 284

Contents 

14.11Including additional configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 

14.12Integrating Python code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 

15 Univention System Setup 289 

15.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 

15.2 Univention System Setup modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 

15.2.1 Basic settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 

15.2.2 Keyboard settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 

15.2.3 Language settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 

15.2.4 Network settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 

15.2.5 Software components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 

15.2.6 Time zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 

15.3 Univention System Setup event registration . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 

15.4 Configuration for executing at system start . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 

15.5 Changing machine passwords/SSL certificates during system start . . . . . . . . . . . . . . 299 

16 Frequently asked questions 301 

16.1 How do I replace the DC master with a DC backup? . . . . . . . . . . . . . . . . . . . . . . 301 

16.2 How can I install Microsoft TrueType fonts subsequently? . . . . . . . . . . . . . . . . . . . 302 

16.3 How does a user change his password? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 

16.3.1 On a Linux workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 

16.3.2 On a Windows workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 

16.3.3 When logging on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 

16.3.4 Via Univention Directory Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 

16.4 How is the password for root changed? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 

16.5 What criteria must a password satisfy? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 

16.6 Individual websites cannot be accessed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 

16.7 Thin clients experience log-in problems in a domain spread over several locations . . . . . 305 

16.8 How do I change the Univention Directory Manager timeout? . . . . . . . . . . . . . . . . . 305 

16.9 Why are NFS shares not mounted during boot-up? . . . . . . . . . . . . . . . . . . . . . . . 305 

16.10What does ”No DB server name found.” mean? . . . . . . . . . . . . . . . . . . . . . . . . . 306 

16.11Computer name and network settings in Windows XP Prof. . . . . . . . . . . . . . . . . . . 306 

16.12Avoiding double log-ins on Windows terminal servers . . . . . . . . . . . . . . . . . . . . . . 307 

Further documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 

9

Contents 

10

1 Introduction 

Contents 

1.1 What is Univention Corporate Server? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

1.2 UCS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

1.3 Further documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

1.4 Symbols and conventions used in this manual . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

1.1 What is Univention Corporate Server? 

Univention Corporate Server (UCS) is a Linux-based operating system realising an overall concept with 

central administration from the server right through to the client. In doing so, it makes copious use of a 

comprehensive domain concept. 

UCS consists of three main elements 

1. UCS base system 

2. Univention Management System 

3. UCS components 

The base system consists of the operating system (The UCS Linux distribution based on Debian GNU/Linux) 

and tools for the installation, updates and for local configuration management of clients and servers. 

The Univention Management System realises a single point of administration where the accounts of all 

domain members (users, groups, and hosts) and services like DHCP and DNS are managed in a single 

directory service. For this purpose, the system makes use of the standard components OpenLDAP, Ker- 

beros, DNS, and SSL. It can be used via a web-based or a command-line-based interface. It is extendable 

and provides a flexible client-server architecture which allows changes to be transferred to the involved 

systems and be activated there. 

UCS components extend the system with functions such as the thin client infrastructure, terminal ser- 

vices, groupware or services for Windows, which all integrate in the Univention Management System. 

UCS allows not only simple, comfortable management of individual services, but also the administration 

of complex permission schemes of large organisations on multiple sites with many servers and clients and 

tens of thousands of users. It’s modular design provides many interfaces for extension and modification. 

1.2 UCS Overview 

As an operating system designed for multi-user and multi-tasking application right from the start, where 

the focus was always on stability, safety, and compatibility to other operating systems, Linux is predestined 

11


for being used in complex environments. In general opinion, however, the management of Linux systems 

used to be regarded as being difficult and far from comfortable. This is the point where UCS comes into 

play. 

UCS allows Linux to be deployed as a central and economic component within your IT infrastructure. All 

the business-critical applications are integrated in a uniform concept, adapted to each other, and pre- 

configured for professional utilisation. UCS is equally suitable for small organisations with few servers and 

clients, as for complex, heterogeneous environments where several tens of thousands of users work at 

computers with a variety of different operating systems and tasks. 

The deployment of UCS starts with the easy installation, which can be run interactively on profile-based 

from a DVD or via the network. During the installation, a system role is assigned to the host. As with Win- 

dows, all UCS hosts are controlled within a common security and trust context - the UCS domain. Available 

system roles are domain controllers, member servers and client. Additionally, stand alone servers can be 

integrated into the domain. 

Depending on the role the computer is to play within the domain such services as Kerberos, OpenLDAP, 

modules for a notification mechanism, or a Root CA (certification centre) are installed on the computer 

and are automatically configured for the selected role within the system. Thus manual implementation 

and configuration of every single service and application are not required. Due to the modular design, 

tailor-made solutions to individual requirements can nevertheless be realised. 

By selecting additional components during installation, the feature set of a host can be expanded. Due 

to its modular design, UCS scales well and can easily be adapted to local needs. The components 

are preconfigured according to the UCS design concept and integrate seamlessly into the Univention 

Management System. 

With Univention Management System all elements of the UCS domain can be centrally organised across 

system, OS and site boundaries. As such, it provides a single point of administration. A key factor of 

the Univention Management System is the LDAP directory, which contains all data relevant for central 

administration. Apart from user accounts and related information it also contains information of services 

such as the DHCP service. Central data storage avoid multiple configuration of system and reduces the 

possibility of errors and inconsistencies considerably. 

A LDAP directory is a tree-based structure, whose root node provides the base entry of the UCS domain. 

The UCS domain provides the security and trust context for it’s users. A user is a member of the domain if 

he has an account in the LDAP directory, hosts perform a domain join. Windows users and hosts can join 

the domain as well. 

When logging into the domain, the user is authenticated against the LDAP directory, and receives a Ker- 

beros ticket. He can then access all the shared resources of the domain, such as files, applications and 

computers, according to his rights, without having to enter his username and password again, since his 

Kerberos ticket handles his internal authentication (The implementation of this single-sign-on is still pend- 

ing for some of the services). 

UCS uses OpenLDAP for the directory service. It is being provided on the domain controller master and 

replicated to all domain controllers of the domain. Since it is being designed to replace the DC master in 

case of a hardware failure, the full LDAP directory is replicated to the DC backup. The replication to DC 

slaves can also be limited to some parts of the directory through access control lists (ACLs), which allows 

12

1.3 Further documentation 

selective LDAP replication. This can be needed if data is only to be stored on some systems for security 

reasons. To encrypt LDAP commucation and further services, UCS also integrates a root CA (certificate 

authority). 

Access to the LDAP directory is achieved via the program Univention Directory Manager which provides 

a web front-end and a command line interface. The latter is particularly useful for performing administra- 

tive tasks via scripts. The web front-end is a graphic interface with intuitive user guidance. In principle, 

Univention Directory Manager allows the user to access the LDAP directory from any location. 

Univention Directory Manager makes it possible to enter data into the LDAP directory, to view these data, to 

edit and delete them. Searching for data is also possible with a wide range of filter criteria. The web front- 

end provides wizards for managing Benutzern, Gruppen, Netzwerken, Rechnern, Verzeichnisfreigaben 

und Druckern The administration of computers also comprises comprehensive functions for distributing 

and updating software. 

Advanced setttings like DHCP, DNS, policies and the settings for Univention Directory Manager itself are 

available through the navigation. It also allows easy definition of custom attributes. 

Policies simplify administration since a policy transfers its settings to all the linked objects. These objects 

in turn pass the settings on to subordinated objects. 

If, for example, the company uses computers with the same type of screen in different locations within the 

enterprise, then the graphics settings have to be outlined just once in a policy and linked to the relevant 

computers to be valid. If the settings are to be valid for all the computers of a node of the LDAP directory, 

then the policy is linked to the relevant node. The inheritance mechanism makes sure that the policy will 

be valid for all the subordinated computers. 

A major element of the Univention Management System is the listener/notifier system. It triggers events 

on arbitrary hosts based on modifications in the LDAP directory. If, for example, a directory is configured 

in Univention Directory Manager to be shared through NFS and Samba, the share is not only added to the 

LDAP directory, but also integrated into the configuration files for Samba and NFS on the target host. Ad- 

ditionally the directory to be shared is created if it doesn’t exist yet. As such, the Univention Management 

System ensures that the necessary steps are taken even on remote hosts. The listener/notifier system 

can easily be expanded for site-specific needs. 

Apart from Univention Directory Manager as a means to access the LDAP directory containing the domain 

data, Univention Management Console is available as a program which allows web-based configuration 

and administration of individual computers. This program allows, among other things, to set parameters 

which are then automatically passed on to all relevant configuration files, local software administration, 

and for monitoring and controlling the services and the operating system. Thus, Univention Management 

System makes it possible to manage domain data as well as local computer data from any location via 

comfortable graphic, web-based interfaces. 

1.3 Further documentation 

This manual addresses just a small selection of the possibilities in UCS. Among other things, UCS con- 

tains: 

13


• Comprehensive support for complex server environments and replication scenarios 

• Advanced capabilities for Windows environments (e. g. automatic Windows client installation) 

• Central network management with DNS and DHCP 

• Monitoring systems and networks with Nagios 

• Print server functionalities 

• Thin Client support 

• Fax service 

• Proxy server 

• Virtualisation with Xen 

• Integrated backup functions 

• Linux desktop for business operations 

Further documentation related to UCS and further issues is published under [1]. 

1.4 Symbols and conventions used in this manual 

The manual uses the following symbols: 

Attention: 

This symbol points to an issue which should be noted in the present context. 

Info box ’Conventions’ 

Attention: 

The info symbol points out info boxes summarising information on a certain topic. 

Menu entries, button labels, and similar details are printed in bold lettering. In addition, [button labels] 

are represented in square brackets. 

Notes are in italics. 

Computer names, LDAP DNs, program names, file names, file paths, internet addresses, and op- 

tions are also optically accented. 

Commands and other keyboard input is printed in the Courier font. 

In addition, excerpts from configuration files, screen output, etc are 

printed on a grey background. 

A backslash \ at the end of a line signifies that the subsequent line feed is not to be understood as an end 

of line. This circumstance may occur, for example, where commands cannot be represented in one line 

in the manual, yet have to be entered in the command line in one piece without the backslash or with the 

backslash and a subsequent Enter. 

The path to a function is represented in a similar way to a file path. Users ➞ Add means for example, you 

have to click Users in the main menu and Add in the submenu. 

14

2 Domain concept 

Contents 

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

2.2 UCS system roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

2.2.1 Domain controller master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

2.2.2 Domain controller backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

2.2.3 Domain controller slave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

2.2.4 Member server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

2.2.5 Base system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

2.2.6 Managed client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

2.2.7 Mobile client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

2.2.8 Thin Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

2.3 System roles in Windows domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

2.3.1 How are these roles integrated in the UCS concept? . . . . . . . . . . . . . . . . . . 18 

2.4 Joining domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

2.1 Introduction 

2.4.1 How UCS systems join domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

2.4.2 How to join domains with Windows clients . . . . . . . . . . . . . . . . . . . . . . . . 21 

2.4.3 Rotation of machine account passwords . . . . . . . . . . . . . . . . . . . . . . . . . 23 

Univention Corporate Server offers a cross platform domain concept with a common trust context between 

Linux and/or Windows systems. Within this domain a user is known to all systems via his username and 

password stored in the Univention Management System and can use all services which are authorised for 

him. 

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

mechanism: On the master domain controller the notifier service monitors changes in the LDAP directory 

and makes the selected changes available transaction-based to the listener services on the other domain 

systems with a copy of the LDAP. Alongside replication of the LDAP contents, the dissemination of the 

domain-wide file changes also includes transfer of the changes to LDAP contents in configuration files of 

non-LDAP-compatible services (e.g., NFS). The following diagram offers an overview; for more detailed 

documentation of the technical processes and the possibilities of the error analysis, please refer to the [2] 

technical document. 

15


2.2 UCS system roles 

Figure 2.1: Listener/Notifier mechanism 

In a UCS domain systems can be installed in different system roles. The following gives a short charac- 

terisation of the different systems: 

2.2.1 Domain controller master 

The domain controller master (DC master for short) contains the original dataset for the entire LDAP 

directory. Changes to the LDAP directory are only performed on this server. For this reason, this must be 

the first system to be commissioned and there can only be one of them within a domain. In addition, the 

Root Certification Authority (root CA) is also on the DC master. All SSL certificates created are archived 

on the DC master. 

2.2.2 Domain controller backup 

Servers with the role of domain controller backup (DC backup for short) contain a replicated copy of the 

entire LDAP directory, which cannot be changed as all write accesses occur exclusively on the DC master. 

A copy of all SSL certificates including the private key of the root CA is kept on the DC backup. 

The root CA is created on the DC master during installation. The root CA directory 

/etc/univention/ssl is transferred when the DC backup joins the domain and then maintained syn- 

chronised. The computer account is accepted into a special group for this (DC backup hosts). Only this 

group can read the complete data of the root CA directory. The information on the DC master is also avail- 

able at many other places in the domain. This allows the load to be distributed between the DC master 

and one or more DC backups and means that the domain can still operate via the other servers if one 

server collapses. 

16

2.2 UCS system roles 

The DC backup is as such a backup copy of the DC master. If the DC master should collapse completely, 

running the univention-backup2master command allows the DC backup can take over the role of 

the DC master permanently in a very short time. This is only necessary if changes are to be made to the 

LDAP directory or new certificates are to be given, as these tasks can only be fulfilled by a DC master. 

2.2.3 Domain controller slave 

Each domain controller slave (DC slave for short) contains a replicated copy of the entire LDAP directory, 

which cannot be changed as all write accesses occur on the DC master. The copy can either contain the 

entire directory or be limited to the files required by a location through selective replication. 

The DC slave only stores a copy of its own and the public SSL certificate of the root CA. 

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

2.2.4 Member server 

Member servers are members of a LDAP domain and offer services such as file storage for the domain. 

Member servers do not contain a copy of the LDAP directory. 

It only stores a copy of its own and the public SSL certificate of the root CA. 

2.2.5 Base system 

A base system is an independent system. It is not a member of a domain and does not maintain trust 

relationships with other servers or domains. 

A base 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. 

The services of a base system cannot be configured over the UCS management system. However, it is 

possible to configure DNS and DHCP settings for base systems via the Univention Management System 

as long as the base system is entered as an IP managed client in the directory service. (See Chapter 

4.5.4). 

2.2.6 Managed client 

A managed client is a PC with a Linux desktop which is a member of the UCS domain. As standard it saves 

the passwords of the last three different users temporarily so that these three users can log in without the 

need for a network connection to a domain controller. Applications are run locally on the client. These two 

factors render it largely independent of server systems. 

17


2.2.7 Mobile client 

A mobile client offers a Linux desktop like a managed client, includes the last three passwords in its 

cache and is a member of the UCS domain. However, it also offers the possibility of maintaining software 

specially suited to notebook hardware. 

2.2.8 Thin Client 

A thin client is a diskless computer which is booted over the network and displays applications run on a 

terminal server (Linux or Windows). 

There is also no operating system installed on the thin client, which means that it requires very little 

maintenance. 

2.3 System roles in Windows domains 

In a Windows NT domain, which can be provided by UCS using the Samba software, there must always be 

a primary domain controller (PDC). There can also be backup domain controllers (BDC), member servers 

and clients. The PDC provides the password database. BDCs retrieve a copy of the password database 

from the PDC so that they can take some of the load off the PDC or take over its role in the case of a 

collapse. The copies must not, however, be changed directly. Changes are usually always performed on 

the originals on the PDC and then replicated on the BDCs. In a Windows NT domain there can only be 

one original password database. There can thus only be one PDC. A member server offers services such 

as file storage. In contrast to the PDC and BDCs, it does not have a password database. 

2.3.1 How are these roles integrated in the UCS concept? 

The LDAP directory is used in UCS as a password database and for further administrative tasks in the 

Windows domain. As the LDAP directory in which the changes should be made is usually provided by 

the DC master, it also usually accepts the role of the PDC. BDC are usually found on the DC backup or 

DC slave. Any deviations from this pattern are usually implemented with a LDAP referral, with the help of 

which the PDC can make changes in the LDAP directory on the DC master. Replication is not possible 

between Windows NT-based domain controllers and UCS-based ones. For this reason, the PDC and all 

BDCs in a UCS-based Windows domain need to be UCS-based, whilst member servers can be operated 

with both UCS and Windows. The PDC and BDCS identify themselves as such to the Windows client 

so that Windows client can execute operations on the PDC where the user database is changed (e.g., 

changing a user password). The replication of the password database is performed by the replication of 

the LDAP directory. The replication is automatically set up using the system role which you specify during 

the installation of a computer. Manual configuration is then not necessary if you add a further server to 

the domain at a later point in time. Servers and clients on which a Microsoft Windows operating system is 

installed locally are administrated as Windows computers in the LDAP directory. 

18

2.4 Joining domains 


All users, Linux and Windows systems within a UCS domain have a domain account. This allows system- 

to-system or user-to-system authentication. The management system keeps the account synchronised for 

the windows log-in, Linux/Posix systems and Kerberos. 

A UCS or Windows system must join the domain after installation. The following describes the different 

possibilities to do this: 

2.4.1 How UCS systems join domains 

There are three possibilities for a UCS system to join an existing domain; directly after installation in the 

Univention Installer (see Chapter 13) or subsequently using the command univention-join or using 

the Univention Management Console. 

The domain controller master should always be installed at the most up-to-date release stand of the do- 

mains, 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 synchronised 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. 

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//.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 domain controller master). 

2.4.1.1 Joining domains with univention-join 

univention-join retrieves a number of essential parameters interactively; however, it can also be 

configured using a number of parameters: 

• The domain controller master is usually detected via a DNS request. If that is not possible (e.g., a 

DC slave server with a different DNS domain is set to join), the computer name of the DC master 

can also be entered directly using the -dcname HOSTNAME parameter. The computer name must 

then be entered as a fully qualified name, e.g., master.company.com. 

The DNS reference can also be set up on an existing external DNS server at a later date. To do this, 

a service record with the name _domaincontroller_master._tcp. 

must be added to the zone file. The fully qualified domain name (FQDN) of the DC master with a full 

stop at the end should be entered as the computer name. 

• A user account which is authorised to add systems to the UCS domains is called a join account. By 

default, this is the Administrator user or a member of the Domain Admins group. The join account 

can be assigned using the -dcaccount ACCOUNTNAME parameter. 

19


• The password can be set using the -dcpwd FILE parameter. The password is then read out of the 

specified file. 

2.4.1.2 Joining domains with Univention Management Console 

A domain can also be joined over the web via the Univention Management Console, which can be called 

up under https:///univention-management-console/ on the joining computer. As 

the domain-wide administrator user does not yet exist on a system which has yet to join the domain, the 

log-in to Univention Management Console is done as the root user. 

The button of the same name must be selected in the Domain join module of the Univention Management 

Console. The username and password of a user authorised to add computers to a domain must now be 

entered in the resulting dialogue. 

As for the domain joining procedure via the command line, a DNS service record on the DC master is also 

required for the Univention Management Console. There is no possibility here of entering the FQDN of the 

DC master explicitly. 

Clicking on the [Repeat domain join] button restarts the joining procedure (see Figure 2.2). The informa- 

tion released in the process can be monitored via Log files. 

Figure 2.2: Repeated join through Univention Management Console 

Additional services which are yet to be initialised are shown on the Status of domain join tab. Selecting 

[Repeat] allows this to be made up for each individual service. The username and password of the user 

authorised to add computers to a domain must also be entered here. 

2.4.1.3 Subsequent running of join scripts 

The univention-run-join-scripts command is used to run all of the join scripts installed on a 

system. The scripts check automatically whether they have already been initiated. 

The name of the join script, the issue of the script and the exitcode are also recorded in 

/var/log/univention/join.log. 

If univention-run-join-scripts is run on another system role as a domain controller master or 

domain controller backup, the user will be asked to input a username and password. 

20

2.4.2 How to join domains with Windows clients 


The procedure for joining a Windows system to a UCS domain made available via Samba is now described 

for Windows 7, Windows Vista, Windows XP Professional, Windows 2000 Server and Windows NT 4.0 

Workstation. The process is similar for other Windows versions. For Windows 95/98/Me/XP Home Edition 

only the authentication against a domain is possible; not the joining into a domain. 

A Samba account can be created automatically for a computer in the LDAP directory when joining the do- 

main - i.e., a Windows-type computer object - which only contains the computer name and the predefined, 

primary group. The Univention Configuration Registry variable samba/defaultcontainer/computer 

can be used to specify a container in which the computer is stored (the predefined value is 

cn=computers,). If the computer object should be saved at another place in the LDAP direc- 

tory, the Windows computer must be entered with Univention Directory Manager before the domain joining 

(see also Chapter 8.4.4). Information concerning MAC and IP addresses, the network, DHCP or DNS can 

be expanded on prior to or after joining the domain with Univention Directory Manager. 

Then, following local log-in as an administrator, the instructions of the Windows version used should be 

followed (see below). 

Attention: 

If the computer name is changed via Hostname, the computer must be restarted before the domain join 

can go ahead. The computer name must match that entered via Univention Directory Manager in the 

LDAP directory. 

Joining the domain takes some time and the process must not be cancelled prematurely. After successful 

joining a small window appears with the message Welcome to the domain . This should 

be confirmed with [OK]. The computer must then be restarted for the changes to take effect. 

Domain names must be limited to 15 characters as they are otherwise truncated at the Windows client and 

this can lead to log-in errors. 

2.4.2.1 Windows 7 

The joining of domains is only possible with the Professional, Enterprise or Ultimate editions of Windows 

7. 

When using Windows 7 certain settings must be made in the Windows registry before joining the domain. 

A corresponding REG file can be downloaded from http://sdb.univention.de/1102. The system 

must then be restarted. 

The basic configuration dialogue is found under Start ➞ Control Panel ➞ System and Security ➞ See 

the name of this computer . Change settings must be selected and Change clicked under Computer 

name, domain, and workgroup settings. 

The Domain option field must be ticked and the name of the Samba domain entered in the input field for 

the domain join. After clicking on the [OK] button, the Administrator must be entered in the input field 

Name and the password from uid=Administrator,cn=users, transferred to the Password 

input field. The process for joining the domain can then be started by clicking on [OK]. 

21


2.4.2.2 Windows Vista 

The joining of domains is only possible with the Professional, Enterprise or Ultimate editions of Windows 

Vista. 

The basic configuration dialogue is found under Start ➞ Settings ➞ Control Panel ➞ System Change 

settings must be selected, the subsequent security request confirmed and Change clicked under Com- 

puter name, domain, and workgroup settings. 


the domain join. After clicking on the [OK] button, the Administrator must be entered in the input field 



2.4.2.3 Windows XP Professional 

The dialogue for joining domains can be reached by right clicking on the Desktop entry in the start menu. 

Properties ➞ Computer name ➞ Modify must be selected there. 


joining the domain. After clicking on the [OK] button, Administrator must be entered in the input field 



2.4.2.4 Windows 2000 Server 

The domain join can be initiated under Properties ➞ Network identification ➞ Properties in the menu 

shown when you right click on the Desktop icon 

The Domain option field must be ticked and the name of the Samba domain entered in the input field. After 

clicking on the [OK] button, the Administrator must be entered in the input field Name and the password 

from uid=Administrator,cn=users, transferred to the Password input field. By default this is 

the same as the password of the local user root on the DC master. The process for joining the domain 

can then be started by clicking on [OK]. 

2.4.2.5 Windows NT 4.0 Workstation 

An input mask is reached via Start ➞ Settings ➞ System control ➞ Network ➞ Identification ➞ Modify 

in which the Domain must be ticked and the name of the Samba domain must be entered in the input field. 

If the computer was already entered in the LDAP directory with Univention Directory Manager and the 

Initialize password with hostname checkbox was ticked on the Machine account tab, the process for 

joining the domain can be begun by clicking the [OK] button. The password is changed when the domain 

is joined. (If the computer is to rejoin the domain, the password must be reset to the computer name by 

checking the Initialize password with hostname checkbox.) 

22


If the computer has not yet been entered in the LDAP directory, the Create machine account in domain 

checkbox must be ticked first, the name Administrator entered in the User name input field and the 

password from uid=Administrator,cn=users, entered in the Password input field. This is 

the same as the password of the local user root on the DC master. The process for joining the domain 

can then be started by clicking on [OK]. 

2.4.3 Rotation of machine account passwords 

The passwords of the machine accounts of the server system roles are automatically changed 

on a three week rotation as standard. The Univention Configuration Registry variable 

server/password/interval can be used to input a different value in days. 

The old passwords are saved in the /etc/machine.secret.old file and the procedure is documented 

in the /var/log/univention/server_password_change.log file. 

23


24

3 Installation 

Contents 

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

3.2 Text-based Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

3.2.1 Operating the Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 

3.2.2 The Procedures of Text-based Installation . . . . . . . . . . . . . . . . . . . . . . . . 27 

3.3 Hardware-related Installation problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

3.3.1 Starting the Installation with additional kernel parameters . . . . . . . . . . . . . . . 38 

3.3.2 Additional kernel parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

3.3.3 Adjusting the automatic hardware detection . . . . . . . . . . . . . . . . . . . . . . . 38 

3.4 Installing and Renewing Licences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 

3.5 Subsequent Installation of Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 


The following documentation describes how to install Univention Corporate Server. 

Generally speaking, installation of Univention Corporate Server is similar to that of other Linux distributions. 

The difference lies in that the function of the system to be installed is largely dependent on the system role 

selected. System roles are components of the UCS domain concepts and are described in Chapter 2.1. 

Several types of installation are supported: 

• Univention Corporate Server can be installed from the DVD. The installation of the first UCS system 

of a domain usually occurs from DVD. There is either a text-based installation or an automated 

installation via a pre-configured installation profile. With text-based installation, all system settings 

are to be entered by the user, see chapter 3.2. 

• With profile-based installation, system settings are stored in text files, the so-called installation pro- 

files. Further information on this issue can be found in a separate document [3]. Installation profiles 

can be integrated locally via floppy disks or USB storage media, or they can be stored beforehand 

on the installation medium in the form of an adjusted installation DVD. 

• In addition, installation profiles can be retrieved from an installation server during a net-based instal- 

lation using the Univention Net Installer, see [3]. 

3.2 Text-based Installation 

After booting the system from the installation medium, the boot prompt is displayed as shown in illustration 

3.1. 

25


Figure 3.1: Installation boot prompt 

Now you can choose between several installation procedures. 

26 

• Univention Installer starts the text-based installation routine on the basis of the Linux kernel in 

version 2.6.32. With text-based installation, the system requests a number of parameters such as 

network settings, hard drive partitions, system role, and the selection of software components for the 

computer to be installed. Then the installation is performed. Text-based installation is documented 

in chapter 3.2.2. 

• Additional options allows the selection of advanced options for the installation process. First a 

request appears, requesting the Linux kernel to be installed. Unlike the standard installation, a 

kernel based on Linux 2.6.18 can also be selected here. 

Different installation versions can then be selected: 

– Univention Installer (normal mode) performs an interactive standard installation. 

– Univention Installer Software RAID (expert mode) also starts a text-based installation like 

the previous mode. In this version the partitioning, however, is not performed with the support of 

the installer, but effected manually. To do this a number of programs including cfdisk, mdadm 

and mkfs.ext3 are available. This mode can, for example, be used to set up a software 

RAID or an encrypted hard drive partition. After the partitioning, the text-based installation is

continued. 


– Univention Installer Profile starts the profile-based installation. With profile-based installa- 

tion, a pre-arranged installation profile is selected from which the system reads the installation 

parameters. The installation profile to be used is taken from a directory on the installation 

medium. Profile-based installation is described in a separate documentation under [3]. 

– Univention Installer Profile Floppy also starts a profile-based installation. The installation 

profile is taken from a floppy disk. 

– Univention Installer Profile USB also starts a profile-based installation. The installation profile 

is taken from a USB storage medium. 

• Boot from first hard drive partition does not start the UCS installation, but the operating system 

installed on the first hard drive instead. 

Now, the kernel is loaded from the installation medium and status messages appear on the screen. The 

installation itself is divided into modules. Each module contains settings which are connected as regards 

content. There are modules for network configuration or for selecting the software to be installed, among 

others. 

3.2.1 Operating the Installer 

The input screens of the modules are operated via keyboard exclusively: 

• The TAB key moves the cursor to the next entry field. 

• Use Shift-TAB to go back to the previous entry field. 

• The RETURN key is used for transmitting values entered into an entry field, and for confirming 

buttons. 

• Within a list or table, the arrow keys can be used for navigating between entries. 

• For further information on a module, the F1 function key may be pressed for calling a help dialog. 

• The next module is called via the F12 function key, while the F11 function key lets you go back to 

modules already processed. As an alternative to F11 and F12, the buttons can also be used. 

Further assignments of function keys are given below in the descriptions of the individual modules. 

Attention: 

In the left-hand window on the installation surface, a list of all the modules is displayed. The active module 

is highlighted in colour. This list cannot be used for navigation, it is only for orientation purposes. 

3.2.2 The Procedures of Text-based Installation 

The modules are executed in a pre-defined order. The description of the modules follows this order. In 

dependence of the selected system role, some of the modules are not available. 

1. Selecting the installation language 

The language which is to be used during the installation process, is selected here. Available lan- 

guages are German and English. 

27


28 

2. Hardware detection 

The hardware components of the computer are detected automatically. For devices which are sup- 

ported by the kernel, the relevant modules will be loaded. The [Add modules] button opens a list 

containing all the available modules. By selecting additional modules, devices can be activated which 

were not detected automatically. 

3. Selecting the installation medium 

The installation medium is detected. The installation medium to be used is specified via the F2 

function key. This parameter can be used in case problems with one or several CD drives occur, or 

if the net-based installation is to be executed from a different installation server. The F4 function key 

is used for rescanning the list of installation media. 

4. Selecting the time zone 

Here the desired time zone can be selected. If German was chosen as the installation language, 

then the time zone Europe/Berlin will be pre-selected; if English was chosen, then US/Eastern will 

be the pre-selected zone. 

5. Selecting the keyboard layout 

Here the keyboard layout of the keyboard in use is selected. If German was chosen as the installation 

language, then the qwertz:de-latin1 will be pre-selected; if English was chosen, then qwerty/us 

will be used. 

The selected keyboard layout will be activated as soon as this dialogue is confirmed. 

6. Selecting the system language(s) 

Here you can select the system language you wish to use. The selection has an influence on the 

use of language-specific characters and permits the representation of program output in the selected 

languages. 

Several languages can be selected. The administrator can specify the language to be used later via 

the Univention Configuration Registry variable locale. 

7. Selecting the standard system language 

Here one of the previously selected system languages is defined as the standard system language. 

This language will be used, for example, for Univention Directory Manager or for Univention Man- 

agement Console, provided an appropriate translation is available. 

8. Selecting the system role 

The system role for the system to be installed is selected here. 

The following are available to choose from: 

a) Domain controller master 

b) Domain controller backup 

c) Domain controller slave 

d) Member server 

e) Managed client 

f) Mobile client

g) Base system 

Attention: 


The first system to be installed on a UCS domain should always be a domain controller master. 

The installation of further UCS systems requires a domain controller master to be running during 

installation. The sole exception to this is the base system system role, which can be installed 

without a connection to a domain controller master. 

The system roles are described in Chapter 2.1. 

9. Domain settings 

System name is the name by which the host is to be accessible within the network. The name 

must consist of a combination of the following characters: letters a-z in lower case, numerals 0-9, 

hyphens, and underlines. The host name has to begin with a letter and must not be longer than 15 

characters. 

Domain name is the name of the UCS domain, for example, firma.de. 

Once the domain name is set, the fields LDAP base and Windows domain will be assigned by 

derived values. If the LDAP basis is to be changed, the name conventions for DNs have to be 

observed. The basis DN has to begin with ’cn=’, ’dc=’, ’c=’, ’l=’, or ’o=’. Basis DNs violating these 

conventions will be rejected. 

The name of the Windows domain may have a maximum length of 15 characters; it may consists of 

letters, numerals and hyphens exclusively. The entry field LDAP base appears solely in the system 

role of Domain Controller Master. 

Root password is the password for the user ’root’. This password is also set for the user ’Administra- 

tor’. The user ’Administrator’ is used for joining Windows clients into the UCS domain. In subsequent 

operation, the passwords of the users ’root’ and ’Administrator’ can be managed independently. The 

password is entered for a second time in the final entry field. This double input is necessary to avoid 

spelling errors since the entered characters are not displayed on the screen, see 3.2. 

For security reasons, the root passwords needs to consist of at least eight characters. 

10. Partitioning dialog 

This menu is used for partitioning the existing hard drives. It is recommended to use at least two 

partitions - one for the root file system, and one for the swap area which is used internally by Linux. 

At the first opening of this menu, the installer offers automatic partitioning of the system. On 

confirmation, the installer displays a partitioning proposal in which all the existing hard drives are 

newly partitioned and formatted using the Logical Volume Manager (LVM). 

Attention: 

All the data stored on these hard drives will be lost during this process! Should the proposed parti- 

tioning be undesirable, it can be rejected by pressing the F5 function key. The disk space of external 

storage media, such as USB sticks and USB hard drives, is also included in the automatic partitioning 

procedure, so these media should be disconnected if necessary. 

The properties of the detected drives, existing partitions, and LVM media (name, range of a partition, 

type, formatting, directory in which the partition is to be mounted, and size in MB) are displayed in a 

table. See Illustration 3.3. 

29


30 

Figure 3.2: Domain settings 

For creating a new partition, select the free entry of the desired drive and select the [F2-Create] 

button. In the next dialogue, enter the directory where the partition is to be mounted (mount point), 

the size of the partition to be created in megabytes, the file system which is to be created on the 

partition, and the type of partition (primary partition or logical partition within an extended partition). 

If a partition is to be created for the swap area, it is not necessary to give the name of a directory 

where the partition is to be mounted. If all settings are made, click the [F6-Write partitions] button 

to confirm and store the settings. 

If you wish to include a partition from a former installation, or to correct settings made during the 

creation of a new partition, just select the appropriate partition and [F3-Edit]. The following input can 

be made: the directory for the partition to be included in, the file system, and whether the partition is 

to be formatted. If the [Format] option is selected, all data in this partition will be deleted. The size 

of the partition cannot be changed later. 

New partitions, or partitions created during previous installation procedures, can be deleted by se- 

lecting the partition and then selecting [F4-Delete]. 

It is also possible to use the Logical Volume Manager during manual partitioning of hard drives. The 

installer will only support a single LVM media group (volume group) which is automatically named 

vg_ucs. The possibility of creating physical and logical LVM media (volumes) will only be available 

if LVM support was activated manually beforehand, or if a physical LVM medium is already existing 

on one of the connected hard drives. 

When deleting LVM media (physical volumes), it should be noted that the installer will support this

Figure 3.3: Partitioning hard drives 


procedure only if all existing logical LVM media were deleted via the installer beforehand. Otherwise 

the contents of the physical LVM medium have to be manually moved to other physical LVM media 

via the pvmove command, and the physical LVM medium then removed from the LVM media group 

and deleted, via the vgreduce and pvremove commands. 

The settings for a new partition are not immediately activated. The [F5-Reset changes] button (F5 

function key) can be used for restoring the previous settings. Only if the [F6-Write partitions] button 

(F6 function key) is used, will the new partition table be written to the hard drive. 

11. Boot loader 

In this dialogue box you can select whether the boot loader should be installed in the master boot 

record (MBR), or in the first sector of a bootable hard drive partition. If the UCS system is the only 

operating system installed on the computer, then the master boot record and the corresponding hard 

drive should be selected here. 

12. Network configuration 

With the first execution of the network configuration, a dialogue box will open which allows you to 

make the settings for the first detected network interface card. 

If the DHCP option was not chosen, the IP address to be bound to the network card must be entered. 

In addition to the IP address the net mask must also be entered. F5 DHCP request is used to 

request an address from a DHCP server. This is used as the default and can also be configured 

statically. 

Once the first network card is set up, further network-specific settings can be made. The IP address 

or full name of the standard gateway present in the subnet can be entered in the field Gateway. 

31


32 

Figure 3.4: Network settings 

The IP address of the name server which is to be used for resolving host names to IP addresses, 

can be entered in the field Name Server. The [More] button offers the possibility of entering multiple 

name servers. 

If the name server cannot be contacted during installation, it should not be configured during instal- 

lation, but rather set after installation using Univention System Setup. This prevents long timeouts 

during the installation. 

Forwarders are only registered if a local name server is operated within the system. If host names 

or IP addresses from DNS requests to the local name server cannot be answered, then the request 

is passed on to the forwarder. The reply given by the forwarder is then returned to the requesting 

host. The [More] button offers the possibility of entering multiple forwarders. 

DNS forwarders are only queried when installing the system roles domain controller master, domain 

controller backup and domain controller slave. 

Three different situations are possible during DNS setup: 

a) The installed system is a domain controller master. A name server for the UCS domain should 

be operated here. This name server only administrates computer names and IP addresses 

belonging to the UCS domain. To be able to answer requests from external computer names, 

an external name server must be entered as forwarder for this server. 

If packages are downloaded from external web servers during system installation, the name 

server must be specified over which computer names from the web server can be resolved. 

The name server already entered as forwarder or another external name server can be used


as the name server. In later use the domain controller master will only use its local name 

server. The external name server(s) will be used as the forwarder and if the local name server 

is not available. 

b) The installed system is another UCS server system on which a name sever should be operated 

for the UCS domain. The IP address of a computer must be entered under name server over 

which DNS service records used within the UCS domain can be resolved. This is usually the 

domain controller master or backup. This name server will only be used in later operation 

if the local name server is not available. IP addresses from external name servers or other 

UCS server systems with name servers which themselves have an external name server as a 

forwarder can be entered as forwarder. 

c) No local name server is operated on the installed system. The IP address of at least one 

computer must be entered under name server over which DNS service records used within 

the UCS domain can be resolved. No forwarder needs to be entered. 

Attention: 

It is recommended to install the name server on at least one of the UCS server systems and 

enter this UCS server as the first name server for all other UCS systems as so-called DNS 

service records and alias names are used in the UCS domain which are sometimes changed 

automatically by the management system. For example, during installation of a second repos- 

itory server, the DNS alias univention-repository is placed on the new repository server. 

Univention offers a technical document for the use of an external name server, which explains 

the different service records and DNS alias names which an external name server must provide 

alongside the individual UCS computer name. 

During the installation of some of the packages, files such as the installation images for the 

univention-windows-installer-image package, have to be downloaded from external web servers 

due to legal restrictions. Should the UCS system have no direct access to the internet, the URL of 

an accessible proxy server can be entered in the HTTP Proxy field, which can be used for handling 

the download procedures. The format of the URL is: http://: 

Attention: 

Since, depending on the installed components, the resolution of host names during the installation 

procedure cannot be ensured at any time, the IP address of the proxy server should be entered. 

For integrating multiple network cards, or for configuring further virtual network adapters on an al- 

ready integrated network card, the corresponding entry in the table is selected and the [F2-Add] 

key pressed. The dialogue box for entering the IP address, broadcast address, subnet mask, and 

network area will again be opened. 

13. Join options 

This input mask does not appear with the domain controller master and base system system roles. 

As standard the UCS domain is joined at the end of the installation. The Start join at the end of 

installation option can be used to suppress the joining procedure. The system must then join the 

domain when running using the univention-join command. 

33


34 

If a UCS server system was entered in the corresponding settings mask as a name server, the name 

of the domain controller master is confirmed via a DNS request. In all other cases, the Search 

Domain controller Master in DNS option must be deactivated and the fully qualified domain name 

of the domain controller master entered in the Hostname of Domain controller Master field. 

A user account which is authorised to add systems to the UCS domain is called a join account. 

As standard this is the Administrator user, which was created during installation of the domain 

controller master. The corresponding password of the user account must be given under Password. 

The password must be entered identically in both fields. 

Further information on joining a domain can be found in Chapter 2.4.1. 

14. SSL settings 

This input mask only appears with the domain controller master system role. A SSL certificate 

infrastructure is managed on an UCS domain controller master. The certificates are used by the 

UCS systems for mutual authentication and for encrypting network connections. In the Country 

code field the 2-character token of the country name as per ISO 3166-1 should be entered, e.g. 

DE for Germany; in the State field the federal state or province; in the City field the location of the 

company, and in the Department field the name of the department. The mail address will be created 

from the domain name. It will be used in the certificates of this certificate infrastructure. 

15. Security options 

The Univention Installer makes it possible to pre-configure package filter profiles. The following three 

profiles are available: 

• Disabled (no service will be blocked). 

• Typical selection of services (some typically unnecessary services will be filtered). 

• Locked-down setup. Only SSH, LDAP and HTTPS are allowed. 

Further details on this topic can be found in chapter 10.3.2. 

16. Selecting software components 

Components are software packages which are connected with each other as regards content, and 

can be installed for providing a variety of services. Components can themselves consist of several 

subcomponents. The subcomponents can be installed individually, or all together. 

Navigation within a list of components is done via the arrow keys. To access the subcomponents, 

select a component and press the TAB key. 

There are three states of selection for a component. These states are displayed in a checkbox 

in front of each component. If all the subcomponents belonging to a component are selected for 

installation, the checkbox shows an X. If none of the subcomponents was selected for installation, 

the checkbox is empty. If only some of the subcomponents are selected for installation, the checkbox 

shows a slash (/). See Illustration 3.5. 

The following components are available: 

• Services for Windows 

– Samba - allows the application of Linux computers as domain controller or file server in a 

Windows domain (see Chapter 8).

Figure 3.5: Selection of components 


– Windows Installer - Allows the completely automatic installation of Windows comput- 

ers(see [4]). 

– Samba PDC on Non-DC Master - This option allows operation of a Windows PDC on 

other system roles than the domain controller master (only available on domain controller 

slave/backup and member servers, see also Chapter 8.3). 

– Winbind - This service is particularly required in trust settings between UCS and Windows 

domains (see Chapter 8.4.1). 

– Univention AD Connector - Solution for bidirectional synchronisation of the Univention 

Directory Service and Active Directory. 

• Mail/Groupware 

– Standard mail services - Basic mail services based on Postfix for sending mail via SMTP 

and Cyrus for providing mailboxes via IMAP and POP3. Virus scans via ClamAV and spam 

detection via Spamassassin are integrated (see Chapter 12). 

– Kolab 2 for UCS - A groupware solution according to the Kolab standard. 

• IP management 

– DNS - Service for resolving computer names into IP addresses using Bind. 

– DHCP - Dynamic IP management service. 

– Squid proxy server - Service for central caching and policy management of visited web 

sites. 

• System services 

– Terminal server - Linux terminal server for operating Linux-based thin clients. (see chapter 

9.5). 

35


36 

– Thin client environment - Components for operating thin clients. (see chapter 9.5). 

– Print server - Print server based on CUPS. 

– Print quota - Allows quota arrangement of print jobs. 

– Nagios server - System and network monitoring using Nagios. 

– Nagios client - Allows integration of Nagios systems via the NRPE protocol. 

– Fax server - Management of incoming and outgoing fax messages based on Hylafax (see 

[5]). 

– OpenSSH server - server for providing an encrypted SSH remote login. 

– FreeNX server - Server for providing a NX remote login. NX offers efficient compression 

and can be used interactively even over a slow connection. 

• Virtualization 

– Virtual Machine Manager (UVMM) - UMC Module for management of virtual machines 

– Xen virtualization server - Virtualisation of systems using the Xen hypervisor 

– KVM virtualization server - Virtualisation of systems using KVM 

• Administrative tools 

– Univention Directory Manager - central component of the UCS management system (see 

chapter 4.1). 

– Univention Management Console - administration of UCS systems via a web interface. 

– Univention Software Monitor - Central collection of installed software packages on UCS 

systems. 

– UCS Net Installer - Net-based installation of UCS systems supported by installation pro- 

files. 

• Backup 

– Backup (Bacula) - Enterprise backup solution 

– Unidump - Tool for file backup on a tape drive. 

– Remote backup - File backup for distant computers. 

• Desktop environment 

• Tools 

– Graphical user interface - X.org infrastructure and GDM login manager. 

– KDE desktop - A user-friendly desktop environment. 

– KDE add-ons - Further KDE desktop applications, including k3b for burning DVD/CDs and 

the video and music players Amarok, Kaffeine and MPlayer. 

– OpenOffice.org - An office package including a word processor, spreadsheet, presenta- 

tion program and database management program. 

– Mozilla Firefox - a web browser. 

– Java plugin/runtime - Java integration for the Firefox browser. 

– Flash plugin - An installation program for integrating the Flash plugin into the Firefox 

browser. 

– Mplayer plugin - A plug-in for the Firefox browser to play videos. 

– Microsoft fonts - An installation programm for the integration of free-of-charge Truetype 

standard fonts from Microsoft. 

– Java - The Sun Java runtime environment.

17. System settings 


– Commandline tools - The editors vim and emacs, the less tool for viewing text files, the 

text-based web browser elinks, the port scanner nmap, the compression tools zip and 

unzip, the download tool wget and eject for script-controlled opening of a DVD drive. 

In this dialogue you can specify whether a local software repository should be set up on the UCS 

system. The local UCS system and other UCS systems can use this software repository for software 

installations and updates. A software repository is also required for net-based installations. The 

Create home share option specifies, whether the /home directory is to be shared via NFS and - in 

case the Services for Windows component is installed - as the user directory via Samba. 

18. Overview 

This dialogue shows the major settings that were made. If all the settings are correct, the installation 

of the software can be initiated by clicking the [Start installation] button. 

During installation, a large number of status messages will be displayed on the screen. The system will 

format the hard drives as stated, mount the partitions to the directory tree, and install first the basic system 

and afterwards, if necessary, additional components and packages. 

Attention: 

During the installation of certain components, attempts will be made to download files from the internet, 

e.g. the Flash plugin. Should the download fail, these files can be installed at a later date. The overall 

installation is not impaired by this fact.However, repeated attempts to download files during installation can 

increase the overall installation time. 

With the prerequisite that the Start join at the end of installation option has not been deactivated, all 

computers apart from base systems and domain controller masters try to join the UCS domain, read 

configuration settings for their services out of the LDAP directory and configure their services accordingly. 

Chapter 2.4 explains how the joining of the domain can be initiated anew if the attempt to join during the 

installation failed. 

The installation protocol of the Univention installer is stored as installer.log and the protocol of the 

package installation as installation.log in the /var/log/univention/directory. As a final 

step, the installation profile installation_profile which was created during installation, is copied to 

the /etc/univention/ directory. If the appropriate command is given via the Create local repository 

setting, the installation CD is also copied to /var/lib/univention-repository. 

For completing the installation, the Enter key is to be pressed for restarting the system. The DVD should 

be ejected during restart to avoid the system booting from the installation DVD again. Alternatively, the 

computer’s BIOS can be configured in such a way that the hard drive is the first boot drive, and the CD 

drive the second. 

The system will then boot from the hard drive. After the booting process, the user root or Administrator 

can login using the password stated during installation. If the computer was installed as a Domain Con- 

troller Master, the licence can now be entered (see paragraph 1.6). For managing the system, there is, 

among others, the web front-end Univention Directory Manager (see chapter 4.1) available. 

37


3.3 Hardware-related Installation problems 

In case any hardware-related problems occur during installation, these can usually be circumvented by 

additional kernel parameters or by adjusting the automatic hardware detection. 

3.3.1 Starting the Installation with additional kernel parameters 

To start the installation with additional kernel parameters, select the desired installation procedure at the 

boot prompt (cf. Illustration 3.1 on page 26) by using the arrow keys. 

Press the ’e’ key for having the configuration lines of the boot loader displayed for the selected installation 

procedure. The uppermost line, which begins with kernel, will be selected. After pressing the ’e’ key once 

again, the list of boot parameters can be adjusted. Additional kernel parameters have to be added at the 

end of each line. Where several parameters are to be added, these must be separated by blanks. 

The input is confirmed by pressing the Return key. Pressing the ’b’ key causes the computer to boot 

with the changed boot parameters. After successful installation, the UCS Installer automatically transfers 

the additional parameters to the Univention Configuration Registry variable grub/append so that the 

parameters will be considered during future boot procedures. 

3.3.2 Additional kernel parameters 

Some graphic cards do not support the VESA standard for frame buffers which is necessary for represent- 

ing bootsplash graphics. On such systems, the use of the frame buffer can be suppressed by the kernel 

parameter 

video=vga16:off 

However, this parameter is not permanently adopted into the boot configuration. 

When using older hardware, problems might occur when using the ’Advanced Configuration and Power 

Interface’ (ACPI). In such cases, the use of ACPI should be disabled via the kernel parameter 

acpi=off 

3.3.3 Adjusting the automatic hardware detection 

During start-up, the UCS Installer executes an automatic hardware detection. If during the automatic 

hardware detection a system crash or hardware trouble should occur, the automatic hardware detection 

can be disabled via the additional boot parameter noprobe. 

As standard the Univention Installer uses udev for device management. To deactivate automatic hardware 

detection udev must also be disabled with the boot parameter noudev. 

The boot parameter is interpreted exclusively by the UCS Installer; it is to be declared at the boot prompt 

in the same way as an additional kernel parameter. It should be noted, that for a successful installation, all 

38

3.4 Installing and Renewing Licences 

the necessary kernel drivers (for hard drives, Ethernet adapter, etc.) have to be declared manually in the 

UCS Installer. 

The boot parameter loadmodules can be used at the boot prompt for including certain kernel drivers into 

the list of drivers to be loaded (e.g. for a profile-based installation). This parameter can consist of several 

kernel drivers. The individual drivers are to be separated by blanks: 

loadmodules="driver1,driver2,driver3" 

In some cases it might be necessary to suppress the loading of certain kernel drivers. The boot parameter 

excludemodules prevents the declared kernel drivers from being automatically loaded during hardware 

detection. When excluding several kernel drivers, the individual drivers are to be separated by commas: 

excludemodules="driver1,driver2,driver3" 

Attention: 

When loading kernel drivers, the kernel treats hyphens ’–’ and underlines ’_’ which might be included in 

the driver names, as synonymous. This means, when using loadmodules, no difference has to be made 

between usb-storage and usb_storage. excludemodules, in contrast, requires the accurate spelling in 

the present use of the kernel. The relevant kernel drivers should therefore be declared in excludemodules 

using both spellings (hyhpen only or underline only): 

excludemodules="usb-storage,usb_storage" 

3.4 Installing and Renewing Licences 

The licence is installed in the Univention Directory Manager. For this purpose, the About dialogue is to be 

called as the user Administrator in Univention Directory Manager. Here, the licence file can be selected 

by clicking on the Search button. After confirming via the Load file button, the file is transferred to the DC 

Master and installed. Then after successful installation, a renewed login at Univention Directory Manager 

Manager is necessary. Then the information on the installed licence can be viewed via the About dialogue. 

3.5 Subsequent Installation of Software 

UCS is based on Debian which is the most frequently used Linux distribution in the professional sector. 

The advantages of Debian - and thus also of UCS - include a very flexible and well thought-out package 

management. 

The DVD used to install UCS contains packages for the installation of the UCS base system and packages 

for the different roles of a UCS computer (e.g., DC master, DC backup, DC slave, member server, managed 

client). In addition, the UCS DVD also includes other packages which are not required for the operation of 

UCS, but do expand UCS with practical functions. 

If additional packages are to be installed on an Univention Corporate Server system, it is recommended to 

browse the DVD first to see if the desired functionality can be provided by one of the available packages. 

The advantage of using the programs supplied is that their compatibility with UCS has already been con- 

firmed by Univention. On request, Univention can also offer further packages in many cases. 

39


The recommended method for integration of third-party software in UCS is compiling the software on the 

UCS computer in question with the Debian source packages and installing the binary program which is 

built. During the installation it is important to ensure that no other packages are updated or uninstalled in 

the installation as this can cause functional errors in the UCS system. On request, Univention can offer 

further packages in many cases. 

Package sources for installing Debian packages are included in the file /etc/apt/sources.list. This 

file already contains several entries which should not be changed or deleted. 

Univention also offers an online repository. The current, relevant sources.list entries are published under 

http://apt.univention.de. 

Besides the usual way via software distribution, there are basically three further methods for installing 

additional Debian packages: The Univention Management Console, univention-install, and dpkg. 

Univention Management Console offers a comfortable way of managing software packages via the graphi- 

cal interface of a web browser. This is achieved by using the apt mechanism. It is capable of automatically 

resolving dependencies, yet it can only read packages from package sources. 

( The repository serves as a package source. Chapter 11 explains how to add packages to the repository.) 

When using dpkg, packages can be installed from any directory. Dependencies which might not be satis- 

fied, are not automatically resolved by dpkg. 

Example for installing the package univention-samba: 

univention-install univention-samba 

In the first example, a package called univention-samba has to be present in any of the package sources 

included in /etc/apt/sources.list. After entering the command, the package - together with its 

potential dependencies - is taken from the available package sources, and installed. 

With the dpkg -i command no dependencies to other packages are resolved, thus no further packages 

from any package sources are installed. Only the Debian package declared as a parameter is installed. 

Software which is not available in the form of Debian packages, should, if possible, be installed into the 

/opt or /usr/local directories. These directories are not used for installing UCS or Debian packages, 

thus a clean separation between UCS/Debian-specific software and other software is ensured. 

40

4 Univention Directory Manager 

Contents 

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 

4.2 Instructions for Operating the Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 

4.2.1 Notes on list fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 

4.2.2 Notes on group membership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 

4.3 Univention Directory Manager Wizards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 

4.3.1 The ”Search” submenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 

4.3.2 The ”Add” submenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 

4.4 Navigation in LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 

4.4.1 Navigating the directory tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 

4.4.2 Displaying and editing objects in the LDAP navigation . . . . . . . . . . . . . . . . . 52 

4.5 Univention Directory Manager modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 

4.5.1 User administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 

4.5.2 Group management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 

4.5.3 Network administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 

4.5.4 Host management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 

4.5.5 Shares management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 

4.5.6 Samba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 

4.5.7 Printer management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 

4.5.8 Containers, organisational units, domains . . . . . . . . . . . . . . . . . . . . . . . . 91 

4.5.9 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 

4.5.10 DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 

4.5.11 Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 

4.5.12 Univention Directory Manager settings . . . . . . . . . . . . . . . . . . . . . . . . . . 129 

4.5.13 User-defined attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 

4.5.14 Extended attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 

4.6 Policy-controlled Layouts for the Web Front-End of Univention Directory Manager . . . . . . 146 


Univention Directory Manager allows a comfortable web-based management of objects in an LDAP direc- 

tory. 

Objects can be, for example, users, groups, computers or DHCP entries. Alongside the Univention Direc- 

tory Manager web interface described here, there is also a command line interface, see [6]. The scope of 

operations which a user of Univention Directory Manager may carry out, is defined by his access rights in 

the directory service (ACLs). Univention Directory Manager itself does not perform any management and 

41


evaluation of rights, it merely passes on the authentication information and users’ requests to the directory 

service. 

The Univention Directory Manager web interface can be accessed by a browser by just entering 

the URL https://IP-address-of-server/univention-directory-manager/ into the address 

field. In doing so, IP-address-of-server is to be replaced by the IP address of the server where 

Univention Directory Manager is installed. If the name resolution is correctly implemented, direct 

access to the name of the Univention Directory Manager host is also possible. For this purpose, 

https://name-of-server.domainname/univention-directory-manager/ is to be entered. 

Univention Directory Manager is installed on the DC master as standard. If the name resolution is con- 

figured correctly, Univention Directory Manager can also be accessed through the host name by entering 

https://name-of-server.domainname/univention-directory-manager/. 

Univention Directory Manager uses Javascript and CSS functions to display the web surface, which may 

cause display problems in some browsers. If the interface is opened with any other browser than Firefox 

3.x or Internet Explorer versions as of 6.0, a warning appears. 

In certain circumstances it may be necessary to access the Univention Directory 

Manager over an insecure connection. This can be the case if no SSL certifi- 

cates have been created for this system yet. The insecure access can be per- 

formed via http://IP-address-of-server/univention-directory-manager/ or 

http://IP-address-of-server.domainname/univention-directory-manager/. 

Attention: 

In such a case, passwords will be sent across the network unencrypted. 

The login form will appear on the screen. When logging into the system for the first time, the user Admin- 

istrator can be used with the password specified for user root during the installation of the DC Master. 

Also, the user interface language of the Univention Directory Manager can be selected. By default German 

and English are available. 

After entering user name and password, the login procedure is completed by clicking the [Login] button. 

After successful login, the Univention Directory Manager start page will open. See also Illustration 4.2. 

The main menu can be found on the left-hand side. Below the main menu, there is a status field where 

relevant messages relating to the user’s input or to other actions are displayed. At the upper border, the 

name of the logged-in user is displayed, in this case Administrator. 

The menu item Navigation allows the user to navigate through the LDAP directory, and to create, modify 

or delete objects within the LDAP directory. Further details can be found in chapter 4.4. 

The other menu items on the left side - called wizards in the following descriptions - allow a comfortable 

handling of certain objects. 

Depending on the licence and installation used, the wizards shown may vary. More information can be 

found in Chapter 4.5. 

The header contains links which allow you direct access to frequently used functions: creating a host or 

user object; accessing the Navigation and signing out from the surface. 

42

Figure 4.1: Unsecured start page 


The menu item About UDM offers, among other things, information on the licence used and on the Uni- 

vention Directory Manager program version. The submenu item Update licence via File can be used for 

importing a software licence file. 

Clicking Logout in the main menu opens a dialogue box asking whether to proceed with logging out. The 

[Abort] button leads back to the previous menu item and back into the program. The [Ok] button causes 

the system to proceed with the log-out. After login the user out, a page with a link for renewed login is 

displayed. 

A similar window will appear if a running Univention Directory Manager session is automatically closed 

down for security reasons due to a time-out. 

Renewed login is possible by clicking Login. 

To change the time interval for automatic close-down, the Univention Configuration Registry variable 

directory/manager/timeout can be adjusted. The interval is to be entered in seconds. Thus, for 

setting the interval for automatically closing down the session to ten minutes, the value 600 has to be 

entered. 

The language used by Univention Directory Manager can be controlled with the Univention Configuration 

Registry variable directory/manager/web/language. For the English version of Univention Directory 

Manager, the variable has to be set to us. 

In the default setting, the UCS system checks for available updates regularly. If an update is available, a 

corresponding message will be displayed in the upper part of the welcome page (Abbildung 4.2). This mes- 

sage is only shown to users who are represented in at least one of the groups specified in the Univention 

Configuration Registry variable directory/manager/web/update/available/groups. The default 

setting is set as Domain Admins during installation. The groups should be specified separated by com- 

43


mas. 

Figure 4.2: Start page 

4.2 Instructions for Operating the Program 

Univention Directory Manager is optimised for the application of web browsers which support JavaScript. 

This is why the manual on hand assumes in its illustrations and descriptions that a graphic browser with 

activated JavaScript functionality is used. Without activated JavaScript functionality, some of the functions 

are not executed automatically, which will result in deviations in the program’s operations. 

Input fields in Univention Directory Manager, which are marked by an asterisk (*) are compulsory, all the 

other fields are optional. 

Unless otherwise indicated, all characters are permitted, including < and >, ä, ö, ü, and ß. 

44

Figure 4.3: Automatic log-out after time-out 

4.2 Instructions for Operating the Program 

In list fields, the [Ctrl] and [Shift] keys, arrow keys, as well as the mouse can be used for selecting multiple 

entries at the same time. 

4.2.1 Notes on list fields 

Among the entry fields of Univention Directory Manager there are special list fields which are applied 

whenever there is a choice of one or multiple values to be entered. Illustration 4.4 shows an example for a 

list field including a description of its functions. 

In the entry field (➊ in Illustration 4.4), the desired value can be entered and accepted by clicking the [+] 

button ➋. The value will then be displayed in the list field Entries ➌. 

There are several variants of list fields which differ in the type of the entry field ➊. Instead of a single entry 

field, several entry fields can also be displayed. Furthermore, select lists or combinations of entry fields 

and select lists can be used. The behaviour of the list fields is the same in all these variants. 

In some cases it might be necessary to bring the entries of a list field into a certain order. After having 

been selected by a single mouse click, the relevant entry can be moved up and down within the list via the 

buttons [△] ➍ and [▽] ➎. 

45


Figure 4.4: Declaring DNS servers via a list field. 

When using the [Ctrl] and [Shift] keys, several entries can be selected at the same time for being moved 

or deleted. 

The button [-] ➏ makes it possible to delete one or multiple selected entries. 

Attention: 

Values entered into the entry field ➊ without being accepted by clicking the [+] button, will not be added to 

the list field Entries when the user subsequently confirms the changes in the object! 

4.2.2 Notes on group membership 

To allow a comfortable management of the group members, an additional dialogue element was introduced 

(see Illustration 4.5). With the help of this dialogue element, a search for certain criteria within a set of 

objects, can be performed, and selected objects of this set can be added to the group . The element is 

used, among other things, for selecting members for a user group. 

In the select list Property (➊ in Illustration 4.5), an attribute can be selected as a search criterion. With 

some attributes, an entry field replacing the placeholder none ➋, will automatically be loaded after the 

selection was made. 

In the additional entry field ➋, which is named after the attribute, a search pattern can be entered. In doing 

so, an asterisk ’*’ can be used as a placeholder for a string of arbitrary characters. 

46 

Figure 4.5: Example for group membership

4.3 Univention Directory Manager Wizards 

Clicking the [show] button causes all objects which fit the entered search criterion, to be displayed in the 

list field All ➌. The list field Current ➍ shows the currently selected objects. 

The [▹] and [◃] ➎ buttons can be used for swapping the selected objects between the list fields All and 

Current, and thus for including them in or excluding them from the group. 


Besides the LDAP Navigation for navigating within the directory tree, Univention Directory Manager offers 

a number of wizards in the main menu on the left-hand side of the page (see Illustration 4.2). These 

wizards are interfaces for frequently occurring administrative procedures. By default, the following wizards 

are displayed: 

• Users 

• Groups 

• Networks 

• Computer 

• DNS 

• DHCP 

• Printers 

• Shares 

• Policies 

Depending on the installed software and the licence used, the number of wizards may vary. 

After clicking a wizard, a submenu will open, and the items Search and Add will be displayed. The 

search is activated and a search performed for the current object type. If you do not wish to search 

directly - perhaps in large environments with many objects - this function can be suppressed by setting the 

Univention Configuration Registry variable directory/manager/web/modules/autosearch to 0. 

4.3.1 The ”Search” submenu 

The Search submenu is a simple means of searching and/or editing objects of a certain type or of a certain 

group of types. 

In the Search select list, the user can choose between different search areas; thus he can specify which 

parts of the LDAP directory are to be searched. Further details on the registered containers can be found 

in chapter 4.5.12.7. 

If the wizard applies to several Univention Directory Manager modules, then a list of valid object types is 

displayed under Select type. 

The Property select list makes it possible to restrict the search to certain attributes. With some properties 

(e.g. when searching for users with the property Disabled, a checkbox will appear. For most of the 

remaining properties, an entry field will appear where the value of the relevant attribute can be entered. 

47


Figure 4.6: Searching for user names 

Wildcards such as the asterisk * can be used; the success of the search then depends on the schema 

specifications of the LDAP directory. 

Example: 

A search is to be performed for all users with the last name beginning with the letter m. First the user 

wizard is started. In the select list Property, the Last name attribute is selected, and in the entry field, m* 

is entered. 

The Results per page entry field is for specifying how many objects are to be displayed on one page. 

By default a maximum of 1,000 objects is displayed on one page (this behaviour can be adapted with 

the Univention Configuration Registry variable directory/manager/web/ldap/sizelimit). If more 

than one page is necessary to display all the objects, then a mouse click on the page numbers makes it 

possible to browse the pages. The page number of the currently displayed page is optically highlighted. 

Clicking the Search button starts the procedure using the selected criteria. Clicking the Reset button 

resets all criteria to their default values. In such a case, no search is performed. The wizards for users and 

for groups offer the additional button [create report]. This makes it possible to export the search results to 

a PDF document or, alternatively, to a file in the CSV format. Details on the Univention Directory Reports 

can be found in the documentation under [7]. 

Clicking the Search button produces a search result which is displayed in a table consisting of the follow- 

ing columns: Object, Property (if applicable), Location, and Select (checkboxes). The Object column 

contains all the results meeting the search criteria. Each result is represented by a symbol for the object, 

and the name of the object. 

If a certain Property was selected, an additional column titled according to the selected property is in- 

cluded in the table, containing the appropriate values as entries. For example, if the search concerned the 

48

last names of the users, a column with the last names will be displayed. 


The Location column shows the position of the search result within the LDAP directory. The position is a 

value consisting of the domain, followed by the name of the currently selected container. 

The final column Select contains a checkbox for each of the objects. Below these checkboxes, a list field 

offers several operations to be performed on the selected objects. The Invert selection option unselects 

the selected objects and selects the rest of the objects instead. The Edit option allows several objects 

to be edited at the same time. For example, if several users are to be deactivated at the same time, this 

command can be used. The Delete option makes it possible to delete objects. 

Clicking the name of the object or the symbol in front of the name in the list of search results opens the data 

of the object for viewing/editing. The data are distributed among several tabs and basically correspond to 

the data in the object adding mode. The differences are described in the relevant Univention Directory 

Manager module documentation (see chapters 4.5.1 to 4.5.12). 

When editing is finished, the changes can either be written to the LDAP directory by clicking the [Ok] 

button, or be discarded by clicking [Cancel]. 

Attention: 

When clicking one of the mentioned buttons, the previously buffered search results are displayed again. 

Changes made in the meantime are not yet included in the buffered search results! 

4.3.2 The ”Add” submenu 

Figure 4.7: Adding a user 

The Add submenu is a simple means of adding objects of a certain type. 

The Select container select list makes it possible to choose between different positions within the LDAP 

directory. Further details on the registered containers can be found in chapter 4.5.12.7. 

If the wizard applies to several different Univention Directory Manager modules, then a list will be displayed 

from which the desired type can be selected. 

If the Univention Directory Manager module, which is concerned with this wizard, supports templates, then 

a list of possible templates will be presented under Select Template. 

Clicking the [Cancel] button discards the input and activates the wizard’s Search submenu. 

Clicking [Next] shows the tabs of the new object. On these tabs, all the relevant data concerning the 

new object can be entered. By a final click on the [Ok] button, the entered data are written to the LDAP 

49


directory, by clicking [Cancel] the data entry is discarded. Instructions to the tabs can be found in the 

relevant chapters relating to the Univention Directory Manager modules, see chapters 4.5.1 to 4.5.12. 

4.4 Navigation in LDAP 

4.4.1 Navigating the directory tree 

The Navigation menu item makes it possible to navigate the LDAP directory, to create new objects in the 

LDAP directory, to modify these objects, or to delete them. 

Clicking the Navigation menu item opens a page on which a table with an excerpt of the data in the LDAP 

directory is displayed. This table will be called the summary in the below description (see Illustration 4.8). 

Figure 4.8: Summary of the directory 

The shown position (➊ in Illustration 4.8) indicates the position within the directory tree of the domain. The 

uppermost level is represented by the name of the domain. If the display level is changed, say by clicking 

the users container ➋, the current path will be shown in the Position field. Individual path segments can 

be clicked for switching to the corresponding levels. 

50

4.4 Navigation in LDAP 

By clicking the up-labelled upwards arrow (➌ in Illustration 4.9), the user can navigate one level upwards 

within the LDAP directory. At the uppermost level, the symbol up is not displayed. 

Figure 4.9: Displaying user objects 

The select list Add new object at current position ➍ offers object types which can be created at this 

position within the LDAP directory. 

Via the select list type ➎ and the [show] button ➏, the user can control which of the objects are to be 

displayed in addition to the container objects of this level. If a type is selected in the list ➎, an additional 

select list property ➐ will be displayed if applicable. Once the desired property has been selected, a 

further entry field will be displayed, if applicable, in which a search string can be entered. 

In the entry field Results per page ➑, the user can specify how many objects are to be displayed on 

one page. If more than one page is necessary to display all the objects, then a mouse click on the page 

numbers ➒ makes it possible to browse the pages. The page number of the currently displayed page is 

optically highlighted. 

Clicking the [Search] button ➏ causes all objects of the current level, which meet the search criteria, to be 

displayed in the summary. The directory objects are displayed irrespectively of the search criteria. 

For each object, a symbol signifying the object type, and a name are displayed in the Object column of 

51


the summary. In the Type column, the type of the object is represented in words. If a search criterion 

was defined, then the next column will show the result of the search criterion. The final column Select 

contains a checkbox for each of the objects. Below these checkboxes, a list field offers several operations 

to be performed on the selected objects. The Invert selection option unselects the selected objects and 

selects the rest of the objects instead. The Edit option allows several objects to be edited at the same 

time. For example, if several users are to be deactivated at the same time, this command can be used. 

The Delete option makes it possible to delete objects. With the Move option, the user can move one or 

multiple objects to a different position within the directory tree. 

4.4.2 Displaying and editing objects in the LDAP navigation 

The information stored on an object can be displayed and edited by clicking the symbol or the name of the 

object in the summary. So-called tabs will be displayed which contain information on the corresponding 

object (see Illustration 4.10). 

Figure 4.10: User object of the Administrator 

If the object in question is a container which might contain further objects, then the contents of the container 

will be displayed in a directory view. The object itself is represented in this view by its symbol and the 

52

4.5 Univention Directory Manager modules 

remark (current). A mouse click on the symbol or on (current) causes the tabs and information relating 

to the object to be displayed. 

The tabs in the editing mode correspond to those in the ’adding objects’ mode, and will be described in 

detail in the corresponding section of this manual (see chapter 4.5. 

If the information is merely to be viewed, then the object should, after viewing, be quit by clicking the 

[Cancel] button. 

Some values are protected from changing and cannot be edited. Such values are displayed in grey. 

Other values are compulsory; such values can usually be changed but not deleted. The field caption of 

such a value is usually followed by an asterisk in brackets (*). These values have to be entered before the 

tab can be left. Apart from this, random switching of the tabs is possible. The entered values are preserved 

when switching tabs. 

Once all the desired changes to an object have been executed, clicking the [Ok] button causes the entered 

data to be accepted. The corresponding changes are then carried out in the LDAP directory. 


Apart from the possibility to modify the LDAP directory via the LDAP browser, Univention Directory Man- 

ager also provides several modules making it easier for the user to search, add, modify, and delete LDAP 

objects, by combining common procedures (e.g. creating DHCP entries and DNS entries when creating a 

new client object. 

The attributes which can be administrated in an Univention Directory Manager module are subdi- 

vided into standard attributes and advanced attributes. In the default settings only the standard at- 

tributes are shown in the tabs of a module. Clicking Show the advanced settings shows the remain- 

ing tabs. All attributes are shown as standard when the Univention Configuration Registry variable 

directory/manager/web/modules/advancedview is set to 1. 

A summary of the full scope of functions can be found in [8]). 

4.5.1 User administration 

The following policy objects can be applied/inherited to the user administration (see chapter 4.5.11): 

• Mail quota 

• Password policy 

• Univention Directory Manager view 

• Desktop settings 

• UMC access 

53


54 

’General’ tab 

User name (*) 

This is the name, by which the user logs into the system. Specifying a user name is obligatory for 

any user; the name has to begin with a letter which has to be followed by: letters a-z in lower case, 

numerals 0-9, dots, hyphens, or underlines. Only the first letter may be an uppercase letter. 

Attention: 

In order to ensure compatibility to non-UCS systems, Univention Directory Manager prevents the 

creation of users which are only distinguished from each other by upper and lower case letters. Thus, 

if the user name ’smith’ already exists, then the user name ’Smith’ cannot be created. 

Description 

Arbitrary descriptions for the user can be entered here. 

Password (*) 

The user’s password has to be entered here. 

Password (retype) (*) 

In order to avoid spelling errors, the user’s password has to be entered for a second time. 

Override password history 

By checking this box, the password history is overridden for this user and for this password change. 

This means, with this change the user can be assigned a password which is already in use. Further 

details on the password policies for users can be found in chapter 4.5.11.5. 

Override password check 

By checking this box, the requirements for the length of the password and for password quality checks 

are overridden for this user and for this password change. This means, the user can e.g. be assigned 

a shorter password than would be possible according to the defined minimum length. Further details 

on the password policies for users can be found in chapter 4.5.11.5. 

First name 

The first name of the user is to be entered here. 

Last name (*) 

The last name of the user is to be entered here. 

Title 

The title of the user is to be entered here. 

Organisation 

The organisation is to be entered here.

’User account’ tab 

Account expiry date 


In this entry field, the date is specified by which the user account becomes invalid. The format of the 

date is dd mm yy, e.g. 05 03 08 for 5 March 2008. From this date onwards, a user trying to log into 

the system will be notified of the fact that his user account has become invalid; he has no longer any 

access to the system. If the date is deleted or replaced by a different, future date, the user will regain 

the right to log in. 

Password expiry date 

If the password is subject to an expiry date, then this date is displayed in this entry field. The format 

of the date is dd mm yy, e.g. 05 03 08 for 5 March 2008. These entry fields cannot be directly edited. 

The date can be changed/influenced via the checkbox Change password on next login on this tab, 

or via the entry field Expiry Interval on the policies tab. 

If the date of password expiry is reached or exceeded, the user is asked to change his password. 

Once the password is changed, the user will regain his access to the system. 

If a value is declared for the Expiry Interval on the Password policies tab, or if the value is inherited 

from a higher-level object, then the expiry date is automatically adjusted once the user has changed 

his password. The new expiry date is calculated by the date the password was changed plus the 

value declared in the Expiry Interval field. 

If no Expiry interval is declared, the old expiry date will be deleted and no new date will be set. 

Account deactivation 

The Account deactivation selection field can be used to deactivate the user account for one or more 

login methods. As long as the respective account type is deactivated, the user cannot log into the 

system. This is typically used when a user leaves the company. In a heterogeneous environment, an 

account deactivation might also be caused by external tools; in that case the selection field reflects 

the account status. Normally users should always be deactivated for all account types. The following 

deactivation states can be realised: 

• None - Basic status; all logins are possible. 

• All disabled - All account types are blocked. 

• Windows disabled 

• Kerberos disabled 

• POSIX disabled 

• Windows und POSIX disabled 

• Windows und Kerberos disabled 

• POSIX und Kerberos disabled 

55


56 

The following interconnections between the different login methods are derived from the UCS PAM 

configuration: 

• The Linux login (e.g., on GDM or a tty) is only deactivated if all login methods are deactivated; 

a deactivated POSIX account alone is not enough. 

• Samba requires a not-deactivated POSIX account - that means that the deactivation of the 

POSIX account automatically deactivates Samba as well. 

• The Kerberos library (Heimdal) also evaluates the Samba account settings - that means that 

the deactivation of the Windows account will also deactivate Kerberos. 

Change password on next login 

If this checkbox is ticked, then the user has to change his password during the next login procedure. 

If the option is activated, the present date will be used as the expiry date for the current password. 

Further details can be found in the description Expiry Date on the same tab. 

Locked login methods 

This selection field can be used to block individual login methods. This can happen automatically 

for security reasons, for example, if a user has entered his password incorrectly too often. Normally 

users should always be blocked for all login methods. 

In contrast to Account deactivation, the account is not blocked, but the login is denied. The following 

login methods can be restricted: 

• None 

• Locked all login methods 

• Locked Windows/Kerberos only 

• Locked POSIX/LDAP only 

’Mail’ tab 

Primary e-mail address 

The primary e-mail address of the user is declared here. E-mail addresses can consist of the following 

characters: letters a-z, numerals 0-9, dots, hyphens, and underlines. The address has to begin with 

a letter and must include an @ character. 

Alternative e-mail addresses 

Further e-mail addresses can be declared here for the user. E-mails to these addresses will be 

delivered to the same inbox as mails sent to the user’s primary e-mail address. It is possible for 

several users to use the same alternative e-mail address. However the multi-used alternative e-mail 

address should not be used as the primary e-mail address by one of the users.

Attention: 


Wird Scalix für UCS verwendet, so ist der Betrieb von mehreren Benutzern mit identischer alternativer 

Email-Adresse nicht möglich. 

Use global spam folder 

If this option is used, e-mails classified as spam will not be delivered to the user’s personal spam 

folder but to a global spam folder instead. 

’Contact’ tab 

Attention: 

The data relating to the phone number, street, city, and post code are stored in the attributes for the 

business address within the LDAP directory. The private contact data can be entered on the Private 

contact tab. 

E-Mail address(es) 

The e-mail address of the user is declared here. The values of this attribute are stored in the attribute 

mail of the LDAP directory service. Most of the address books using an LDAP search function will 

search for an e-mail address by this attribute. The syntax is identical to that of the Primary e-mail 

address attribute. 

Telephone number(s) 

This field contains the user’s phone number. Valid characters include the numerals 0-9, the letters 

a-z in upper and lower case, and the ), (, /, + and - characters. 

Street 

The user’s street and house number can be entered here. 

Postal code 

This field contains the post code of the user’s address. 

City 

This field contains the city of the user’s address. 

Birthday 

This field is used to save a user’s birthday. 

User’s picture (JPEG format) 

This mask can be used to save a picture of the user in LDAP in JPEG format. In the default settings 

the file size is not limited; a size limit can be imposed using Univention Configuration Registry variable 

directory/manager/jpegphoto/maxsize. 

57


58 

’Private contact’ tab 

Phone numbers can consist of the numerals 0-9, the letters a-z in upper and lower case, and the ), (, 

/, + and - characters. 

Mobile telephone number 

The user’s mobile numbers can be entered here. 

Home telephone number 

The private fixed network phone number can be entered here. 

Pager telephone number 

Pager numbers can be entered here. 

Home postal address 

One or more of the user’s private postal addresses can be entered in this field. In UCS versions prior 

to 2.3 only one address could be saved in this field. If you have updated from an earlier version it will 

only be possible to save one address here. 

’Organisation’ tab 

Employee number 

Numbers for staff members can be entered in this field. 

Employee type 

The category of the staff member can be entered here. 

Department number 

The department number of the staff member can be entered here. 

Room number 

The room number of the staff member. 

Superior 

The superior of the user can be selected here. 

’POSIX (Linux/UNIX)’ tab 

UNIX home directory (*) 

The path of the user’s home directory is to be entered here. By default, /home/ followed by the user 

name is preset. The declaration of the home directory should be unique across the domain.

Further information can be found in the desktop documentation in Chapter 9.7. 

Login shell 


The user’s login shell is to be entered in this field. This program is started if the user performs a 

text-based login. By default, /bin/bash is preset. 

User ID 

If the user is to be assigned a certain user ID, the ID in question can be entered in this field. If no 

user ID is assigned, Univention Directory Manager will assign an available user ID when creating the 

user. The user ID can only be declared when adding the user. When the user data are subsequently 

edited, the user ID will be represented in grey and barred from change. 

Group ID 

When adding the user, the group ID of the user’s primary group will be entered here. This value 

can only be changed while adding the user. During editing, the primary group can be edited on the 

Groups tab. 

Home share 

An alternative shared directory can be selected here, where the user’s home directory is located, or 

where it is to be created. By default the local home share is used. 

Home share path 

The path of the home directory relative to the Home share is declared here. The username is already 

preset as a default value. 

Attention: 

Only if both values are entered (Home share and Home share path), will the settings be adopted 

into the LDAP directory. 

GECOS 

User entries in the /etc/passwd file are also known as GECOS fiels. However, a username entered 

in this input field is not written to /etc/passwd, but stored in the LDAP attribute gecos. 

When creating a new user this attribute is preset to ’ ’. (Special charac- 

ters are replaced) 

When editing either the first name or the family name of a user, the input field is altered automatically 

if the previous value had been set to ’ ’. 

59


60 

’Windows’ tab 

This tab is used for the settings of the user’s Windows account. Standard values from the Samba 

configuration are used for empty fields. 

Windows home path 

The path of the directory which is to be the user’s Windows home directory, is to be entered here. 

Example: 

\\ucs-file-server\smith 

Windows home drive 

If the Windows home directory for this user is to show up on a different Windows drive than that 

specified by the Samba configuration, then the corresponding drive letter can be entered here. 

Example: 

M: 

Windows logon script 

The user-specific logon script relative to the Netlogon share is entered here. 

Example: 

scripts\user.bat 

Windows profile directory 

The profile directory for the user can be entered here. 

Example: 

\\ucs-file-server\user\profile 

Relative ID 

The relative ID (RID) is the local part of the SID. If a user is to be assigned a certain RID, the ID in 

question can be entered in this field. If no RID is assigned, the next available RID will automatically be 

used. The RID cannot be subsequently changed. Integers from 1000 upwards are permitted. RIDs 

below 1000 are reserved to standard groups and other special objects. 

Logon 

In this entry field, the Administrator can define certain times of the day (0-24h) in one hour intervals, 

when this user may log into a Windows client. This means, a time window can be specified within 

which the user may log in. If no entry is made in this field, the user can log in at any time of day. 

Allowed hosts 

This setting specifies the clients where the user may log in. If no settings are made, the user can log 

into any client.

’Groups’ tab 


This tab has the purpose of defining the user’s group membership. If no settings are made on this 

tab when creating the user, the preset value for the primary group will be stored. 

Primary group 

This select list can be used for specifying the user’s primary group. All the groups registered in the 

domain are open for selection. By default, the group Domain Users is preset. This setting can be 

changed, further details on this issue can be found in chapter 4.5.12.6. If the primary group of a user 

has been removed by an external LDAP modification, the default group is assigned to the user object 

the next time the object will be modified. 

Groups 

Additional groups can be assigned to the user here, in which he is to be a member. 

’Windows Advanced’ tab 

Settings for working on Windows terminal servers can be made here. 

Home directory for Windows terminal services 

The directory path which is to be the user’s Windows home directory on the terminal server can be 

entered here. 

Example: 

\\ucs-file-server\ts\user 

Home drive for Windows terminal services 

If the Windows home directory for this user is to appear on different Windows drive than specified in 

the Samba configuration, the respective letter of the drive can be entered here followed by a colon, 

e.g. M:. 

Startup command 

Path to a program which should be run when a terminal session is started. The Explorer is started as 

standard for Microsoft Windows. 

Working directory for startup command 

The program’s working directory, which is entered under Startup command. 

Use client configuration for startup command 

Both configuration settings Startup command and Working directory for startup command can 

be overwritten by the client application. If this checkbox is activated, the client configuration is used. 

61


62 

Profile directory for Windows terminal services 

The path to the Windows profile which is to be used in the terminal server session should be entered 

here. If no value is entered, the standard profile path is used. 

Keyboard layout 

The keyboard layout for the terminal server session. 

Allow Windows terminal server login 

If this checkbox is activated the user can log on to a terminal server. 

Connect client drives at login 

The client drives can be made available during a terminal server session when this checkbox is 

activated. 

Connect client printers at login 

The client printers are connected during log-in to the terminal server and are thus available during 

the terminal server session. 

Make client default printer the default printer for Windows terminal services 

If this checkbox is activated the client standard printer will be declared the standard printer for this 

terminal server session. 

CTX Mirroring 

This selection list specifies whether a user session can be mirrored. If Disabled is selected the 

session cannot be mirrored. 

If an entry with the Input On option is selected, the user who initiated the mirroring will be given the 

permission to perform keyboard inputs and mouse action in the mirrored session. If an entry with the 

Message On option is selected, a message is shown on the client stating that a request has been 

made to mirror the session. 

Terminated or timed-out sessions 

In this selection list one can select whether ended or expired connections should be Disconnecteded 

or Reset. 

Reconnect session 

You can select here whether the ended connection to each client or just the previous client can be 

rebuilt. 

CTX RAS Dialin 

This option configures the callback function of a remote access server. If enabled, the dialin line of

the user is disconnected after authentication and the user is called back. 

’(Options)’ tab 


This tab makes it possible to discard individual LDAP object classes for the user. Entry fields for the 

attributes of deactivated classes are disabled. 

Mail account 

If this checkbox is not ticked, the user will not be assigned the object class univentionMail. 

Kerberos principal 

If this checkbox is not ticked, the user will not be assigned the object classes krb5Principal and 

krb5KDCEntry. 

Samba account 

If this checkbox is not ticked, the user will not be assigned the object class sambaSamAccount. 

POSIX account 

If this checkbox is not ticked, the user will not be assigned the object classes posixAccount and 

shadowAccount. 

Personal information 

If this checkbox is not ticked, the user will not be assigned the object classes organizationalPerson 

and inetOrgPerson. 

Groupware account 

If this checkbox is not ticked, the user will not be assigned the object classes univentionKolabIne- 

tOrgPerson and kolabInetOrgPerson. 

Public key infrastructure account 

If this checkbox is not ticked, the user will not be assigned the object class pkiUser. 

Simple authentication account 

This option can be used for creating user objects which have only a username and a password. With 

these users, authentication is possible against the LDAP directory service exclusively; logging into 

UCS or Windows systems is not possible. If this option is activated, the object classes uidObject 

and simpleSecurityObject will be used. 

4.5.2 Group management 

The following policy objects can be applied/inherited to the group administration (see Chapter 4.5.11): 

63


64 

• UMC Access 


Name (*) 

The name of the group has to begin and end with a letter or a numeral. The rest of the characters 

which form the group name may include letters, numerals, spaces, hyphens, or dots. 

Description 

A description of the group can be entered here. 

Group ID 

If a group is to be assigned a certain group ID, the ID in question can be entered in this field. Other- 

wise, Univention Directory Manager will automatically assign the next available group ID when adding 

the group. The group ID cannot be subsequently changed. When editing the group, the group ID will 

be represented in grey. The group ID may consist of integers between 1000 and 59999 and between 

65536 and 100000. 

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, Univention Directory Manager will automatically assign the next available group ID when 

adding the group. The RID cannot be subsequently changed. When editing the group, the group 

ID will be represented in grey. Since RIDs have to be unique across the domain, Univention Direc- 

tory Manager prevents an RID from being assigned twice. For RIDs, integers higher than 999 are 

permitted. RIDs below 1000 are reserved for standard groups and other special objects. 

Samba group type 

Three types of groups can be distinguished: 

• Domain Group: 

These groups are known across the domain. In Univention Directory Manager, new groups 

belong to the type ’Global group’ by default. 

• Local Group: 

Local groups are relevant on Windows servers exclusively. 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 

NT domain, local groups in UCS can be handled in the same way as global groups. 

• Well-Known Group: 

This type contains groups pre-configured by Samba servers or by Windows servers, which can 

be available across the domain or locally restricted. 

Example: 

Adminusers, Printer Admins, etc.

Mail address 


The e-mail address by which all the members of this group can be addressed, can be entered in this 

field. 

’Members’ tab 

Users 

This tab can be used for accepting users as members of the group. 

’Nested groups’ tab 

Membership of other Groups 

On this tab, other groups can be added as members of the current group (groups in groups). 

Circular 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. 

’Member of’ tab 

Membership in other Groups 

On this tab, the current group can be added as a member to other groups. 


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. 

Samba group 

This checkbox indicates whether the group contains the object class SambaGroupMapping. 

Posix group 

This checkbox indicates whether the group contains the object classPosixGroup. 

4.5.3 Network administration 

Networks provide network-capable machines such as computers and printers with an appropriate IP ad- 

dress automatically as well as creating DNS and DHCP entries. 

65


66 


Name (*) 

The name of the network is entered in this input field. The network appears under this name in other 

areas of Univention Directory Managers such as in computer management (see Section 4.5.4). 

Network (*) 

The network address is entered in dot-decimal form in this input field. 

Example: 

192.168.1.0 

Netmask (*) 

The network mask can be entered in this input field in binary (network prefix) or dot-decimal form. 

Attention: 

If the network mask is entered in dot-decimal form it will be subsequently be converted into the 

corresponding network prefix and later also shown so. 

Example: 

The network mask 255.255.255.0 will be shown as 24 later. 

’IP’ tab 

One or more IP ranges can be stored in this tab. When a host is assigned to this network at a later 

point, it will automatically be assigned the next, free IP address from the IP range entered here. 

When no IP range is entered here, the system automatically uses the area suggested by the network 

and the subnet mark entered on the General tab. 

Attention: 

If a single IP address is entered as a range, the IP address must be entered in both the First Address 

and Last Address input fields. 

Attention: 

The IP ranges must not overlap. Otherwise an error warning will be given alerting you of the overlap 

when you confirm with the [OK] button. 

’DNS’ tab 

Forward lookup zones and reverse lookup zones can be selected on this tab. When a unit is assigned 

to this network at a later point, a host record in the forward lookup zone and/or a pointer record in 

the reverse lookup zone will be created for the unit automatically. If no zone is selected, no automatic 

entries will be created. There is always the possibility of editing the settings both on the unit object 

and directly in the DNS zones.

DNS Entry 


The forward lookup zone where units from the network should be entered must be specified here. All 

the forward lookup zones entered in the domain and their subcontainers are available for selection. 

DNS Entry Reverse 

The reverse lookup zone where units from the network should be entered must be specified here. All 

the reverse lookup zones entered in the domain and their subordinate subcontainers are available for 

selection. 

’DHCP’ tab 

A DHCP service can be assigned to the network on this tab. When a unit is assigned to this network 

at a later point, a DHCP host entry with a fixed IP address will be created for the unit automatically 

in the selected DHCP service. If no DHCP service is selected here, there will also be no DHCP host 

entry automatically created. There is always the possibility of editing the settings on the unit object or 

under the DHCP service. 

4.5.4 Host management 

The following host objects can be created in computer management. Further information on the individual 

system roles can be found in Chapter 2.1. 

• Domain controller master 

The domain controller master, also called DC master, maintains the writable copy of the directory 

service. There can only ever be one DC master in a UCS domain. 

• Domain controller backup 

A domain controller backup, also called DC backup, contains an exact copy of the directory service. 

A DC backup can be promoted to a DC master. There can be any number of DC backup systems in 

a UCS domain. 

• Domain controller slave 

A domain controller slave, also called DC slave, contains a copy of the directory service. This copy 

may contain all or just one part of the data. There can be any number of DC slaves systems in a 

UCS domain. 

• Member server 

In contrast to the other domain controller system roles, the member server does not have a copy of 

the directory service. It is still fully integrated in the UCS domain, for example, all users and groups of 

the domain are also available on the member server. There can be any number of member servers 

in a UCS domain. 

• Domain trust account 

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

67


• IP managed client 

An IP managed client is specially intended for non-UCS systems, for example for network printers 

and routers, to allow simplified DNS and DHCP management. UCS base systems can also be 

created as IP managed client. 

• Mac OS X client 

A MAC OS X client can be created for the administration and integration of Max OS X clients. 

• Managed client 

A managed client is a UCS domain member with a Linux desktop 

• Mobile client 

A mobile client is similar to the managed client except that the focus with mobile clients is on note- 

books. 

• Thin client 

A thin client is a host which simply displays applications which are run on a terminal server (Linux or 

Windows). A thin client thus requires very little maintenance. 

• Windows 

The Windows role is specially designed for Windows hosts. If a Windows system joins the UCS 

domain, a Windows account is automatically created unless it has been created in advance. 

The following policy objects can be used on these host objects (see also Chapter 4.5.11): 

68 

• Autostart 

• Client devices 

• Display settings 

• Print server 

• LDAP server 

• Packages Client 

• Packages Master 

• Packages Member 

• Packages Mobile Client 

• Packages Slave 

• Maintenance 

• Release 

• Repository server 

• Repository synchronisation 

• Sound Settings 

• Thin client configuration 

• Windows installation


Name (*) 


The name for the host should be entered in this input field. The following information in the “Computer 

names” infobox should be observed. 

Description 

Any description can be entered for the host in this input field. 

MAC address 

The MAC address of the host can be entered here. It is required if the host is to receive a DHCP 

entry. The MAC address must always be given for thin clients, as thin clients cannot be commissioned 

without a DHCP entry. Example: 

2e:44:56:3f:12:32 

or 

2e-44-56-3f-12-32 

Network 

The host can be assigned to a newly created network. All networks registered in the domain are 

available for selection. The host will then be allotted the next free IP address from this network 

automatically. When the network contains DNS and DHCP settings the host will automatically also 

be entered in the DNS and DHCP service. The values which are automatically assigned after network 

selection on the IP, DNS und DHCP tabs can be checked and changed subsequently. 

Inventory number 

Inventory numbers for hosts can be stored here. 

Infobox ’Host names’ 

In theory, computer names can be selected without requirements. Under certain circumstances, e.g., 

when using Windows operating systems, the computer name entered in the LDAP directory must be 

identical to that entered in the DNS domain, which was entered directly locally on the host (usually 

during installation of the operating system). 

When the name of the domain to which the host belongs is added to the computer name, we are left 

with the fully qualified domain name of the host. This is better known by the acronym FQDN. 

To guarantee compatibility with different operating systems and services, computer names should 

only contain the lowercase letters a to z, numbers, hyphens and underscores. 

69


70 

Umlauts and special characters are not permitted. The full stop is used as a separating mark between 

the individual components of a FQDN and must therefore not appear as part of the computer name. 

Computer names must begin with a letter. 

Microsoft Windows accepts computer names with a maximum of 15 characters, so as a rule computer 

names should be limited to 15 characters if there is any chance that Microsoft Windows will be used. 

’IP’ tab 

IP address 

Fixed IP addresses for the host can be given here. If a network was selected on the General tab, the 

IP address assigned to the host from the network will be shown here automatically. The IP addresses 

shown here can still be changed at another time. A thin client needs a fixed IP address under all 

circumstances. 

Attention: 

An IP address entered here (and in the LDAP directory) can be now be transmitted to the host via 

DHCP. If no DHCP server is being used, the IP address can also be transferred to the host locally. 

Attention: 

If the IP addresses entered for a host are changed without the DNS zones being changed, they are 

automatically changed in the computer object and — where they exist — in the DNS entries of the 

forward and reverse lookup zones. If the IP address of the host was entered at other places as well, 

these entries must be changed manually! For example, if the IP address was given in a DHCP boot 

policy instead of the name of the boot server, this IP address will need to be changed manually by 

editing the policy. 

’DNS’ tab 

This tab allows selection of the forward and reverse lookup zones in which the host is entered and 

specification of a DNS alias. A fixed IP address is required for these entries, which must be entered 

on the IP tab so that the DNS entries can be created automatically. No entries are created so long 

as no zones have been selected. In order for a thin client to function correctly it requires a DNS entry 

(Host record in the forward lookup zone). 

More detailed information on the topic of DNS can be found in the Chapter 4.5.9. 

Forward zone for DNS entry 

A forward lookup zone for the host can be selected here. All the forward lookup zones entered in the 

domain and their subcontainers are available for selection. In addition it is also necessary to select 

one of the host’s IP addresses with which the host should be included in the forward lookup zone.

Reverse zone for DNS entry 


A reverse lookup zone for the host can be selected here. All the reverse lookup zones entered in the 

domain and their subcontainers are available for selection. In addition it is also necessary to select 

one of the host’s IP addresses corresponding to the reverse lookup zones with which the host should 

be mounted in the reverse lookup zone. 

Alias 

If a zone entry for forward mapping has been set up for the host in the Forward zone for DNS entry 

field, the additional alias entries via which the host can be reached can be configured here. 


More detailed information on the topic of DHCP can be found in the Chapter 4.5.10. 

DHCP 

In order for a host to receive an IP address from a DHCP service an entry must consist of DHCP 

service, MAC address and IP address. 

The DHCP service which should assign the host an IP address should be selected in the first selec- 

tion field. The DHCP services registered in the domain are available for selection. Please note that 

the selected DHCP server must be responsible for the physical network. 

The MAC address of the network card with which the host requests an IP address from the DHCP 

service must be entered in the second selection field. The MAC address of the host’s network card 

required for this must firstly be entered on the General tab. 

The IP address which the DHCP service assigns to the host should be selected in the third selection 

field. 

If a network is selected on the General tab an appropriate entry for the network will be added auto- 

matically. This can be adapted subsequently. A DHCP entry is necessary for a thin client under all 

circumstances. 

’Account’ tab’ 

This tab is only found on host types which join the UCS domain, e.g., domain controller, managed 

clients, Mac OS X clients, . . . 

Password 

Hosts which are member of the UCS domain require a password to be able to read and change 

their own data in the LDAP directory. The host creates a password automatically when joining the 

domain and makes a note of this in the /etc/machine.secret file and in the LDAP directory. Any 

71


72 

passwords already entered there are overwritten. If the password here is set or changed it must also 

be entered locally on the host in the /etc/machine.secret file. 

Password (retype) 

If the password is entered or changed manually in the Password input field, it must be repeated in 

this input field to exclude the risk of typing errors. 

Primary group 

The primary group of the host can be selected in this selection field. This is only necessary when 

they deviate from the automatically created default values. The default value for a DC master or DC 

backup is DC Backup Hosts, for a DC slave DC Slave Hosts and for member services, managed 

clients and mobile clients Computers. 

’Unix account’ tab 

This tab is only found on computer types which join the UCS domain, e.g., domain controller, man- 

aged clients, Mac OS X clients, . . . 

Unix home directory (*) 

A different input field for the host account can be entered here. The automatically created default 

value for the home directory is /dev/null. 

Login shell 

If a different login shell from the default value is to be used for the computer account, the login shell 

can be adapted manually in this input field. The automatically set default value assumes a login shell 

of /bin/bash. 

’Machine account’ tab 

This tab is only found on Windows computers. 

Machine account group 

This selection list allows you to specify the primary group for the Windows host. The Windows Hosts 

default value does not usually need to be changed. 

Initialize password with hostname 

This checkbox must be selected for Windows NT 4.0 computers which are to join the domain. The 

computer name is then saved as the password. The computer object is not selected when it is 

opened with Univention Directory Manager again. The password is changed when the domain is 

joined (Windows NT 4.0 expects the password to be the same as the computer name when joining 

the domain).

’Deployment’ tab 


This tab is found on DC master, DC backup, DC slave, member servers, managed clients, mobile 

clients and Windows hosts. Further information on the automatic installation can be found in the 

documentation for the profile-based UCS installation [3] and the Univention Windows Installer [4]. 

(Re-)install on next boot 

This checkbox should be selected if UCS should be installed automatically the next time the host is 

booted. 

Attention: 

The check must be removed again with Univention Directory Manager during or after the installation 

or else it will be reinstalled every time the host is booted! 

This checkbox must be selected for Windows hosts if Windows should be installed automatically 

on the host the next time it is booted. In addition a unattend.txt file should be entered on the 

[Windows installation] tab. The check is automatically removed during the Windows installation. 

Name of installation profile 

An installation profile can be specified for the host in this input field for UCS hosts. Profile should be 

made available in the /var/lib/univention-repository/profiles/ directory on the server 

on which the Univention Net Installer is executed. The file name of the profile should be entered 

without specifying the path. 

Additional start options 

The options from this input field are passed to the kernel during the network based installation, e.g. 

for the deactivation of ACPI during system startup. 

Interactive installation 

A profile-based installation is executed as standard in installation with the Univention Net Installer. 

This checkbox must be selected if an interactive installation should be executed instead. Values in 

the Name of installation profile input field are saved in the LDAP directory but not used during the 

installation. 

The Name of installation profile input field and the Interactive installation checkbox are not found 

on this tab for Windows hosts. The [Windows installation] tab should be used instead. 

’Services’ tab 

This tab is available on the DC master, DC backup, DC slave and member server hosts. 

73


Service 

The system services provided by this UCS system can be selected from the default values and 

entered in this list field. 


This tab is only available when adding a host and only for computer types which receive a computer 

account as standard. The tab is not shown when editing hosts. The tab allows selection of certain 

object classes for the host. The input fields for attributes of deselected object classes are not shown. 

For UCS hosts: 

Kerberos principal 

If this checkbox is not selected the host does not receive the krb5Principal and krb5KDCEntry 

object classes. 

Posix account 

If this checkbox is not selected the host does not receive the posixAccount object class. 

Nagios support 

If this checkbox is not selected the host does not receive the univentionNagiosHostClass object 

class. 

For Windows hosts: 

Samba account 

If this checkbox is not selected the host does not receive the sambaSamAccount object class. 

Nagios support 

If this checkbox is not selected the host does not receive the univentionNagiosHostClass object 

class. 

4.5.4.1 Domain trust account 

Windows domains (Windows NT/2000/2003, Samba) which allow the UCS Samba domain a trust relation- 

ship require a domain trust account entry in the LDAP directory (see also Chapter 8.4.1.1). 

74


Name (*) 


The name of the Windows domain which trusts the Samba domain should be entered in this input 

field. 

Description 

A description of your choice for the domain trust account can be entered in this input field. 

’Domain Trust Account’ tab 

Password (*) 

The password which will later be used on the PDC of the Windows domain must be entered in this 

input field. The password can be chosen freely, although the general requirements for passwords 

must be taken into account when doing so. 

Password (retype) (*) 

To avoid the risk of typing errors the above password must be reentered. 

4.5.5 Shares management 

In the sharing management, directory shares for NFS and Samba can be added, searched, edited, and 

deleted. Shares deleted in Univention Directory Manager will automatically be removed from the system. 

The data contained in the shared directory are preserved when the share is removed. 

The following policy objects can be used for or inherited in share management (see Chapter 4.5.11): 

• User quota 


Name (*) 

The name of the share is to be entered here. 

Host 

The server where the share is located. This setting cannot be subsequently edited. All of the domain 

controller master/backup/slave computers and member servers entered in the LDAP directory for the 

domain are available for selection which are entered in a DNS forward lookup zone in the LDAP 

directory. This setting cannot be subsequently edited. 

Directory (*) 

The absolute path of the directory to be shared, without quotation marks (this also applies if the 

name includes special characters such as spaces). If the directory does not exist, it will be created 

75


76 

automatically on the selected server. No shares can be created in and below /proc, /tmp, /root, 

/dev and /sys. 

Directory owner 

The user who is to own the share. All the users registered for the domain in the LDAP directory 

are available for selection. If more than 1000 users are found (this value can be configured with 

the Univention Configuration Registry variable directory/manager/web/sizelimit), or if the 

search for users within the LDAP directory takes longer than ten seconds, an entry field will be 

displayed instead of the select list, in which the username is to be entered. 

Directory owner group 

The group which is to own the share. All the groups registered for the domain in the LDAP directory 

are available for selection. If more than 1000 groups are found (this value can be configured with 

the Univention Configuration Registry variable directory/manager/web/sizelimit), or if the 

search for groups within the LDAP directory takes longer than ten seconds, an entry field will be 

displayed instead of the select list, in which the group name is to be entered. 

Directory mode 

Read, write, and access permissions for the share. 

Attention: 

Univention Directory Manager stores the set values for users, groups, and access rights in the LDAP 

directory, and makes sure that the directory exists and shared appropriately. Should the directory al- 

ready exist, then the values defined in the file system will be overwritten by the values taken from the 

LDAP directory. Changes in the shared directory, which were carried out directly in the file system, 

are not passed on to the LDAP directory, and can therefore not be displayed by Univention Directory 

Manager. If the shared object is edited within the LDAP directory, then the changes in the file sys- 

tem will be overwritten. Therefore, settings should be made and changed with Univention Directory 

Manager exclusively. 

’Samba general’ tab 

Samba name 

The name of the share to be used by Samba (NetBIOS name). This is the name by which the 

directory is represented, for example, on Windows clients within the network environment. When 

adding a directory share, Univention Directory Manager automatically adopts the name entered in 

the Name (*) field of the General tab as the Samba name. 

Attention: 

The homes share plays a special role within Samba. This share is used for sharing the home directo- 

ries of the users. This share is automatically converted to the user’s home directory. Samba therefore 

ignores the rights assigned in the share, and uses the rights of the respective home directory instead.

Browseable 


Specifies whether the share in question is to show up on Windows clients within the network environ- 

ment. 

Public 

Permits access to this share without a password. Every access is carried out by means of the com- 

mon guest user nobody. 

Postexec script 

A script or command which is to be executed if the connection to this share is finished. 

Preexec script 

A script or command which is to be executed each time a connection to this share is established. 

VFS Objects 

Virtual File System (VFS) modules are used in Samba for performing actions before an ac- 

cess to the file system of a share is made. A VFS module can be, for example, an 

anti-virus software which moves each infected file that is accessed within the share, to a 

quarantine area. VFS modules are documented in the official Samba HOWTO manual at 

http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/VFS.html. 

MSDFS Root 

A distributed file system makes it possible to map shares spanning several servers and paths to a 

virtual directory hierarchy. This mechanism can be utilised for distributing loads to several servers, or 

to outsource storage locations. It also represents an improved method for mapping logical structures. 

MSDFS means Microsoft Distributed File System, and represents the implementation of a distributed 

file system. 

Setting the MSDFS Root option indicates that the shared directory is a share which can be used for 

the MSDFS. References to other shares are only displayed in such an MSDFS root, elsewhere they 

are hidden. 

To be able to utilise the functions of a distributed file system, the Univention Configuration Registry 

variable samba/enable-msdfs has to be set to yes. Afterwards Samba has to be restarted. 

For creating a reference from server sa within the share fa to share fb on the server sb, the following 

command has to be executed in directory fa: 

ln -s msdfs:sb\\fb zufb 

77


78 

This reference will be displayed on every client capable of MSDFS (e.g. Windows 2000 and XP) as a 

regular directory. 

Attention: 

Only restricted user groups should have write access to root directories. Otherwise, it would be pos- 

sible for users to redirect references to other shares, and intercept or manipulate files. In addition, 

paths to the shares, as well as the references are to be spelt entirely in lower case. 

If changes are made in the references, the concerned clients have to be restarted. Further informa- 

tion on this issue can be found in the Samba documentation [9] in the chapter ’Hosting a Microsoft 

Distributed File System Tree’. 

Users with write access may modify permissions 

According to the Unix file permission concept, only those users who own a file may change access 

permissions. Samba has adopted this scheme. If this option is activated, all users with write permis- 

sion to a file are allowed to change permissions, ACL entries, and file ownership rights. It has to be 

noted that users of an owner group, who merely have read permission, are not authorised to carry 

out any changes. 

Hide unreadable files/directories 

If this option is activated, all files which are nonreadable for the user due to their file permissions, will 

be hidden. 

’Samba permissions’ tab 

Samba write access 

Permits writing access to this share from Windows clients. 

Force user 

This username and its permissions and primary group is used for performing all the file operations 

of all users. The username is only used once the user has established a connection to the Samba 

share by using his real username and password. A common username is useful for using data in a 

shared way, yet improper application might cause security problems. 

Force group 

A group which is to be used by all users connecting with this share, as their primary group. Thereby, 

the permissions of this group automatically apply as the group permissions of all these users. A group 

registered here has a higher priority than a group which was assigned as the primary group of a user 

via the Force user entry field. 

If a + sign is prefixed to the group name, then the group is assigned as a primary group solely to 

those users which are already members of this group. All other users retain their primary groups.

Valid users 


Names of users or groups which are authorised to access this Samba share. To all other users, 

access is denied. If the field is empty, all users may access the share - if necessary after entering a 

password. 

The entries are to be separated by spaces. The special characters @, + and & can be used in 

connection with the group name for assigning certain permissions to the users of the stated group for 

accessing the Samba share: 

• A name beginning with the character @ will first be interpreted as a NIS Netgroup. Should no 

NIS Netgroup of this name be found, the name will be considered as a UNIX group. 

• A name beginning with the character + will be exclusively considered as a UNIX group, a name 

beginning with the character & will be exclusively considered as a NIS Netgroup. 

• A name beginning with the characters +&, will first be interpreted as a UNIX group. Should 

Hide files 

no UNIX group of this name be found, the name will be considered as a NIS Netgroup. The 

characters &+ as the beginning of a name correspond to the character @. 

Files and directories to be accessed under Windows, yet not to be visible. Such files or directories 

are assigned the DOS attribute hidden. 

When entering the names of files and directories, upper and lower case letters are to be differentiated. 

Each entry is to be separated from the next by a slash. Since the slash can thus not be used for 

structuring path names, the input of path names is not possible. All files and directories of this name 

within the share will be hidden. The names may include spaces and the wildcards * and ?. 

Example: 

/.*/test/ hides all files and directories the names of which begin with a dot, or which are called test. 

Attention: 

Entries in this field have an impact on the speed of Samba since every time particular contents of the 

share are to be displayed, all files and directories have to be checked according to the active filters. 

NT ACL support 

If this option is activated, Samba will try to show POSIX ACLs under Windows, and to adopt changes 

to the ACLs, which were performed under Windows, for the POSIX ACLs. For this purpose, the Linux 

file system has to support POSIX ACLs. In UCS the file systems ext3 and XFS support POSIX-ACLs. 

If this option is not set, existing POSIX ACLs are effective but not shown under Windows, and conse- 

quently cannot be changed under Windows. 

79


80 

Users with write access 

Only the users and groups listed here have write permission for the corresponding share. 

Inherit ACLs 

When activating this option, each file created in this share will inherit the ACL (Access Control List) 

of the directory where the file was created. 

Inherit owner 

When activating this option, each newly created file will not be assigned of the user who created the 

file, but to the owner of the superior directory instead. 

Inherit permissions 

When activating this option, for each file or directory created in this share, the UNIX permissions of 

the superior directory will automatically be adopted. 

’Samba custom settings’ tab 

Custom settings for Samba shares 

Apart from the properties which can, as a standard feature, be configured in a Samba share, this 

setting makes it possible to define further arbitrary Samba settings within the share. A list of available 

options can be obtained by the command man smb.conf. In Key the name of the option is to be 

entered, and in the Value field the value to be set. Double entries of configuration options are not 

checked. 

Attention: 

The definition of extended Samba settings is only necessary in very special cases. The options 

should be thoroughly checked before setting since they might have security-relevant effects. 

Samba extended permissions 

If a new file is created on a Samba server from a Windows client, the file permissions will be set in 

several steps: 

1. First, only the DOS permissions are translated into UNIX permissions. 

2. Then the permissions are filtered via the File mode. UNIX permissions which are marked in 

File mode, are the only ones preserved. Permissions not set here, will be removed. Thus, the 

permissions have to be set as UNIX permissions and in File mode in order to be preserved. 

3. In the next step, the permissions under Force file mode are added. As a result, the file will 

have all the permissions set after step 2 or under Force file mode. This means, permissions 

marked under Force file mode are set in any case.


Accordingly, a newly created directory will initially be assigned the same permissions as that which 

are set as UNIX permissions and in Directory mode at the same time. Then these permissions are 

completed by those marked under Force directory mode. 

In a similar way, the security settings are adopted for existing files and directories the permissions of 

which are edited under Windows: 

Only those permissions can be changed under Windows, which are marked in Security mode or in 

Directory security mode. Once this is done, the permissions marked under Force security mode 

of under Force directory security mode are set in any case. 

Thus, the parameters File mode and Force file mode, or Directory mode and Force directory 

mode are applied during the creation of a file or directory, while the parameters Security mode and 

Force Security Mode or Security directory mode and Force security directory mode are applied 

when changing permissions. 

Attention: 

The security settings only relate to the access via Samba. 

The user on the Windows side does not receive any notification of the fact that the file or directory 

authorisations might by changed according to the Samba settings on this tab. 

File mode 

The permissions Samba is to adopt when creating a file, provided they are set under Windows. 

By default, this parameter is set to 0744, i.e. the owner has full access, the group and others have 

read permission. 

Directory mode 

The permissions Samba is to adopt when creating a directory, provided they are set under Windows. 

By default, this parameter is set to 0755, i.e. the owner has full authorisation, the group and others 

only have the permission to list the contents of the directory, and to change into the directory. 

Force file mode 

The permissions Samba is to set in any case when creating a file, irrespective of whether they are 

set under Windows or not. 

By default, this parameter is set to 0000, i.e. no additional permissions are set. 

Force directory mode 

The permissions Samba is to set in any case when creating a directory, irrespective of whether they 

81


82 

are set under Windows or not. 

By default, this parameter is set to 0000, i.e. no additional permissions are set. 

Security mode 

The file permissions to which Samba is to permit changes made from Windows side. 

By default, this parameter is set to 0777, meaning all permissions may be changed. 

Directory security mode 

The directory authorisations to which Samba is to permit changes made from Windows side. 

By default, this parameter is set to 0777, meaning all authorisations may be changed. 

Force security mode 

The permissions Samba is to set in any case (irrespective of whether they are set under Windows or 

not), if file permissions are changed from Windows side. 

By default, this parameter is set to 0000, meaning no permissions will be set compulsively in case of 

changes. 

Force directory security mode 

The permissions Samba is to set in any case if directory permissions are changed from Windows 

side (irrespective of whether they are set under Windows or not). 

By default, this parameter is set to 0000, meaning no permissions will be set compulsively in case of 

changes. 

’Samba performance’ tab 

Locking 

Locking means preventing concurrent access to one resource, making an exclusive access possible. 

When activating this checkbox, Samba will lock the access to files on the client’s request. 

If Locking is deactivated, the execution of lock and unlock requests is only pretended. All lock 

requests will be answered by the assertion, the requested file could be locked. 

This option can be useful for improving performance, yet it should generally not be set in shares with 

write access, since without locking, files might be corrupted due to concurrent access. 

Blocking locks

Clients can send a lock request with a time limit for a certain area of an open file. 


In case Samba is unable to comply with a the lock request, and this option is activated, then Samba 

will - in periodical intervals until the expiry of the time limit - try to lock the requested file area. If the 

option is deactivated, no further attempt will be made. 

Strict locking 

If this option is activated, Samba will with each read or write access check if the file is locked, and will 

deny access if required. On some systems, this procedure can take a long time. 

If this option is deactivated, Samba will check if the file is locked on the client’s request exclusively. 

Well configured clients ask for a check in all important cases, so that this option is usually unneces- 

sary. 

Oplocks 

If this option is activated, Samba will use so-called opportunistic locks. This can improve the speed 

of file access considerably. However, the option permits clients local caching of files on a large scale. 

In unreliable networks it might therefore be necessary to do without Oplocks. 

Level 2 oplocks 

When activating this option, Samba will support an extended form of Oplocks, the so-called oppor- 

tunistic read-only locks or Level 2 Oplocks. Windows clients receiving a read/write Oplock for a 

file can then scale down this Oplock to a read-only Oplock instead of having to abandon the Oplock 

completely as soon as a second client opens the file. All clients supporting Level 2 Oplocks, will then 

cache read access processes to the file exclusively. Should one of the clients write to the file, all the 

other clients will be asked to abandon their Oplocks, and to empty their caches. 

It is recommended to activate this option to speed up access to files which are normally not written to 

(e.g. programs / executable files). 

Attention: 

If kernel Oplocks are supported, Level 2 Oplocks will not be allowed, even if the option is activated. 

Only if the checkbox Oplocks is also ticked, this option will become valid. 

Fake oplocks 

When activating this option, Samba will allow all Oplock requests irrespective of the number of clients 

having access to a file. This method considerably improves performance, and is useful for shares 

which can only be accessed for reading (e.g. CD-ROMs), or where it is ensured that there can never 

occur a situation when several clients make access at the same time. 

If it cannot be excluded that several clients make reading and writing access to a file at the same 

83


84 

time, this option should not be activated, since it may cause data loss. 

Block size 

The block size in which unoccupied disk space is to be reported to the clients. By default, this size is 

defined as 1024 bytes. 

Client-side caching policy 

This option specifies in which way the clients are to cache the files of this share offline. The available 

alternatives are manual, documents, programs, and disable. 


Export for Samba clients 

This option defines whether the share is to be exported for Samba clients. 

Export for NFS clients 

This option defines whether the share is to be exported for NFS clients. 

Export for Web clients 

This option defines whether the share is to be exported for web access through the Horde client. 

’NFS General’ tab 

NFS write access 

Permits writing NFS access to this share. 

NFS synchronisation 

The synchronisation mode for the share. The sync setting causes immediate synchronisation of the 

data, async initiates synchronisation when the workload of the server permits to do so. Synchroni- 

sation is then performed in the background. 

Redirect root access 

In the NFS standard procedure, identification of users is achieved via user IDs. To prevent a local 

root user from working with root permissions on other shares, root access can be redirected. If this 

option is activated, access operations are executed as user nobody. 

Attention: 

The local group staff , which is by default empty, owns privileges which come quite close to root 

permissions, yet this group is not considered by the redirection mechanism. This fact should be 

borne in mind when adding users to this group.

Subtree checking 


If only one subdirectory of a file system is exported, the NFS server has to check whether an accessed 

file is located on the exported file system and in the exported path, each time access is made. Path 

information is passed on to the client for this check. Activating this function might cause problems if 

a file opened by the client, is renamed. 

Allowed hosts 

By default, all hosts are permitted access to a share. In this select list, host names and IP addresses 

can be included, to which the access to the share is to be restricted. For example, access to a share 

containing mail data could be restricted to the mail server of the domain. 

4.5.6 Samba 

With its extensive range of functions Samba is an important link between UCS domains and Windows 

computers. Certain Samba settings can be performed in Univention Directory Manager. For example, it is 

possible to manage the settings for passwords and RIDs. 

4.5.6.1 Settings: Samba Domain 

The Settings: Samba Domain object can be used to control the issuing of RIDs for users, groups and 

other groups as well as performing password-relevant settings. It is normally stored in the samba container 

in the LDAP navigation. 


Samba Domain Name (*) 

The Samba domain name given here is assigned to the Samba security ID (SID). The Samba domain 

name can also be changed after the object is created. 

When changes are made, the Univention Configuration Registry variable windows/domain must 

also be set to the respectively used domain names on the Samba servers locally (see Chapter 8.4.6). 

Samba SID 

The Samba security ID can only be given or modified when creating an object. Subsequent changes 

are not possible. The field is greyed out in this case. 

Next User RID 

The figure given here is issued as the next Samba user RID. If no setting is made, Samba manages 

the RIDs itself. 

Next Group RID 

85


86 

The figure given here is issued as the next Samba group RID. If no setting is made, Samba manages 

the RIDs itself. 

Next RID 

The figure given here is issued as the next RID for objects which are neither users nor groups. 

Password Length 

Specifies the minimum length for passwords. The user cannot set passwords shorter than this length. 

Password History 

To force the user to use different passwords, the recently used passwords are archived here. If an 

attempt is made to use an existing password when setting a new password, this password will be 

rejected. The number of passwords archived can set in this input field. 

Minimum Password Age 

If a minimum password age is set, the user can only reuse this password once the time period given 

has expired. This can be set in seconds, minutes, hours or days. 

Maximum Password Age 

If a maximum password age is set, the user will be asked to change his password when the time since 

the last password change exceeds the time period given here. This can be set in seconds, minutes, 

hours or days. 

Bad Lockout Attempts 

To suppress or slow down repeated attempts at guessing passwords, a user can be blocked automat- 

ically after the number of failed attempts to log in given here. 

Lockout Duration Minutes 

A user who has been blocked following too many failed attempts to log in will have this block lifted 

after the time period given here elapses. This can be set in seconds, minutes, hours or days. 

Reset Count Minutes 

The counter for failed log-in attempts will be automatically reset once the time period given here 

elapses. This time period is set in minutes. 

User must Logon to Change Password 

Selecting this checkbox requires a user to be logged on before he can change his password. If the 

maximum password age has already been exceeded, the user can no longer log in and must ask 

an administrator to reset the password. If the checkbox is not selected, the user can change the 

password when logging in

Disconnect Time 


This input field is used to specify after what period of inactivity the connection to the Samba share 

should be teared down. This can be set in seconds, minutes, hours or days. 

4.5.7 Printer management 

Printer shares can be added, searched, edited and removed in printer management. When a printer share 

is added, the printer is automatically set up in CUPS. All printers set up in CUPS are automatically provided 

for Windows computers via Samba. When a printer share is removed, the printer is also automatically 

removed from the CUPS configuration and, when appropriate, from the Samba configuration. 

Attention: 

Network printers with their own network interface should be entered as an IP managed client in computer 

management. 

In addition, printer groups can be defined, the members of which are used in rotation to process print jobs, 

which distributes the loads automatically amongst printers set up near to each other. Printer groups are 

described as a part of the whole UCS print system in Chapter 13.3.4. 

Print Quota settings can be applied/inherited to the printer management using a policy (see Chapter 

4.5.11): 

4.5.7.1 Printers 


Name (*) 

This input field contains the name of the printer share, which is used by CUPS. The printer appears 

under this name in Linux and Windows. The name may contain alphanumeric characters (i.e., upper- 

case and lowercase letters a to z and numbers 0 to 9) as well as hyphens and underscores. Other 

characters (including blank spaces) are not permitted. 

Spool host (*) 

A print server (spooler) manages the printer queue for the printers to be shared. It converts the data 

to be printed into a compatible print format when this is necessary. If the printer is not ready, the print 

server saves the print jobs temporarily and forwards them on to the printer subsequently. If more than 

one print server is specified, the print job from the client will be sent to the first print server to become 

available. 

Protocol and Destination (*) 

These two input fields create the URI (Universal Ressource Identifier). A resource (e.g., a queue) 

can be addressed using the communications protocol (http://, ipp://, . . . ) and the path. The following 

table describes the syntax of the individual protocols and gives an example for each: 

87


88 

Protocol Target syntax Example 

file:/ /tmp/print.file 

http:// [:]/ 192.168.0.10:631/printers/remote_prn 

ipp:// /printers/ printer_01/printers/laser 

lpd:// / 10.200.18.30/bwdraft 

parallel:/ dev/lp0 

socket:// : printer_03:9100 

usb:/ dev/usb/lp0 

smb:// / prroom104/slot3 

cups-pdf:/

Manufacturer 


When the printer manufacturer is selected, the Printer model selection list updates automatically. 

Printer model (*) 

This selection list shows all the printers available from the selected manufacturer. If the required 

printer model is not there, a similar model can be selected and a test print used to establish correct 

function. Chapter 4.5.12.2 explains how to expand the list of printer models. 

Attention: 

The “Printer models” None and smb can be found under “Manufacturer” misc. The None model can 

be selected if the printer is PostScript-compatible and the printing hosts sends print jobs in PostScript 

format. This is also the case is the computer send print jobs which are already in the format of the 

printer. The print jobs are then spooled from CUPS and not filtered. 

The smb model is suitable for printers which can be contacted using the smb protocol. This is usually 

the case for printers connected to a Windows computer. 

Samba name 

A printer can also be assigned an additional name by which it can be reached from Windows. Unlike 

the CUPS name (see Name), the Samba name may contain blank spaces and umlauts. The printer 

is then available to Windows under both the CUPS name and the Samba name. 

Using a Samba name in addition to the CUPS name is practical, for example, if the printer was already 

in use in Windows under a name which contains blank spaces or umlauts. The printer can then still 

be reached under this name without the need to reconfigure the Windows computers. 

Enable quota support 

If quota were activated for this printer, the quota settings on the [Print Quota] tab apply. 

Attention: 

The ’Services/Print quota’ components need to have been selected during installation or installed by 

running the univention-system-setup-software in order to be able to calculate print quotas 

and print costs. 

Price per page 

The user is charged the value given in this input field for every page printed. The incurred costs are 

summarised in the user’s account and used for the accurate calculation of print costs. If no value is 

specified, print costs will not be calculated. 

Price per print job 

The user is charged the value given in this input field for every print job. The incurred costs are 


89



Location 

This is displayed by some applications when selecting the printer. It can be filled with any text. 

Description 

This is displayed by some applications when selecting the printer. It can be filled with any text. 

’Access Control’ tab 

Access control 

Access rights for the printer can be specified here. Access can be limited to certain groups or users 

or generally allowed and certain groups or users blocked specifically. As standard, access is available 

for all groups and users. These rights are also adopted for the corresponding Samba printer shares, 

so that the same access rights apply when printing via Samba as when printing directly via CUPS. 

Allowed/denied users 

This lists individual users for whom access should be controlled. 

Allowed/denied groups 

This lists individual groups for whom access should be controlled. 

4.5.7.2 Printer groups 

90 


Name (*) 

This input field contains the names of the printer group share, which is used by CUPS. The printer 

group appears under this name in Linux and Windows. 

The name may contain alphanumeric characters (i.e., uppercase and lowercase letters a to z and 

numbers 0 to 9) as well as hyphens and underscores. Other characters (including blank spaces) are 

not permitted. 

Spool host (*) 

A range of print servers (spoolers) can be specified here to expand the list of printers available for 

selection. Printers which are assigned to the servers specified here can then be adopted in the Group 

members list from the selection arranged below them. 

Samba name 

A printer group can also be assigned an additional name by which it can reached from Windows.


Unlike the CUPS name (see Name), the Samba name may contain blank spaces and umlauts. The 

printer is then available to Windows under both the CUPS name and the Samba name. 

Using a Samba name in addition to the CUPS name is practical, for example, if the printer group was 

already in use in Windows under a name which contains blank spaces or umlauts. The printer group 

can then still be reached under this name without the need to reconfigure the Windows computers. 

Group members 

This list is used to assign printers to the printer group. 

Enable quota support 

If quota were activated for this printer group, the quota settings on the [Print Quota] tab apply. 

Attention: 

The ’Services/Print quota’ components need to have been selected during installation or installed by 

running the univention-system-setup-software in order to be able to calculate print quotas 

and print costs. 

Price per page 

The user is charged the value given in this input field for every page printed. The incurred costs are 



Price per print job 

The user is charged the value given in this input field for every print job. The incurred costs are 



4.5.8 Containers, organisational units, domains 

4.5.8.1 Adding containers and organisational units 

As a means of structuring the data of the LDAP directory, containers and organisational units can be 

included at any position within this structure. Organisational units represent units existing in the real world, 

such as the departments of a company or an institution, while containers stand for fictional units within the 

enterprise, e. g. all the computers of the company. 


Name (*) 

A random name for the container / organisational unit. 

91


Description 

A random description for the container / organisational unit. 

’Container settings’ tab 

Add to standard containers 

If this option is activated, the container or organisational unit will be regarded as a standard container 

for a certain object type (see chapter 4.5.12.7). 

’Policies’ tab 

This tab is described in chapter 4.5.11.3. 

4.5.8.2 Edit domain 

The domain object is automatically created in the LDAP directory during installation. It forms the basis of 

the LDAP directory and can be edited via Univention Directory Manager. 

This directory is often called the directory tree, with the domain object as its root. 

92 


Name (*) 

The name of the domain. Once the domain has been created, the name cannot be changed again. 

’Domain Password’ tab 

This tab is not used in one-domain concepts. 

’DNS’ tab 

All the DNS zones stored within the domain are listed here. The procedures for creating, editing and 

deleting DNS zones are established in Chapter 4.5.9; alterations there are automatically adopted in 

the lists shown here. The lists on this tab cannot be altered manually. 

DNS forward lookup zone 

All the Forward Lookup Zones stored within the domain are listed here. 

DNS reverse lookup zone 

All the Reverse Zones stored within the domain are listed here.

’Samba’ tab 


The Samba settings are only performed here if installation was performed with a UCS version up to 

1.2-3. As of UCS 1.2-4 Samba settings are managed in their own objects (see Chapter 4.5.6). 

Samba domain name (*) 

Names of Samba domains can be added and removed here. In this, the Samba domain names 

are simply allocated to the Samba SIDs visible on this tab. In addition, the Univention Configuration 

Registry variable windows/domain must also be set to the respectively used domain names on the 

Samba servers (see Chapter 8.4.6.1). 

Samba SID (*) 

The Samba SID is shown here. The SID is displayed in grey as it cannot be changed. 

Next Samba user RID (*) 

This option can be used to configure what number should be allocated as the next Samba user RID. 

Next Samba group RID (*) 

This option can be used to configure what number should be allocated as the next Samba group RID. 

’Kerberos’ tab 

Kerberos realm (*) 

The name of the Kerberos realm. This entry is displayed in grey and barred from being changed. 


Mail relay server 

You can enter the FQDN of clients here, which are to be used as relay hosts. (siehe Kapitel 12) . 


The policies tab is described in chapter 4.5.11.3. 

4.5.9 DNS 

DNS files are stored in the cn=dns, container as standard. Forward and reverse lookup zones 

are stored directly in the container. Additional DNS objects such as pointer records can be stored in the 

respective zones. 

The relative or fully qualified domain name (FQDN) (see the information on host names, page 69) should 

always be used in the input fields for computers and not the computer’s IP address. A FQDN should always 

93


end in a full stop to avoid the domain name being added anew. 

4.5.9.1 Forward lookup zone 

A forward lookup zone contains information which is used to resolve DNS names into IP addresses. 

94 


Zone name (*) 

This is the complete name of the DNS domain for which the zone will be responsible. 

Attention: 

The domain name must not end in a full stop in zone names! 

Zone Time-to-Live (*) 

The time to live specifies how long these files may be cached by other DNS servers. The preset value 

is three hours. 

’Start of Authority’ tab 

Each DNS zone has at least one authoritative, primary name server whose information governs the 

zone. Subordinate servers synchronise themselves with the authoritative server via zone transfers. 

The entry which defines such a zone is called a "SOA record" in DNS terminology. 

Contact person (*) 

The e-mail address of the person responsible for administrating the zone (with a full stop at the end). 

Name server (*) 

The fully qualified domain name with a full stop at the end or the relative domain name of the primary 

master name server. 

Attention: 

Only the primary master name server should be entered in this field. Further name servers can be 

entered on the Name servers tab. 

Serial number (*) 

Other DNS servers use the serial number to recognise whether zone data have changed. The slave 

name server compares the serial number of its copy with that on the master name server. If the serial 

number of the slave is lower than that on the master, the slave copies the changed data. 

There are two commonly used patterns for this serial number: 

• Start with 1 and increment the serial number with each change


• By including the date the number can be entered in the format YYYYMMDDNN, where Y stands 

for year, M for month, D for day and N for the number of the change of this day. 

If the serial number is not changed manually, Univention Directory Manager automatically increases 

the value by 1 if [OK] was clicked. If the process is cancelled, the serial number remains unchanged. 

Refresh interval (*) 

The time span after which the slave name server checks that its copy of the zone data is up-to-date. 

Common values are between one and 24 hours. The preset value is eight hours. 

Retry interval (*) 

The time span after which the slave name server tries again to check that its copy of the zone data 

is up-to-date after a failed attempt to update. This time span is usually set to be less than the update 

interval, but can also be equal. The preset value is two hours. 

Expiry interval (*) 

The time span after which the copy of the zone data on the slave becomes invalid if it could not be 

checked to be up-to-date. 

For example, an expiry interval of one week means that the copy of the zone data becomes invalid 

when all requests to update in one week fail. In this case, it is assumed that the files are too outdated 

after the expiry interval date to be used further. The slave name server can then no longer answer 

name resolution requests for this zone. 

Common periods for this are one week. Longer expiry intervals can be selected if there are problems 

with the network connections to the master name server. The preset value is one week. 

Minimum Time-to-Live (*) 

The minimum time to live specifies how long other servers can cache no-such-domain (NXDOMAIN) 

answers. This value cannot be set at more than 3 hours, the preset value is 3 hours. 

’Name servers’ tab 

Name servers (usually called NS records in DNS terminology) can be assigned to a zone on this tab. 

The name server entered on the Start of Authorty tab appears automatically in the Entries list field. 


The fully qualified domain name with a full stop at the end of the relative domain name of the name 

server. 

Attention: 

The name server which appears at the top of the list is always the master, irrespective of what is 

95


entered in the Name server input field of the Start of Authority tab. 

’TXT records’ tab 

Text records (known as TXT records in DNS terminology) can be defined here. These contain human- 

readable text and can contain descriptive information, which is used in anti-spam measures, for ex- 

ample. 

TXT Record 

Descriptive text for this zone. Text records must not contain umlauts or other special characters. 

’MX records’ tab 

The mail exchanger entry for a zone (called MX record in DNS terminology) is important DNS infor- 

mation necessary for e-mail routing. It points to the computer which accepts e-mails for a domain. 

Priority (*) 

A numerical value between 0 and 65535. If several mail servers are available for the MX record, an 

attempt will be made to engage the server with the lowest priority value first. 

Mail Server (*) 

The mail server responsible for this domain as fully qualified domain name with a full stop at the end. 

Only canonical names and no alias names can be used here. 

4.5.9.2 Alias record 

A pointer to an existing, canonical DNS name can be defined here using an alias record (also known as 

CNAME record in DNS terminology). Any number of alias records can be defined to one canonical name. 

An alias record must always be assigned to a forward lookup zone and can therefore only be added to a 

forward lookup zone or a subordinate container. 

96 


Alias (*) 

The alias name as fully qualified domain name with a full stop at the end or as a relative domain name 

which should point to the canonical name. 

Zone Time-to-Live 


is three hours.

’Alias’ tab 

Canonical name (*) 


The canonical name of the computer that the alias should point to, entered as a fully qualified domain 

name with a full stop at the end or a relative domain name. 

The canonical name is the name which was entered in the Hostname input field on the host object. 

If the host object was created automatically when adding a computer, the value is the same as the 

computer name entered at the time. 

4.5.9.3 Host record 

Additional information about a computer and its configuration can be defined in a host record. It must 

always be assigned to a forward lookup zone and can therefore only be added to a forward lookup zone or 

a subordinate container. 

Attention: 

When adding or editing a computer a host record can be created automatically or edited. 

Karteikarte ’Allgemein’ 

Hostname (*) 

The FQDN with a full stop at the end or the relative domain name of the name server. The notes on 

computer names (Chapter 4.5.4) must be observed. 

IP Address 

A host record assigns an Ipv4 address to a DNS name. This entry creates such a record for the 

current host. 

Zone Time-to-Live 



’IP addresses’ tab 

Further IP addresses for the computer (and further A records) can be entered and removed here. 

IP Address 

Additional IP addresses where the computer can be reached. 

Attention: 

In this variant, all IP addresses are assigned to the same canonical name. If each IP address should 

97


be able to be reached under its own canonical name, a host record must be created for each IP 

address and different names entered in the Hostname input field. 

4.5.9.4 Service record 

Service records (SRV record in DNS terminology) offer the possibility of storing information on available 

system services in the DNS. In UCS service records are used amongst other things to make LDAP servers 

or the domain controller master known domain-wide. 

A service record must always be assigned to a forward lookup zone and can therefore only be added to a 

forward lookup zone or a subordinate container. 

98 


Service (*) 

The name under which the service should be reachable. 

Protocol (*) 

TCP and UDP are available. 

Priority (*) 

A whole number between 0 and 65535. If more than one server offer the same service, the client will 

approach the server with the lowest priority value first. 

Weight (*) 

A whole number between 0 and 65535. The weight function is used for load balancing between 

servers with the same priority. When more than one server offer the same service and have the 

same priority the load is distributed across the servers in relation to the weight function. 

Example: Server1 has a priority of 1 and a weight function of 1, whilst Server2 also has a priority 

of 1, but has a weight function of 3. In this case, Server2 will be used three times as often as 

Server1. The load is measured depending on the service, for example, as the number of requests or 

connection. 

Port (*) 

The port where the service can be reached on the server (valid value from 1 to 65535). 

Server (*) 

The name of the server on which the service will be made available, as a fully qualified domain name 

with a full stop at the end or a relative domain name. 

Zone Time-to-Live




Several servers can be entered for each service via the check box. 

4.5.9.5 Reverse lookup zone 

A reverse lookup zone is used to resolve IP address into host names. 


Subnet (*) 

The IP address of the network for which the reverse lookup zone shall apply. For example, if the 

network in question consisted of the IP addresses 192.168.1.0 to 192.168.1.255, 192.168.1 should 

be entered. 

Zone Time-to-Live (*) 



’Start of Authority’ tab 

Each DNS zone has at least one authoritative, primary name server whose information governs the 

zone. Subordinate servers synchronise themselves with the authoritative server via zone transfers. 

The entry which defines such a zone is called a SOA record in DNS terminology. 

Contact person (*) 

The e-mail address of the person responsible for administrating the zone (with a full stop at the end). 


The fully qualified domain name with a full stop at the end or the relative domain name of the primary 

master name server. 

Attention: 

Only the primary master name server should be entered in this field. Further name servers can be 

entered on the Name server 

Serial number (*) 

Other DNS servers use the serial number to recognise whether zone data have changed. The slave 

name server compares the serial number of its copy with that on the master name server. If the serial 

number of the slave is lower than that on the master, the slave copies the changed data. 

99


100 

There are two commonly used patterns for this serial number: 

• Start with 1 and increment the serial number with each change. 

• By including the date the number can be entered in the format YYYYMMDDNN, where Y stands 

for year, M for month, D for day and N for the number of the change of this day. 

If the serial number is not changed manually, Univention Directory Manager automatically increases 

the value by 1 if [OK] was clicked. If the process is cancelled, the serial number remains unchanged. 

Refresh interval (*) 

The time span after which the slave name server checks that its copy of the zone data is up-to-date. 

Common values are between one and 24 hours. The preset value is eight hours. 

Retry interval (*) 

The time span after which the slave name server tries again to check that its copy of the zone data 

is up-to-date after a failed attempt to update. This time span is usually set to be less than the update 

interval, but can also be equal. The preset value is two hours. 

Expiry interval (*) 

The time span after which the copy of the zone data on the slave becomes invalid if it could not be 

checked to be up-to-date. 

For example, an expiry interval of one week means that the copy of the zone data becomes invalid 

when all requests to update in one week fail. In this case, it is assumed that the files are too outdated 

after the expiry interval date to be used further. The slave name server can then no longer answer 

name resolution requests for this zone. 

Common periods for this are one week. Longer expiry intervals can be selected if there are problems 

with the network connections to the master name server. The preset value is one week. 

Minimum Time-to-Live (*) 

The minimum time to live specifies how long other servers can cache no-such-domain (NXDOMAIN) 

answers. This value cannot be set at more than 3 hours, the preset value is 3 hours. 

’Name servers’ tab 

Name servers (usually called NS records in DNS terminology) can be assigned to a zone on the 

Name servers tab. The name server entered on the Start of Authority tab appears automatically in 

the Entries list field. 

Name servers (*) 

The fully qualified domain name with a full stop at the end of the relative domain name of the name

server. 

Attention: 


The name server which appears at the top of the list is always the master, irrespective of what is 

entered in the Name server input field of the Start of Authority tab. 

4.5.9.6 Pointer record 

A pointer record (usually called PTR record in DNS terminology) allows resolution of an IP address into a 

host name. It thus represents the equivalent in a reverse lookup zone of a host record in a forward lookup 

zone. This entry is only available within reverse lookup zones. 


Address (*) 

The last octet of the computer’s IP address (depends on network prefix, see below). 

Pointer 

The computer’s fully qualified domain name with a full stop at the end. 

Example: 

In a network with a 24-bit network prefix (subnet mask 255.255.255.0) a pointer should be created for 

the client001 computer with the IP address 192.168.1.101. 101 must then be entered in the Address 

field and client001.company.com. in Pointer. 

Example: 

For a network with a 16-bit network prefix (subnet mask 255.255.0.0) the last two octets should be 

entered in reverse order for this computer (here 101.1). client001.company.com. also needs to be 

entered in the Pointer field here. 

4.5.10 DHCP 

The Dynamic Host Configuration Protocol (DHCP) assigns computers an IP address, the subnet mask 

and further information on the router or NetBIOS server as necessary. The IP address can be either fixed 

or variable. The aim of this procedure is that the IP addresses are not entered locally on the computers, 

but rather on a central DHCP server (or in the LDAP directory), where they can be managed from one 

location. 

Thin clients are even set to retrieve an IP address via the DHCP when they have no persistent memory and 

therefore cannot store information locally for considerable periods of time. In addition, the DHCP service 

informs them which boot file should be used to boot from which server. 

101


DHCP servers with a common configuration are compiled in a DHCP service. Global configuration pa- 

rameters are entered in the DHCP service; specific parameters in the subordinate objects. 

A number of DHCP servers within one DHCP service can be used if only fixed IP addresses are assigned. 

If variable IP addresses are also assigned, a maximum of two DHCP servers can be used in combination 

with the DHCP failover mechanism. 

A DHCP host entry is used to make the DHCP service aware of a computer. These computer entries can 

be created automatically when adding or editing a computer in computer management or in the navigation. 

A computer entry is required for computers attempting to retrieve a fixed IP address over the DHCP. 

A DHCP subnet entry is required for every subnet, irrespective of whether variable IP addresses are 

allocated from this subnet. 

Configuration parameters can be assigned to the different IP ranges by creating DHCP pools within sub- 

nets. In this way unknown computers can be allowed in one IP range and excluded in another IP range. 

DHCP failover can also be set-up in DHCP pool objects. DHCP pools can only be created below DHCP 

subnet objects. 

If several subnets use the same common, physical network, this should be entered as a DHCP shared 

subnet below a DHCP shared network. DHCP shared subnet objects can only be created below DHCP 

shared network objects. 

Instead of DHCP group declarations, containers can be created to accept the objects to be grouped. The 

parameters of such an object group are determined via a policy, which is linked to the container. 

Values which are input on a DHCP configuration level always apply for this level and all subordinate levels, 

unless other values are specified there. Similar to with the policies, the value which is closest to the object 

always applies. Unlike for the general policies, it is not possible here to set it so that a value cannot be 

altered from lower levels. 

Attention: 

Note that values assigned to an object via a policy are inherited by all subordinate objects. For example, if 

the domain name company.com is fixed in a DHCP service object via a policy and a DHCP host object is 

created in the same DHCP service object, the DHCP host object automatically adopts the domain name 

because of the inherited policy settings. If the DHCP host object now retrieves an IP address from a 

DHCP pool where the domain name sales.company.com was entered, the domain name company.com 

will remain valid for the DHCP host object. 

This applies to all settings which are made on tabs where the writing at the top of the tab is enclosed in 

square brackets. The inherited values are displayed on the respective tabs of the subordinate objects and 

can be altered there (see also Chapter 4.5.11). 

The following policies can be applied for the DHCP objects described below: 

102 

• Boot parameters 

• DHCP miscellaneous 

• DNS 

• DNS update 

• Allow/Forbid

• Lease time 

• NetBIOS 

• Routing 

More information on these can be found in Chapter 4.5.11.5. 

4.5.10.1 DHCP service 


DHCP services are stored in the dhcp container by default, which is automatically created when the 

domains are created. 


Service name (*) 

Any unique name can be entered in this entry field for the DHCP service. 

The following parameters are often set at this level which then apply to all the computers which are served 

by this DHCP service (unless other values are entered in lower levels): 

• Domain name and Domain name servers on the [DNS] tab 

• NetBIOS name servers on the [NetBIOS] tab 

A description of this and the other input possibilities in the policy-based tabs can be found in Chap- 

ter 4.5.11.5. 

4.5.10.2 DHCP server 

Each server which should offer the DCHP service requires a DHCP server entry in the LDAP directory. 

Otherwise the DHCP service will not be started. 

To add the DHCP server, the first step is to open the DHCP service object. The DHCP service object can 

usually be found in Navigation ➞ dhcp. A DHCP server object can now be created in the DHCP service 

object. 


Server name (*) 

The computer name which will offer the DHCP service should be entered in this input field. 

Attention: 

A server cannot be entered in more than one DHCP service at the same time. 

Attention: 

If several DHCP servers are entered in the same DHCP service, the DHCP failover mechanism must be 

activated to be able to assign variable IP addresses. 

103


4.5.10.3 DHCP subnet 

Attention: 

A DHCP subnet entry is required for every subnet from which variable or fixed IP addresses are to be 

assigned. It is only necessary to input IP ranges when variable IP addresses are to be assigned. 

To add a DHCP subnet, the first step is to open the corresponding DHCP service in Navigation where the 

DHCP subnet object is to be created. 

If DHCP shared subnet objects are to be used, the corresponding subnets should be created below the 

DHCP shared subnet container created for this purpose (see Chapter 4.5.10.7). 

104 

’General’ tab’ 

Subnet address (*) 

The IP address of the subnet should be input here in dot-decimal form, e.g. 255.255.255.0. 

Netmask (*) 

The network mask can be entered in this input field as the network prefix as a decimal number in or 

dot-decimal form. 

Attention: 

If the network mask is entered in dot-decimal form it will be subsequently be converted into the 

corresponding network prefix and later also shown so. 

Example: 

The network mask 255.255.255.0 will be shown as 24 later. 

Broadcast address 

The broadcast address can be entered in this input field in dot-decimal form, e.g. 192.168.1.255. 

’Dynamic address assignment’ tab 

A single or several IP ranges can be set up on this tab. The IP addresses from these ranges are then 

available for dynamic allocation. 

Attention: 

IP ranges for a subnet should always either be specified exclusively in the subnet entry or exclusively 

in one or more special pool entries. The types of IP range entries within a subnet must not be mixed! 

If different IP ranges with different configurations are be set up in one subnet, pool entries must be 

created for this purpose. Pool entries must also be used to set up the DHCP failover mechanism in a 

subnet immediately or at a later date. 

First address 

The lowest IP address in the IP range should be entered here in dot-decimal form, e.g. 192.168.1.100.

Last address 


The highest IP address in the IP range should be entered here in dot-decimal form, e.g. 

192.168.1.200. 

Attention: 

To enter a single IP address as a range, this IP address must simply be entered in both fields. 

This is often the level where the following parameter is fixed, which applies to all computers in this subnet 

(unless other values are entered in lower levels). 

• Routers on the [Routing] tab 

A description of this and the other input possibilities in the policy-based tabs can be found in Chap- 

ter 4.5.11.5. 

4.5.10.4 DHCP pool 

Attention: 

If DHCP pools are to be created in a subnet, there should be no IP ranges defined in the subnet entry. 

These should only be created in the pool entries. 

A DHCP pool object must always be created below a DHCP subnet object. 


Name (*) 

Any unique name can be entered in this entry field for the DHCP pool, e.g. sales.company.com. 

First address 

The lowest IP address in the IP range should be entered here in dot-decimal form, e.g. 192.168.1.100. 

Last address 

The highest IP address in the IP range should be entered here in dot-decimal form, e.g. 

192.168.1.200. 

Attention: 

To enter a single IP address as a range, this IP address must simply be entered in both fields. 

’Advanced’ tab 

Failover peer 

If the DHCP failover mechanism is to be included, the unique identifier for the DHCP server pair must 

105


106 

be given in this input field which is responsible for this pool. The identifier entered here must match 

the identifier entered for both the participating DHCP servers in the /etc/dhcp3/dhcpd.conf file. 

As dynamic BOOTP is not compatible with the DHCP failover mechanism, the entry deny must be 

selected in the Allow dynamic BOOTP clients select list. It is not sufficient to select deny in the 

BOOTP select list on the [Allow/Deny] tab for the DHCP server or DHCP subnet! 

Attention: 

The servers which make up the failover pair must be configured accordingly for the DHCP failover 

mechanism to work. TO do this, the configuration files are adapted locally on the servers and thus 

the configuration cannot be performed with the Univention Directory Manager. 

Allow known clients 

When the allow entry is selected, the DHCP service assigns IP addresses from the pool to clients 

with a DHCP host entry below the DHCP service. If deny is selected, the DCHP service does not 

assign these clients IP addresses from this pool (see Note below). 

Allow unknown clients 

When the allow entry is selected, the DHCP service assigns IP addresses from the pool to clients 

without a DHCP host entry under the DHCP service. If deny is selected, the DCHP service does not 

assign these clients IP addresses from this pool (see Note below). 

Allow dynamic BOOTP clients 

When the allow entry is selected, the DHCP service also assigns IP addresses from the pool to 

clients which sent a request via the BOOTP protocol. Dynamic BOOTP clients do not receive an IP 

address from this pool if the deny entry is selected (see Note below). 

All clients 

When the allow entry is selected, the DHCP service assigns IP addresses from the pool to any clients 

as long as they are not already excluded by other settings. The DHCP service does not assign IP 

addresses from this pool, irrespective of the type of client making the request, if the deny entry is 

selected (see Note below). 

This setting can be used to force all active clients to allow themselves to be assigned a new IP 

address when they renew their existing IP address as part of an address restructuring in the network. 

Attention: 

If allow has been selected in one of more select lists, a client must fulfill the allow settings for at least 

one of these to receive an IP address. If at least one deny setting applies to a client, the client will 

not be assigned an IP address, even if other allow settings would permit this.

4.5.10.5 DHCP host 


A DHCP host entry is used to make the DHCP service aware of the respective computer. A computer may 

be treated differently depending on whether it is known to the DHCP service or not. Moreover, only known 

computers can receive fixed IP addresses from the DHCP service. Unknown computers only receive 

variable IP addresses. 

DHCP host entries are normally added automatically when a computer is added via the computer wizard 

or the navigation. Below the DHCP service object you have the possibility of adding DHCP host entries 

or editing existing entries manually, irrespective of whether they were created manually or automatically. 

A DHCP host object must be created below a DHCP service object. 


Hostname (*) 

This entry field contains the name for the host. The computer usually also has a computer object 

entry in computer management. It is recommended to enter the same name and the same MAC 

address for the computer in both entries to facilitate assignment. 

Type (*) 

The type of network used can be selected here. 

Attention: 

The FDDI network type is not currently supported by DHCP. 

Address (*) 

The MAC address of the network adaptor is entered in this input field, e.g. 2e:44:56:3f:12:32 or 

2e-44-56-3f-12-32. 

’Fixed IP adresses’ tab 

Fixed IP address 

One or more fixed IP addresses can be assigned to the computer here as required. Alongside an IP 

address, a FQDN can also be entered, which will be resolved into one or more IP addresses by the 

DNS server. 

The following parameter is often determined on this level. It is then applicable for this computer: 

• Boot server on the [Boot parameters] tab 

4.5.10.6 DHCP shared network 

DHCP shared network objects accept subnets which use a common physical network. A DHCP shared 

network object must be added below a DHCP service object. 

107


Attention: 

A shared subnet should be entered in the shared network under all circumstances as otherwise the DHCP 

server will terminate and needed to be restarted if it finds an empty shared network in its configuration. 


Shared network name (*) 

A name for the shared network should be entered in this input field. The name must begin with a 

letter (a to z). The remaining characters of the name may contains the letters a to z, numbers 0 to 9, 

full stops, hyphens and underscores. 

4.5.10.7 DHCP shared subnet 

Subnets are declared as DHCP shared subnet when they use the same, common physical network. 

All subnets which use the same network should be stored below the same shared network container. A 

separate DHCP shared subnet object must be created for each subnet. DHCP shared subnet objects 

are exclusively available below the DHCP shared network objects. 

4.5.11 Policies 

Policies are a means of simplifying administration by passing on configuration settings to objects which 

are linked to the corresponding policies or to objects subordinate to the objects linked to said policies. 

If an object is linked to a policy, the statements of the policy are applied to the object. For example, the 

configuration of a graphic user interface can be defined by a policy for a certain client model, and the client 

object can be linked to the policy. The values set by the policy are then also valid for this client. 

In the same way, the values set by a policy in a superordinate container, will be valid for all objects within 

this container. This mechanism is called inheritance. 

If, for example, the same password interval is to be defined for all users of a location, then a special 

container can be created for these users. After moving the users into the container, a password policy can 

be linked to the container. This policy is valid for all user objects within the container. 

For every object, the applied value is always that which lies closest to the object in question. The values 

of superordinate policies can be overwritten by the values of subordinate policies. Thus it is possible to 

define, for example, an alternative keyboard layout for an individual client object, even if the superordinate 

policy defines a different keyboard layout. 

An exception to this rule is a value which was defined in a policy in the form of Fixed attributes. Such 

values cannot be overwritten by subordinate policies. 

The mechanisms of linking objects to policies, of inheriting and defining individual values, are an extensive 

and flexible way of achieving comfortable and central methods of configuring and administrating a UCS 

domain. 

108

4.5.11.1 Adding a policy 


Univention Directory Manager allows direct as well as indirect creation of policies. When directly creating 

a policy, the user can use the LDAP Browser to jump to the desired location within the LDAP directory and 

select the desired type of policy via the select list Add new object at current position. 

Alternatively, new policies can be directly created via the policies wizard (Policies ➞ Add). After having 

selected the desired type of policy and the target container, the new values of the policy can be entered. 

Policies can also be indirectly created via Univention Directory Manager by filling in or editing a tab for an 

object if the caption of the tab is set in square brackets, and Select configuration is available (see chapter 

4.5.11.4). The values adapted on these tabs are stored as policies. 

By default, policies are stored in the container policies which was automatically generated during the 

creation of the domain. For further structuring, the container policies includes containers for each policy 

type. 

When adding or editing objects, policies of a suitable type are available from the registered policies con- 

tainers in the select list Select configuration on the relevant tab. 

Attention: 

It has to be ensured that the container wherein a policy is created, is registered as a standard container 

for policies (see chapter 4.5.12.7). Otherwise, the policy will not be found. The automatically generated 

container policies is already registered as a standard container for policies. 

Settings, which can be made for the different types of policies, will be explained together with the tabs 

of the corresponding objects. When directly adding a policy, the entry field Name is displayed, wherein 

a random name for the policy can be entered. Furthermore, an Object tab will only be displayed when 

directly creating or editing a policy. 

’Object’ tab 

This tab is available for every policies object. It enables the user to make settings relating to object 

classes and attributes. 

Required object classes 

Object classes can be stated here, to which the objects have to belong so that they can be linked to 

this policy. 

Prohibited object classes 

Object classes can be stated here, to which the objects to be linked with this policy may no belong. 

Fixed attributes 

Attributes can be selected here, the values of which may not be changed by subordinate policies. 

Empty attributes 

Attributes can be selected here, which are to be set to empty in the policy, meaning they will be 

stored without containing a value. This can be useful for removing values inherited by an object 

109


from a superordinate policy. In subordinate policies, new values can be assigned to the attributes in 

question. 

Attention: 

If one of the entry fields of a subordinate policy remains empty, this means that the value of the superordi- 

nate policy is adopted unchanged. To make sure that the value of the superordinate policy is not valid in 

subordinate objects, the appropriate entry field is to be declared in Empty attributes in the Object tab. 

4.5.11.2 Applying policies 

Policies can be linked to container objects via the Policies tab. With other objects, the appropriate policy 

types are available on the individual tabs, where an existing policy can be selected or a new policy created 

for the object. 

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 link a policy to the root of the 

LDAP directory, which is then valid for all the objects of the domain which can apply this policy. Objects 

which cannot apply this policy are not affected. 

Attention: 

To every object which is linked to a policy, the current settings of this policy always apply. Thus, when 

editing a policy, the settings for all the objects linked to this policy are changed! The values from the 

changed policy apply to objects already registered in the system and linked to the policy, in the same way 

as to objects added in the future. 

The Referencing objects tab of the policies objects shows a list of all objects linked to the policy. 

4.5.11.3 Linking policies to containers 

110 


This tab is available for containers, organisational units and domains. It shows the policies currently 

linked to the object (see Illustration 4.11). The tab offers the possibility to edit the settings of a policy, 

and to link the changed settings to the objects as a new policy. Furthermore, linked policies can be 

unlinked from the object. 

In the first column, all the available policy types are listed. The second column states which concrete 

policy of the relevant type is valid for the present object. In this context, inherited means if any 

policies are set for superordinate objects, the present object will inherit these policies. 

Inheritance works over a random number of levels. The superordinate object can therefore have in- 

herited the policy from the next higher object. Inherited is the standard setting. Inherited is displayed 

even if none of the superordinate objects has a policy assigned. This circumstance is illustrated in


Illustration 4.11 which shows the Policies tab for the domain, i.e. the root of the LDAP directory of a 

typical UCS installation. 

Inheritance cannot be switched off directly. Yet, the object can be linked to a new policy in which the 

fields can be freely defined, meaning they can also be defined as being empty. 

To link the object to another/new policy, the appropriate policy type has to be clicked on the Policies 

tab. Another tab will then open where the settings for the policy can be made. Alternatively, an 

existing policy can be selected from the Select configuration list (see chapter 4.5.11.4). 

After confirmation by clicking [OK], the new settings are adopted, unless the editing process as a 

whole is aborted. A new or changed policy is stored under a unique name which is derived from 

the name of the container (see chapter 4.5.11.4). The original settings are retained unchanged if 

[Cancel] is clicked. 

To unlink a policy from its present object, the checkbox behind the policy is to be ticked first. If the 

user then clicks [Disconnect], Inherited will be displayed on the tab instead of the previous policy. 

The unlinking process is confirmed by clicking [OK]. 

4.5.11.4 Linking policies to other objects 

Square brackets on a tab indicate that the settings on this tab can be performed via policies. 

The Select configuration list shows existing policies which can be applied to the present position. The 

preset configuration is Inherited in which the configuration parameters of the superordinate container are 

adopted for the current object. 

Once a configuration has been selected, the values resulting from the policy will be displayed in the 

corresponding fields on the tab. Greyed-out values cannot be changed. All values displayed in black 

lettering as well as all empty fields can be adjusted at random. 

A new policy is generated by Univention Directory Manager from the new values. A container for each 

policy type is prepared in the policies container. The policies generated by Univention Directory Manager 

are automatically stored in these containers. 

A policy generated by Univention Directory Manager is named after the object for which it was created. If 

there is already a policy of the same name, the suffix _uv0 will be appended to the name of the new policy. 

Further policies with conflicting names will be numbered consecutively, by the endings _uv1, _uv2, etc.. 

The policy can be found under this name in the container for the corresponding policy type. If one of the 

existing policies is changed, these changes will affect all objects to which the policy in question is applied. 

If, in contrast, a value is changed via the Policies tab of the object for which the policy was created, a new 

policy will automatically be created with the changed values, and the original policy remains unchanged. 

So, the new values apply only to the present object and, if applicable, to subordinate objects. 

111


4.5.11.5 Policy-based tabs 

112 

’[Autostart]’ tab 

This tab is only available on thin clients, managed clients and mobile clients. 

Thin clients can be operated without a log-in mask to start a Citrix client automatically and exclusively 

every time the computer is switched on, for example. 

Autostart session 

The name of the autostart script should be entered here which should be started the next time 

the client is started. An autostart script is a shell script in which programs are entered which 

are started each time the user autostart logs in automatically. This script must be saved un- 

der /var/lib/univention-client-root/etc/gdm/Autostart/ on the thin client’s terminal 

server. On a managed or mobile client it is saved under /etc/gdm/Autostart/. 

Examples for integrating the Citrix client, nxclient or rdesktop in autostart scripts can be found 

on a UCS server with installed thin client infrastructure package (univention-thin-client) under 

/var/lib/univention-client-root/etc/gdm/Autostart/. 

’[Boot parameters]’ tab 

A DHCP boot policy can be used to assign computer configuration parameters for booting from a 

server. Changes values are used as of the next time which the respective computer is started. 

Attention: 

As thin clients can not boot without these parameters, Univention Corporate Server already includes 

a DHCP boot policy. As the boot server is not set in this policy, the client uses the DHCP server from 

which it retrieves its IP address as its boot server. The pxelinux.0 file is entered as the boot file as 

standard. The policy is linked with the ldap base so that it applies automatically for all thin clients in 

the domain, in so far as nothing else has been defined closer to the client object. 

Computers which are not booted from the server, but rather start from a locally installed operating 

system, do not require this input. The inputs are ignored by these computers. 

Boot server 

The IP address or FQDN of the boot server from which the client should load the boot file should be 

entered in this input field. If no value is entered in this input field, the client boots from the DHCP 

server from which it retrieves its IP address. 

Boot filename 

The path to the boot file is entered here. The path must be entered relative to the base directory of 

the TFTP service.


The directory to be shared is entered as a parameter when starting the TFTP service. If this case 

the path to the boot file should be entered relative to the /var/lib/univention-client-boot 

directory. 

If the required file is called linux.0 and stored in the directory 

/var/lib/univention-client-boot/kernel/, Boot filename the path kernel/linux.0 

must be entered in the input field. 

’[Client devices]’ tab 

This tab is only found on thin client computers. 

Activate access to client devices 

Selecting this checkbox allows access from this thin client to peripherals such as CD-ROM and disk 

drives connected to this thin client. 

’[Univention Configuration Registry]’ tab 

Detailed information on the policy-based inheritance of Univention Configuration Registry variables 

can be found in Chapter 14.9. 

’[Desktop settings]’ tab 

The appearance of the KDE Linux interface can be configured for the user on this tab. 

Desktop language 

The user’s KDE language setting. 

Attention: 

For the selection to take effect, the corresponding KDE language package must be installed on the 

computer - on the terminal server for thin clients. 

Desktop profile 

A profile which stipulates the appearance of the KDE Linux interface for the user. The profiles entered 

in the univention container in the default object are available for selection (see Chapter 4.5.12.6 and 

[10]). 

Logon scripts 

The script entered here is run during the user’s KDE log-in. 

113


114 

Attention: 

For the selection to take effect, the corresponding file must be executable on the computer - on the 

terminal server for thin clients. 

Logout scripts 

The script entered here is run when the user logs out of the KDE session. 

Attention: 

For the selection to take effect, the corresponding file must be executable on the computer - on the 

terminal server for thin clients. 

’[DHCP Allow/Deny]’ tab 

Attention: 

The keyword ignore used in the tab is only different from deny in that it prohibits the logging of denied 

requests. 

Unknown clients 

If allow is selected from the list, the DHCP service also issues IP addresses to clients which do not 

have a DHCP computer entry. If on the other hand deny or ignore is selected, the DHCP service 

does not issue IP addresses to unknown clients. 

It is recommended not to perform this setting globally or on the subnet level, but rather at the pool 

level. (see Advanced tab in DHCP:Pool objects on page 105). 

BOOTP 

When nothing or allow is selected from the list, the DHCP replies to BOOTP requests, otherwise it 

does not reply to these requests. 

Booting 

This input stipulates whether requests (from a particular client) are replied to (no selection or allow) 

or not (deny or ignore selected) by the DHCP service. If the DHCP service does not reply, the client 

is not assigned an IP address. The setting is usually only made directly for a DHCP computer object. 

Duplicates 

When nothing or allow is selected in this list, the DHCP service allows clients to receive a new lease 

and keep existing leases which belong to the same MAC address. 

If the entry deny is used and the MAC address of the client submitting the request matches a DCP 

computer entry, the DHCP discards all leases which match the same MAC address. This action is a 

breach of the DHCP protocol, but can avoid the case of clients with a client identifier which changes 

often receiving many leases at the same time.

Declines 


If nothing or allow is selected in the list, the DHCP service accepts DHCPDECLINE messages from 

the client. The client sends these messages when it deems the proffered IP address invalid. The 

DHCP service then gives this IP address the status abandoned and does not use it for a certain 

period of time. A defective or malicious client can exhaust the pool of free addresses by sending 

DHCPDECLINE messages excessively. If deny or ignore is selected, the DHCP service ignores 

these messages. 

’[DHCP DNS]’ tab 

Domain name 

Name of the domain which the client automatically hangs on computer names that he send to the 

DNS server for resolution and which are not fully qualified domain names. Usually this is the name of 

the domain to which the client belongs. 

Domain name servers 

IP addresses or fully qualified domain names for DNS servers can be added here. When using fully 

qualified domain names ensure that the DHCP server can resolve them to IP addresses. The DNS 

servers are contacted by the clients according to the order specified here. It can thus be practical to 

reorder the DNS servers specified. 

’[DHCP Dynamic DNS]’ tab 

Settings for dynamic DNS updates can be performed on this tab. For technical reasons these cannot 

yet be performed with a UCS-based DNS service, but only with external servers. 

DDNS hostname 

As standard, the DHCP service uses the computer name delivered from the client for DDNS updates. 

If a string is entered in this input field, this is used instead of the delivered computer name. 

DDNS domain name 

The domain name entered here is used together with the client’s computer name to compile a fully 

qualified domainn name. 

DDNS reverse domain name 

The domain name entered here is hung onto a reversed IP address to compose a name for a pointer 

record (PTR record). If no domain name is entered, the standard value in-addr.arpa. is used. 

DDNS updates 

If this setting is set to on, the DHCP service attempts a DNS update if a lease is confirmed. No 

update is performed when off is selected. The standard setting is on. 

115


116 

DDNS update style 

There are currently two DNS update patterns available: the ad-hoc DNS update mode (ad-hoc) and 

the interim DHCP-DNS interaction draft update mode (interim). The ad-hoc mode is now outdated 

and should no longer be used. Attention: 

This setting is evaluated once by the DHCP service when importing the configuration. It is thus not 

possible to stipulate the update style for each client individually. 

DDNS Forward Updates 

If the True value is selected, the DHCP service updates the DNS computer entry (A record) if a DHCP 

client requests or renews a lease. No update is performed if the setting is set to false. This input 

only applies when DNS updates are activated and the DDNS update style is set to interim. DDNS 

forward updates are performed as standard. 

Update static leases 

If the True value is selected, the DHCP service performs DNS updates, even when they are assigned 

a static IP address. No update is performed if the setting is set to false. This input only applies when 

DNS updates are activated and the DDNS Update Stil is set to interim. 

Client updates 

When the Allow value is selected, the DHCP service notes the intention of the DHCP client to update 

its own DNS computer entry (A record). This input only applies when DNS updates are activated and 

the DDNS Update Stil is set to interim. 

’[DHCP lease time]’ time 

Default lease time 

If the client does not ask for a specified lease time it will be assigned the standard lease time. If this 

input field is left empty, the DHCP server’s default value is used. That is 43200 seconds (12 hours). 

Maximum lease time 

The maximum lease time specifies the longest period of time for which a lease can be granted. If this 

input field is left empty, the DHCP server’s default value is used. That is 86400 seconds (24 hours). 

Minimum lease time 

The minimum lease time specifies the shortest time for which a lease can be valid. If this input field 

is left empty, the DHCP server’s default value is used. That is one second.

’[DHCP NetBIOS]’ tab 

NetBIOS name servers 


Also called NBNS or WINS servers. The names or IP addresses of the NetBIOS name servers are to 

be entered here. It must be verified that the DHCP server can resolve these names in IP addresses. 

The servers entered are contacted by the client in the order in which they stand in the selection list. 

NetBIOS scope 

The NetBIOS over TCP/IP scope for the client according to the specification in RFC1001 and 

RFC1002. 

Attention: 

Attention must be paid to uppercase and lowercase when entering the NetBIOS scope. Further 

information on the character set to use can be found in RFC1035. 

NetBIOS Node Type 

Dieses Auswahlfeld legt den Node Type eines Clients fest. Mögliche Werte sind: 

• 1 B node (Broadcast: no WINS) 

• 2 P node (Peer: only WINS) 

• 4 M node (Mixed: first Broadcast, then WINS) 

• 8 H node (Hybrid: first WINS, then Broadcast) 

’[NFS mounts]’ tab 

This policy can be used to configure NFS shares mounted on the server or client. There is a NFS 

Share for selection, which is mounted in the file path specified under Mount point. 

’[DHCP routing]’ tab 

Routers 

The names or IP addresses of the routers are to be entered here. It must be verified that the DHCP 

server can resolve these names in IP addresses. The routers are contacted by the client in the order 

in which they stand in the selection list. 

Attention: 

Routers usually have several network interfaces each with its own IP address. If the name of the 

router is entered instead of the IP address, it must be verified that the name definitely points to the 

required network interface on the router! 

117


118 

’[DHCP statements]’ tab 

Authoritative 

This selection controls the sending of DHCPNAK messages to incorrectly configured clients. 

Attention: 

The Yes setting should only be selected if the consequences of this setting can be estimated and the 

DHCP service has been correctly configured! 

The Yes setting prompts the DHCP service to send a DHCPNAK message to each incorrectly con- 

figured client. If this is not done, clients are not in a position after changing subnets (e.g., notebooks) 

to receive a correct IP address until their old lease has expired. This can take some time. 

If nothing or no is selected, the DHCP service does not send any DHCPNAK messages. This is 

the standard procedure for the DHCP service and should avoid any problems with an insufficiently or 

incorrectly configured DHCP service. 

Setting the setting is only practical for physical network segments. The setting should be made for 

a DHCP shared network or a DHCP subnet. The setting should be avoided for a DHCP shared 

subnet and DHCP pool- and DHCP host objects! 

Boot unknown clients 

If True is selected from the list, the DHCP service also issues IP addresses to clients which do not 

have a DHCP computer entry. The prerequisite for this is that an appropriate pool of IP addresses 

is set up. Limits to the issuing of IP address made on the DHCP pool object are taken into account 

here. If the entry False is selected, the DHCP service does not issue IP addresses to client which do 

not have a DHCP computer entry. 

This setting is overwritten at DHCP pool level by the settings on the Advanced tab. 

Ping check 

If nothing or True is selected, the DHCP server uses a ping to check whether an IP address is free 

before issuing it dynamically. This delays the reply to the client by a second. If this represents a 

problem for the client submitting the request, the setting No should be selected here. The availability 

check via the ping is then not performed and the DHCP server replies immediately. 

Add hostnames to leases 

If True is selected from the lst, the DHCP server resolves all IP addresses for which this input applies 

into the respective computer name in the DNS domain and uses it for the hostname DHCP option. If 

nothing or False is selected, the DHCP server does not use the DNS domain names. 

Server identifier 

The IP address of the server the clients should use to communicate with the DHCP server. This field


should only be filled out in justified exceptional cases. It must be ensured that the correct DHCP 

server is used if several servers are set in a DHCP service. 

Server name 

This name is provided to a client as the name of the server from which it boots. 

’[Display]’ tab 

This tab is only found on managed client, mobile client and thin client computers. This tab is used to 

configure the graphics adapter, monitor, keyboard and mouse for the computer. Changes are applied 

the next time the computer is started when there is a connection to the LDPA directory. 

Automatic detection 

When this option is activated, the drivers required for the graphics card are recognised automatically. 

If no suitable driver is available for the card, the VESA driver is used. The matching screen resolution 

for the connected monitor is also recognised and activated. 

Graphics adapter driver 

The appropriate driver for the graphics adapter can be selected from this selection list. 

Resolution of primary display 

The monitor resolution of the primary monitor is entered here. The values for width and height should 

be separated by a x. 

Example: 

1024x768 

Resolution of secondary display 

The monitor resolution of a secondary monitor, if used. Combined with the primary monitor a shared 

screen is displayed. 

Position of secondary display 

This selection specifies the relative position of the secondary monitor with respect to the primary 

monitor. 

Color depth 

The colour depth should be entered in bits per pixel. Admissable values are 1, 2, 4, 8, 16 and 24. 

Mouse protocol 

A number of different mouse protocols are available for using a mouse. 

• Auto usually chooses the correct protocol for the mouse used automatically. 

• IMPS/2 is used for mice with a wheel on the PS/2 connection. 

119


120 

• PS/2 is used for simple mice on the PS/2 connection. 

• Serial is used for mice on the serial port (ttyS0 or ttyS1 and in Windows/DOS COM1 or COM2). 

• USB is required for USB mice. 

In addition there are also further special mice protocols available: 

ExplorerPS/2, ThinkingMouse, ThinkingMousePS/2, NetScrollPS/2, Intellimouse, NetMousePS/2, 

GlidePoint, GlidePointPS/2 and MouseManPlusPS/2. 

Mouse device 

The connection where the mouse is connected to the computer is selected here. PS/2, Serial and 

USB are available for selection. 

Keyboard layout 

Selecting the country activates the conventional keyboard layout for this country on the computer. 

This includes Germany for a German and United States for an English layout. There is also the 

possibility of not performing any settings pertaining to the keyboard layout. 

Keyboard variant 

At this point a keyword can be entered to select the keyboard layout variant. German keyboard 

layouts usually use the nodeadkeys variant. This has the effect that particular special accents such 

as the tilde “~” can be entered by simply pressing the key. Nevertheless, the accent can then not be 

written over another character. In the basic variant, the key for the accent must be pressed and then 

the key for character above which the accent should appear. For example, to write the word “senor” 

with the letter “ñ”, the tilde must be pressed first followed by “n”. To insert a tilde on its own, the tilde 

is pressed first followed by the spacebar. 

Enable VNC export 

The option allows administrators to access the graphic interface of the computer and take over control 

of the mouse and keyboard if the user allows this by confirming a security dialog. This option is used 

for example in troubleshooting if a user finds himself in a situation he cannot follow or he cannot rectify 

on his own. This option is deactivated as standard. 

This policy is only evaluated with thin clients. 

Viewonly VNC export 

This option allows administrators to view the user’s desktop without being able to change anything 

via keyboard inputs or mouse movements. A security dialog is displayed which the user must confirm 

in order to grant the administrator access. This option is activated as standard. 

This policy is only evaluated with thin clients.

RAM on the graphics adapter in kb 


If the graphics driver does not recognise the amount of graphics memory, the correct size of the RAM 

on the graphics card can be entered in this input field. This is entered in kilobytes. 

Virtual size of dual monitor desktop 

The graphics interface can also be displayed on two monitors. The attained display size of the virtual 

desktop must be specified in advance. This is calculated by adding together the screen dimensions; 

for example, if two monitors with a resolution of 1024x768 pixels are operated next to each other, the 

size of the virtual desktop will be 2048x768. The setting must be given in the x y format, i.e., with 

a blank space as a separator, e.g., 2048 768. This setting usually does not need to be specified, 

but rather is calculated from the settings for Resolution of primary display and Resolution of 

secondary display. 

Name of primary display 

The X-11 internal identifier for the primary monitor, e.g. LVDS or VGA. The device name varies de- 

pending on the model of the graphics card and can be ascertained by running the xrandr command. 

If there is no identifier specified here, the identifier is auto-detected in the GDM init script. 

Display size (mm) of primary display 

If the measured length of the diagonal screen size is entered the monitor resolution (dpi) can be 

calculated automatically. The entry is made in XxY format in millimetres. 

This setting is only applied if the Name of primary display has been set. 

Horizontal sync of primary display 

The horizontal line frequency of the monitor should be given as a single number or as a range in kHz. 

When entering a range, the two values should be separated by a minus sign, e.g. 30-70. 


Vertical refresh of primary display 

The vertical line frequency of the monitor should be given as a single number or as a range in Hz. 



Name of secondary display 

The X-11 internal identifier for the secondary monitor, e.g. LVDS or VGA. The device name varies de- 

pending on the model of the graphics card and can be ascertained by running the xrandr command. 

If there is no identifier specified here, the identifier is auto-detected in the GDM init script. 

121


122 

Display size (mm) of secondary display 

If the measured length of the diagonal screen size is entered the monitor resolution (dpi) can be 

calculated automatically. The entry is made in XxY format in millimetres. 

This setting is only applied if the Name of secondary display has been set. 

Horizontal sync of secondary display 

The horizontal line frequency of the monitor should be given as a single number or as a range in kHz. 



Vertical refresh of secondary display 

The vertical line frequency of the monitor should be given as a single number or as a range in Hz. 



’LDAP server’ tab 

LDAP server 

The computer uses the LDAP server specified here for requests to the LDAP directory. The order of 

the servers determines the order of the computer’s requests to the server if a LDAP server cannot be 

reached. 

’[Mail quota]’ tab 

Quota limit (MB) 

The maximum size of the mailbox of a user in megabytes. If this limit is reached, no further mails 

will be delivered to the mailbox until the user provides storage place by deleting older mails from his 

account. 

’[Maintenance]’ tab 

This option is used to control the time for (un)installation or packages and system updates. 

System startup 

If this option is activated, the packages selected on the Packages [. . . ] tab are (un)installed when 

the computer is started.

System shutdown 


If this option is activated, the packages selected on the Packages [. . . ] tab are (un)installed when 

the computer is shutdown. 

Reboot after maintenance 

This option makes it possible to perform an automatic system restart following a UCS update. The 

following values are available for selection. 

• No Reboot: the boot process is continued as normal following the update. The restart must 

then be initiated manually. 

• Immediately: the system restart is performed directly after the update 

• specifies the time between 15 minutes (00:15) and 23 hours and 45 minutes (23:45) between 

Attention: 

the update and the automatic system restart. 

When the system restart is activated, the restart only occurs after a UCS update to a higher version 

number. No restart is initiated after (un)installation of individual packages! 

Use Cron settings 

If this field is activated, the fields Month, Day of week, Day, Hour and Minute can be used to 

specify an exact time when the new package should be (un)installed. 

’[Packages . . . ]’ tab 

This tab is available for every UCS system type apart from thin clients. 

This option can be used to create a list for packages to be installed or uninstalled to facilitate the main- 

tenance of installed software packages. These lists are processed by the system affected (managed 

client, mobile client, member server or domain controller) at the next (un)installation interval. 

This tab is directly linked to the Maintenance tab where the (un)installation time can be set. 

Package list 

The package list containing the required package is selected here. Package lists can be managed 

via a Settings: Package list object (see Chapter 4.5.12.9). 

Package installation list 

Once the required package has been selected it can be added to the installation list. Any number of 

packages can be installed subsequently in this way. 

Package removal list 

The package to be uninstalled is to be selected here. 

123


124 

’[Passwords]’ tab 

Intervals for change or expiry of passwords can be specified on this tab. 

History length 

The number of passwords stored for the user. The user may not utilise any of these passwords as 

a new password. Example: If the number 3 is entered in this field, the last three passwords will be 

barred from being accepted as new passwords. 

Attention: 

The passwords are not stored retroactively. Example: If ten passwords were stored, and the value 

is reduced to three, the oldest seven passwords will be deleted during the next password change. If 

then the value is increased again, the number of stored passwords initially remains at three, and is 

only increased by each password change. 

Password expiry interval 

The interval (in days) after which the user has to change his password. 

Password quality check 

If this option is activated, additional checks - including dictionary checks - are performed for pass- 

word changes in Samba, Univention Directory Manager and Kerberos. The configuration is done via 

Univention Configuration Registry and should occur on all login servers. The following checks can be 

enforced: 

• Minimum number of digits in the new password (password/quality/credit/digits). 

• Minimum number of uppercase letters in the new password (password/quality/credit/upper). 

• Minimum number of lowercase letters in the new password (password/quality/credit/lower). 

• Minimum number of characters in the new password which are neither letters nor digits 

(password/quality/credit/other). 

• Individual characters/digits can be excluded (password/quality/forbidden/chars). 

• Individual characters/figures can be made compulsory (password/quality/required/chars). 

Password length 

The minimum number of characters of which a user password is to consist. If no value is entered 

here, the minimum size is eight characters. 

Attention: 

The default value of eight characters for password length is fixed in Univention Directory Manager, so 

it always applies if no policy is set and the checkbox Override password length is not ticked. This 

means it even applies if the default settings password policy were deleted.

’[Print quota]’ tab 

Attention: 


The ’Print quota’ component need to have been selected during installation or installed by running 

the univention-system-setup-software in order to be able to calculate print quotas and print 

costs. 

Print quota for users 

A print quota is established for the user selected here. 

Soft-Limit (Pages) 

If a user reaches the number of pages entered here, he receives a warning message per e-mail that 

his print contingent is almost exhausted. The limit is removed by entering 0. Further information can 

be found in Chapter 13.5.2. 

Hard-Limit (Pages) 

If a user reaches the number of pages entered here, all further print jobs from this user will be denied. 

Only an administrator can reactivate the user’s contingent. The limit is removed by entering 0. Further 

information can be found in Chapter 13.5.2. 

Print quota for groups per user 

The soft limit and hard limit are set for every user of the group specified here. The quotas are 

evaluated for each user individually. 

Print quota for groups 

The group specified here is assigned a common contingent. All users belonging to the group can use 

this contingent. 

If more than 200 users or groups are found, or if the search in the LDAP directory takes longer than 

ten seconds, an input field will be displayed instead of the select list, in which the user name or group 

name is to be entered. 

’[Print server]’ tab 

Print server 

The name of the print server whose printer the computer should use can be entered here. 

’[Release]’ tab 

Activate policy 

If this field is activated, the computer performs an automatic system update. Release version is 

used to specify to which version number the update should go. If this field is not activated, there is no 

125


automatic system update. 

Release version 

This input field contains the version number where the system update should stop. The system stops 

at the version number given there and doesn’t import any updates with a higher version number 

automatically. If no entry is made, the system continues updating to the highest available version 

number. 

’[Repository server]’ tab 

Repository server 

The computer retrieves its installation packages from the repository server entered in this input field. 

’[Repository synchronisation]’ tab 

This tab is only available on UCS server systems. 

Repository syncronisation settings 

The fields Month, Day of week, Day, Hour and Minute can be used to specify an exact time when 

repository synchronisation should be performed. 

’[Sound]’ tab 

This tab sets up the sound output. It is only shown on thin client computers. 

Sound enabled 

Selecting this checkbox activates sound support. As standard sound support is not activated. 

Sound module 

Normally the setting auto detect provides an appropriate driver module for sound support automat- 

ically. Alternatively, a driver module for the sound card can be specified manually in the selection 

list. 

126 

’[Thin client]’ tab 

This tab is only found on thin client computers. Changed values will apply from the next time the thin 

client is booted. Some input fields require a server to be specified. To avoid problems during the 

resolution of names, the fully qualified domain name should always be entered. In addition, it must 

be verified it can be resolved in an IP address. 

Authentication server


The users who log on to this thin client authenticate themselves on the servers specified here. 

If nothing is entered here and a user tries to log on, the system establishes all Kerberos servers using 

service records in the DNS. The system then attempts to authenticate the user using one of these 

Kerberos servers. 

File server 

The file server for the thin client can be entered and edited here. The /home directory is mounted 

on the thin client from this server when a user logs on, for whom no mountable share is defined (see 

also POSIX (Linux/UNIX) tab in Chapter 4.5.1 on page 58). If a mountable share is entered for the 

user, it is mounted. There is no need to enter the file server if a mountable share is entered for all 

users. Users can not log on without a mounted home directory. 

Attention: 

If the user data should be saved on the file server by the Linux terminal server, the file server must 

be mounted on the terminal server manually! It goes without saying that this is not necessary when 

the terminal server and the file server are in fact the same computer. Windows terminal servers find 

out where a user’s home directory is via the log-in server. 

If more than one file server is entered the thin client tries to connect the file server at the top in the 

Entries list first. If this fails, it tries the next one, etc. 

Linux terminal server 

One or more Linux terminal servers can be added or edited here for the thin client. 

A Linux terminal server is a server which provides the programs for the Linux workstation on which 

the Terminal services component is installed. 

The decision of which server is used when multiple entries exist is taken automatically by UCS using 

a load balancing mechanism. 

Windows terminal server 

If the users should be provided with a Windows environment on this thin client, a server must be 

entered in this input field which is to provide this Windows interface. 

If several Windows terminal servers are entered, the first one in the list will be used. 

Windows domain 

If the users should be provided with a Windows workstation on this thin client, the name of the 

Windows domain where the user is registered is to be entered in this input field. 

127


128 

Attention: 

As standard, a default-settings policy is created, which is valid for the whole domain. Computers on 

which the Terminal services component is installed enter themselves automatically as Linux terminal 

servers in the policy when a domain is joined; computers on which the univention-nfs package is 

installed enter themselves as file servers. The package is installed on all UCS servers (DC masters, 

backups and slaves) as standard. 

’[Univention Directory Manager View]’ tab 

This tab is explained in chapter 4.6. 

’[User quota]’ tab 

Detailed information about quota can be found in the UCS quota documentation under [11]. 

User quota can be configured according to the quantity of files or the space occupied by files. Quota 

limits are set for users during registration. 

The following settings apply for all users of a directory share; it is not possible to establish different 

quota settings for different users in one share. 

Illustration 4.12: 10 MB soft limit and 20 MB hard limit for all directory shares in the 

container shares 

Changes to the quota limit only apply to users when they re-login after the change is made. Users for 

whom quotas are already set are not affected by the changes. Quotas for these users can be edited


and listed with the Linux commands setquota and repquota. Further information can be found in 

the UCS quota documentation under [11]. 

Alternatively, group-based assignment is possible via univention-quota-group. The use is also 

described in the documentation mentioned above. 

Soft limit (Bytes) 

The disk space in bytes at which the user is requested to free up disk space (as standard within seven 

days). 

Hard limit (Bytes) 

The maximum disk space in bytes which each user can occupy permanently in this share. 

Soft limit (Files) 

The quantity of files at which the user is requested to free up disk space (as standard within seven 

days). 

Hard limit (Files) 

The maximum quantity of files which each user can save permanently in this share. 

’[Windows installation]’ tab 

This tab is only found on Windows computers. 

Filename of unattend installation profile 

The name of the unattend.txt file entered in this input field is used for the auto- 

matic installation of Windows on the computer. The file name is entered relative to the 

/var/lib/univention-windows-installer/install/policy. 

Ssyn 

4.5.12 Univention Directory Manager settings 

In the Univention settings container univention, configuration options for the behaviour of Univention 

Directory Manager are defined. 

4.5.12.1 License 

The container univention ➞license contains information on the scope of the currently installed licence. 

These entries are purely informative and cannot be changed with Univention Directory Manager. Instruc- 

tions on installing and updating licences can be found in chapter 3.4. 

129


’License’ tab 

Name (*) 

The Name of the licence object. 

Module (*) 

This field states the module for which the licence was granted. 

Expiry date (*) 

The date by which the licence becomes invalid. 

Base DN (*) 

The Base DN for which the licence was granted. The licence can only be used if the Base DN of the 

licence is identical to the Base DN of the LDAP directory. 

Max. user accounts 

The maximum number of user accounts covered by this licence. 

Max. groupware accounts 

The maximum number of groupware accounts covered by this licence. 

Max. clients 

The maximum number of clients covered by this licence. 

Max. desktops 

The maximum number of desktops covered by this licence. 

Valid product types 

The licence applies to the product types registered here. Product types not listed here are not covered 

by the licence and will not be activated by Univention Directory Manager. 

Signature (*) 

The digital signature of the licence. 

4.5.12.2 Printer driver lists 

As standard the printer driver lists for printer management are saved in the univention ➞cups container. 

New lists can be added here or existing ones edited. 

130


Name (*) 


The name of the printer driver list. The name under which the list appears in the Manufacturer 

selection list on the General tab for printer shares. 

Driver 

The path to the ppd file or to the /usr/share/cups/model/ directory. For example, if the 

/usr/share/cups/model/laserjet.ppd should be used, laserjet.ppd must be entered here. 

gzip compressed files can also be entered here. 

Attention: 

Ensure that printer drivers entered are saved on the respective printer server under the 

/usr/share/cups/model/ directory. 

Description 

A description of the printer driver, under which it appears in the Printer model selection list on the 

General tab for printer shares. 

4.5.12.3 Printer URI Lists 

When setting up a printer via Univention Directory Manager (see Chapter 4.5.7) the fields Protocol and 

Destination must be filled out. If the required protocol is not available in the displayed Protocol selection 

list, it can be added via a Printer URI List object. 

As standard the printer URI lists are saved in the univention ➞cups container. 


Name (*) 

The freely selectable name of the printer URI list. 

Printer URI 

One or more protocols can be entered in this field, which are then displayed in the Protocol selection 

field when setting up a printer, e.g ftp:// . 

4.5.12.4 User templates 

User templates can speed up the process of creating a user by presetting certain values. Predefined user 

templates can be found in the user administration under Add in the Select Template list. 

User templates can only be created beneath cn=univention,, and are stored in 

cn=templates,cn=univention, by default. 

131


User templates named following the pattern . Groupware Account are automatically 

provided for each Kolab home server during a Kolab for UCS installation. More detailed information 

can be found in the Kolab for UCS manual. Attributes can be included in the template by use of angle 

brackets. A list of possible attributes can be called by the command: 

univention-directory-manager users/user 

in the section users/user variables of the output. 

For example: A user-defined UNIX home directory can be created as /home/ - this corre- 

sponds to the standard if no user template is applied - or as /home/.. The e-mail 

address could, for example, be predefined by .@firma.com. 

Such replacements are generally possibly for any value, there is no syntax or semantics check. So, if no 

first name is given during the creation of a user, the above e-mail address would begin with a dot and would 

thus be invalid according to the e-mail standard. Similar sources of error can also occur when handling file 

paths etc. 

Irresolvable attributes are deleted. If due to a spelling error in a user template the e-mail address 

is predefined, for example, as .@firma.com, then the result will be .@firma.com. 

If only a single character of the attribute is required, the index of the required character can be given in the 

user template in square brackets after the name of the attribute. The count of characters of the attribute 

begins with 0, so that index 1 corresponds to the second character of the attribute value. Accordingly, 

[0].@firma.com means, an e-mail address will consist of the first letter of the 

first name plus the second name. 

A substring of the attribute value can be defined by declaring a scope within square brackets. In doing 

so, the index of the first required character and the index of the last required character plus one are to be 

entered. The input [2:5] returns the third to fifth character of the first name. 

Appending :lower or :upper to the attribute name converts the attribute value to lower or upper case, e.g. 

. 

Attention: 

If a user template is used for adding a user, this template will overwrite all the fields with the preset values 

of the template. In doing so, an empty field is set to ””. Thus, if the user template has ”” as the UNIX home 

directory, then this field is empty when the user is added, so that a value can be entered manually. If UCS 

standard behaviour is desired, the standard values documented in this chapter should be entered into the 

template. 

Detailed documentation of attributes configurable within a user template can be found in Chapter 4.5.1. 

4.5.12.5 Locked values 

The data contained in the temporary container are created and used on a program-internal basis exclu- 

sively. 

The values of some of the attributes have to be unique. If a certain value is to be set, a search within the 

LDAP directory will be performed beforehand in order to check whether the value is already in use. 

132


Values presently edited - and therefore not accessible for search - are locked during editing in order to 

ensure that these values are not used a second time. Such values are reserved for the editing process 

and cannot be utilised by any other process. Once editing is finished, the lock is lifted. 

In case of an error, a lock can sometimes persist by accident. To ensure an error-free operation, Univention 

Directory Manager automatically releases locked values after a maximum locking time (five minutes). 

Locked values are stored in the appropriate containers beneath the temporary container, and are checked 

and, eventually, deleted in Univention Directory Manager like any other objects. Manual deleting is not 

recommended except in special cases: 

• If, due to an error, the lock was not lifted, and the value is to be used again before the locking time 

is expired. In such a case, it has to be ensured that the persistence of the lock is indeed due to an 

error, and not just to the fact that another process has made access to the value in the meantime. 

• The lock was lifted, yet the locked object was not automatically removed from 

cn=,cn=temporary,cn=univention,. Such objects do not disturb 

the program flow, they will be overwritten by Univention Directory Manager as soon as the necessity 

arises. 


Name (*) 

The name of the locked object. The name corresponds to the value to be set as the attribute. 

Locked until 

The time (in seconds), from 1 January 1970 onwards, when the object is automatically released after 

the expiry of the maximum locking time. 

4.5.12.6 Default values 

Certain default values can be set in the default object. 


Name (*) 

The name of the object. The name is fixed and cannot be changed so the box is shown in grey. 

’Primary groups’ tab 

Default values for the primary groups of different object types can be set on this tab. 

’Default Primary Group’ tab 

A default value for the primary group of users, which should be entered in advance when adding a 

133


user object as the primary group of the user. As standard this is the Domain Users groups. 

’Default Computer Group’ tab 

The default value for the primary group for Windows computers, which should be selected in advance 

in the Machine account group selection list on the Machine account tab when adding a Windows 

computer. As standard this is the Windows Hosts group. 

’Default DC Master & Backup Server Group’ tab 

The default value for the primary group for domain controller master and domain controller backup 

computers. As standard this is the DC Backup Hosts group. 

’Default DC Slave Computer Group’ tab 

The default value for the primary group for domain controller slave computers. As standard this is the 

DC Slave Hosts group. 

’Default Member Server Group’ tab 

The default value for the primary group for member server computers. As standard this is the Com- 

puters group. 

’Default Client Computer Group’ tab 

The default value for the primary group for client computers. As standard this is the Computers 

group. 

’KDE Profiles’ tab 

Default KDE Profiles 

Absolute path to the profiles for the KDE graphic interface. The profiles are available when adding or 

editing a user on the [Desktop Settings] tab. 

As standard KDE profiles are saved in the /usr/share/univention-kde-profiles/ directory. 

The univention-kde-profile-builder program can be used to create packages from these 

profiles. The contained profiles are automatically saved in the standard directory during installation 

of these packages. Further information can be found in Chapter 9 bzw. [10]. 

4.5.12.7 Default containers 

Distinguished Names (DN), which have to be known within the system, are stored in the object default 

containers. These include, for example, the DNs of the containers which are offered by the search function 

for restricting the search area, or DNs required by Univention Directory Manager or other programs, such 

as the storage location of licences. 

134

The DNs of the predefined containers are registered here by default. 


To register a container as a standard container, the object default containers is to be opened in the 

univention container via the LDAP browser. There is a tab for each standard container type in this object, 

on which the list of standard containers can be edited. If, for example, the DN of a standard container for 

clients is to be added, then the Clients tab is to be selected, and the DN of the container to be defined as 

the standard container for clients is to be entered in the entry field standard client container. Alternatively, 

the DN can be entered automatically during adding or editing a container or an organisational unit (see 

chapter 4.5.8.1). 


Name (*) 

This field states the name of the object. For the standard container, this name is preset to default 

containers, and cannot be changed. 

’Users’ tab 

User Link 

The DNs of the containers to be used as standard containers for user objects, is to be entered here. 

’Groups’ tab 

Group Link 

The DNs of the containers to be used as standard containers for group objects, is to be entered here. 

’Computers’ tab 

Computer Links 

The DNs of the containers to be used as standard containers for client objects, is to be entered here. 


Policy Link 

The DNs of the containers to be used as standard containers for policy objects, is to be entered here. 

’DNS’ tab 

DNS Link 

The DNs of the containers to be used as standard containers for DNS objects, is to be entered here. 

135



DHCP Link 

The DNs of the containers to be used as standard containers for DHCP objects, is to be entered here. 

’Network’ tab 

Network Link 

The DNs of the containers to be used as standard containers for network objects, is to be entered 

here. 

’Shares’ tab 

Share Link 

The DNs of the containers to be used as standard containers for share objects, is to be entered here. 

’Printers’ tab 

Printer Link 

The DNs of the containers to be used as standard containers for printer objects, is to be entered here. 


Mail Link 

The DNs of the containers to be used as standard containers for mail objects, is to be entered here. 

’License’ tab 

License Link 

The DNs of the containers to be used as standard containers for licence objects, is to be entered 

here. 

4.5.12.8 Prohibited user names 

By adding a Settings: Prohibited user names object, a list of usernames can be defined, which may 

not be added by Univention Directory Manager. Thus the use of usernames can be prevented which, for 

example, already exist in a local password file. When migrating a Windows domain, user accounts with 

forbidden usernames are not migrated. 

136


Name (*) 

The name of the object which prohibits usernames. 

Prohibited user name 


A list of usernames, the use of which in Univention Directory Manager is to be excluded. 

4.5.12.9 Package lists 

Software packages for the distribution of software can be compiled in Settings: Package List objects. 

Package lists are stored in the packages container. More detailed information can be found in Chap- 

ter 11.3.4. 


Name (*) 

The name of the package list. 

Package list 

The names of the software packages should be entered in this field that are to be installed or unin- 

stalled via software distribution. 

4.5.12.10 Services 

With Settings: Service objects, preset values can be defined which specify whether a UCS system is to 

offer a certain system service. 

The default values defined here can be assigned to individual computers in computer management (see 

’Services’ tab in the Chapter 4.5.4). This is currently supported on the Univention groupware server 

systems for the Kolab service and Scalix service. 


Service name (*) 

The name of the service to be offered by a UCS system. 

4.5.13 User-defined attributes 

One of the targets when developing UCS is the possibility for the operator to extend the system. Therefore, 

on the one hand UCS utilises open standards such as LDAP, on the other hand especially developed 

interfaces are documented and designed for extendibility. In Univention Directory Manager, user-defined 

137


attributes offer a mechanism for assigning unused or newly created LDAP attributes to dialogue masks for 

objects managed by UCS, which can be freely configured. Furthermore, user-defined attributes make it 

possible to adjust existing settings. 

Creating user-defined attributes at the web front-end User-defined attributes are LDAP objects of the 

type Settings:Attribute which are stored in the LDAP directory under univention ➞custom attributes. 

All settings are stored in attributes of the object. 

138 


Name (*) 

The name of the LDAP object for storing the user-defined attribute. Within a container, the name has 

to be unique. In Univention Directory Manager, this name is used exclusively for the output of data 

via the command line interface. 

Required module (*) 

The Univention Directory Manager module which is to be extended by the user-defined attribute. 

The command univention-directory-manager modules can be used for displaying a list of 

all modules at the command line. Several modules can be added to the list via the Add button. For 

extending a group property, groups/group is to be entered here, for a user property, users/user. 

The major Univention Directory Manager modules are: 

Property of Univention Directory Manager"=Modul 

Users users/user 

Groups groups/group 

Computers computers/computer 

computers/domaincontroller_backup 

computers/domaincontroller_master 

computers/domaincontroller_slave 

computers/ipmanagedclient 

computers/macos 

computers/managedclient 

computers/memberserver 

computers/mobileclient 

computers/thinclient 

computers/windows

Tab name 


The name of the tab at the Univention Directory Manager web front-end. Names of tabs belonging to 

the standard scope of UCS can also be entered. It has to be considered that only the user-defined 

attributes are displayed on the tabs. The range of possible settings in Univention Directory Manager 

can thus be extended or restricted. Some attributes, e. g. the expiry date of the password or the 

group membership, cannot be handled by user-defined attributes. 

Number on tab 

If several user-defined attributes are to be managed on one tab, the position of the individual attributes 

on the tab can be influenced here. A random number of attributes can be displayed on one tab. 

Description 

Short Description (*) 

This entry will be used as the title of the entry field in the Univention Directory Manager web front-end, 

and for changing the value via the Univention Directory Managerr command line interface. Umlauts 

may not be used for the short description. 

Long description 

This extended description will be displayed in the Univention Directory Manager web front-end as a 

tool tip. 

Object classes 

Object Class (*) 

The object class to which the attribute entered on the LDAP Mapping tab belongs. Schema defi- 

nitions define which attributes are provided by an object class. Every LDAP object which is to be 

extended by an attribute, has to contain the object class to which the desired attribute belongs. 

Delete object class 

If the value of a user-defined attribute in Univention Directory Manager is deleted, the attribute is 

removed from the LDAP object. If no further attributes of the object class registered as Object Class 

are used in this LDAP object, then the object class will also be removed from the LDAP object if this 

option is activated. 

’LDAP Mapping’ tab 

Syntax 

The data type of the LDAP syntax in the schema definition of the value to be managed for this 

attribute. Apart from standard data types for strings and integers, there are two possibilities for 

expressing a binary condition: TrueFalse is represented internally by the strings true and false, while 

139


TrueFalseUpper corresponds to the OpenLDAP boolean values TRUE and FALSE. Additionally, it is 

possible to enter the name of a Univention Directory Manager syntax definition here. These definitions 

will be explained below. 

LDAP mapping (*) 

The name of the attribute where the values of the LDAP object are to be stored in. The attribute has 

to be included in the schema definition of the stated object class. 

Multivalue 

Specifies whether a single value or several values can be stored in the attribute. Permitted values 

to be entered are 1 for activated and 0 (default) for deactivated. The schema definition of the LDAP 

attribute specifies whether one or several instances of the attribute may be used in one LDAP object. 

Default value 

If a preset value is defined here, newly created objects will be initialised with this value. Existing 

LDAP objects remain unchanged. 

Univention Directory Manager syntax definitions The extended Univention Directory Manager syntax 

definitions make it possible to establish the permitted values for an attribute via an LDAP search. Moreover, 

user-defined attributes can be created the values of which are displayed for information purposes, but not 

stored, as a list at a foreign object (see, for example, the Referencing objects tab in chapter 4.5.11.2). 

The syntax definitions can be created via the LDAP browser of the Univention Directory Manager beneath 

the container cn=univention. 

For creating a new syntax definition, a new object of the type Settings: Syntax Definition is to be created 

in the desired container. In the subsequent dialogue, the following values are to be entered: 

140 


Syntax name (*) 

The unique name of the syntax definition. 

Short description 

An optional description of the syntax definition. 

LDAP search filter (*) 

This search filter is used for selecting the objects which define the set of permitted values. 

Example: 

(&(objectClass=univentionHost)(cn=a*)) 

sucht alle Rechner"=Objekte, deren Name mit ’a’ beginnt.

Displayed attributes 


Two select fields allow the selection of the object and the attribute to be displayed. When using 

the syntax definition in a user-defined attribute in Univention Directory Manager, solely the attribute 

selected here will be displayed. DN can be selected for displaying the LDAP DN of the object. 

Displayed LDAP attributes 

Instead of setting Displayed Attributes via the Univention Directory Manager modules in Attributes 

to be displayed, a list of LDAP attribute names can also be defined. 

Stored attribute 

The attribute to be stored when selecting an LDAP object, is selected via two fields. The attribute to 

be stored can differ from the attribute to be displayed. Example: In Univention Directory Manager, the 

staff member number of the users specified by a search filter can be displayed, whereas in the LDAP 

directory the pager number is stored. DN can also be stated for storing the LDAP DN of the object. 

Stored LDAP attribute 

Instead of setting the selection of attributes to be stored via the Univention Directory Manager mod- 

ules in Stored Attribute, the name of the LDAP attribute can also be directly defined. 

LDAP base 

The base entry in the LDAP directory service where the search is to start. 

Example: 

cn=branch2,cn=users,dc=ucs,dc=local 

Show only 

If this option is activated, the attribute will only be displayed as a list at the related object. The list 

elements are references pointing to the view of these objects. 

If a syntax definition thus created is to be used in a user-defined attribute, it is sufficient to state the syntax 

name of the syntax definition in the field Syntax of the user-defined attribute. 

4.5.14 Extended attributes 

To expand the aim of the administrator’s possibility to extend the UCS system, the mechanism of the 

user-defined attributes was developed further and the result provided to the user as extended attributes 

Extended attributes encompass the complete scope of functions of the user-defined attributes and offer 

additional, more in-depth possibilities to extend the Univention Directory Manager with your own settings 

masks. 

Creating extended attributes in the Univention Directory Manager web interface 

141


Extended attributes are Settings: Extended attributes objects and created in the navigation (LDAP 

browser) under univention ➞custom attributes. All required settings are stored in attributes of the 

object. 

142 


Name (*) 

The name of the LDAP object which will be used to store the extended attribute. Within a container, 

the name has to be unique. 

Default short description (*) 

Used as title of the input field in the Univention Directory Manager web interface or as the attribute de- 

scription in the Univention Directory Manager command line interface. The standard short description 

should be compiled in English as this is the standard language for Univention Directory Manager. 

Default short description 

This long description is shown as a tool tip in the input fields in Univention Directory Manager web in- 

terface. This long standard description should be compiled in English as this is the standard language 

for Univention Directory Manager. 

Translated short description 

Translated short descriptions can be saved in several languages so that the title of extended attributes 

is also output with other language settings in the respective national language. This can be done by 

assigning the respective short description to a language code (e.g., de_DE or fr_FR) in this input 

field. 

Translated short description 

Additional information displayed in the tool tip for an extended attribute can also be saved for several 

languages. This can be done by assigning the respective long description to a language code (e.g., 

de_DE or fr_FR) in this input field. 

UDM Web 

Tab name 

The name of the tab in the Univention Directory Manager web interface on which the extended at- 

tribute should be displayed. If the tab does not already exist, it will be created automatically. Names 

of tabs belonging to the standard scope of UCS can also be entered. The name of the tab should be 

compiled in English as this is the standard language for Univention Directory Manager. 

If no tab name is entered, user-defined will be used. 

Translated tab name 

If a user with different language settings logs on to Univention Directory Manager, the names of


the tabs will also be translated accordingly. To ensure that extended attributes are also displayed 

on the correct tab when using a different language, translated tab names can be assigned to the 

corresponding language code (z.B. de_DE oder fr_FR) in this input field. 

Span both columns 

As standard all input fields are grouped into two columns. This option can be used for overlong input 

fields, which need the full width of the tab. 

Position number on tab 

If several extended attributes are to be managed on one tab, the order of the individual attributes on 

the tab can be influenced here. They are added to the end of the tab in question in ascending order 

of their numbers. 

If extended attributes have the same number, they are listed in a random order. If the difference 

between two consecutive numbers is larger than 1 and the first attribute is shown in the left column, 

the second will be displayed in the next line. 

If the Overwrite existing tab option is activated, the numbers will be used to overwrite an existing 

input field. The numbering of the input fields starts in the top left of the tab with 1. 

Overwrite existing widget 

In some cases it is practical to overwrite predefined input fields with extended attributes. If this option 

is activated, the input field located at the specified number will be overwritten with this extended 

attribute. It must be noted that this option can cause problems with compulsory fields. 

Overwrite existing tab 

If this option is activated, the tab in question is overwritten before the extended attributes are posi- 

tioned on it. This option can be used to hide existing input fields on a predefined tab. It must be noted 

that this option can cause problems with compulsory fields. 

Advanced tab 

Settings possibilities which are not often used can be placed on tabs with extended settings. These 

tabs are only visible when the Show the advanced settings option has been activated. If there is an 

extended attribute on the specified tab for which the Advanced tab is deactivated, this option will not 

be used. 

Add an empty value to choicelist 

If the attribute’s syntax offers a select list - e.g., a list of all computers - this option can be used to add 

an empty value as an additional selection. 

143


144 

UDM General 

UDM CLI name of extended attribute (*) 

The specified attribute name should be used when employing the Univention Directory Manager 

command line interface. When the extended attribute is saved, the Name of the General tab is 

automatically adopted and can be subsequently modified. 

Options 

Some extended attributes can only be used practically if certain options are activated on the (Op- 

tions) tab. One or more options can optionally be saved in this input field so that this extended 

attribute is displayed or editable. Only existing options can be drawn on - it is not possible to define 

new options. 

Hook 

The functions of the hook class specified here are used during saving, modifying and 

deleting the objects with extended attributes. Additional information can be found at 

http://sdb.univention.de/1080 (currently only available in German). 

Needed module (*) 

The Univention Directory Manager module which is to be expanded with the extended attribute. The 

command univention-directory-manager modules can be used for displaying a list of all 

modules at the command line. Several modules can be added to the list via the Add button. 

To add a user property, the users/user module needs to be entered here, for example. 

The most important Univention Directory Manager" modules: 

Property of Univention Directory Manager moduke 

Users users/user 

Groups groups/group 

Computers computers/computer 

computers/domaincontroller_backup 

computers/domaincontroller_master 

computers/domaincontroller_slave 

computers/ipmanagedclient 

computers/macos 

computers/managedclient 

computers/memberserver 

computers/mobileclient 

computers/thinclient 

computers/windows

Data type 

Syntax 


When values are entered, the Univention Directory Manager performs a syntax check so that no 

LDAP error messages appear when the values are subsequently saved. The syntax to be used is 

dependent on the LDAP scheme used and the intended application. Apart from standard syntax 

definitions (string) and (integer), there are three possibilities for expressing a binary condition: The 

syntax TrueFalse is represented at LDAP level using the strings true and false, while the syntax 

TrueFalseUppercorresponds to the OpenLDAP boolean values TRUE and FALSE and the syntax 

boolean does not save any value or the string 1. 

If no syntax is specified, the syntax string is used automatically. Custom syntax definitions which 

can also be used at this point are described in the user-defined attributes in Section 4.5.13. 

Default value 

If a preset value is defined here, new objects to be created will be initialised with this value. The value 

can still be edited manually during creation. Existing objects remain unchanged. 

Multi value 

This option establishes whether a single value or multiple values can be entered in the input mask. 

The scheme definition of the LDAP attribute specifies whether one or several instances of the attribute 

may be used in one LDAP object. 

May change 

This option establishes whether the object saved in the extended attribute can only be modified when 

saving the object, or whether it can also be modified subsequently. 

Value required 

If this option is active, a valid value must be entered for the extended attribute in order to create or 

save the object in question. 

Unsearchable 

If it should not be possible to search for an extended attribute in the search window of a wizard, this 

option can be activated to remove the extended attribute from the list of possible search criteria. For 

example, this can be the case when using your own, very special syntax definitions. 

Value not editable 

If this option is activated, the attribute cannot be modified by the administrator, neither at creation 

time, nor later. This is useful for internal state information configured through a hook function or 

internally inside a Univention Directory Manager module. 

145


LDAP 

Object class (*) 

Object class to which the attribute entered under LDAP mapping belongs. In LDAP scheme def- 

initions it is established which LDAP attributes are provided by an LDAP object class. Each LDAP 

object which should be extended with an attribute is automatically extended with the LDAP object 

class specified here if a value for the extended attribute has been entered by the user. 

LDAP mapping (*) 

The name of the LDAP attribute where the values of the LDAP object are to be stored. The LDAP 

attribute must be included in the specified Object class. 

Delete object class 

If the value of a extended attribute in Univention Directory Manager is deleted, the attribute is removed 

from the LDAP object. If no further attributes of the registered object class are used in this LDAP 

object, the Objektklasse will also be removed from the LDAP object if this option is activated. 

UCS LDAP schema for customer extensions 

To keep the efforts required for small extensions in LDAP as low as possible, Univention Corporate Server 

has its own LDAP scheme for customer extensions. The LDAP object class univentionFreeAttributes 

can be used for user-defined attributes or extended attributes without restrictions. The LDAP object class 

offers 20 freely usable attributes (univentionFreeAttribute1 to univentionFreeAttribute20) and can be 

used in connection with any LDAP object (e.g., a user object). 

4.6 Policy-controlled Layouts for the Web Front-End of Univention Directory 

Manager 

The layout of Univention Directory Manager can be modified by policies in order to allow users a differen- 

tiated access to the functions of the Univention Directory Manager. The policy type Univention Directory 

Manager View makes it the possible to pre-define the available Univention Directory Manager modules 

for the users. Available modules include: 

146 

• About 

Shows information on the installed UCS version, the validity period of the UCS root certificate of the 

domain, and currently valid licences. 

• Browse 

By activating ’Browse’, the user is permitted direct access to the LDAP (see below under ’LDAP base 

DN’). 

• Personal settings 

Permits the user to define the settings of his user object at his own discretion (see below under ’Self 

tabs list’).

• Wizards 

4.6 Policy-controlled Layouts for the Web Front-End of Univention Directory Manager 

Besides the menu items ’About’, ’Browse’ and the ’Personal settings’, the wizards can be used as a 

simple means for modifying the LDAP directory (see below under ’Visible Web-Admin Wizards’). 

Besides the configuration of the menu items of Univention Directory Manager, presets for the LDAP 

Browser can also be specified. The attributes defined in the field Show these attributes in the navi- 

gation are displayed in the form of additional columns (see ➊ in Illustration 4.13). If the attribute values of 

the objects are not set, then the corresponding fields in the column will remain empty. 

When using the wizard’s search function, it is often helpful to have additional attribute values for the found 

objects displayed. In a similar way as in the LDAP Browser, the attribute values are displayed in additional 

columns ➋ (see Illustration 4.14). The scope of displayed attribute columns complies with the object type 

declared in the search ➌. 

With the standard setting, the layouts are defined by two policies: default-admins and default-users. 

These policies specify the layouts of administrators and the rest of the users, respectively, and can be 

found in the container policies ➞ users ➞ admin-settings. 

Below, the settings for the policy type ’Univention Directory Manager View’ are explained. 

Univention Directory Manager settings 

Name 

Name of the policy 

LDAP base DN 

If in Visible Univention Directory Manager modules the browse module was selected, an LDAP 

base DN can be entered here for restricting the access to the LDAP navigation. Once the setting has 

been made, the user can only access the mentioned Basis DN and its child objects. 

Visible Univention Directory Manager modules 

The Univention Directory Manager modules selected in this field are made available for the user in 

the main menu of Univention Directory Manager. Selecting the Wizards module makes it possible to 

define which wizards are being shown, via Visible Web-Admin Wizards. 

Visible Univention Directory Manager wizards 

The selected wizards are shown in the menu of Univention Directory Manager. 

Attention: 

If no entries are made here, all wizards will be shown. If no wizards are to be shown, None has to be 

selected. 

Visible tabs for personal settings 

If the Personal settings module was activated, elements of the user object can be selected in Visible 

tabs for personal settings, which are to be shown to and can be edited by the user. This setting 

can be used, for example, to permit a user to configure an e-mail forwarding. 

147


148 

Show these attributes in search results 

If a search is performed via a wizard, additional attributes can be displayed in the results table, apart 

from the name and location of the objects. The attributes declared in Show these Attributes in 

search results are shown in the results table in the form of additional columns. If a certain attribute 

value of an object is not set, the corresponding field in the table will remain empty. 

Show these attributes in the navigation 

The output of the LDAP Browser can be extended by additional columns, which show the attribute 

values of the corresponding objects. The attributes declared in Show these attributes in the nav- 

igation are shown in the results table in the form of additional columns in the LDAP Browser. If a 

certain object does not have the stated attribute, then the corresponding field in the table will remain 

empty. 

Allow Personal Univention Directory Manager settings 

If this setting is activated, the user can modify the settings of the user view for his account at his own 

discretion. User-made settings relating to the Univention Directory Manager layout have priority over 

the presets of the relevant policy. 

Attention: 

If the option Allow personal Univention Directory Manager settings is activated, a user can ac- 

tivate all the wizards available for his account, and thus gains read access to the data stored in the 

LDAP directory, unless this access is restricted by LDAP Access Control Lists.


Figure 4.11: Policies tab’ 

149


150 

Figure 4.13: Adapted layout in the LDAP Browser


Figure 4.14: Adapted search for objects 

151


152

5 Univention Management Console 

Contents 

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 

5.2 Layout of the Web Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 

5.2.1 Login Mask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 

5.2.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 

5.3 Standard modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 

5.3.1 System statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 

5.3.2 Kernel modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 

5.3.3 VNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 

5.3.4 System information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 

5.3.5 Univention Configuration Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 

5.3.6 Printer administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 

5.3.7 Process overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 

5.3.8 Filesystem quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 

5.3.9 System services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 

5.3.10 Joining a domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 

5.3.11 Package management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 

5.3.12 Reboot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 

5.3.13 Online update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 

5.4 Wizards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 


5.4.1 Basis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 

5.4.2 Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 

5.4.3 Mail server configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 

Univention Management Console is a modularly designed, web-based application for the administration of 

individual Univention Corporate Server systems. The application allows the user to control services, check 

system utilisation, and check or adjust system parameters. 

The web interface of the Univention Management Console can be used by any client. The permission 

concept of Univention Management Console is based on policies. This makes it possible to define for 

each user or group the services they may influence, the extent of the exerted influence, and on which 

servers they may do so. In this way, for example, certain people can be assigned the permission to 

administrate the print service of one or a number of servers, whilst another group can only use the quotas. 

A further group could only be given a restricted permission to delete print jobs, but not restart paused 

153


printers. This method permits a targeted authorisation of the required functions without confusing the 

user by a load of unnecessary options. 

By default, the members of the Domain Admins group have permission to use all modules and functions 

of the Univention Management Console. 

The operation of Univention Management Console is described in the following chapters. After some 

instructions on how to handle Univention Management Console and the diverse controlling elements and 

structures, the individual modules and functions will be explained in detail. 

5.2 Layout of the Web Interface 

With its web interface, Univention Management Console offers an easy way of performing administrative 

tasks from any client. The possibilities for the individual user depend to a large degree on which permis- 

sions are defined for this user. 

The following paragraphs comprise an illustrated description of the layout and operation of the user in- 

terface of the Univention Management Console. Details relating to the functionalities of the individual 

modules can be found in subsequent chapters. 

5.2.1 Login Mask 

The simplest way of accessing Univention Management Console is to enter the URL 

https:///umc/ in the address field of a web browser. Replace by the client 

name or by the IP address of the system, e. g. https://ucs-master.univention.local/umc/. 

Under special circumstances, it might be necessary to access Univention Management Con- 

sole via a secure connection. This can be the case if there haven’t been any SSL certifi- 

cates created yet for this system. Insecure access is performed via the http address, e. g. 

http://ucs-master.univention.local/umc/. 

Attention: 

In this case, passwords are transmitted in plain text across the network. 

The login mask is displayed as the welcome page for the user (see Illustration 5.1). He can log in via 

his username from the UCS domain and the appropriate password. Depending on the user’s authorisa- 

tions, the subsequent screens displayed in the web browser might look slightly different from the below 

screenshots. 

The Administrator account is generally used for administrative accesses. 

Also, the language of the user interface can be selected during login. 

5.2.2 Overview 

After successful login, and if sufficient permissions were assigned to the user, an overview of all available 

modules will be displayed as shown in Illustration 5.2. The display will only include modules to which the 

154

Figure 5.1: Login mask of Univention Management Console 

5.3 Standard modules 

user is granted access permission. For example, if a user has no permission for printer administration, 

then the corresponding module will be hidden. 

The Overview tab is always the first to be opened. The subdivision into tabs follows the layout of the 

Univention Directory Manager. In addition there are so-called categories in Univention Management Con- 

sole, which are displayed in the upper area of each tab. Illustration 5.2 shows an example in which the 

categories All modules, System, and Wizards are displayed in the tab. According to the presets, the 

category All modules is always the first in line. 

Starting from the Overview tab, the user can jump to the individual modules via the displayed icons. If 

the module has not yet been activated during the current session, then a new tab for this module will be 

opened and displayed automatically. If the module was already used, the existing tab will come to the 

front. Thus, several modules can be active, and the user can switch between modules via Overview. This 

means, if a long-term task is being performed in one module, the user is not compelled to wait for the end 

of the task; instead he can perform other tasks in other modules. At a later date, he can return to the initial 

module and check the status or results of the performed task, or abort the task. A tab can be closed via the 

Close button. However, this merely affects the display; the module will keep on working in the background 

until its task is finished. 

Apart from the Overview tab, there is the About tab. This tab contains information on the installed program 

version. 


Having described the layout and navigation within Univention Management Console above, we will now 

address the individual functions of he standard modules in detail. 

155


Figure 5.2: Overview page of Univention Management Console 

Some software packages include further UMC modules; the documentation for these modules can be 

found in the respective chapters or documentation. 

5.3.1 System statistics 

The utilisation statistic displays the utilisation of the system. For this purpose, a diagram is displayed for 

different periods: 

• The past 24 hours 

• The past week 

• The past month 

• The past year 

The following system information is documented: 

• The utilisation of the main memory in percent 

• The processor utilisation of the system 

• The number of terminal server sessions active 

• The utilisation of the swap file 

For the operation of this module, the univention-maintenance package has to be installed. If the package 

is not installed, a corresponding message will be displayed. 

156

5.3.2 Kernel modules 


The module Kernel modules offers the possibility of loading or unloading existing kernel modules. The 

start page contains a search mask for searching kernel modules. Apart from selecting the module cat- 

egory, such as drivers/video or drivers/usb, and the name, the user can restrict the display to loaded 

modules. 

In the search list, each module will be displayed and can be loaded or unloaded after prior confirmation. 

5.3.3 VNC 

The VNC protocol (Virtual Network Computing) can be used to display graphic screen outputs from a 

distant computer on a local computer. This module allows the displaying of the desktop in the web browser, 

see Figure 5.3. 

Figure 5.3: Desktop in web browser 

Once the module has been loaded, a password must be entered, which can later be used to start the 

VNC session. The password is saved in an encrypted form in the .vnc/passwd file in the user’s home 

directory. If the file is deleted, the request is shown again. 

A check is then run to determine whether a VNC server is already running. If no VNC server is running, 

a VNC server can be started using the Start link. As soon as a VNC server is running, it can be stopped 

using the Stop VNC server link or a connection can be created to the VNC server. To do this, a java applet 

is loaded in the web browser and the UCS system can be accessed graphically in the web browser. 

157


5.3.4 System information 

The system information module collects information relating to the hardware of the current system. This 

can then be requested in a support case, for instance. The transmission of the information is also used to 

broaden the database of hardware supported by UCS. 

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 trans- 

mits the data via HTTPS, Send mail (optional) opens a dialogue, which can be used to initiate sending 

via e-mail. 

5.3.5 Univention Configuration Registry 

The Univention Configuration Registry module is used to display and change Univention Configuration 

Registry variables. There is also the possibility of registering new Univention Configuration Registry vari- 

ables. Further information on Univention Configuration Registry can be found in Chapter 14. 

A search mask is displayed on the start page. Along with the category, search filters can also be selected 

for variable names, the value or the description. Following a successful search, the variables found are 

displayed in a table with the variable name, the value, the description and the category (see Figure 5.4. 

Clicking on the variable name opens the editing mask for a variable. The following settings can be made 

there: 

• the value 

• the category (e.g., desktop or mail) 

• the type (e.g., string) 

• the description in a number of languages 

A few core variables - e.g. the domain name - cannot be modified directly, but only indirectly by means of 

Univention System Setup or the UMC base wizards. These variables are displayed grayed-out. Changes 

using the command line frontend are still possible. 

Once changes have been made, the action can be completed with the Set button or cancelled with the 

Cancel button. The last search is then displayed. 

158

Figure 5.4: Univention Configuration Registry search mask 


New Univention Configuration Registryvariables can be added in the subcategory Add. Unlike the editing 

mask, the name of the variable can also be given here; the page is otherwise structured identically. 

5.3.6 Printer administration 

This module offers the possibility of checking the status of individual printers, restarting paused printers or 

deleting print jobs out of the queue. 

The start page of the module contains a search mask with which the available printers can be selected. 

The results list displays the server, name, status, print quota properties, location and description of the 

respective printer. The status of more than one printer can be changed simultaneously by selecting the 

printers and running either the deactivate or activate function. 

Clicking on the printer name displays details of the selected printer. The information displayed includes 

a list of the print jobs currently in the printer queue. These print jobs can be deleted from the queue by 

selecting the jobs and running the [Delete] function. 

5.3.7 Process overview 

The module Process overview shows all current processes in a table. By default, a maximum of 50 

processes are displayed. The menu item Number of processes allows this value to be changed to 10, 

159


Figure 5.5: List of available printers 

20, or all processes. In addition, the processes can be sorted according to several criteria: 

• CPU utilisation 

• Username 

• Resident size of working memory 

• Virtual size of working memory 

• Process ID 

After having changed the selection, the user can confirm the changes via Reload. 

5.3.8 Filesystem quotas 

The module for Filesystem quotas management offers the possibility of limiting or expanding the space 

on the hard drive that users are allowed to use for their files on the server. The space for each partition on 

a system can be limited individually here. 

If the Filesystem quotas module is selected in the Overview tab, a page is shown at the beginning which 

is similar to the 5.6 figure. This shows a list of all the available partitions of a computer. In addition to the 

partition names and the mount point, information on the size and available space is also shown. Further 

information which is important for quota management can be found in the Quota column: The deactivated 

status means that no quota settings can be made on the partition at this time. The support must firstly be 

160

Figure 5.6: List of partitions 


activated. On the other hand, if the activated status is shown in the column next to partitions, the quota 

has already been activated. 

To activate this support for one or more partitions subsequently, it must be selected and activated in the 

table. 

If the quota management on a partition is activated, it is possible to change to the Partition overview 

category via the partition name in the table. This view shows details on current quota settings on the 

selected partition. An example of this can be seen in Figure 5.7. 

The quota settings for individual users can be added, deleted or changed here. There is an input mask for 

each task. The values inputted limit the file quantities for each user on the selected partition. In general, 

such limitations are defined by two values: 

Soft limit When this limit is met, the user is warned that he has reached his quota limit. This value must 

be smaller than the hard limit so that the user still has the possibility of deleting files. 

Hard limit When this limit is reached the user can no longer write on the partition. For example, if this 

applies to the home directory it can lead to problems with log-ins. 

These two limit values can be specified in different units. 

Files The soft and hard limits for files limit the quantity of user files by imposing a limit on the number of 

files created. 

Blocks The limitation of blocks applies to the file quantity in respect of the total size of all the user’s files 

in a partition. 

The difference between the soft and hard limits should be selected large enough to allow users sufficient 

time to clean up and save files. 

161


Figure 5.7: Details on a partition 

Alternatively, group-based assignment is possible via univention-quota-group. The use is docu- 

mented under [11]. 

5.3.9 System services 

On the System services start page, the current services are displayed in a table, as shown in Illustration 

5.8. Apart from its name and an icon, the status of each service is shown as well as the starting mode and 

a short description. 

At the end of the table several actions can be performed via a select list. The following actions are possible: 

• Invert selection 

• Select all 

• Start services 

• Stop services 

• Start automatically 

• Start manually 

• Start never 

The items Start automatically/manually refer to the start of the system. 

The option Start never additionally prevents the manual service start by the administrator. 

162

5.3.10 Joining a domain 

Figure 5.8: Overview of System Services 


The Univention Management Consolemodule for joining a domain is described in Chapter 2.4.1.2. 

5.3.11 Package management 

The Package management module helps install or uninstall software packages. 

A search mask is displayed on the start page in which the user can select the package category, a search 

filter (name or description) or whether installed software packages are to be displayed exclusively. An 

example dialogue can be found in Illustration 5.9. The results are displayed in a table with the following 

columns: 

• Package name 

• Section/category 

• Installation status 

• Package description 

Clicking the name of the software package opens a detailed information page with a comprehensive de- 

scription and the priority of the package, among other things. In addition, one or more buttons will be 

163


Figure 5.9: Package management search mask 

displayed: Install is displayed if the software package is not installed yet; Uninstall is displayed if the soft- 

ware package is installed and Actualise is displayed if the software package is installed but not updated. 

Abort can be used for returning to the previous search request. 

5.3.12 Reboot 

The Reboot module can be used for restarting or shutting down the system. 

On the Reboot module page, the user can choose between shut-down or restart. Additionally, a system 

message can be entered which will be logged in /var/log/syslog. 

After confirmation via the Proceed button, the system message will be displayed on the screen, and the 

action will be performed immediately. 

164

5.3.13 Online update 

Figure 5.10: Reboot input mask 

The Online updates module allows the installation of version updates and security updates. 


Figure 5.11 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.11: Online update module 

If a newer UCS version is available, a select list is displayed. Clicking on Install release updates presents 

a link to the release notes and after 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 

165


restrictions of the server services during the update. Any intermediate versions are also installed automat- 

ically. 

Clicking on Install available security updates installs all the available security updates for the current 

release. 

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 following configuration changes can be made in the Settings tab. 

Figure 5.12: Online update: repository settings 

The Repository server and, if applicable, a Repository prefix can be specified in Release settings. In 

addition, one can configure which repository options should be used: 

Use maintained repositories This is activated in the preset values and integrates the standard package 

repository. 

Use unmaintained repositories Further software for UCS releases can be found in the unmaintained 

repositories, which can be integrated with this option. As standard this is not activated. 

Use hotfix repositories This option can be activated in order to be able to use the Univention hotfixes. 

Further details can be found in Section 11.2.1. 

An overview of software components which expand the scope of function of Univention Corporate Server 

can be found under Component settings. 

The Add a new component button allows a new software component to be installed. Name identifies 

the component on the download server. A free text can be entered under Description, for example, for 

describing the functions of the component in more detail. The host name of the download server is to be 

entered in the input field Server name, and, if necessary, an additional file path in Prefix. A Username and 

166

Figure 5.13: Online update: component settings 

5.4 Wizards 

Password can be configured for download servers which require an authentication. A software component 

is only available in the Package management after it has been Enabled. 

All these settings can be subsequently made for components which are already configured, by clicking the 

Configure button in the list. 

The Version specifies for which UCS versions a component should be installed. If the field is left blank, 

the component is integrated for all currently installed minor releases, e.g., for an installation with UCS 2.3 

for UCS 2.0 to 2.3. Similarly, if current is entered in this field, all minor releases for this components are 

enabled, with the additional verification, however, that an update to a new minor release can only occur if 

the component for this minor release is also available. 

As with the standard repositories, components are differentiated between maintained and unmaintained 

components. 

5.4 Wizards 

Univention Management Console offers several wizards for performing standard procedures during the 

implementation of services. These wizards combine the basic settings of individual UCS components, and 

can be of particular help in during the initial implementation. 

5.4.1 Basis 

The Basis wizard has the purpose of performing basic settings of the UCS system; these include the 

following values: 

• Host name 

167


• DNS domain name 

• LDAP basis 

• Windows domain name 

Affected system services will be restarted during the changes. Since these are basic settings, the overall 

system should also be restarted once all the changes are made. 

More information can be found in Chapter 2.4. 

5.4.2 Nagios 

A telephone number can be entered here for Nagios. With this option, Nagios not only sends events to 

an e-mail address, an SMS is also sent to a mobile phone. More information can be found in the Nagios 

documentation [12]. 

5.4.3 Mail server configuration 

Basic settings for the mail server are performed in the mail server wizard. 

168 

• Spam filtering 

This checkbox is used to activate/deactivate spam filtering. Further information can be found in 

Chapter 12.4. 

• Virus detection 

This checkbox is used to activate/deactivate virus detection. Further information can be found in 

Chapter 12.5. 

• IMAP access 

IMAP access to mailboxes can be switched on and off here. 

• IMAP quota support 

This option can be used to enforce a setting so that the size of the inbox is checked when IMAP 

mailboxes are accessed. 

• POP3 access 

POP3 access to mailboxes can be switched on and off here. 

• Maximum message size 

The maximum size in bytes for acceptable e-mails can be set here. 

• Alternative e-mail address for root 

Many system servers send the root user status e-mails. An alternative recipient for the root user 

can be specified here.

6 Univention Virtual Machine Manager (UVMM) 

Contents 

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 

6.1.1 Paravirtualisation / virtIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 

6.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 

6.3 Managing virtual machines with UVMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 


6.3.1 Creating a virtual instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 

6.3.2 Modifying virtual machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 

6.3.3 Migration of virtual machines from failed virtualization servers . . . . . . . . . . . . . 178 

Univention Virtual Machine Manager (UVMM) is a management system for virtualisation servers and virtual 

machines. It offers the possibility of monitoring all the virtualisation servers (based on Xen or KVM) 

registered in the UCS domain and administrating the virtual instances on these systems. 

A Univention Management Console module forms the management interface; it can be installed on any 

system in the UCS domain (however, a domain controller is preferable). All virtualisation servers are then 

administrated from this management system. 

Section 6.2 describes the installation of the management system and the virtualisation servers and the 

functions of the Univention Management Console module. 

Univention Wiki (http://wiki.univention.de) includes a step-by-step quickstart guide [13] and fur- 

ther technical documentation as well as howtos [14]. (Currently only available in German) 

6.1.1 Paravirtualisation / virtIO 

In principle, the virtualised systems can run arbitrary operating systems. This mode of operation is called 

fully virtualised systems. 

KVM and Xen each offer interfaces to provide the virtualised systems with direct access to the resources 

of the virtualisation server. This considerably improves performance. 

In Xen, this technology is referred to as paravirtualisation. Current Linux systems support paravirtualisa- 

tion as standard; support drivers need to be installed for Microsoft Windows systems (see [14]). 

KVM offers the virtIO interface. This allows network and storage devices a direct connection to the KVM 

resources. This technology is comparable to paravirtualisation. When menu points in UVMM refer to 

paravirtualisation, this also includes virtIO. 

169


UVMM supports both full virtualisation and paravirtualisation for virtualised systems. Using paravirtualisa- 

tion/virtIO is recommended. 

virtIO and Xen paravirtualisation drivers for Microsoft Windows are included in UCS as of version 2.4-4. 

Installing the respective KVM or Xen packages provides ISO images, which can be added in the drive 

settings of a virtual machine. The images are added to the storage pool specified with the Univention 

Configuration Registry variable uvmm/pool/default/path: 

• On Xen virtualization servers an ISO image named Xen Windows drivers (gplpv 308) is provided 

, which contains the GPLPV virtualization driver for Microsoft Windows. 

• On KVM virtualization servers an ISO and a floppy image named KVM Windows drivers (virtio 

1.1.16) is provided, which contains the virtIO virtualization driver for Microsoft Windows. 

6.2 Installation 

Univention Virtual Machine Manager comprises three different packages. They can all be selected di- 

rectly when installing the UCS system or alternatively installed subsequently via Univention Management 

Console. 

Virtual Machine Manager (UVMM) (Package: univention-virtual-machine-manager-daemon) This 

package must be installed on the management system. In doing so, both an additional service 

and the Univention Management Console module are set up. This package should be installed on 

a domain controller in the UCS domain. The installation on member servers requires additional 

configuration steps, which are documented in [14]. If UVMM is installed on a slave domain controller 

or backup domain controller, the package univention-virtual-machine-manager-schema needs to 

be installed on the master domain controller beforehand. 

Xen virtualisation server (Package: univention-virtual-machine-manager-node-xen) This package 

must be installed on each system which is to be used as a Xen-based virtualisation server. 

KVM virtualisation server (Package: univention-virtual-machine-manager-node-kvm) If KVM is to 

be used for the virtualisation, this package should be installed on the virtualisation servers. 

The two packages for the virtualisation servers register the service in the LDAP directory. Additionally, a 

particular kernel is installed on Xen systems, which is necessary to allow Xen to be used. 

When installing the virtualisation servers, only one virtualisation technology should be used per server. 

Xen and KVM are both equally supported by Univention Virtual Machine Manager. However, the technolo- 

gies have different advantages and disadvantages depending on the host systems and hardware used. 

For example, KVM requires virtualisation support in the central processing unit, while Xen can also virtu- 

alise (within limits) systems without support from the hardware. More detailed information can be found on 

their respective websites: http://www.linux-kvm.org/ and http://www.xen.org/. 

Additionally, the architecture must also be taken into account during installation of the virtualisation servers. 

64 bit systems can only be virtualised on UCS systems where are installed using the amd64 architecture. 

A 64-bit system (amd64) is recommended for use as the virtualisation server. 

Where possible, hard drives images should be accessed paravirtualised: 

170

6.3 Managing virtual machines with UVMM 

• In UCS systems installed under Xen or KVM, a paravirtualised access is automatically activated via 

the profile. 

• In Windows systems installed under Xen, no UVMM configuration adaptations are necessary; in this 

case, Windows drivers merely need to be subsequently installed on the machine. (See [14]) 

• In Windows systems installed under KVM, paravirtualisation must be activated before beginning the 

Windows installation, see [14] and Section 6.3.2. 


The Univention Management Console module Virtual machines (UVMM) offers the possibility to create, 

edit and delete virtual instances/machines and to change their status. In principle, these functions are 

independent of the virtualisation technology employed (Xen or KVM), however they may vary slightly de- 

pending on the hypervisor in use. The items that must be observed are illustrated in the following section 

on the description of the functions. 

Once the UMC module has been opened, a tree structure is displayed on the left-hand side, which gives 

an overview of the existing virtualisation servers and the virtual instances defined there. 

All the other entries in the tree structure can also be selected. If a virtualisation server is selected, an 

overview showing the status of the server itself and the existing virtual instances with CPU utilisation and 

memory requirements is listed. This overview can be seen in Figure 6.1. The Refresh button which can 

be seen in the top right can be used to refresh the information. 

Figure 6.1: Overview of a virtualisation server 

When selecting a virtual machine, the status can be seen from the symbol in the tree structure, i.e., 

whether it is running, paused or stopped. As can be seen in Figure 6.2, the configurations are also shown 

in addition to the statistics when a virtual instance is selected. All the settings of the instance can be 

changed and saved here. 

6.3.1 Creating a virtual instance 

Virtual machines can be created in just a few steps in UVMM using a wizard. 

171


Figure 6.2: Overview of a virtual instance 

In the first step a profile is selected (Figure 6.3) which specifies some of the basic settings for the virtual 

machine (e.g., a name prefix, number of CPUs, RAM and whether the direct access per VNC should be 

activated). 

The existing UVMM profiles are stored in the LDAP directory and can also be edited there. The 

profiles can be found in the Navigation section of Univention Directory Manager in the container 

cn=Profiles,cn=Virtual Machine Manager. Additional profiles can also be added there. 

The virtual machine is now given a Name (up to 25 characters) and a Description and assigned Memory 

and CPUs. 

The Enable direct access option specifies whether the machine can be accessed via the VNC protocol. 

This is generally required for the initial operating system installation. 

Now the disk drives of the virtual machines are configured. The setup is documented in Section 6.3.2.3. 

Clicking Finish concludes the creation of the virtual machine. 

172

6.3.2 Modifying virtual machines 

Figure 6.3: Assistant for creating a virtual machine 


The overview page of a virtual machine is divided into multiple sections (Figure 6.4): 

173


6.3.2.1 Snapshots 

Figure 6.4: Settings of a virtual machine 

UVMM offers the possibility to save the contents of the main and hard drive memory of a virtual machine in 

snapshots. This allows the administrator to revert to these snapshots at a later point in time, which makes 

them a useful “safety net” when installing software updates. 

Snapshots can only be used with KVM instances which access all their hard drive images in Qcow2 format. 

All snapshots are stored using copy-on-write (see 6.3.1) directly in the hard drive image file. 

Create new snapshot can be used to create a snapshot with the name of your choice, e.g., DC Master 

before update to UCS 2.4-2. In addition to the description the time is saved when the snapshot is created. 

The following list shows all available snapshots ordered reverse-chronologically. Revert can be used to 

return the machine to an earlier snapshot and Delete can be used to remove a snapshot. 

174

6.3.2.2 Operations (Starting/stopping/suspending virtual machines) 


Instances created via UVMM are turned off in the initial status. This status can changed in the overview 

of the respective virtualisation server in the respective list entry or in the overview of the virtual machine 

itself. In the latter case, there is an Operations section, in which the status can be set. The following 

possibilities exist: 

Start starts the virtual machine. 

Stop turns the virtual machine off. It must be noted that the operating system is not shutdown first, i.e., it 

should be compared with turning off a computer by pulling the power plug. 

Pause assigns the instance no further CPU time. This still uses the working memory on the virtualisation 

server, but the instance itself is paused. 

Suspend saves the contents of the machine’s system memory on the hard drive and does not assign the 

machine further CPU time, i.e., compared with Pause the working memory is also freed. Suspended 

machines can be restarted with Start. This function is only available on KVM-based virtualisation 

servers. 

Resume starts assigning the instance CPU time again, so that it continues in the state it was prior to the 

pausing. 

Remove Virtual instances no longer required can be deleted along with all their hard drives and ISO 

images. The images to be deleted can be selected from a list. It must be noted that ISO images and 

sometimes also hard drive images may still be used by other instances. They should only be deleted 

when they are no longer used by any instance. 

A further function which can be found in the Operations section of the overview is the possibility of migrat- 

ing a virtual machine to another virtualisation server. This works with both paused and running instances 

(live migration). The option is only displayed if at least two compatible virtualisation servers are available 

in the domain. 

During the migration it must be noted that the images of the mounted hard drives and CDROM drive must 

be accesible by both virtualisation servers. This can be achieved, for example, by storing the images in a 

central storage system. Notes on the setting up of this type of environment can be found under [14]. 

6.3.2.3 Drives (Hard drives/CD-ROM/DVD-ROM/floppy) 

The Drives section contains a list of the defined drives with the type, image file and size as well as the 

assigned storage pool. At the end of each line there is a Delete button, which can be used to remove the 

drive (the image file can also optionally be deleted with it). In addition, a wizard can be used to create new 

hard drives and CDROM drives. 

Adding a drive If virtual hard drives are added, image files are usually used for the data keeping. An 

image file can either be generated for this purpose or an existing image file can be assigned to a virtual 

machine. Alternatively, a hard drive partition can also be assigned to a virtual machine via the Use a local 

device option. 

175


Hard drive images can be administrated in two ways on KVM systems; by default images are saved in 

the Extended format (qcow2). This format supports Copy-on-write which means that changes do not 

overwrite the original version, but store new versions in different locations. The internal references of 

the file administration are then updated to allow both access to the original and the new version. This 

technique is a prerequisite for efficiently managing snapshots of virtual machines. 

Alternatively, you can also access a hard drive image in Simple format (raw). Snapshots can only be 

created when using hard drive images in Extended format. 

Only the Simple format is available on Xen systems. 

These image files are stored in so-called storage pools. Each virtualisation server already provides a 

storage pool with the name Local directory in the default setting. This can be found on the virtualisation 

servers in the /var/lib/libvirt/images directory. 

If a live migration of virtual machines between different virtualisation servers is planned, the storage pool 

must be stored on a system which can be accessed by all virtualisation servers (e.g., an NFS share or an 

iSCSI target). This is described in [14]. 

Image files are created as sparse files with the specified size, i.e., these files only grow when they are 

used and then up to the maximally specified size and thus initially require only minimal disk space. 

It is also possible to provide a virtual machine with a disk drive via an image (in VFD format) or the 

passthrough of a physical drive. 

If drives are defined for a new virtual machine, it must be ensured that it is possible to boot from the 

CDROM drive. The UVMM profile specifies the boot order for the fully-virtualised instances in advance. 

For the paravirtualised instances, it is defined by the order on the definition of the drives and can be 

adapted subsequently in the settings section. 

Modifying a drive In the settings of a drive, Paravirtual drive allows specification of whether the access 

to the drive should be paravirtualised. Where possible, this setting should not be changed for a virtual 

machine which already has an operating system installed, as this may disrupt the access of partitions. 

If drives or network interfaces are subsequently added to a virtual instance, the utilisation of paravirtuali- 

sation is determined by heuristics. 

If installation of a KVM-based Windows system with the virtIO drivers is planned, the setting must be 

activated before beginning the Windows installation. Further information can be found under [14]. 

6.3.2.4 Network Interfaces 

When a virtual machine is created, it is automatically assigned a network card with a randomly generated 

MAC address. 

This menu contains a list of all network cards; in addition, new cards can be added or existing ones edited. 

The Type specifies the network connection. In the basic settings, a Bridge on the virtualisation server is 

used to access the network directly. The virtual instance uses its own IP address for this. 

176


NAT network cards are defined in a private network on the virtualisation server. To do so, the virtual 

machine(s) must be assigned an IP address from the 192.168.122.0/24 network. This virtual instance is 

granted the access to the external network via NAT, so that the access is performed via the virtualisation 

server’s IP address. 

The UVMM servers are already preconfigured for both types of network cards. However, there are restric- 

tions for bridged network cards. On the UVMM servers, the physical network card to which the standard 

route is set, is converted to a bridge in the default setting. If additional network cards are integrated in 

the server, these are not adapted accordingly. If several bridge network cards are required in a virtual 

instance, an additional network card must be configured as a bridge on the server in advance. If a bridge 

is used, the Source of the network interface used can be selected. 

NAT network cards are only restricted by the IP addresses available in the 192.168.122.0/24 network. 

The Driver can be used to select what type of card will be provided. The Realteak RTL-8139 is supported 

by almost all operating systems, the Intel Pro-1000 offers advanced abilities and a Paravirtual device 

offers the best performance. 

The MAC address is generated automatically, but may also be subsequently changed. 

6.3.2.5 Settings 

The basic settings of a virtual machine can only be changed if it is turned off. 

Name defines the name of the virtual machine. This does not have to be the same as the name of the 

host in the LDAP directory. 

Operating System can contain a description of the virtual instance or of the operating system used. 

Contact defines the contact person for the virtual machine, e.g., in the form of an e-mail address. 

Description can describe the function of the virtual machine, e.g. mail server. 

Architecture specifies the architecture of the emulated hardware. It must be noted that virtual 64 bit 

machines can only be created on virtualisation servers using the amd64 architecture. This setting is 

not shown on i386 systems. 

Number of CPUs defines how many virtual CPUs are assigned to the virtual instance. 

Memory specifies the size of the system memory. 

6.3.2.6 Extended settings 

The extended settings of a virtual machine can only be changed if it is turned off. 

Virtualization Technology shows the technology used for virtualisation. This setting can only be speci- 

fied when creating a virtual instance. 

Boot order specifies the order in which the emulated BIOS of the virtual machine searches the drives 

for bootable media. This setting is only available for fully-virtualised instances. In paravirtualised 

instances, the Set as boot device option can be used in the drive settings. 

177


Direct access defines whether VNC access to the virtual machine is available. If the option is activated, 

the UMC module can be used to start a VNC program directly. The VNC URL is displayed in a tool tip. 

A Java VNC program is used for this in the default setting. By switching the Univention Configuration 

Registry variable uvmm/umc/vnc to the value of external, an external program can be used instead. 

This requires the web browser on the workstation computer to be configured properly to handle the 

URI scheme vnc://. 

Available globally defines whether the VNC remote access is also possible from remote systems. If the 

option is not activated, the VNC session can only be accessed from the virtualisation server. 

Password sets a password for the VNC connection. 

Keyboard layout defines the layout for the keyboard in the VNC session. 

6.3.3 Migration of virtual machines from failed virtualization servers 

As of UCS 2.4-4, information about the virtual machines running on the virtualization servers is stored 

centrally via the Univention Virtual Machine Manager. If the image files of the virtual machines are stored 

in a storage pool, the machine can be migrated to another server and restarted there if a virtualization 

server fails. 

How to set up one of these storage pools is documented in the Univention Wiki [14] and is a prerequisite 

for migrations. 

If a server fails (failure detection is performed periodically every 15 seconds), the server and the virtual 

instances operated on it are identified as inactive with a red symbol, a warning appears (see Figure 6.5) 

and Migrate is offered as the only operation in the menu. 

178 

Figure 6.5: Migrating a failed virtual machine from a failed virtualization server


Following the migration, the virtual instance is no longer displayed in the overview tree of the failed virtual- 

ization server in the UVMM, but it is not possible for UVMM to report back to the virtualization server as it 

is no longer available. 

Attention: 

It must be ensured under all circumstances that the virtual machine on the original and the secondary 

server are not started in parallel; this would involve their both writing in the image files simultaneously, 

which would result in data loss. If virtual machines are started automatically after startup, simultaneous 

access must be prohibited by disconnecting the network connection or restricting access to the storage 

pool. 

If the failed computer is reactivated - e.g., in the case of a temporary power failure - the virtual machines re- 

main available on the system locally and are reported to UVMM; consequently, there are then two versions 

of the instance. 

As such, one of the two instances should subsequently be deleted. However, the employed image files for 

the drives should not be deleted at the same time. 

179


180

7 UCS Directory service 

Contents 

7.1 Overview 

7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 

7.2 Logging of LDAP changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 

7.2.1 Installation and setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 

7.2.2 Format of the log file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 

7.3 Timeout for inactive LDAP connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 

7.4 Configuration of LDAP ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 

7.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 

7.4.2 Definition of objects for which a rule applies (access to) . . . . . . . . . . . . . . . . 184 

7.4.3 Definition of the access permissions on the objects . . . . . . . . . . . . . . . . . . . 184 

7.4.4 Definition of the permission on the objects . . . . . . . . . . . . . . . . . . . . . . . . 185 

7.4.5 Definition of the handling of further rules with applied rules . . . . . . . . . . . . . . 185 

7.4.6 Delegation of the privilege to reset user passwords . . . . . . . . . . . . . . . . . . . 186 

Univention Corporate Server saves domain-wide data in a LDAP directory service based on OpenLDAP. 

This chapter describes the advanced configuration and coordination of OpenLDAP. Alongside the logging 

of LDAP modifications there is also the possibility of adapting the access control lists to the directory 

service. 

7.2 Logging of LDAP changes 

The univention-directory-logger package allows logging of all changes in the LDAP directory 

service. In addition, an integrated hash sum ensures that no changes can be deleted from the log file. 

7.2.1 Installation and setup 

Logging is activated as standard following installation of the package and can be deactivated using the 

Univention Configuration Registry variable ldap/logging (yes/no). 

Individual areas of the directory service can be excluded from the logging. These branches can be config- 

ured over the ldap/logging/exclude1, ldap/logging/exclude2 etc. variables. As standard the 

container is excluded in which temporary objects are stored (cn=temporary,cn=univention,Base-DN). 

181


Logging of the LDAP changes is effected by a Univention directory listener module. The univention- 

directory-listener service should be restarted if changes are made to the Univention Configuration Reg- 

istry. 

7.2.2 Format of the log file 

Changes to the directory service are documented in the /var/log/univention/directory-logger.log 

file as a series of data records in the following format: 

START 

Old hash: 

DN: 

ID: 

Modifier: 

Time stamp: 

Action: 

Old values: 

 

New values: 

 

END 

There are three types of changes: 

• For added entries (add), only the New Values section appears. 

• For changed entries (modify), both the New Values section and the Old Values section appear. 

• For deleted entries (delete), only the Old Values section appears. 

A hash sum is calculated for each logged data record and documented as a line in the daemon.info 

section of the Syslog service in the following format: 

directory_logger: 

DN= 

ID= 

Modifier= 

Timestamp= 

New Hash= 

The new hash sum is also saved in the /var/lib/univention-directory-logger/cache file to 

allow further rotation of the directory-logger.log via Logrotate. Both files are saved in such a way 

that read access is limited to the root Posix user and the adm Posix group. 

As each data record contains the hash value of the old data record, manipulations of the log file - such as 

deleted entries - can be uncovered. 

7.3 Timeout for inactive LDAP connections 

The LDAP server accepts 1024 connections as standard. When many clients create connections which 

they only use sporadically, the point may come when the LDAP server cannot accept any more connec- 

182

tions. 

7.4 Configuration of LDAP ACLs 

The Univention Configuration Registry variable ldap/idletimeout is used to configure a time period 

in seconds after which the connection is cut off on the server side. When the value is set to 0, no expiry 

period is in use. 

The nssldap/idle/timelimit variable can be used to set the timeout for the NSS-LDAP interface. 

When this runs out libnss-ldap shuts down the connection to the LDAP server itself and recreates it for 

the next request. 

When a value is set for ldap/idletimeout, a smaller value should be chosen for 

nssldap/idle/timelimit. 


7.4.1 Introduction 

Access to the information contained in the LDAP directory is controlled by Access Con- 

trol 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. 

The standard permissions of the LDAP server make it possible for each user to read all attributes and 

changes to be made exclusively through a special account: the root DN. 

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. 

Each rule comprises up to four elements: 

• Which object in the LDAP is the rule applied to? 

• Which users will be assigned the permission? 

• Which permission will be assigned? 

• How should further rules be handled? 

If errors should be investigated during ACL processing, it is advisable to set the log level of the LDAP 

server to 129 using the Univention Configuration Registry variable ldap/debug/level and restart the 

LDAP server. The debug output can be found in /var/log/syslog. 

ACL expansions should be packaged in Debian package format where possible so that the adapted ACLs 

can be installed easily on domain controller backup systems. 

183


If ACL settings are subsequently relaxed, replication problems may arise if change transactions 

apply to an object which was formerly subject to stricter ACLs. In this case it is recom- 

mended to start a new replication on the slave domain controller and backup systems using the 

univention-directory-listener-ctrl resync replication command. 

7.4.2 Definition of objects for which a rule applies (access to) 

Access rules are implemented via access to access directives. Rules can be defined on three different 

classes of objects. These can be used in any combination: 

• The directive can be assigned to a DN, i.e., to an unique position in the LDAP directory. For example, 

the identifying part of the directive, which allows access to a database administration account would 

look as follows: 

access to dn="uid=databaseadmin,cn=users,dc=company,dc=com" 

The DNs can also be defined with a regular expression. The regular expressions are given here in 

the POSIX standard: 

access to dn.regex="cn=.*,cn=dc,cn=computers,dc=company,dc=com" 

• The directive can be defined using a LDAP filter. For example, the access can be limited to MAC 

addresses using an object class. 

access to filter="(objectClass=macAddress)" 

• The attributes affected by the directive can be defined using attrs, the following uses the user and 

group IDs as an example: 

access to attrs=uidNumber,gidNumber 

7.4.3 Definition of the access permissions on the objects 

Each permission directive starts with the by statement. It determines which user can access the object 

specified in the access directive. A number of syntax possibilities are available here: 

Each definition of users with access permissions is followed by the assigned permission and optionally an 

option, which controls the manner in which subsequent rules are controlled; see the following Sections: 

184 

• * applies the rule to all users. 

• Non-authenticated accesses are covered by anonymous. This makes it possible, for example, to 

allow access to an attribute necessary for an authentication only for the authentication phase and 

block it for users who are already logged on. 

• The opposite to the above-mentioned anonymous is users. 

• The self rule defines the accessing object’s access to its own attributes. This allows a user or 

computer object to change its own attributes. 

• dn can be used to specify the access using the accessing object’s DN. This can be entered in 

different forms:

– Using a concrete DN via dn.base, e.g., via 

by dn.base="uid=database-admin,cn=users,dc=company,dc=com" 

– Using a regular expression, e.g., via 

by dn.regex="cn=.*,cn=dc,cn=computers,dc=company,dc=com" 


• group can be used to set the permission for a member of a group. In addition, the object class of 

the group object and the attribute must be specified, which identifies a member. A group permission 

in UCS looks as follows: 

by group/univentionGroup/uniqueMember="cn=Domain Admins,cn=groups,dc=company,dc=com" 

• peername, sockname and domain allow the definition of the socket file name or the network origin 

of the accessing user. Some examples: 

by sockname="PATH=/var/run/slapd/ldapi" 

by peername.ip=127.0.0.1 

by domain.subtree=example.com 

7.4.4 Definition of the permission on the objects 

Each by directive is completed with the assigned permission. The rules are ordered hierarchically with 

each following rule receiving all the privileges of its predecessor. 

• none denies every access. 

• disclose denies the access but still issues an error warning. 

• auth limits access to authentication and authorisation requests. 

• compare limits the access to compare operations. 

• search limits the access to search requests. 

• none allows read-only access. 

• write allows write access. 

7.4.5 Definition of the handling of further rules with applied rules 

For each by directive there are three possibilities for controlling how further rules are handled: 

• As standard the processing of further access rules is stopped when a rule applies. This can also be 

fixed explicitly using a stop directive. 

• continue allows the processing of further permission rules within an access rule. 

• break checks further access rules to see whether they apply. 

185


7.4.6 Delegation of the privilege to reset user passwords 

To facilitate the delegation of the privilege to reset user passwords, the univention-admingrp-user- 

passwordreset package can be installed. It uses a join script to create the User Password Admins 

user group, in so far as this does not already exist. 

Members of this group receive the permission via additional LDAP ACLs to reset the passwords 

of other users. These LDAP ACLs are activated automatically during the package installation. To 

use another group, or a group that already exists, instead of the User Password Admins group, 

the DN of the group to be used can be entered in the Univention Configuration Registry variable 

ldap/acl/user/passwordreset/accesslist/groups/dn. 

Passwords can be reset via Univention Directory Manager. In the default setting, Univention Directory 

Manager only offers the user wizard to the Administrator user, which allows the setting of new passwords. 

During the installation a new default-user-password-admins policy is created automatically, which can 

be linked to the members of the User Password Admins group and/or a corresponding container in the 

LDAP directory. 

The policy makes it possible to search for users and create an overview of all the attributes of a user object. 

If an attempt is made to modify further attributes in addition to the password when the user does not have 

sufficient access rights to the LDAP directory, Univention Directory Manager denies him write access with 

the message Permission denied. 

Attention: 

The package should be installed on the domain controller master and the domain controller backup sys- 

tems. During the installation, the LDAP server is restarted and is thus temporarily unavailable. 

To prevent the resetting of the passwords for certain users (e.g., domain administrators), the UIDs of the 

users to be protected can be entered, separated by commas, in the Univention Configuration Registry 

variable ldap/acl/user/passwordreset/protected/uid. Once a variable has been changed, it is 

necessary to restart the LDAP directoy service using the /etc/init.d/slapd restart command for 

the changed LDAP ACLs to take effect. In the default setting, the Administrator user is protected against 

having his password changed by the User Password Admins group. 

If access to additional LDAP attributes should be necessary for changing the pass- 

word, the attribute names can be expanded in Univention Configuration Registry variable 

ldap/acl/user/passwordreset/attributes. After the change, the LDAP directory service 

must be restarted for the change to take effect. This variable is already set appropriately for a UCS 

standard installation. 

186

8 Services for Windows 

Contents 

8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 

8.2 Univention Corporate Server and Samba . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 

8.2.1 Authentication Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 

8.2.2 File server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 

8.2.3 Print server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 

8.2.4 NetBIOS Network Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 

8.3 Building Samba domains with UCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 

8.4 Extended Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 


8.4.1 Trust relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 

8.4.2 WINS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 

8.4.3 NETLOGON share . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 

8.4.4 Creating objects in the LDAP directory using Samba . . . . . . . . . . . . . . . . . . 197 

8.4.5 Configuring Windows user accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 

8.4.6 Configuring Samba servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 

For the purposes of Windows systems, Univention Corporate Server can assume the tasks of Windows 

server systems. These tasks comprise, among other things, the functions of a domain controller as well 

as file services and authentication services within Samba domains. 

Printer services can also be provided over Samba. Trust relationships are possible between Samba and 

Windows domains. 

Alongside the chapters listed here there is also further documentation available on the topics of Windows 

domain migration with UCS [15] and the automatic installation of Windows clients with UCS [4]. 

8.2 Univention Corporate Server and Samba 

In the following, a domain with domain controllers based on UCS with the Samba component in which the 

members communicate using the SMB/CIFS protocol amongst other things is called a Samba domain. 

In the following, a domain with domain controllers based on Microsoft Windows NT in which the members 

also communicate using the SMB/CIFS protocol is called a Windows NT domain. The same applies for 

Windows 2000/2003 etc. domains. 

The program Samba serves as a kind of switchboard between the Windows clients and the UCS server. 

187


With this program a UCS server can adopt the role of a member server and the role of a primary domain 

controller (PDC) or a backup domain controller (BDC) in the domain (More information on server roles can 

be found in Chapter 2.1. 

Thus, the combination Samba/OpenLDAP is a hybrid between Windows NT domains and Active Directory. 

From the perspective of a Windows client, it is a Windows NT domain. Univention AD Connector can be 

used for connecting an Active Directory service. 

However, as far as the administration of user, group and computer information is concerned, it is a complete 

directory service based solution with all of its advantages. 

Attention: 

Replication between Windows-based and Linux-based domain controllers is not implemented in Samba as 

standard. Univention can, however, provide Samba BDC packages for UCS, with which a UCS system can 

be operated under a Windows NT PDC (primary domain controller) in a Windows NT domain as a BDC 

(backup domain controller). Otherwise only domain controllers with the same directory service can be used 

within one domain, so that changes can be replicated to the other directories from the changed master 

directory. That means that without the expansion mention above, it is not possible to operate Windows- 

based domain controllers and Samba-based domain controllers with OpenLDAP in one domain. Notes on 

the synchronisation of directory service objects with Windows 2000/2003/2008 with Active Directory can 

be found in the documentation for the Univention Active Directory Connector [16] 

Further reading on Samba can be found on the website http://www.samba.org/. 

8.2.1 Authentication Service 

The passwords are stored in the LDAP directory. Users are authenticated against the LDAP directory 

when logging into the domain with their username and password, and can then access all the shared 

resources of the domain without having to enter their username and password again. Computers with any 

kind of Windows operating systems are authenticated in the same way as in Windows NT domains, via 

the NTLMv2 protocol. 

8.2.2 File server 

Users working on Windows clients can also store their files on an UCS server. This process is transparent 

for the users since they can store their files on a drive, as with Windows. Per default the home directories 

of all users are shared by Samba and assigned as drive I: after login. Univention Directory Manager allows 

the drive letters to be adapted in a comfortable way for each user (see chapter 4.5.1, tab Windows). 

The share management of Univention Directory Manager makes it possible for users to share other direc- 

tories of the Linux file system within the domain in the form of Windows shares (see chapter 4.5.5). 

Recommendable file systems on the Linux side are ext3 and XFS. These file systems allow the use of 

Access Control Lists (ACLs) and disk space restrictions (quotas) for users or user groups. Both of these 

features can be configured under Windows. 

188

8.2.3 Print server 

8.3 Building Samba domains with UCS 

Samba offers the possibility of sharing printers set up under Linux as network printers for Windows clients. 

In UCS, printers can be configured in the Univention Directory Manager printer management (see Chap- 

ter 4.5.7). When doing so, it is possible to use a printer driver coordinated for the printer in question on the 

client or to set a PostScript printer driver for all printers, whereby the Linux print system then converts the 

PostScript into the appropriate printer language. 

The second solution (PostScript) offers the advantage that no further printer driver administration is re- 

quired on the Windows side. On the other hand, PostScript printer drivers cannot satisfy certain require- 

ments of some printer models, so that the use of Windows printer drivers may be necessary in these 

cases. These drivers can be provided centrally on the Samba server and are available to all Windows 

clients. 

As standard, UCS uses Common UNIX Printing System (CUPS) as the spool system for Linux. CUPS 

is ideally suited because it supports a large number of printers and printer protocols. In addition, CUPS 

offers a web interface which allows local changes such as printer restarts. 

8.2.4 NetBIOS Network Service 

Windows systems use NetBIOS as a network protocol for resolving host names and for network commu- 

nication wich is usually based on TCP/IP. 

Host names can have a maximal length of 15 characters in Windows networks, the notification to other 

systems is performed via broadcasts. 

Samba maps NetBIOS functions by means of the system service nmbd, and thus permits a seamless 

integration in Univention Corporate Server. 

The NetBIOS name of a UCS system by default corresponds to the host name. In Univention Management 

Console, a different NetBIOS name can be assigned with the help of the Univention Configuration Registry 

variable samba/netbios/name. The variable samba/netbios/aliases can be used for arranging 

additional NetBIOS aliases for the system. Thus, in case of a migration, processor names used within the 

Windows domain can be assigned as NetBIOS names or NetBIOS aliases beforehand. After changes to 

the NetBIOS service, Samba has to be restarted. 

8.3 Building Samba domains with UCS 

This chapter uses the example of building of a new Samba domain with UCS in an organisation with 

headquarters and two branches to illustrate this concept. 

A PDC is set up in the headquarters along with a BDC which helps the PDC in cases of high traffic and 

can replace it in the event of a collapse. So that the branches can also continue to function if there are 

network problems, they also receive a BDC each. These BDCs function solely as authentication servers 

and are not intended to replace the PDC in the event of a collapse. 

Windows-based clients can be integrated into the Samba domain as in a Windows NT domain. The Samba 

domain receives the first part of the DNS domain as its name (see also Chapter 8.4.6.1). 

189


A DC master with Samba automatically offers the PDC function. DC backup and DC slave servers with 

Samba can be used as BDCs; member servers with Samba as so-called member servers. The package 

univention-samba-slave-pdc is used to use systems apart from the DC master as the PDC (e.g., domain 

controller backup, domain controller slave and member server). In general it should be noted that only one 

PDC can be installed on a network as visible via Broadcast and WINS (see also Chapter 8.4.2). 

Building a Samba domain involves the following steps: 

1. As standard the PDC of a Samba domain is on the DC master. The DC master must thus be 

installed using the Samba package from the Services for Windows component. A PDC must be 

set up before join scripts of other Samba systems can be run. 

2. Windows clients are joining the domain 

3. Installation of BDC in headquarters as DC backup with Samba. The joining of the domain and 

replication of the LDAP directory from the DC master occur automatically. 

4. Installation of BDCs in the branches as DC slave with Samba. The joining of the domain and repli- 

cation of the LDAP directory from the DC master occur automatically again. 

5. Addition of further objects in the LDAP directory Univention Directory Manager. 

The domain joins of the Windows clients can also be effected at the end. It is only important the DC master 

is installed first of all. Changes to the LDAP directory can only be made on the DC master and are then 

automatically replicated on the Samba domain controllers. 

To increase security, the replication range of the Samba domain controllers in the branches can be limited. 

To do this, the LDAP ACLs are adapted so that only the branches of the LDAP directory which are actually 

needed in the branch are replicated in the branch and there is no access to the other areas. 

Notes on joining domains with Windows systems can be found in Chapter 2.4.2. 

8.4 Extended Configuration 

8.4.1 Trust relationships 

Trust relationships between domains make it possible for users from one domain to log on to computers 

from another domain. If a Windows domain trusts a Samba domain, there is also the possibility to log 

on to the Samba domain alongside the Windows domain when logging on to computers belonging to the 

Windows domain. Users from the Samba domain signal this when logging on and are authenticated by a 

domain controller in the Samba domain. 

If a Samba domain trusts a Windows domain, users from the Windows domain enter the user name 

+ when logging on to a Linux computer belonging to the 

Samba domain. In this way the users can also log on on the Linux workstations of the UCS domain. 

The user’s home directory is created under /home/- on 

the PC or BDC on which the user was authenticated. 

A user smith from the WIN domain would thus enter e.g., WIN+smith to log-in. His home directory would 

have the path /home/WIN-smith in Linux. 

190


When setting up and using the trust relationship the domain controllers of both domains must be able to 

reach each other over the network and identify each other using broadcasts or WINS. 

8.4.1.1 Windows domain trusts Samba domain 

1. In Univention Directory Manager ➞ Computer a Domain Trust Account must be created - with a 

name reflecting the NetBIOS name of the Windows domain - and a password issued for the account. 

The password quality requirements which may apply to Windows domains must be observed. 

2. A trust relationship must be created on the Windows PDC (see below). The NetBIOS name of the 

Samba domain is required for this. 

3. The trust relationship between the Windows domain and the Samba domain can be removed by 

deleting the trust relationship on the Windows PDC and the domain trust account in Univention 

Directory Manager. 

Windows NT 

1. The user manager usrmgr.exe must be started on the Windows PDC and selected in the menu 

Policies ➞ Trust Relationships ➞ Trusted domains ➞ [Add]. 

2. The NetBIOS name of the Samba domain must be entered in the input field Domain and the pass- 

word of the domain trust account entered in the input field Password. Clicking [OK] prompts the 

message The trust relationship with has been set up successfully. 

Windows 2000 

1. The menu for trust relationships can be found under Start ➞ Programs ➞ Administrative tools ➞ 

User manager for domains on the Windows PDC. Right clicking on the personal domain opens the 

Properties dialogue. 

2. Following selection of Trust relationships ➞ Trusting domains ➞ [Add], the NetBIOS name of the 

Samba domain can be entered in the input field Trusting Domain and the password of the domain 

trust account can be entered in the input field Initial password. The password must be repeated. 

Clicking [OK] set up the trust relationship. If the procedure is successful, a confirmation message is 

displayed, which can be confirmed with [OK]. 

Windows 2003 

Attention: 

The documentation was based on Windows Server 2003 Standard Edition. 

1. The menu for trust relationships on the Windows PDC can be reached via Start ➞ Administrative 

Tools ➞ Active Directory Domains and Trusts. Right clicking on the personal domain opens the 

Properties dialogue. 

2. When Trusts ➞ New Trust is selected, the New Trust Wizard is opened and must be confirmed 

with [Next]. 

191


3. Once the NetBIOS name of the Samba domain has been entered, this must also be confirmed with 

[Next]. 

4. One-way: outgoing must be selected as the direction for the trust relationship and confirmed with 

[Next]. 

Three functions are available: 

A unidirectional trust relationship is a connection created between two domains for authentication in 

one direction. This means that in a unidirectional trust relationship between domain A and domain 

B, the users in domain A have access to the resources in domain B. The users in domain B do not, 

however, have accesses to the resources in domain A. If such a trust relationship is to be set up 

in domain A, the One-way: outgoing function should be selected. If domain B should receive this 

permission, One-way: incoming should be selected in domain A. In One-way relationships it is 

important to note whether the connection is to be transitive or not. 

The transitivity determines whether a trust relationship can be expanded on domains apart from the 

two domains in which it was created. A transitive trust relationship can be used to expand trust 

relationships on other domains whilst non-transitive ones do not allow this expansion. 

In a bidirectional trust relationship domain A trusts domain B and domain B trusts domain A. This 

means that the authentication requests are exchanged in both directions between the two domains. 

5. If users from the Samba domain should be made equal to users from Windows domains, Domain- 

wide authentication must be activated. If users from the Samba domain should only be endowed 

with certain permissions in the Windows domain, ucsMenuEntrySelective authentication is sufficient. 

The permissions can be configured in Windows once the trust relationship has been concluded. 

[Next] must then be clicked to move to the next dialogue. 

6. Once the domain trust account password has been given in the input fields Trust password and 

Confirm trust password, [Next] is used to pass to the next setting. 

7. Once the settings for the trust relationship have been checked, any necessary changes can be made. 

Clicking [Next] creates the trust relationship. 

8. This step simply shows the changes made. [Next] is used to pass to the next step. 

9. When it has been verified that a domain trust account has been created and a connection can be 

made to the PDC, Yes, confirm the outgoing trust. must be activated and [Next] selected. 

10. The change status The trust relationship was successfully created and confirmed. is now 

shown and this step confirmed with [Finish]. 

8.4.1.2 Samba domain trusts Windows domain 

192 

1. The winbind package must be installed on the Samba PDC and the Winbind service winbindd 

must be running. Winbind assigns UNIX IDs to Windows users and groups 

Univention Management Console can be used to check whether the winbind package is installed 

on the server. If this is not the case, it must be installed (see Chapter 5.3.11). 

Once installed, the winbind service starts automatically. Depending on which services are 

to use winbind, the Univention Configuration Registryvariables auth/admin/methods and/or


auth/user/methods must be expanded with winbind using Univention Management Console (see 

Chapter 5.3.5), e.g., to krb5 ldap unix winbind. 

If the winbindd process cannot be found in the process list in Univention Management Console, it 

must be started there (see Chapter 5.3.9). 

On a domaincontroller master/backup 

net idmap secret WINDOWSDOMAIN $(cat /etc/ldap.secret) 

needs to be called. 

On a domain controller slave or a member server 

net idmap secret WINDOWSDOMAIN $(cat /etc/machine.secret) 

needs to be executed instead. 

2. A trust relationship must be created on the Windows PDC (see Chapter 8.4.1.2). Any requirements 

for Windows applicable to the Windows domain must be taken into account when choosing the 

password for the trust relationship. The NetBIOS name of the Samba domain is required for this. 

3. The root user must run the following command on the Samba PDC: 

net rpc trustdom establish 

The winbind service must then be restarted over Univention Management Console. 

must be replaced with the NetBIOS name of the Windows domain. The com- 

mand requests the input of a password; the password used on the Windows PDC must be entered. 

The message Trust to domain established then appears. 

Attention: 

This command must be run on all Samba log-in servers (domain controller master, backup and 

slave). 

The command occasionally provokes unjustified error messages such as Could not connect to 

server . The following command can be used to check that the trust 

relationship has been added correctly: 

net rpc trustdom list 

The password of emphroot on the Samba PDC or BDC should be used. The command display 

should be similar to the following: 

Trusted domains list: 

S-1-5-21-1275210071-1060284298-839522115 

Trusting domains list: 

none 

The System log in Windows can offer help in problem containment when troubleshooting. 

4. The command 

net rpc trustdom revoke 

can be used to remove the trust relationship with the Windows domain. The trust relationship must 

also be removed from the Windows PDC. 

193


194 

5. Attention: 

The nscd service must be restarted following each of the following settings, e.g., over Univention 

Management Console. 

Windows NT 

a) The user manager usrmgr.exe must be started on the Windows PDC and selected in the menu 

Policies ➞ Trust relationships ➞ Trusted domains ➞ Add. 

b) The NetBIOS name of the Samba domain must be entered in the input field Account for 

domain and a password of your choice entered in the input field Password. Once the password 

has been confirmed, the set-up can be completed by clicking on [OK]. 

Windows 2000 

a) After selecting Start ➞ Programs ➞ Administrative tools ➞ User manager for domains on 

the Windows PDC, right clicking on the individual domain and selecting Properties ➞ Trust 

relationships ➞ Trusting domains ➞ [Add] opens the set-up dialogue. The NetBIOS name 

of the Samba domain must be entered in the input field Trusting domain and a password of 

your choice entered in the input field Password. Once the password has been repeated, this 

can be confirmed with [OK]. 

b) If the message To verify the new trust, you must have permissions to administer trusts 

for the domain ’Name of Samba domain’. Do you want to verify the new trust? appears, 

it should be declined with [No]. 

Windows 2003 Attention: 

The documentation was based on Windows Server 2003 Standard Edition. 

a) After selection of Start ➞ Administrative tools ➞ User manager for domains on the Win- 

dows PDC, right clicking on the individual domain opens the Properties dialogue. 

b) The Windows domain must be operated in mixed mode. This is displayed on the General tab 

by Domain mode: Windows 2000 mixed mode. 

c) Following selection of Trust relationships ➞ [New trust relationship] the assistant for new 

trust relationships opens, which can be continued with [Next]. 

d) The NetBIOS name of the Samba domain must be entered in the input field Name; this must 

be confirmed with [Next]. 

e) The connection should be configured as Intransitive to suppress access to the resources of 

domains with which the Windows domain already has entered into a trust relationship. 

f) One-way incoming must be selected as the direction for the trust relationship and confirmed 

with [Next]. 

g) Following entry of a password into the input fields Trust password, [Next] must be clicked. 

h) Following verification of the settings for the trust relationship and performance of any necessary 

changes, the trust relationship can be established by clicking [Next]. 

i) The changes shown must be confirmed [Next].

8.4.2 WINS 


j) No, do not confirm the incoming trust should be selected and confirmed with [Next]. 

k) The displayed change status of The trust relationship was successfully created and con- 

firmed. must be confirmed by clicking on [Fertig stellen]. 

l) The trust relationship is displayed under Trusted domains (outgoing trust relationship) 

Windows operating systems use so-called NetBIOS names when operating in networks. Similar to DNS in 

TCP/IP networks, the Windows Internet Name Service (WINS) is used for resolving such NetBIOS names 

into IP addresses. In addition, WINS provides information on the services of the hosts. 

The WINS service can also be adopted by Samba. WINS data can also be replicated among several 

systems. Information on setting up WINS replication can be found in the Univention Support database at 

http://sdb.univention.de/1107 

If only one WINS server is being used and this server should collapse, the WINS server can be activated 

on another Samba server by inputting a few commands (see Chapter 8.4.2.1). 

WINS is activated by setting the Univention Configuration Registry variable windows/wins-support 

on the desired Samba server to yes. (Correspondingly, WINS is deactivated by emptying the variable or 

setting it to no). 

As standard, WINS support is activated on the PDC. If more than one Samba server is being used, other 

servers can be assigned the FQDN or the IP address or the WINS server via the Univention Configuration 

Registry variable windows/wins-server. 

The Univention Configuration Registry variables are used for setting the Samba parameters wins sup- 

port and wins server. On a Samba server where WINS is activated, there may be no WINS server 

entered in the Samba configuration. This is why the value of the Univention Configuration Registry vari- 

able windows/wins-server is only entered into the Samba configuration if windows/wins-support 

is not set to yes. 

If the value of windows/wins-support or windows/wins-server is changed, Samba has to be re- 

started via Univention Management Console in order to make the changes valid. 

The WINS server can be made known to the Windows clients via DHCP. To do this the WINS server must 

be entered in the [NetBIOS] tab for the corresponding DHCP object in Univention Directory Manager or 

connected with a container above the object using a DHCP-NetBIOS policy. 

When migrating a Windows domain where the Samba-WINS server is using the same IP address as the 

Windows-WINS server, there is no need to enter a new WINSServer on Windows clients which have no 

DHCP. A virtual network interface on the Samba-WINS server which has the IP address of the Windows- 

WINS server assigned, serves the same purpose. 

8.4.2.1 Replacing a collapsed WINS server 

The following steps must be taken to replace a collapsed WINS server. 

195


1. The Univention Configuration Registry variable windows/wins-support must be set to yes using 

Univention Management Console on the Samba server which should offer WINS from this point 

onwards 

2. The Samba service must be restarted 

3. Existing systems must be configured to the address of the new WINS server using, for 

example, a DNS alias record (see Chapter 4.5.9.2), a DHCP-NetBIOS policy (see Chap- 

ter 4.5.11.5) or for Samba servers by configuring the Univention Configuration Registry variable 

windows/wins-server. 

8.4.3 NETLOGON share 

The NETLOGON share serves the purpose of providing system policies and logon scripts in Windows 

domains. Under UCS, the directory /var/lib/samba/netlogon is set up as the Samba share NETL- 

OGON. 

The NETLOGON share must be available on all Samba domain controllers and contain the same contents. 

To provide this guarantee,changes are only made on the DC master (even when Samba is not installed on 

the DC master) and synchronised (as standard hourly) encrypted with the help of the programs rsync und 

ssh to all DC backup and DC slave systems on which Samba is installed The synchronisation intervals 

can be changed on the individual servers in the /etc/cron.d/univention-samba file. 

8.4.3.1 Logon Scripts 

Logon scripts are executed on Windows computers after successful login of a user. They permit a variety 

of changes to be made in the user’s environment before he can work within the system. The logon script 

can be found in the scripts directory of the Samba share NETLOGON. Chapter 8.4.5 explains how other 

login scripts on Samba level and on user level can be defined. Scripts have to be saved in a format which 

can be executed by Windows, such as bat and cmd. 

Under Windows, the 

net user / domain 

command is used for checking if a logon script is assigned to the user stated in username and if so, which 

script this is. 

The Univention Configuration Registry variable samba/logonscript can be used for defining a global 

logon script. If this variable is set on a Samba server, then all users logging into this Samba server have 

the specified logon script assigned. 

8.4.3.2 System policies 

Samba supports the use of so-called system policies which are created and edited under Windows by the 

tool poledit.exe. System policies allow a large number of presettings to be made concerning users and 

clients. For example: Users can be restricted to execute only a small number of predefined programs. 

196


System policies have to be stored in a Windows or Samba domain in the NETLOGON share and have to 

be named ntconfig.pol. 

8.4.4 Creating objects in the LDAP directory using Samba 

If user or group accounts are created in a Samba domain or a Windows computer joins the domain, these 

data are entered in the LDAP directory via Samba. 

To do this, initially it is checked if an object with the same name already exists in the LDAP directory. These 

existing objects will be adapted to the new data. 

If the objects do not yet exist in the LDAP directory, the accounts are created in stan- 

dard containers. These standard container can be determined with the Univention Configura- 

tion Registry variables samba/defaultcontainer/user, samba/defaultcontainer/group and 

samba/defaultcontainer/computer. The full DN of the container in question must be used. For 

example, if the Univention Configuration Registry variable samba/defaultcontainer/group is config- 

ured to the cn=windows-groups,cn=groups,dc=firma,dc=com container using Univention Management 

Console, this becomes the standard container for group accounts. The variables can contain differing val- 

ues on different Samba servers. In this way, for example, computers at location 1 can be stored in a differ- 

ent container from computers at location 2. If these variable are not set, the containers cn=users,, cn=groups, and cn=computers, are used. 

When NT user accounts are imported, the standard containers are used of the server on which the migra- 

tion script is run. Existing objects are described in more detail in the migration documentation [15]. 

8.4.5 Configuring Windows user accounts 

Settings which are to be valid for all the Windows user accounts, are made in the Samba configuration. 

This configuration consists of the file /etc/samba/smb.conf and the files integrated therein. Many 

parameters of the Samba configuration can be set via the Univention Configuration Registry variables. 

Where several servers are in use, the Samba configuration applicable for each user is that one which 

belongs to the server against which the user is authenticated. User-specific settings can be defined via 

the menu Univention Directory Manager ➞ Add/Find Users ➞ Windows 

UNIX directories which are to be used under Windows, have to be set up as Samba shares (see chapter 

4.5.5). In the following examples, is to be replaced with the NetBIOS name of the server 

on which the directory is located (siehe Kapitel 8.4.6). 

8.4.5.1 Windows home directory 

Samba automatically provides the user’s Linux home directory as a drive letter under Windows. 

The Samba configuration contains the parameter logon home, which by default is resolved to 

\\\, for example \\ucs-samba-server\meier. Accordingly, 

the directory will show up under Windows on the home drive (see chapter 8.4.5.2) as a directory named 

after the username. 

197


A different server can be arranged in the Samba configuration via the Univention Configuration Reg- 

istry variable samba/homedirserver, and a different directory for logon home via samba/homedirpath. 

These values will then be valid for all the users. 

If these variables as well as samba/homedirletter are set to local, then no directory will be automati- 

cally provided under Windows, and the settings specified in Univention Directory Manager, if available, are 

used. 

In Univention Directory Manager, a user-specific server and directory can be defined in the entry field 

Windows Home Path. If a different server than that which is predefined in the Samba configuration, is to 

be applied for the user, then this server as well as the username for the home directory is to be entered in 

the corresponding entry field., e. g.: \\ucs-file-server\meier. 

If instead of the user’s UNIX home directory, a different UNIX directory is to be displayed as the home 

directory on the Windows drive, then this server as well as the home directory is to be entered in the 

Windows Home Path entry field. 

8.4.5.2 Drive for the home directory 

The parameter logon drive within the Samba configuration defines on which Windows drive the users’ 

UNIX home directories are to show up by default. Under UCS, this drive is by default I:. 

Should this drive letter be assigned otherwise, or if a different drive letter is to be used for 

other reasons, then this value can be changed via the Univention Configuration Registry variable 

samba/homedirletter in the Samba configuration. 

If this variable as well as samba/homedirserver and samba/homedirpath are set to local, then no 

drive will be mounted, and the settings from Univention Directory Manager, if available, will be used. 

If only a certain number of the users are to have their home directories show up on a different Windows 

drive, then the respective drive letter and colon is to be entered in the entry field Windows Home Drive in 

Univention Directory Manager. 

8.4.5.3 Logon Script 

If a user logs into Windows, a so-called logon script can automatically be started. The default logon script 

can be found in the scripts directory in der Samba share NETLOGON which in UCS provides the directory 

/var/lib/samba/netlogon (see chapters 8.4.3 and 8.4.3.1). 

A different, user-specific login script relative to the NETLOGON share, meaning relative to 

/var/lib/samba/netlogon, can be arranged in the entry field Logon script of Univention Directory 

Manager. If for example, /var/lib/samba/netlogon/scripts/meier.bat is to be applicable to the 

use meier, then scripts\meier.bat is to be entered. This corresponds to the Samba configuration 

parameter login script. 

198

8.4.5.4 Profile directory 


The user profile for the Windows user interface is stored in the profile directory. In the Samba 

configuration there is the parameter logon path, which under UCS is by default resolved to 

\\\\windows-profiles\. 

This directory is also used for storing the files which the user saves under Windows in the My documents 

folder. Initially, these files are stored locally on the Windows computer; they are only stored on the drive of 

the Samba server after the user has logged out of Windows. 

The Univention Configuration Registry variable samba/profileserver can be used for specifying a 

different server, the variable samba/profilepath for defining a different directory for logon path. 

A different path or server for the user’s profile directory can be configured in the Windows Profile Path 

entry field of Univention Directory Manager Example: \\ucs-file-server\meier\profiles\winXP. 

If the path is changed at a later date, then a new profile directory will be created. The data in the old profile 

directory will be kept. These data can be manually copied or moved to the new profile directory. Finally, 

the old profile directory can be deleted. 

Profiles stored on the server can be deactivated by setting the Univention Configuration Registry variables 

samba/profilepath and samba/profileserver to local. The Samba service has to be restarted 

after this procedure. 

If further BDCs should be used alongside the PDC, this setting must also be performed on other systems. 

8.4.5.5 Relative ID 

All users, groups and processors within a Windows domain have a security ID (SID) consisting of two 

parts. The first part is identical for all users and groups of the domain, and different from those of other 

domains. The second part is used for distinguishing the users and groups within the domain. This part 

is called relative ID (RID). Thus the overall SID is unique for each object. The RIDs from 0 to 999 are 

reserved for standard groups and similar special objects. 

8.4.5.6 Password characteristics for Windows clients 

In Univention Directory Manager, specifications for user passwords can be defined regarding minimum 

length, password quality and password history, via the policy Password. These presettings have an 

indirect influence on passwords changed under Windows. 

The background: Samba accepts password changes made by Windows clients, and passes them on to 

the Univention Directory Manager. In Univention Directory Manager the policy Password is analysed; 

if the policy is violated, say by a password consisting of too few characters, then the password change 

is rejected. Samba returns to the Windows client the message: You are not authorised to change the 

password. 

To make it possible for Samba to return meaningful error messages to the client, some settings regarding 

password properties can be made in the Samba configuration. 

199


To do this, the Samba domain object must be edited in Univention Directory Manager. 

In Univention Directory Manager the ucsMenuEntrysamba container can be opened via Navigation. This 

contains the entry Settings: Samba domain, which can be edited. 

The same value should be used as Password length as is used in the Password policy (the preset value 

of the policy 8). The same value should be used for Passwort history as is used in the Password policy 

(the preset value is 3). These settings can be saved by clicking [Ok]. To facilitate later troubleshooting, the 

settings in the Password policy and Samba settings object should be identical. 

The next time passwords are changed on Windows computers an appropriate error message will be given 

if this setting is violated. 

Attention: 

The settings of the Samba Domain object only apply to Windows clients. Settings which can be also 

be configured in the same way in Univention Directory Manager should be kept synchronised wherever 

possible. 

Further Samba domain password features for Windows clients can be configured via the Samba domain 

object. 

Parameter Description 

Minimum password age This is the minimum interval which must elapse before a pass- 

word can be changed again. If no value is set, the password 

can be changed again immediately. 

Maximum password age The maximum age of a password before it must be changed. 

Failed log-in attempts before 

blocking 

If no value is configured, the password will remain valid indefi- 

nitely. It is advisable to keep the password expiry intervals for 

the UCS and Samba domains the same. 

The number of possible failed log-in attempts before an account 

is blocked. 

Duration of blocking Duration of blocking when log-in fails too many times. 

Reset failed log-in attempts The number of successful log-ins which are required to reset 

Password change requires log- 

in 

the saved number of failed attempts. 

When the option is selected, passwords can only be changed 

when the user is logged in successfully. 

Disconnect after Configures the maximum length of a logged-in session. 

Reject change to computer 

password 

8.4.6 Configuring Samba servers 

8.4.6.1 Samba domain name 

This option declines all requests to change a computer pass- 

word. 

As standard a Samba domain in UCS receives the first part of the DNS domain name as its name. Thus 

if the DNS domain name is firma.com, the Samba domain is called firma. 

200


This name is stored in the LDAP directory when the DC master is installed, irrespective of whether the 

Services für Windows component is saved on the DC master or not. 

When the univention-samba package is installed, the Univention Configuration Registry variable 

windows/domain is also set to this name, in so far as it doesn’t already exist. 

In environments in which the Samba domain, for example, should have different names at different loca- 

tions, the Univention Configuration Registry variable windows/domain can be set to the desired name 

on the respective local Samba servers. These names must be entered under Navigation ➞ samba in 

Univention Directory Manager as Settings: Samba Domain LDAP objects. When doing this, it must be 

noted that the objects are connected with the same Samba SID despite having different Samba domain 

names in order to compose one single Samba doman despite the different names. 

8.4.6.2 LDAP replication sleep 

The Univention Configuration Registry variable samba/ldap/replication/sleep is used to adapt 

the ldap replication sleep parameter in the Samba configuration. The parameter sets the time interval 

foreseen in Samba for the replication of changes in the LDAP directory (in milliseconds). The preset value 

is 1000 milliseconds (i.e., a second). In environments in which the replication causes delays, e.g., due to a 

slow network connection, it is advisable to set the value higher. The maximum value is 5000 milliseconds. 

8.4.6.3 Windows permissions 

Samba gives administrators the possibility of transferring permissions to other users and thus distributing 

the administrative workload particularly in larger environments. 

Users who are to receive administrator permissions can be entered in the Univention Configuration Reg- 

istry variable samba/adminusers. These users are assigned to the Adminusers Samba group in which 

only the Administrator user is entered as standard. 

To keep the number of Adminusers low, it is advisable to grant users individual privileges rather than full 

administrator permissions. 

That means that the administrator can grant a user a particular privilege which otherwise only the admin- 

istrator would have. To transfer these privileges to other users, they must firstly be activated in Samba, 

where the Univention Configuration Registry variable samba/enable-privileges is set to yes. 

The following command can be used to list the available privileges: 

net rpc rights list -U Administrator 

Here is the output with explanations: 

Privilege Description 

SeMachineAccountPrivilege Allows joining of computers in the domain 

SePrintOperatorPrivilege Allows printer management 

SeAddUsersPrivilege Allows adding of domain users and domain groups 

SeRemoteShutdownPrivilege Allows restart of another computer 

201


SeDiskOperatorPrivilege Allows management of directory shares 

SeBackupPrivilege Allows data backup of files and directories 

SeRestorePrivilege Allows restoration of files and directories 

SeTakeOwnershipPrivilege Allows ownership to be taken of files and directories and thus 

the changing of permissions 

The following command assigns a privilege to specified users: 

net rpc rights grant -U Administrator 

For example: 

net rpc rights grant -U Administrator USER1 SeMachineAccountPrivilege 

The following output appears once the root password has been entered. 

Successfully granted rights. 

USER1 now has the privilege to add new computers to the domain. 

The following command can be used to revoke this privilege: 

net rpc rights revoke -U Administrator 

The following output should appear when the administrator password is entered a second time: 

Successfully revoked rights. 

The following command can be used to list which privileges are assigned to a user: 

net rpc rights list -U Administrator 

8.4.6.4 Samba character sets 

For different systems to be able to communicate with each other, they need to use the same character 

sets (e.g., the German umlauts and the ß are not used in all character sets). The Univention Configuration 

Registry variables samba/charset/unix, samba/charset/dos and samba/charset/display can 

be used to configure character sets. 

As standard the named Univention Configuration Registry variables are empty and Samba uses the preset 

of the operating system, e.g., UFT-8 as the character set. 

8.4.6.5 Support for permissions from extended attributes 

The Samba configuration in Univention Corporate Server allows the saving of DOS file attributes 

(ARCHIVE, HIDDEN, SYSTEM, READ-ONLY) in advanced attributes of the Unix file system. The DOS 

attributes are saved there in user.DOSATTRIB attributes. 

To use extended attributes, the partition must be mounted using the mount option user_xattr. 

Support for the advanced attributes is activated as standard in the UCS kernels for ext2, ext3 and XFS. 

202

9 Desktop systems 

Contents 

9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 

9.2 Desktop system roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 

9.2.1 Thin clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 

9.2.2 Managed clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 

9.2.3 Mobile clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 

9.3 Managing desktop systems with Univention Directory Manager . . . . . . . . . . . . . . . . 205 

9.3.1 Graphical user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 

9.3.2 Connection to server systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 

9.3.3 Autostart scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 

9.3.4 NX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 

9.4 VNC desktop sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 

9.4.1 Configuring VNC access for thin clients . . . . . . . . . . . . . . . . . . . . . . . . . 208 

9.4.2 Configuring VNC access for managed/mobile clients . . . . . . . . . . . . . . . . . . 208 

9.5 Thin client environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 

9.5.1 Support for booting from Compact Flash cards or USB sticks . . . . . . . . . . . . . 210 

9.5.2 Thin client components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 

9.6 Home directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 

9.6.1 Creation of new home directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 

9.6.2 Modifying the default content of home directories . . . . . . . . . . . . . . . . . . . . 215 

9.6.3 Setting environment variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 

9.7 Global home directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 


9.7.1 Creating and modifying global home directories . . . . . . . . . . . . . . . . . . . . . 217 

Univention Corporate Desktop (UCD) allows the flexible application of centrally managed Linux clients for 

desktop workstations and is specially coordinated for use with Univention server systems. 

Univention Corporate Server offers three different types of desktop systems: the managed client for 

stationary desktop systems; the mobile client for mobile clients such as notebook and the thin client for 

diskless workstations. 

A KDE-based user interface and applications configured specially for use in the business landscape (e.g., 

OpenOffice.org) allow efficient work in a modern environment. 

As of UCS 2.3 the GNOME desktop environment is also available. Instructions for setting up GNOME are 

available in the Univention Support database: http://sdb.univention.de/1094 

This chapter describes the configuration and administration of desktop systems, adaptations to the desktop 

and the use of policies in the efficient configuration of larger environments. 

203


9.2 Desktop system roles 

UCS contains three different desktop system roles which can be administrated in Univention Directory 

Manager and were each optimally conceived with a specific field of application in mind. 

The desktop environment can also be installed on any server system role. 

9.2.1 Thin clients 

Thin clients are systems which do not include a hard drive. These systems boot over the network from a 

DC Master, DC Backup or DC Slave server, which acts like a boot server and allows registration on a UCS 

or Windows terminal server. 

When a user logs on to a thin client, the user’s request is forwarded to the authentication server. If 

authentication on the server is successful, a check is performed for whether the home directory is available 

locally or must be called up and mounted from another server. Users can be logged on to several clients 

at the same time, but some applications, e.g. Kontact, can only be used in one user session at a time. 

Having several, simultaneous sessions running can lead to unstable processes. This means that although 

working on two workstations is possible, it is not recommended. 

Thin clients offer no locally installed files, as all software is installed on a server system (the so-called client 

base system). This central administration means that the necessary maintenance work for the installed 

software is considerably reduced. Thin clients cannot be operated when they are not linked up to the 

server systems. From the thin client, the user has access to all resources of the domain as long as any 

relevant permissions have been granted. In addition, thin clients can use local printers connected via USB 

or parallel ports. 

9.2.2 Managed clients 

UCS systems are classified as managed clients when they have a local UCS installation and access to the 

services on the server system. Managed clients can be administrated in Univention Directory Manager 

and usually employ central repository servers for package maintenance. Authentication is performed via 

an LDAP server or using locally cached log-in information. 

Managed clients have a locally installed operating system, which allows them to boot without the need for 

a network connection. The users’ home directories are saved locally and only available for one client. It 

is also possible to save the home directories on a central server; this is described in 9.7. In this case, a 

network connection to this server is necessary for the log-in. 

The log-in and user information and group memberships of the last three users to log on are cached in 

the managed client - the number of log-ins cached can be configured in Univention Configuration Registry 

variable auth/passwdcache/max_user - so that these users can be authenticated without the need for 

a network connection. If the password for this user is changed in the Univention Directory Manager whilst 

the client is not connected to the domain controller via the network, the user will still need to log-in using 

his old password. The password change will be adopted with the next connection to the network. 

204

9.2.3 Mobile clients 

9.3 Managing desktop systems with Univention Directory Manager 

Mobile clients have the same central features as managed clients, e.g., local operating system and access 

to services on the server systems. The mobile client system role is intended for easier identification of 

mobile computers, such as laptops, which are not constantly connected to the domain and on which other 

software is sometimes installed. 

9.3 Managing desktop systems with Univention Directory Manager 

Univention Directory Manager offers a number of different possibilities for managing UCS desktop system, 

which simply the administration of computer environments. 

9.3.1 Graphical user interface 

UCS desktop systems offer a graphical user interface. The X server is used to present this interface. This 

is a program which accepts the output instructions of other programs (e.g., “draw the program interface 

and output the letter A”) and controls the computer hardware accordingly in order to display the graphics 

on the screen. The X server also accepts user inputs via the keyboard and mouse and forwards them on 

to the various user programs. 

In order for the X server to be able to process all information optimally, it must be configured to the 

hardware of the respective computer system (graphics card, keyboard, mouse, monitor). When the UCS 

desktop system is started, the existing hardware is checked automatically and the configuration adapted 

accordingly. 

It can often be preferable to adapt the automatic X server configuration to suit your personal needs, for ex- 

ample: to select a certain screen resolution or a particular keyboard layout. Under certain circumstances, 

e.g., very new hardware, the automatic hardware recognition may not function completely as desired. 

The X server configuration can be adapted in the Univention Directory Manager under Computers ➞ 

[Display settings]. It is also possible to use policies to configure the same settings for complete subtrees 

in the LDAP directory. Further information on the possible settings for the [Display settings] tab can be 

found in the Chapter 4.5.11.5. 

Settings specified here will be read out by the UCS desktop system during system start and adopted in 

the X server configuration. Prerequisite therefor is that the directory service can be accessed at this time. 

9.3.2 Connection to server systems 

Client systems are often mounted in environments with numerous servers systems which can be used 

for various tasks. Services are often distributed over different servers so that any operative loss resulting 

from hardware breakdown is kept as low as possible. The client must thus be aware of which server offers 

which services. 

The most important service, which is used by all UCS desktop systems, is the LDAP server service, which 

is executed on domain controller master, backup and slave systems. During start-up, managed and mobile 

205


clients use the LDAP server service on the DC Master as standard. Thin clients search via DNS service 

records for _ldap._tcp. during start-up and - as long as they are available - attempt to select 

an accessible server in the local subnet. 

If you wish to specify further LDAP servers, these can be entered in the respective computer object on 

the [LDAP servers] tab. This can also be done for several computers using policies. This guarantees 

that if one LDAP server should not be accessible, attempts will be made to revert to further LDAP servers 

for user log-ins and other functions. In addition, entering more LDAP servers can help avoid long waiting 

times when many users attempt to log-on simultaneously. 

For thin clients, the authentication, file, Linux terminal and Windows terminal servers used can also be con- 

figured. These can be entered in the Univention Directory Manager under Computers ➞ ➞ [Thin client configuration]. The authentication server is thus responsible for the Kerberos-based 

user authentication; the file server defines on which server the user’s home directory will be mounted. 

Attention: 

The home directory stated here is used during user log-in to the log-in manager gdm to save the settings 

of the last used session amongst other things. The use of another can be configured for the user for the 

provision of the home directory that will be mounted after successful log-in. Further information on this 

topic can be found in 9.7. 

Alongside UCS terminal servers, thin clients can also access Windows terminal servers. The terminal 

servers that can be used can be entered in the [Thin client configuration] tab. It must be noted for all 

entries that the computer names are stated as fully qualified domain names (FQDN). 

9.3.3 Autostart scripts 

For certain applications, it may be desirable that a UCS desktop system does not require a log-in. This can 

be the case in publically located "surf terminals" or on workstations where one or more users only require 

very few applications and no user-specific data need to be saved. This can be implemented via autostart 

scripts. In this case, a preconfigured user (usually autostart, who only has limited permissions) is logged 

on automatically and one or more preconfigured applications are started. 

A further application case is represented by remote desktop applications like NX, Citrix and rdesktop. 

These automatically create a connection to the relevant server system, where the actual user log-in occurs. 

If an autostart script is already configured for a computer, there is no possibility to log-in to the log-in 

manager GDM or select a session. The automatically logged-on user autostart is not a domain user. 

The required autostart script must be entered in the [Autostart] tab in the Univention Directory Manager 

on the computer object. 

The scripts must be saved under 

/var/lib/univention-client-root/etc/gdm/Autostart 

on the UCS terminal server. When used on UCS managed or mobile clients, they should be saved in 

/etc/gdm/Autostart. 

The sample scripts can already be found there. 

206

9.3.4 NX 

9.4 VNC desktop sharing 

Like VNC, the Windows remote desktop support or Citrix, NX offers the possibility to access the graphic 

interface of a distant system. It offers the possibility to interrupt running sessions temporarily and then 

reinstate them at a later point in time, whereby users logging on to an existing session will find their 

working environment in the same state as it was left with all the previously opened programs running. 

The server components of NX can be installed on all UCS server systems on which the necessary libraries 

for graphic interfaces are also installed. The NX client can be executed on all UCs desktop systems, either 

as an autostart script or manually following user log-in. 

The current NX packages for an NX server can be found in the online repository. The system acting as a 

login host must be able to install the NX server package. The clients must be equipped with the NX client, 

which can be downloaded from the website of the manufacturer, NoMachine. 

The following packages must be installed on the clients for the NX client to run: 

libxcomp1, libxcompext1, nxlibs, libstdc++2.10-glibc2.2, nxclient 

Apart from the nxclient package, which must be downloaded separately, all packages are contained in 

the online repository. The packages should be stored in the repository server used. 

If the NX client is used on a managed or mobile client, the packages can either be installed manually or 

via software distribution. If the NX client is started by an autostart script on a thin client, the necessary 

packages must be installed in the client base system on the terminal server. 

For this, use chroot when on the terminal server to change to the client base system. The necessary 

packages can then be installed with univention-thin-client-apt. 

Following installation the NX client can be used for the autostart script. A sample script for NX can be found 

under /var/lib/univention-client-root/etc/gdm/Autostart/nx. If the file name of the script 

is entered in [Autostart] ➞ Autostart session in the Univention Directory Manager, NX client is started 

when the thin client starts up and the user will be connected to the session stated in the script. 

9.4 VNC desktop sharing 

VNC offers users the possibility to connect to another user’s screen. For example, if problems occur for 

users, administrators have the possibility of viewing the situation and are then in a better position to help 

without having to be at the same client as the user. In addition, there is also the possibility of transferring 

control of the mouse and keyboard over the VNC connection for a limited period of time, so that problems 

can be investigated and solved personally. Before the VNC connection is effected, the user whose interface 

will be shared over VNC must confirm. This request cannot be avoided. Once the user has agreed, VNC 

transmits the data of the local X server to the display of the remote observer and forwards all mouse and 

keyboard activity. 

The access to the client is executed with a VNC remote assistance program. For example, krdc can be 

used in Linux or Ultra VNC in Microsoft Windows. 

207


9.4.1 Configuring VNC access for thin clients 

The package univention-thin-client-vnc needs to be installed on the terminal server for VNC access to 

thin clients. 

For thin clients the connection is controlled by a policy in Univention Directory Manager. To do so, the 

Enable VNC export option must be activated in the Display settings policy. If the tick is placed in 

Viewonly VNC export, the remote user cannot perform any user inputs. 

When the connection is formed, a single-use password is generated which the user who is sharing his 

connection must then pass on. 

9.4.2 Configuring VNC access for managed/mobile clients 

To set up VNC access on a managed or mobile client, this needs to be configured in KDE. 

To do so, the Allow uninvited connections option must be activated in the KDE Control Center under 

Internet & Network ➞ Desktop Sharing 

The option Confirm uninvited connections before accepting (activated by default) ensures that the user 

is informed of the incoming connection request and asked to verify the remote access. 

It is also possible to set a Password. 

The Univention Directory Manager policy referred to in Chapter 9.4.1 is not evaluated for VNC access to 

managed/mobile clients. 

9.5 Thin client environment 

The thin client environment is a self-contained software installation in a subdirectory on each terminal 

server. A booting thin client mounts this subdirectory as its root directory via NFS and starts thus in the 

configured work environment. 

The requirements concerning available programs and services differ depending on the environment and 

the application scenarios. The system is constructed in a modular fashion to allow the possibility to adapt 

the thin client environment flexibly. 

The following describes the main components of the modular base system and how new components can 

be installed. An overview of the general mechanisms for configuring the thin client environment is also 

given. 

Overview 

The central univention-thin-client-basesystem package of the thin client environment provides a base 

system. This allows the booting of thin clients and log-in on the console. 

The univention-thin-client-x-base package must be installed to make a graphic interface available. This 

displays a graphic log-in mask on the thin client from which different X sessions can be started. The fonts 

208


are not installed automatically. These can be found in the additional package univention-thin-client- 

x-fonts. If this package is not installed, they can alternatively be fetched from a font server. Further 

information can be found in Section 9.5.2.7. 

Support for local printers attached to the thin client is provided by a separate package (univention-thin- 

client-cups). The same applies for the use of local USB devices on the thin client (univention-thin-client- 

ltsp) and audio output (univention-thin-client-sound). 

These packages replace all functions of the monolithic thin client base system from earlier UCS versions. 

All these packages are installed as replacements when UCS installations are updated. 

Installation 

All components of the thin client base system are installed via the standard package management tool 

(see Chapter 11). The components contain meta packages which install the necessary expansions for the 

respective components in the subdirectory in the thin client environment. 

The thin client base package includes the command univention-thin-client-apt for this mecha- 

nism, which makes it possible to install packages (including dependencies) in the subdirectory of the thin 

client environment. The tool supports all parameters from apt-get and a few additional, optional, parame- 

ters of its own. When they are given these must be listed before the apt-get options. ’--’ should be entered 

as a separating sign before the apt-get options. The following parameters are available: 

--help, -h: Displays a short help for using the command. 

--prefix, -p: Defines the directory in which the packages should be installed. The predefined value is the 

directory for the thin client environment. 

--arch, -a: Specifies the architecture to be used for the packages. The predefined value here is i386, i.e., 

the thin client environment is also uses i386 packages on amd64 systems. 

--debug, -d: Sets the log level. Possible values are in the region from 0 (no output) to 4 (detailed informa- 

tion) 

With univenton-thin-client-apt further packages can be installed in the thin client environment which are 

not included in the existing components. For example, the following command can be executed to install 

the Emacs editor in the thin client environment. 

univention-thin-client-apt install emacs21 

For example, the following command can be executed to simulate the installation of the emacs21 package 

in a thin client environment below /var/lib/thin-client2. 

univention-thin-client-apt -s -- -p /var/lib/thin-client2 -d 4 install emacs21 

In this the APT configuration of the sources and the cache directory of the terminal server are used. Nec- 

essary dependencies are resolved directly and installed in the thin client environment. A i386 repository is 

necessary for this on amd64 systems. 

Configuration 

The configuration of services on UCS systems is normally performed using Univention Configuration Reg- 

istry. On thin client systems this is possible using Univention Configuration Registry policies (see Section 

14). These can be created in Univention Directory Manager and linked with the thin client objects. 

209


In addition to the Univention Configuration Registry variables which refer directly to the function of individ- 

ual components, there are also certain variable which influence the general behaviour of the thin client: 

thinclient/mount/homedir: The home directory of the logged-on user is mounted per NFS during set-up. 

This can be suppressed with this variable by setting the value to no. 

gdm/sessions/disabled: This variable can be used to remove individual sessions from the GDM selec- 

tion. To do this the sessions script should be given under /etc/gdm/Sessions/ . Where more than 

one session script is used, they should be separated with a colon. 

kernel/modules: If hardware components are not automatically identified, this variable can be used to 

define a list of kernel modules, which are then loaded specifically. The semicolon is used as a 

separating sign when specifying several modules. 

There is also the possibility of deactivating certain services included in the components if they are not 

required. For this, a Univention Configuration Registry variable must be set to no: 

sshd/autostart: Deactivates the SSH service on the thin client. 

portmap/autostart: If the thin client boots over a flash card, the portmapper service is not required. This 

variable can be used to deactivate the service. 

cups/autostart: To suppress the use of printers on thin clients, this variable can be used to deactivate 

the CUPS service itself when the corresponding component is installed. 

9.5.1 Support for booting from Compact Flash cards or USB sticks 

In the standard configuration a thin client boots over the network and mounts its root directory on the 

terminal server with NFS. As an alternative, many thin client models also now have an internal flash card, 

which can be used to boot a minimal system. This technology is supported by the thin client component 

univention-thin-client-flash. 

As an alternative to a local system start from Compact Flash, many thin clients offer the possibility of 

booting from USB mass storage - usually a USB stick. The update process is performed in the same way 

as Compact Flash memory is updated, but the USB device to be recorded on must be configured with 

the Univention Configuration Registry variable thinclient/flash/update/disk. The information is 

entered in the internal notation of the Linux kernel, e.g., /dev/sda1. 

To allow a thin client to boot from an internal flash card, an image must first be installed which contains 

the minimal operating system. This is created from the thin client environment on a terminal server. In this 

way, a thin client which boots over a flash card has the same functions as the thin clients which boot from 

the terminal server on which the image was created. 

The univention-thin-client-flash tool is available for creating the flash image. In the standard configura- 

tion an image is created from the thin client environment available on the terminal server. Alternatively, 

parameters can be used to signal another directory from which the image should be created. 

When booting, a thin client checks whether there is a flash image available. If an image is available on the 

server, a check is performed as to whether it is more up-to-date than the local one (when there is one). If 

the server contains a more up-to-date one, it is downloaded and installed. The next time it is booted the 

thin client can boot the new system from the flash card. 

210


If thin clients with different abilities and configuration are to be included in one environment, there is the 

possibility of creating more than one image. As standard, the flash image created is called root.img. The 

name can be entered when creating the image. A personal version number is maintained for each image, 

so that changes to an image do not affect thin clients with other images. 

The update procedure is carried out for all supported booting methods (PXE, from Compact Flash and from 

USB sticks). The exact procedure can be influenced using Univention Configuration Registry variables: 

thinclient/flash/update: If this variable is set to no the thin client does not perform a flash update, even 

when a newer image is available on the server. 

thinclient/flash/update/url: Defines the URL under which the flash images can be found. The 

name of the image file does not need to be entered here. If the variable is not set, 

a search will be performed for the image under the following URL on the terminal server: 

http:///univention-thin-client-flash/ 

thinclient/flash/update/image: Defines the name of the image file relative to the configured URL. 

9.5.2 Thin client components 

Apart from the basic components, which were also already available in earlier UCS versions for the thin 

client environment, new abilities have also developed, which can be installed optionally in the environment. 

The following section describes the functions and configuration of these components. 

9.5.2.1 Local USB storage devices 

The possibility of mounting local devices on thin clients was already possible in earlier UCS versions but 

has been thoroughly overhauled for UCS 2.1. 

Support for local devices is included in the univention-thin-client-ltsp package. Following installation, a 

service is started on the terminal server, which makes the USB units on the thin client available for the 

terminal server or applications. 

Access to the local units on the thin client occurs over an icon, which is created on the user’s desktop for 

each device. When a unit is removed, the icon is automatically deleted from the desktop. 

9.5.2.2 Secured connections with IPSec 

To use thin clients as a home office, it is advisable to encrypt the communication with the server. This 

possibility is offered by the component for IPSec support. Together with the component for flash cards a 

thin client can boot locally and then open an IPSec tunnel to encode the connection with the corporate 

network. 

The package univention-thin-client-ipsec must be installed on the terminal server to provide IPSec sup- 

port for thin clients. The necessary packages are installed in the thin client environment. This installs a 

service which allows the automatic update of IPSec configurations. If the thin client is started on a local 

network using the flash card, this service checks whether an update for the IPSec configuration is available 

under a specified URL. If this is the case, the configuration is downloaded and saved on the flash card. 

211


The following Univention Configuration Registry variables can be used to configure IPSec: 

thinclient/ipsec/update: This variable must be set to yes so that the thin client performs an IPSec con- 

figuration update when booting. 

thinclient/ipsec/update/url: A URL can be given here where the IPSec configuration can be found. If the 

variable is not set, a search will be performed for the IPSec configuration under the following URL 

on the terminal server: http:///univention-thin-client-ipsec/ 

The IPSec configuration for a thin client must be packed (compressed with gzip) in a tar archive containing 

the following directories and files: 

ipsec.d/cacerts/ 

ipsec.d/certs/ 

ipsec.d/private/ 

ipsec.conf 

ipsec.secrets 

ipsec-setup.sh 

This archive is unpacked directly in the /config 1 directory on the thin client and the corresponding 

symbolic links created in /etc. 

Optionally, a script with the name ipsec-setup.sh can be contained in the archive, which is run before 

the initiation of IPSec. This gives the opportunity to adapt to the respective environment, e.g., setting name 

servers or special routers. 

This type of archive must be created for each thin client which is going to use IPSec and stored on the web 

server. The archive must be named as follows: .tar.gz. The MAC address here is written 

in hyphen notation (e.g., 00-01-02-03-04-05). 

If the archive is saved on the web server and the Univention Configuration Registry variable 

thinclient/ipsec/update set to yes, the thin client will attempt to import a new configuration as 

described above. Thereafter, whenever it is booted the thin client will open a IPSec tunnel over the flash 

card before establishing a connection to the LDAP server. 

9.5.2.3 Audio 

Audio output on the thin client has been thoroughly restructured in UCS 2.1. (Enlightenment Sound Dae- 

mon). ARTS (analog Real time synthesizer) is still the standard network sound server, but this can alter- 

natively be replaced with ESD (Enlightenment Sound Daemon) or PulseAudio. In addition, a Univention 

Configuration Registry policy can be used to set the corresponding variable: 

thinclient/sound/daemon: This variable can optionally be set to esd to use the ESD for audio output and 

to pulseaudio to use PulseAudio. 

thinclient/sound/volume: Defines the volume in percent to be set during start-up. 

The audio service selected is started when a user logs on if support is selected in the management system 

(further details can be found in Section 4.5.11. The service is ended when a user logs off. 

1 This directory mounts a writeable partition on the flash card in the thin client. 

212


If ESD is to be used for audio output, the settings must be adapted in the KDE control centre. To do this, 

the following options must be set in the General tab from the Sound & Multimedia category in the Sound 

System area. 

• Enable the sound system 

• Enable networked sound 

In addition, the Enlightened Sound Daemon value must be selected for the Select the audio device 

option on the Hardware tab. 

9.5.2.4 Scanners 

The univention-thin-client-sane package is used to provide a component which makes it possible to 

operate scanners connected to the thin client. 

The SANE protocol is used for scanner support; it allows scanners to be used over the network. As soon 

as a scanner is connected to a thin client and recognised by SANE an icon appears on the desktop of 

the user who is logged on. This icon can be used to access the scanner. The icon is deleted when the 

scanner is removed. 

Before using a scanner it should be checked whether the model is supported by SANE and to what extent. 

For some models it is also necessary to make a firmware file available on the thin client. This file must be 

copied into the subdirectory of the thin client environment. 

If support from SANE has been verified, the scanner can be connected to the thin client and accessed 

directly using the icon on the user’s desktop. As standard the scanner can only be used from one terminal 

server. If several terminal servers are to be used in the environment or access permitted for other com- 

puters, the Univention Configuration Registry variable thinclient/saned/networks can be set. This 

variable can contain a list of networks separated by commas: 

thinclient/saned/networks=192.168.0.0/24,192.168.1.0/24 

9.5.2.5 SSH access 

The thin client component univention-thin-client-ssh can be used to provide the SSH service on thin 

clients. This offers the possibility of remote diagnosis for thin clients without the need to access the user’s 

x-session. 

When the component is installed a host key is created which is used as standard for all thin clients 

which retrieve their file system from the terminal server or boot a flash image which was created 

on the terminal server. This renders the thin client’s booting process considerably more quick, but 

means that the thin client cannot be clearly identified. The Univention Configuration Registry variable 

thinclient/sshd/generate_key prompts thin clients to create their own host keys during booting. 

For this, the variable must be set to yes. 

213


9.5.2.6 Nagios monitoring 

The component univention-thin-client-nagios is available for monitoring thin clients with Nagios. This 

allows monitoring of both accessibility and the degree of utilisation. 

For monitoring how accessible the thin client is the Nagios service UNIVENTION_PING can be activated 

on the thin client object as for other UCS system roles in Univention Directory Manager. For monitoring 

the degree of utilisation, a new Nagios service object must be created in Univention Directory Manager 

with the name UNIVENTION_LOAD. Only the compulsory fields need to be filled out for this. 

The parameterisation of the monitoring of the degree of utilisation is performed via two Univention Config- 

uration Registry variables on the thin client: 

thinclient/nagios/load/warning: Defines the thresholds for a warning for the Nagios plugin. The value 

is composed of three figures, which define the limits for the time intervals 1, 5 and 15 minutes 

respectively, 

thinclient/nagios/load/critical: Defines the thresholds for a critical state. The value is composed in the 

Example: 

same way as for the warning level. 

thinclient/nagios/load/warning=0.5,0.4,0.3 

thinclient/nagios/load/critical=0.8,0.7,0.6 

If these variables are not set via a policy, the following preset values are defined: 

thinclient/nagios/load/warning=0.1,0.1,0.1 

thinclient/nagios/load/critical=0.5,0.5,0.5 

The Nagios service UNIVENTION_LOAD can then be added as for other Nagios services on the thin client 

object. 

For this Nagios plugin it is necessary for the Nagios server to have access to the thin client. The NRPE 

service running on the thin client must allow this access. As standard, the LDAP server is allowed access. 

The Univention Configuration Registry variable nagios/client/allowedhosts can be set to allow 

other computers access. The variable must contain a list of IP addresses separated by commas. 

9.5.2.7 Font server 

A font server can be used to save space on thin clients with flash cards or use a central font collection. 

This service is used by the thin client’s x-server to request fonts from the font server entered instead of 

using local fonts. There is also the possibility of combining both versions. 

The Univention Configuration Registry variable xorg/fonts/server can be set using a Univention Con- 

figuration Registry policy to allow thin clients to use a font server in addition to local fonts. The value must 

reflect the syntax, which must also be used in the xorg.conf file: 

xorg/fonts/server=/: 

For this, must be replaced with tcp or unix depending on which transport protocol is used to 

access the font server. tcp should be selected here for thin clients. The fully qualified domain name of the 

214

9.6 Home directories 

computer on which the font server is operated must be entered for . 7100 is usually selected 

when entering the port as this is the standard setting for the font server. For example, if a font 

server is operated on port 7100 of the master.ucs.test computer, the variable can be set to the following 

value: 

xorg/fonts/server=tcp/master.ucs.local:7100 

9.6 Home directories 

Each user is allocated his own home directory. This directory is usually stored under /home/ and 

contains amongst other things all program settings which have been changed by the user. As each user 

has write permission for his home directory, this is normally also the place where his personal documents 

can be saved. 

There are a number of different descriptions for a user’s home directory: 

• home directory 

• /home/ 

• $HOME 

• ~ 

• home 

If an alternate path than /home/ is required for the home directory, this can be entered in the 

Univention Directory Manager in the user object under UNIX home directory. This is, however, only 

required and necessary in exceptional cases. The login shell to be used, by default /bin/bash, can also 

be amended or deleted here. 

9.6.1 Creation of new home directories 

The home directories of new users do not need to be created manually. As soon as a user logs on, each 

UCS system automatically checks whether a home directory already exists for this user. If this is not the 

case, a home directory is created. 

When creating a new home directory, the home directory configured for the user is created on the system 

on which the log-in occurs. The univention-skel mechanism then creates specific, predefined files and 

directories in this directory. 

9.6.2 Modifying the default content of home directories 

When creating a new home directory, univention-skel copies the contents of /etc/univention/skel/ 

into this home directory and changes the owner and file groups over to the newly created user. Sub folders 

are created in the home directories as relative paths. 

For already existing user directories, changes to the contents of /etc/univention/skel/ have the 

following consequences: 

215


• If files are added, these files are copied into the user’s home directory at the next user log-in. If files 

with the same name already exist, these will be overwritten. 

• If a file is removed and the user has not made any amendments to this file in his home directory, it 

will be removed. 

• If a file is removed and the user has made amendments to this file in his home directory, it will not 

be removed. 

• If the user amends files created by univention-skel, these amendments remain unchanged at later 

log-ins. If a user deletes files, there are recreated at the next log-in. 

Files are created with 0600 permissions and directories with 0700 as default. These default values can 

be changed with the Univention Configuration Registry variable skel/permissions/directory or the 

Univention Configuration Registry variable skel/permissions/file. 

To adapt newly created directories or files subsequently (e.g., file permissions), the possibility exists of 

storing a script below /etc/univention/skel.meta/. 

For example, the script /etc/univention/skel.meta/.bashrc can be created to amend the 

file .bashrc subsequently. If the directory .emacs needs to be modified subsequently, a 

/etc/univention/skel.meta/.emacs/.directory can be created. 

9.6.3 Setting environment variables 

If environment variables need to be set for users which are valid for the whole KDE session and amongst 

other things can be used in KDE desktop profiles (see following section), this can be done via entries in the 

file /home//.univention-environment. For example, the following entry must be made in 

this file to set the variable $KOLABSERVER to ugs-server01.company.com for the whole KDE session: 

export KOLABSERVER=ugs-server01.company.com 

For users who already have a home directory, this must be entered in 

/home//.univention-environment. To incorporate this for all new users, this file can 

be stored under /etc/univention/skel/ accordingly. 

9.7 Global home directories 

For managed and mobile clients, home directories are automatically created and used on the local hard- 

drive as standard. This has the disadvantage that user settings and files can only be saved on the client 

currently being used and are not available for log-ins on another client. 

It poses a possible problem for thin clients that by default the home directory is used on the terminal server 

on which the terminal session was started. If more than one terminal server is available, however, the 

log-in occurs randomly on one of the systems and the respective local home directory is used. 

To have uniform home directories across all clients, global home directories must be used. These direc- 

tories are saved on a shared server on which all the clients are mounted, and which are thus accessible 

from every client. However, in this case, it must be noted that these home directories are not available for 

managed and mobile clients when there is no connection to the shared server. 

216

9.7.1 Creating and modifying global home directories 

Global home directories can be created in a number of ways: 


• Via the user management of Univention Directory Manager (POSIX (Linux/UNIX) settings and Win- 

dows settings) 

• Via the Samba configuration 

• Via the file /etc/fstab 

In any case, the server used must provide a /home share. This is the case as standard when Create 

home share was selected during the installation. 

9.7.1.1 POSIX (Linux/UNIX) settings 

The configuration of the POSIX (Linux/UNIX) settings is done in the Univention Directory Manager user 

management on the POSIX (Linux/UNIX) tab. This setting must be configured separately for each user. 

The file share on the server is stated under Home share, below which the home directory can be found. 

This is usually /home. The directory below the share which will be used as the home directory must be 

given under Home share path. This is usually the username. 

On the clients, the Univention Configuration Registry variable homedir/mount is used to control whether 

the mountable share is actually mounted. This variable is set to no for managed and mobile clients as 

standard. If this variable is set to yes or does not exist, the stated share will automatically be mounted at 

the user log-in to the client. 

9.7.1.2 Windows settings 

The configuration of Windows settings is performed in the Univention Directory Manager user man- 

agement on the Windows tab. Here the network path to be used as the home directory, e.g., 

\\fileserver\smith, can be given in the Windows home path field. This setting must be performed 

separately for each user. 

The user profile continues to be saved on the Samba server used to log in. If the user profile is also 

to be saved in a certain share, this should be entered in the Windows profile directory field, e.g., 

\\fileserver\smith\windows-profiles\WinXP. 

9.7.1.3 Global configuration in Samba 

If the Windows settings are to be set for all users, it is recommendable to do this directly in the Samba 

configuration. In addition, the Univention Configuration Registry variable samba/homedirserver should 

be set to the file server on all Samba log-in servers. For this, the server must be specified which hosts 

the home directories. If the Windows user profiles are also to be saved centrally, this must be configured 

using the Univention Configuration Registry variable samba/profileserver. 

217


9.7.1.4 Mounting the shares in /etc/fstab 

A further possibility for mounting home directories on managed and mobile clients and terminal servers is 

to mount the directory shared by the shared server with all home directories statically. This is performed 

via an entry in the file /etc/fstab: 

:/home /home nfs defaults,timeo=21,retrans=9 1 2 

The share is automatically mounted during booting by entering mount -a or mount /home. 

218

Figure 9.1: Univention Directory Manager display settings 


219


220 

Figure 9.2: Selection of the session during log-on

10 Basic System Services 

Contents 

10.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 

10.2 Server Homepage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 

10.3 Packet filter with Univention Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 

10.3.1 Service definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 

10.3.2 Service profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 

10.3.3 Local filter rules by Univention Configuration Registry . . . . . . . . . . . . . . . . . 224 

10.3.4 Local filter rules via iptables commands . . . . . . . . . . . . . . . . . . . . . . . . . 224 

10.3.5 Testing Univention Firewall settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 

10.4 Authentication / PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 

10.4.1 Automatic lockout of users after failed login attempts . . . . . . . . . . . . . . . . . . 227 

10.5 Network configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 

10.5.1 Network interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 

10.5.2 DNS servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 

10.5.3 Proxy configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 

10.6 Logging of system messages and system status . . . . . . . . . . . . . . . . . . . . . . . . 229 

10.6.1 Log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 

10.6.2 Logging the system status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 

10.7 Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 

10.7.1 Available kernel variants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 

10.7.2 Hardware drivers / kernel modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 

10.8 GRUB boot manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 

10.9 Executing recurring actions with Cron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 

10.9.1 Hourly/daily/weekly/monthly execution of scripts . . . . . . . . . . . . . . . . . . . . 232 

10.9.2 Defining local cron jobs in /etc/cron.d . . . . . . . . . . . . . . . . . . . . . . . . . . 232 

10.9.3 Defining cron jobs in Univention Configuration Registry . . . . . . . . . . . . . . . . 233 

10.10Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 

10.11Name resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 

10.11.1Name Service Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 

10.11.2LDAP NSS module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 

10.11.3Nameserver cache daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 

10.11.4Configuration of /etc/hosts in Univention Configuration Registry . . . . . . . . . . . . 235 

10.12SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 

10.13Time synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 

221


10.1 Summary 

This chapter describes basic system services of a UCS Installation such as the configuration of the kernel 

and boot manager, the network configuration, Kerberos, SSH, NSS, and the NSCD. 

In addition, the settings possibilities of the PAM authentication interface are also described. 

10.2 Server Homepage 

Every UCS server system offers on its web homepage (at http(s)://HOSTNAME or 

http(s)://IPADDRESS) hyperlinks to services installed in the system (such as Univention Man- 

agement Console or, at the Domain Controller Master, the Univention Directory Manager). An example 

can be found in Illustration 10.1. 

This homepage is defined via the Univention Configuration Registry variable apache2/startsite 

which by default refers to the file ucs-overview/de.html in the Apache directory 

/var/www. This file is managed as a Univention Configuration Registry multi file and can 

be amended, for example by entering links to special in-house applications into the directory 

/etc/univention/templates/files/var/www/ucs-overview/de.html.d/ (and accordingly 

on the English homepage). 

222 

Figure 10.1: Homepage of a DC Master

10.3 Packet filter with Univention Firewall 

10.3 Packet filter with Univention Firewall 

Univention Firewall offers an integration of the packet filter IPTables into Univention Corporate Server. This 

filter permits targeted filtering of undesired services, and the protection of computers during installation 

works. Furthermore it provides the basis for complex scenarios such as firewalls and Application Level 

Gateways. Univention Firewall is included in all Univention Corporate Server installations as a standard 

feature. 

The configuration for the packet filter can be found in the directory /etc/security/netfilter.d/. 

The configuration elements available in this directory, are executed in alphabetical order. The name of 

each script begins with two digits, which makes it easy to create a numbered order. 

After changing the packet filter settings, the service univention-iptables has to be restarted. 

Univention Firewall can be deactivated by setting the Univention Configuration Registry variable 

security/packetfilter/disabled to true. 

10.3.1 Service definitions 

Univention Firewall allows selective filtering of individual services by Univention Configuration Registry, for 

example if a service is temporarily not required or to be deactivated for test purposes. At present, the 

following services are supported in UCS: 

smtp pop3 imap kerberos 

krsh nfs umc nagios 

ipp notifier dhcp dns 

ftp http x11 https 

ldap postgres samba ssh 

telnet ftp 

If the Univention Configuration Registry variable security/services/SERVICE is set to disabled, the cor- 

responding service is filtered out. 

Attention: 

These services are filtered by means of their default ports. If a service is operated at a different port, then 

the corresponding Univention Configuration Registry template has to be adapted. 

10.3.2 Service profiles 

Univention Firewall supports pre-defined service profiles for each system role. The services to be filtered 

out, are defined for each role in the above-mentioned Univention Configuration Registry settings. 

Attention: 

It has to be considered that it is merely a selective filter which is used here. If additional local services are 

applied, they have to be registered subsequently. 

223


The service profiles can be selected during installation (e.g. for a secure installation) and changed in an 

installed system at a later date via univention-system-setup-security. 

There are three profiles which can be selected during installation or at runtime via Univention System 

Setup: 

• Disabled (no service will be blocked). 

• Typical selection of services, recommended (see below) 

• Locked-down setup. Only SSH, LDAP, and HTTPS are allowed. 

For the recommended selection some typically unused services are filtered out. 

• On domain controller master/backup/slave and member servers: Telnet and FTP 

• On managed, mobile clients and base systems: SMTP, Pop3, Notifier, KRSH, Kerberos, IMAP, Na- 

gios, DHCP, DNS, FTP, LDAP, Postgres, Telnet and TFTP 

10.3.3 Local filter rules by Univention Configuration Registry 

Besides pre-defined service definitions, Univention Firewall also allows the implementation 

of package filter rules via Univention Configuration Registry These rules are included in 

/etc/security/netfilter.d/ via a Univention Configuration Registry module. 

All Univention Configuration Registry settings for local filter rules are entered in the following format: 

security/packetfilter/[tcp|udp]/[accept|deny]=ports 

tcp is used for server services via the Transmission Control Protocol, udp for stateless datagram services. 

If a rule is registered as deny, then the packages to this port will be discarded; filtering can be overridden 

by accept. (IPtables rules are executed until one rule applies; thus, if a package is accepted by a rule 

which is discarded by a later rule, then the rule for discarding the package does not become valid). 

Ports can be defined either as a number or as a range separated by a colon X:Y . 

Some examples: 

• security/packetfilter/tcp/deny=2000 

• security/packetfilter/udp/accept=500:600 

10.3.4 Local filter rules via iptables commands 

Besides the existing possibilities for settings via Univention Configuration Registry, there is also the pos- 

sibility of integrating user-defined enhanced configurations in /etc/security/netfilter.d/, e.g. for 

realising a firewall or Network Address Translation. The enhancements should be realised in the form of 

shell scripts which execute the corresponding iptables calls. 

Full documentation can be found at http://www.netfilter.org/. 

224

10.3.5 Testing Univention Firewall settings 

10.4 Authentication / PAM 

Package filter settings should always be thoroughly tested. The network scanner nmap, which is integrated 

in Univention Corporate Server as a standard feature, can be used for testing the status of individual ports: 

Since Nmap requires elevated privileges in the network stack, it should be started as root user. A TCP 

port can be tested with the following command: 

nmap HOSTNAME -p PORT(s) 

A UDP port can be tested with the following command: 

nmap HOSTNAME -sU -p PORT(s) 

Examples: 

• nmap 192.168.1.100 -p 400 

• nmap 192.168.1.110 -sU -p 400-500 


Authentication services in Univention Corporate Server are realised via Pluggable Authentication Mod- 

ules (PAM). To this end different log-in procedures are displayed on a common interface so that a new 

log-in method does not require adaptation for existing applications. 

In the UCS PAM configuration, different methods can be used for the authentication of user accounts. 

unix verifies the hashed password using the /etc/shadow file, ldap performs a bind attempt on the 

LDAP server and krb5 verifies the password using a Kerberos key, which is also stored in LDAP. There 

are also other methods, e.g., the secure shell (ssh) uses a key pair for verification of whether the user is 

really the user he claims to be. 

In UCS it is normally sufficient if the identity can be verified using one of these methods. Which 

method should be used can be configured using the Univention Configuration Registry variable 

auth/admin/methods for the administrator and the Univention Configuration Registry variable 

auth/user/methods for all other users. The default setting is krb5 ldap unix, which allows all three 

methods. 

Alongside this verification, certain services also require a valid user account: This assigns a user his 

home directory, his numerical user identification (UID) and his group memberships. This information is 

required among other things for logins on GDM, on the text console or via SSH. Samba also requires 

this information to store information saved by the user onto the UNIX file system or to verify whether the 

access to files and directories is allowed. In addition, the account data also includes additional information 

such as the age of the password, whether the account is deactivated or whether the account should only 

be valid on certain hosts. 

Here too different methods are used via PAM, which can sometimes be expanded and restricted: unix 

uses the information from /etc/passwd, /etc/group, /etc/shadow and /etc/nsswitch.conf, 

which can be used to mount further information sources. The latter is used to mount all the users 

225


from LDAP in UCS. This is particularly necessary for allowing programs to request users and groups 

via getent. 

It must be observed that the data structures for the shadow method are very restricted and cannot be 

expanded. This prevents the use of other information stored in LDAP among other things. As a result, ldap 

is included again to decide whether a user account is valid on a host based on further criteria. Thirdly, 

krb5 is also used here, which offers the possibility like ldap of deciding which criteria should be taken into 

account during the verification. An important difference is that the Kerberos service does not assign user 

names to the required POSIX information such as UID, GID, GECOS, HOME, Shell, etc. Services which 

require this information, must thus stringently use ldap or unix as well. 

Each of these three methods for account verification uses information from the LDAP directory: unix 

evaluates the shadow information, ldap also uses the host attribute or other filters if necessary and krb5 

evaluates the Samba attributes (sambaAcctFlags). The methods are thus not completely independent of 

each other and (mutually) influence each other. 

The configured PAM log-in procedures can be configured via Univention Configuration Registry. Two kinds 

of variables are differentiated here; services reserved for administrators are configured in the Univention 

Configuration Registry variable auth/admin/services and services for unprivileged users are config- 

ured in the Univention Configuration Registry variable auth/user/services. 

The following authentication procedures are available as standard: 

226 

Name Description of the authenticated 

service 

ftp FTP service 

gdm GDM for log-ins onto KDE/X11 

log-in Shadow log-in 

other fallback for non-configured ser- 

vices 

ppp PPP processes with log-in op- 

tion 

rlogin remote log-in (rlogin) (typically 

obsolete) 

screen screen terminal tool 

chfn chfn tool from Shadow to 

change user data 

chsh chsh tool from Shadow to 

change log-in shell 

kde KDE applications in general 

kscreensaver KDE screensaver 

kcheckpass KDE password verification 

rsh remote shell (rsh) (typically ob- 

solete) 

ssh secure shell 

su tool for changing user identity

sudo tool for running users with ele- 

vated privileges 

passwd passwd tool from Shadow 

cron Cron daemon 


The authorised users for various services can also be restricted using a PAM module. If 

the Univention Configuration Registry variables auth/ftpd/accessfile, auth/gdm/accessfile, 

auth/sshd/accessfile or auth/nagios/accessfile are configured to a file name, access to the 

relevant services is restricted to those users listed in the file separated by commas. 

10.4.1 Automatic lockout of users after failed login attempts 

As standard, a user can enter his password incorrectly any number of times. To hinder brute force attacks 

on passwords, an automatic lockout for user accounts can be activated after a configured number of failed 

log-in attempts. The lockout is activated locally per computer system as standard. In other words, if a user 

enters his password incorrectly too many times on one system, he 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. The global lock can only be set on domain controller master/backup 

systems as other system roles do not possess the requisite permissions in the LDAP directory. On these 

system roles, the user is, however, locally locked or unlocked again via the listener module. 

Attention: 

This setting can also be misused, for example when a user has locked his screen and another user enters 

the password incorrectly several times in his absence. In this case, the user must contact the administrator 

to have his account unlocked. 

The automatic lockout of users following failed logins can be activated 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 activated is configured in the Univention Configuration Registry variable 

auth/faillog/limit. The counter is reset each time the password is entered correctly. 

As standard, 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. 

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 interval has elapsed. This is done by specifying a time 

period in seconds in Univention Configuration Registry variable auth/faillog/unlock_time. If the 

value is set to 0, the lock is reset immediately. 

If accounts are locked locally, the administrator can unlock a user by entering the command faillog -r 

USERNAME. If the lock occurs globally in the LDAP, the user can be reset in the User account tab of a user 

in Univention Directory Manager. 

227


10.5 Network configuration 

10.5.1 Network interfaces 

Network interfaces settings are stored in Univention Configuration Registry. They can be changed via 

Univention System Setup (see chapter 15.2.4), or stored directly in Univention Configuration Registry. For 

each interface there must be four properties stored in Univention Configuration Registry variables: 

• interfaces/ethX/address for the IP address which is to be linked to an interface. 

• interfaces/ethX/broadcast for the Broadcast address of the interface 

• interfaces/ethX/netmask for the subnet mask of the interface 

• interfaces/ethX/network for the network of the interface 

Besides the physical interfaces, additional virtual interfaces can also be defined in the form inter- 

faces/ethX_Y/property. 

The default gateway is configured by the Univention Configuration Registry variable gateway. 

On mobile clients where UCS versions as of 2.3 are installed, Network Manager is used for the IP config- 

uration. 

If a server is configured over DHCP, an address is configured in Univention Configuration Reg- 

istry which can be resorted to if the DHCP request should fail. The setting is specified 

by the Univention Configuration Registry variables interfaces/ethX/fallback/address and 

interfaces/ethX/fallback/netmask. Network and broadcast addresses can be specified us- 

ing the Univention Configuration Registry variables interfaces/ethX/fallback/network and 

interfaces/ethX/fallback/broadcast. A gateway can be specified with gateway/fallback. 

If the Univention Configuration Registry variable networkmanager/dhcp/options/fallback is set 

to yes, options which are not set by the DHCP server are read out of the previously listed Univention 

Configuration Registry variables. 

10.5.2 DNS servers 

One or more DNS servers can be configured for each system in the Univention Configuration Registry 

variables nameserver1, nameserver2 and nameserver3. 

For each configured network interface, the entry in the /etc/hosts can be configured through 

interfaces/ethX_Y/hosts. 

Information on the configuration of the name resolution through the /etc/hosts file can be found in 

Chapter 10.11.4. 

10.5.3 Proxy configuration 

The majority of the command line tools which access web servers (e.g., wget, elinks or curl) check 

whether the environment variable http_proxy is set. If this is the case, the proxy server set in this 

variable is used automatically. 

228

10.6 Logging of system messages and system status 

The Univention Configuration Registry variable proxy/http can also be used to activate the setting of 

this environment variable via an entry in /etc/profile. 

The proxy URL must be specified for this, e.g., http://192.168.1.100. The proxy port 

can be specified in the proxy URL using a colon, e.g., http://192.168.1.100:3128. If 

the proxy requires authentication for the accessing user, this can be provided in the form 

http://username:password@192.168.1.100. 

The environment variable is not adopted for sessions currently opened. A relogin is required for the change 

to be activated. 

The Univention tools for software updates also support operation via a proxy and query the Univention 

Configuration Registry variable . 

Individual domains can be excluded from use by the proxy by including them separated by commas in the 

Univention Configuration Registry variable proxy/no_proxy. Subdomains are taken into account; e.g. 

an exception for univention.de also applies for apt.univention.de. 

10.6 Logging of system messages and system status 

10.6.1 Log files 

All UCS-specific log files (e.g., for the listener/notifier replication) are stored in the 

/var/log/univention directory. Services log in their own standard log files: for example, Samba in 

/var/log/samba/log.smbd and /var/log/samba/log.nmbd. 

The log files are managed by Logrotate. It ensures that log files are named in series in intervals (can 

be configured in weeks using the Univention Configuration Registry variable log/rotate/weeks, with 

the default setting being 12) and older log files are then deleted. For example, the current log file for 

the Univention Directory Listener is found in the listener.log file; the one for the previous week in 

listener.log.1, etc. 

The Univention Configuration Registry variable log/rotate/univention/compress is used to config- 

ure whether the older log files are additionally zipped with Gzip. 

10.6.2 Logging the system status 

univention-system-stats (available as of UCS 2.4-1) can be used to document the current system 

status in the /var/log/univention/system-stats.log file. The following values are logged: 

• The free disk space on the system partitions (df -lhT) 

• The current process list (ps auxf) 

• Two top lists of the current processes and system load (top -b -n2) 

• The current free system memory (free) 

• The time elapsed since the system was started (uptime) 

• Temperature, fan and voltage indices from LM sensors (sensors) 

229


• A list of the current Samba connections (smbstatus) 

The runtimes in which the system status should be logged can be defined in Cron syntax via the Univention 

Configuration Registry variable system/stats/cron, e.g., 0,30 * * * * for logging every half and full hour. 

The logging is activated by setting the Univention Configuration Registry variable system/stats to yes. 

10.7 Kernel 

10.7.1 Available kernel variants 

Several kernel variants are provided in UCS in order to be able to adapt systems efficiently to the require- 

ments of different environments. 

The standard kernel in UCS 2.4 is based on the official Linux kernel 2.6.30. In principle, there are three 

different types of kernel packages: 

• A kernel image package provides an executable kernel which can be installed and started. 

• A kernel source package provides the source code for a kernel. From this source, a tailor-made 

kernel can be created, and functions can be activated or deactivated. 

• A kernel header package provides interface information which is required by external packages if 

these have to access kernel functions. This information is usually necessary for compiling external 

kernel drivers. 

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

The standard kernel in UCS for i386-based systems supports 64 GB RAM in installations as of Version 2.4 

(the so-called bigmem kernel for processors with PAE support). The standard kernel for amd64 systems 

directly supports more than 4 GB working memory, which renders a 64 GB version for amd64 systems 

unnecessary. 

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 by 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. 

A full list of all meta packages can be found in the Univention Wiki: 

http://wiki.univention.de/index.php?title=Supported_kernel_variants 

10.7.2 Hardware drivers / kernel modules 

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. 

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. 

230

10.8 GRUB boot manager 

The GRUB boot manager (see Chapter 10.8) 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 can 

then be mounted onto this, before the temporary archive is removed and the system start implemented. 

The Univention Configuration Registry variable initramfs/modules can then be used to configure 

which modules should be integrated into the initrd. If it is set to most, all framebuffer, ACPI, file system 

and hard drive modules are integrated; netboot only adds basic and network drivers and dep performs 

automatic recognition of the modules which are to be integrated. 

If the Univention Configuration Registry variable initramfs/busybox is set to yes, Busybox, a compact 

implementation of the standard Unix tools, is added, which is useful in failure analysis amongst other 

things. 

The drivers to be used are recognised 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 recog- 

nised (which can occur if no respective hardware IDs are registered or hardware is employed which cannot 

be recognised automatically, e.g., ISA boards), kernel modules to be loaded automatically can be added 

via Univention Configuration Registry variable kernel/modules. If more than one kernel module is to be 

added, these must be separated by a semicolon. 

10.8 GRUB boot manager 

In Univention Corporate Server GNU GRUB 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. In contrast to the boot 

loader LILO, which was used in earlier UCS versions, GRUB can also access file systems directly and can 

thus, for example, load another kernel in case of an error. 

The selection of kernels to be started in the boot menu is stored in the file /boot/grub/menu.lst. 

There is a five second waiting period during which a selection can be made. This value can be changed 

via the Univention Configuration Registry variable grub/timeout. 

In the basic setting, a screen of 1024x768 pixels size and 16 Bit colour depth is pre-set. A different value 

can be set via the Univention Configuration Registry variable grub/vga. A list of available modes can be 

found at http://en.wikipedia.org/wiki/VESA_BIOS_Extensions. 

Setting the Univention Configuration Registry variable grub/memtest86 to true means a memory test 

program is included in the boot selection. For this purpose, the package memtest86+ has to be installed 

on the corresponding system. 

GRUB loads the operating system 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 manage the rest of the boot 

procedure. 

The kernel which is about to be booted, can be provided with configuration options by setting the Univention 

Configuration Registry variable grub/append. 

GRUB uses its own notation for the partitions of a hard drive, which is independent from the device names 

under Linux. The format of this notation is (hdX,Y), wherein X means the drive within the system, and Y 

the partition on the drive (counting begins with 0 in each case). So (hd0,0) means the first partition on the 

231


first hard drive. The Grub root partition can be represented in this notation by the Univention Configuration 

Registry variable grub/groot. 

The root partition which is handed over to the booting kernel, is independent from the above notation. It 

can be changed via the Univention Configuration Registry variable grub/root, and has to be declared in 

standard Linux partitions syntax. 

10.9 Executing recurring actions with Cron 

Regularly recurring actions (e.g., the processing of log files) can be started at a defined time with the Cron 

service. Such an action is known as a cron job. 

10.9.1 Hourly/daily/weekly/monthly execution of scripts 

Four directories are predefined on every UCS system, /etc/cron.hourly/, /etc/cron.daily/, 

/etc/cron.weekly/ and /etc/cron.monthly/. Shell scripts which are placed in these directories 

and marked as executable are run automatically every hour, day, week or month. 

10.9.2 Defining local cron jobs in /etc/cron.d 

A cron job is defined in a line, which is composed of a total of seven columns: 

• Minute (0-59) 

• Hour (0-23) 

• Day (1-31) 

• Month (1-12) 

• Weekday (0-7) (0 and 7 both stand for Sunday) 

• Name of user executing the job (e.g., root) 

• The command to be run 

The time specifications can be set in different ways. One can specify a specific minute/hour/etc. or run 

an action every minute/hour/etc. with an *. Intervals can also be defined, for example */2 as a minute 

specification runs an action every two minutes. 

Some examples: 

30 * * * * root /usr/sbin/jitter 600 /usr/share/univention-samba/slave-sync 

*/5 * * * * www-data /usr/bin/php -q /usr/share/horde3/kronolith/scripts/reminders.php 

232

10.9.3 Defining cron jobs in Univention Configuration Registry 

10.10 Kerberos 

Cron jobs can also be defined in Univention Configuration Registry. This is particularly useful if they are 

set via a Univention Directory Manager policy and are thus used on more than one computer. 

Each cron job is composed of at least two Univention Configuration Registry variables. JOBNAME is a 

general description. 

• cron/JOBNAME/command specifies the command to be run (required) 

• cron/JOBNAME/time specifies the execution time (see 10.9.2) (required) 

• As standard, the cron job is run as a user root. cron/JOBNAME/user can be used to specify a 

different user. 

• If an e-mail address is specified under cron/JOBNAME/mailto, the output of the cron job is sent 

there per e-mail. 

• cron/JOBNAME/description can be used to provide a description. 

10.10 Kerberos 

Kerberos is an authentication framework the purpose of which is to permit secure identification in the po- 

tentially insecure connections of decentralised networks. In Kerberos, all clients use a foundation of mutual 

trust, the Key Distribution Centre (KDC). A client authenticates at this KDC and receives an authenti- 

cation token, the so-called ticket which can be used for authentication within the Kerberos environment 

(the so-called Kerberos Realm). The name of the Kerberos Realm can be defined via the Univention 

Configuration Registry variable kerberos/realm. 

Tickets have a standard validity period of 8 hours; this is why it is vital for a Kerberos domain to have the 

system time synchronised for all the systems belonging to the Kerberos Realm. 

Univention Corporate Server uses the Heimdal Kerberos implementation. Several domain controllers can 

be operated as a KDC within one domain; by default, each Domain Controller Master, Domain Controller 

Backup and Domain Controller Slave works as a KDC. The KDC used by a system can be reconfigured 

via the Univention Configuration Registry variable kerberos/kdc. 

The Kerberos admin server, on which the administrative settings of the domain can be made, runs on the 

Domain Controller Master. Most of the settings in Univention Corporate Server are taken from the LDAP 

directory, so that the major remaining function is changing passwords. This can be achieved by means of 

the Tool kpasswd; the passwords are then changed in the LDAP too. The Kerberos admin server can be 

configured on a system via the Univention Configuration Registry variable kerberos/adminserver. 

10.11 Name resolution 

10.11.1 Name Service Switch 

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. 

233


Instead of the traditional configuration files (such as /etc/passwd or /etc/hosts), the data usually 

returned from function calls for resolving data related to users, groups and hosts, can be drawn from other 

sources such as LDAP or an SQL database. 

The data are stored in the file /etc/nsswitch.conf, which can be managed via Univention Configura- 

tion Registry. By default, the LDAP directory service is used for this purpose. By setting the Univention 

Configuration Registry variable nsswitch/ldap to no, the exclusive use of /etc/passwd, /etc/group 

and /etc/hosts can be specified. 

10.11.2 LDAP NSS module 

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 Reg- 

istry variable ldap/server/name (and if necessary the Univention Configuration Registry variable 

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. 

10.11.3 Nameserver cache daemon 

Data of the NSS service can be cached by the Name Server Cache Daemon (NSCD) in order to speed up 

frequently recurring requests for unchanged data. Thus, if a repeat request occurs, instead of a complete 

LDAP request to be processed, the data are simply drawn directly from the cache. 

The central configuration file of the (/etc/nscd.conf) is managed by Univention Configuration Registry. 

The access to the cache is handled via a hash table. The size of the hash table can be specified in 

Univention Configuration Registry, and should be higher than the number of simultaneously used group- 

s/users/hosts. For technical reasons, a prime number should be used for the size of the table. The following 

table shows the standard values of the variables: 

Variable Default size of the hash table 

nscd/group/size 3001 

nscd/hosts/size 3001 

nscd/passwd/size 3001 

With very big caches it may be necessary to increase the size of the cache database in the 

system memory. This can be configured through the Univention Configuration Registry variables 

nscd/hosts/maxdbsize, nscd/group/maxdbsize and nscd/passwd/maxdbsize. 

As standard, five threads are started by NSCD. In environments with many accesses it may prove neces- 

sary to increase the number via the Univention Configuration Registry variable nscd/threads. 

234

10.12 SSH 

In the basic setting, a resolved group or host name is kept in cache for one hour, a user name for ten min- 

utes. With the Univention Configuration Registry variables nscd/group/positive_time_to_live, 

nscd/hosts/positive_time_to_live and nscd/passwd/positive_time_to_live these peri- 

ods can be extended or diminished (in seconds). 

As of UCS 2.3 a Univention Directory Listener module is also included, which empties the group cache 

when a change is made to group memberships. This listener module can be activated/deactivated 

via the Univention Configuration Registry variable nscd/group/invalidate_cache_on_changes 

(true/false). 

From time to time it might be necessary to manually invalidate the cache of the NSCD. This can be done 

individually for each cache table with the following commands: 

nscd -i passwd 

nscd -i group 

nscd -i hosts 

The verbosity of the log messages can be configured through the Univention Configuration Registry vari- 

able nscd/debug/level. 

10.11.4 Configuration of /etc/hosts in Univention Configuration Registry 

The configuration file /etc/hosts is managed through a Univention Configuration Registry template. 

Individual entries can be added through a Univention Configuration Registry variable in the format 

hosts/static/192.168.1.1="test.local test". 

10.12 SSH 

When installing a UCS system, an SSH server is also installed per preselection. SSH is used for realising 

encrypted connections to other hosts, wherein the identity of a host can be assured via a check sum. 

Essential aspects of the SSH server’s configuration can be adjusted in Univention Configuration Registry. 

By default the login of the privileged root user is permitted by SSH (e.g. for configuring a newly installed 

system where no users have been created yet, from a remote location). If the Univention Configuration 

Registry variable sshd/permitroot is set to without-password, then no interactive password request 

will be performed for the root user, but only a login based on a public key. By this means brute force 

attacks to passwords can be avoided. If the variable is set to no, then the root user cannot login via SSH. 

The Univention Configuration Registry variable sshd/xforwarding can be used to configure whether 

an X11 output should be passed on via SSH. This is necessary, for example, for allowing a user to start a 

program with graphic output on a remote computer by logging in with ssh -X TARGETHOST. Valid settings 

are yes and no. 

The standard port for SSH connections is port 22 via TCP. If a different port is to be used, this can be 

arranged via the Univention Configuration Registry variable sshd/port. 

235


10.13 Time synchronisation 

Asynchronous system times between individual hosts of a domain can be the source of a large number of 

errors: the reliability of log files is impaired; Kerberos operation is disrupted; the correct evaluation of the 

validity periods of passwords can be disturbed; etc. 

Usually the Domain Controller Master functions as the time server of a domain. With the Univention 

Configuration Registry variables timeserver, timeserver2 and timeserver3 external NTP servers 

can be included as time sources. 

Manual time synchronisation can be started by the command ntpdate. 

236

11 Software maintenance 

Contents 

11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 

11.2 UCS updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 

11.2.1 UCS security updates and hotfixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 

11.2.2 UCS release updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 

11.3 Package maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 

11.3.1 Assigning repository servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 

11.3.2 Updating packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 

11.3.3 Adding component repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 

11.3.4 Managing package lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 

11.3.5 Release updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 

11.3.6 Manual package maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 

11.4 Software monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 

11.5 Repository management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 


11.5.1 Creating a repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 

11.5.2 Adding packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 

11.5.3 Removing packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 

11.5.4 Merging repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 

11.5.5 Repository synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 

The software distribution and maintenance mechanism integrated in UCS is an extensive mechanism for 

the central administration of releases and package versions on all UCS systems within a domain. Updates 

for UCS are provided as release and security updates and hotfixes. These can be retrieved from DVDs or 

so-called repository servers. 

These repository servers provide the systems of a UCS domain with software in the form of packages 

which can be downloaded by the UCS systems for installation. As of Version 2.2 of UCS the possibility 

has existed of installing releases updates, security updates, hotfixes and additional components from the 

online repository http://apt.univention.de. This negates the need for a local repository server in 

many UCS domains. Environments where there is no access to an external repository server available, for 

example, can still use a local repository server. 

These mechanisms for software maintenance only cover the UCS systems in a UCS domain. Windows 

systems are not currently supported, although there is the possibility of starting a script-based software 

installation within the scope of an installation using Univention Windows Installer. Alternatively, the 

237


product opsi4ucs can be used for an automatic Windows installation and software distribution, the admin- 

istration of which is possible via the UCS management system. Further information can be found on the 

manufacturer’s website at http://www.uib.de. 

This chapter describes these processes and functions, i.e., it documents the processes for installing up- 

dates, the advanced functions of the UCS management system for software maintenance and the man- 

agement of repositories. 

11.2 UCS updates 

Updates for UCS are always imported on UCS systems via a repository. Depending on the size and infras- 

tructure of the environment, this can be performed using local repositories or using the online repository. 

Details on the management of repositories can be found in Section 11.5. 

Univention Configuration Registry variables are used to define which repository servers a system uses 

to retrieve updates. As of UCS 2.2 a list of files with the repositories for release and security updates, 

hotfixes and components is created automatically in the /etc/apt/sources.list.d directory based 

on these variables. Which Univention Configuration Registry variables influence this list of repositories is 

explained in the following sections. If further repositories are required on a system, these can be entered 

in the /etc/apt/sources.list file. 

If you do not require the automatic creation of the repository lists, this can be deactivated by setting the 

Univention Configuration Registry variable repository/online to false. 

The following explains the installation of release and security updates and hotfixes. 

11.2.1 UCS security updates and hotfixes 

If security risks or serious errors become apparent in software packages, Univention provides secu- 

rity updates. The availability of new security updates is announced per e-mail. An advisory docu- 

ment is published for each security update, which names the updated packages and the reason for 

their updating. The e-mail announcement and the advisory documents will both state whether a sys- 

tem requires restarting after the update. Security updates for current UCS versions can be found at 

http://www.univention.de/updates/security. 

The Univention Configuration Registry variable version/security-patchlevel can be read out to 

check the status of a system as far as security updates are concerned. If new security updates are 

announced, these can either be installed using the Univention Management Console or the command line 

programs outlined below. 

The univention-security-update command is used to install security updates. net or local are 

supported as run parameters. The option --silent can also be entered in addition to the two versions, 

whereby the display of all error messages is suppressed. Independent of this option, all messages are 

logged in the file /var/log/univention/security-updates.log. 

When univention-security-update net is used, the security updates for the system are down- 

loaded from the network and installed on the system. If additional security updates are available for the 

238

11.2 UCS updates 

system version which have not yet been installed, these are installed as well so that the system is kept 

up-to-date. The security updates are downloaded from the set repository server. This is entered in the 

Univention Configuration Registry variable repository/online/server. The web proxy settings of 

the system are taken into account when accessing the server. 

Alternatively, security updates can be downloaded as .tar archives and installed using the 

univention-security-update local command. These variants can, however, only be used on 

repository servers. An example usage is: 

univention-security-update local --file ucs-security-2.2sec1.tar.gz 

In advance it must be checked whether the archive was downloaded completely and correctly. This can 

be done using the md5sum command, which creates a unique check sum for the archive. The check sums 

of all the archives can be found under the specified URL for comparison. If the MD5 sum is correct, the 

security update can be imported with the named command. Firstly the local repository is updated and then 

security update is installed on the system. 

Security updates for UCS usually contains several packages to correct security risks and serious errors. 

This eliminates the need to import new packages individually time and time again. In certain circumstances 

it may be necessary to retrieve the corrections for certain packages as soon as possible. This is done using 

Univention hotfixes. As soon as a package is created with the corresponding correction and this has been 

tested, it is provided in the hotfix repository and the update announced per e-mail. Univention hotfixes can 

be imported on UCS systems from this repository using the command univention-actualise. The 

Univention Configuration Registry variable repository/online/hotfixes needs to be set to yes for 

the inclusion of the hotfix repository. 

11.2.2 UCS release updates 

An important part in the development of UCS is the update-ability. This means that a UCS environment 

can be updated to the next versions without the need for extensive interventions. It is usually not necessary 

for the security updates available for the previous versions to have been imported. 

Parallel to the installation DVDs for a new UCS release, Univention also publishes update DVDs in the form 

of ISO images for the update. Alternatively to the update via an update DVD, this can also be performed 

via the online repository. A changelog document is published for each release update listing the packages 

which have been updated and the reason for their updating or additional functions. In addition, a document 

is published with the release notes containing important information which must be observed. 

As with security updates, in a UCS release update the packages for new UCS version are imported in a 

repository using univention-repository-update before the remaining UCS systems are updated. 

If the online repository should be used, the system update can be begun immediately. When importing 

a release update in a UCS environment, the domain controller master should be the first system to be 

updated. Once the release update has been imported, the respective system must be rebooted. 

It is recommended to update a UCS system directly on the console or using the Univention Management 

Console Updating over a network connection (e.g., SSH session) is not advisable as this may result in the 

update procedure being cancelled. If updating should occur over a network connection nevertheless, it 

239


must be verified that the update continues despite disconnection from the network. The tools screen and 

at can be used for this. GNU Screen has been installed automatically as standard since UCS 2.4. 

The package maintenance policies can be used for the update, which allow an automatic release update. 

This is described in Section 11.3.5. 

The command univention-updater can be used to install UCS release updates directly on the con- 

sole. This supports the following variants: 

• The univention-updater cdrom command is used to update a system from an inserted update 

DVD or an ISO image. This can only be done on repository servers. As standard, the command 

mount /cdrom is used to try to mount the DVD. The parameter −−cdrom can be used to add an 

alternative path. The parameter −−iso can be used to access an existing ISO image. 

If the system possesses a local repository, this is updated firstly. 

• The command univention-updater net is used to update a system via the online repository 

or a local repository in the domain. The update server is set by the Univention Configuration Reg- 

istry variable repository/online/server. In this case too if an existing local repository on the 

system is updated firstly, the update will use the local repository. 

• If a UCS release update has already been imported in the systems’s local repository, 

univention-updater local can be executed. The update then uses the local repository. 

The parameter −−updateto can be used in all named run applications to specify to which version a 

system should be updated. Higher versions are then not installed even if they are available. 

Prior to the installation of a release update, a link to the release notes is displayed and a minute is waited 

in which the update can still be cancelled. This can be skipped via the −−ignore-releasenotes option 

or by setting the Univention Configuration Registry variable update/warning/releasenotes to no. 

If the update has been performed successfully, a check should be made for whether new or updated 

join scripts need to be run. This is not normally required on the DC master and DC backup sys- 

tem roles. The Univention Management Console module Domain join or the command line program 

univention-run-join-scripts, which can be found in the /usr/share/univention-join di- 

rectory, is used for checking and starting the join scripts (see Section 5.3.10). 

Attention: 

It should be noted, that components marked as critical can block an upgrade to the next minor or major 

release. More information can be found in Section 11.3.3. 

11.3 Package maintenance 

Packages can be installed, updated or removed on all UCS systems apart from thin clients. The three 

processes are grouped under the term package maintenance. 

UCS systems access repository servers during package maintenance. Package maintenance can be per- 

formed manually or automatically. In automatic package maintenance the UCS systems check indepen- 

dently whether updated packages are available, new packages should be installed or installed packages 

should be deleted. The package maintenance also installs available security updates. Corresponding 

commands and tools can be used to perform these actions manually. 

240

11.3.1 Assigning repository servers 


Which repository server is used for package management can be set for each UCS system. If there is 

no local repository server in the UCS domain, the online repository http://apt.univention.de is 

used. Otherwise the local repository server is set. This can usually be reached under the DNS alias 

univention-repository. 

When several repository servers are in operation, the UCS systems can distribute the load among several 

repository servers. In Univention Directory Manager the repository server to be used can be entered on 

the computer onjects of the UCS systems in the [Repository server] tab. As this is a policy setting, the 

setting does not need to be performed on each individual computer. Policies are inherited by subordinate 

objects in the directory tree. 

11.3.2 Updating packages 

Figure 11.1: ’Repository server’ tab 

Manual updating of a UCS system is performed using the command univention-actualise as the 

user root. In this, no release updates are performed, but packages are updated from the configured 

repositories. univention-actualise performs a number of actions. Firstly a list of the available pack- 

ages and their versions is requested from the repository server. Once the list has been compared with the 

packages currently installed locally, all packages which are available in newer versions on the repository 

server are downloaded and installed. 

Updates can be installed automatically if the Maintenance policy is assigned to the desired systems. 

Whether the update should be performed during a system start, during shutdown or at a certain time can 

be set in the package maintenance policy. As package maintenance policies are inherited just like all 

policies in UCS, settings for automatic updating can be made in a computer container. The settings apply 

for all computer objects subordinate to the container. 

It must be noted that certain packages, e.g., the kernel, are not updated by univention-actualise 

241


as standard. To update these packages, univention-actualise must be run with the command line 

option −−dist-upgrade. These packages can thus not be updated via a package maintenance policy. 

Updating is possible if the package is checked in advance in a package list for installation (see following 

section). 

Attention: 

When packages are updated, a check is performed for whether any changes have been made to the 

configuration files. If configuration files are no longer there in the form in which they were delivered, 

they will not be overwritten. Instead a new version will be created in the same directory with the 

ending .dpkg-new or .dpkg-dist. If changes should be made to Univention Configuration Reg- 

istry templates, these templates are also not overwritten. Messages relating to this are written in the 

/var/log/univention/actualise.log log file. 

The messages created by univention-actualise during the update are also written on the updated 

system in /var/log/univention/actualise.log except for the standard display. If messages to the 

standard display are suppressed, univention-actualise can be run with the option −−silent. 

If a package is not found, it may be the case that it is available in a repository which is not configured for 

this system. The unmaintained section is a repository section with numerous, further packages, which is 

available for every UCS version. If this area should be mounted on a system, this can be done by setting 

the Univention Configuration Registry variable repository/online/unmaintained to yes. If local 

repository servers are set, it must be observed that the unmaintained section will also be synchronised in 

this case and the repository thus requires more memory space on the hard drive. 

11.3.3 Adding component repositories 

In addition to the standard repositories, additional software components can also be integrated. There 

are two possible variations to use these. On the one hand, the Univention Management Console module 

Online updates can be used. Alternatively this can be performed using the following Univention Configu- 

ration Registry variables: 

repository/online/component//server The repository server on which the components are 

available. If this variable is not set, the server from the Univention Configuration Registry variable 

repository/online/server uses 

repository/online/component/ This variable must be set to enabled if the components are to 

be mounted. 

repository/online/component//localmirror This variable can be used to configure whether the 

component is mirrored locally. In combination with the Univention Configuration Registry variable 

repository/online/component//server, a configuration can be set up so that the 

component is mirrored, but not activated, or that it is activated, but not mirrored. 

repository/online/component//description A descriptive name for the repository. 

repository/online/component//prefix Defines the URL prefix which is used on the repository 

server. This variable is usually not set. 

repository/online/component//username If the repository server requires authentication, the 

242 

user name can be entered in this variable.


repository/online/component//password If the repository server requires authentication, the 

password can be entered in this variable. 

repository/online/component//version This variable controls the versions to include. The fol- 

lowing variants are possible: 

empty or unset All versions of the same major number will be used. If for example UCS-2.3 is 

installed, all repositories of the component with version numbers 2.0, 2.1, 2.2 and 2.3 will be 

used if available. 

current Using the keyword „current” will likewise include all versions of the same major version. 

Additionally it will block all minor and major upgrades of the installed UCS system until the 

respective component is also available for the new release. Patch level and security updates 

are not affected. If for example UCS-2.3 is currently installed and UCS-2.4 or UCS-3.0 is 

already available, the release updated will be postponed until the component is also available 

for version 2.4 and 3.0 respectively. 

major.minor By specifying an explicit version number only the specified version of the component 

will be used. Release updates of the system will not be hindered by such components. Multiple 

versions can be given using commas as delimiters, for example 2.0,2.3. 

repository/online/component//defaultpackages A list of package names separated by blanks. 

The UMC module Online updates offers the installation of this component if at least one of the pack- 

ages is not installed. Specifying the package list eases the subsequent installation of components. 

The name of the repository on the server must be given for . For example, to mount the 

UCS@School component, the following variable must be set: 

ucr set repository/online/component/ucsschool/description="UCS@School packages" \ 

repository/online/component/ucsschool/server=apt.univention.de \ 

repository/online/component/ucsschool=yes 

The following, additional repositories are then mounted on the system: 

deb http://apt.univention.de/2.2/maintained/component ucsschool/all/ 

deb http://apt.univention.de/2.2/maintained/component ucsschool/extern/ 

deb http://apt.univention.de/2.2/maintained/component ucsschool/amd64/ 

The last line in the list is dependent on the architectures available. 

11.3.4 Managing package lists 

Alongside automatic system updates, package maintenance in UCS also supports the installation and 

removal of packages. 

Each system role in UCS is installed with a selection of packages, selected components expand this range. 

When installation profiles are used, single packages can be added additionally during the installation. 

Package lists are used for the subsequent installation of packages on a wide range of systems. 

Packages installed on a system via a package list, are also renewed within the scope of an update when a 

newer version is available in the repository. Packages to be removed must only be removed once. These 

packages are also removed again if they are discovered on the system during the regular system updates. 

243


The package lists themselves do not prompt the installation or removal or packages. Package lists are 

used much more often in package policies relating to specific system roles, which allow the installation or 

removal of packages. 

Specific package policies are available for the different system roles (see table). This makes it possible to 

link the policies with the domain base and apply a single policy to all computers with the same system role 

in the domain without any consequences for computers with other system roles. For example, a package 

selection in the package policy for managed clients only applies to computer with the managed client 

system role. The policies can also be edited on the appropriate tab of the respective computer objects. 

Package policy UCS system role 

Packages Master DC Master and DC Backup 

Packages Slave DC Slave 

Packages Member Member server 

Packages Client Managed client 

Packages Mobile client Mobile client 

The following steps must be performed when using package lists. 

New packages list are created under Navigation ➞ univention ➞ packages in Univention Directory 

Manager. 

Notes on the creation of package list objects can be found in Chapters 4.4 und 4.5.11. 

The entry Settings: Package list is selected from the Add new object at current position menu and a 

Name for the package list entered in the appropriate text field. 

The name of the desired package is entered in the Package List input field. For example, if the Emacs 

editor should be installed on all managed clients. The name of the package is entered without the version 

number and the ending .deb, which gives emacs. The package is entered with the [Add] button. Further 

package names can be entered as required. 

The package list is saved by clicking on [Ok]. The package lists created can be used in a package policy 

specific to a system role. A policy is then created directly on a computer object. 

A computer object is opened on which the packages from the package list should be installed, e.g., on a 

managed client. The [Packages] tab is opened (see Figure 11.2). There are two areas in which package 

lists can be selected. Packages which should be installed can be given in the upper area and packages 

which should be deleted can be given in the lower area. The previously created package list is selected 

from the Package list menu. The package names contained in the package list can not be selected after 

each other under Package Installation list and added to the list of packages to be installed using the Add 

button. 

The settings are saved by clicking on [Ok]. 

A package policy specific to system roles created in this way can also be reused. The path to the policy is 

given in the Configuration field on the policy itself. For example, the entry Packages can be selected via 

(current) ➞ Policies on a computer object and the previously created policy selected in the Configuration 

menu . Once the page has been refreshed, the values are shown in the text field which were entered 

originally. These settings apply to all managed clients below the computer container on activation. 

244

Figure 11.2: Package list client 


If a package maintenance policy has been created for this computer object (see Section 11.3.2), the 

packages will be installed by univention-actualise the next time the package update is started. 

Attention: 

Alternatively, Univention Management Console can be used if software is only to be (un)installed on one 

computer. Further information can be found in Chapter 5.1. 

11.3.5 Release updates 

When more than one UCS release is contained in a repository (see Section 11.5), UCS systems can be 

updated to the latest release manually or automatic. The manual update via univention-updater is 

described in Section 11.2.2. 

The automated release update uses two policies. A UCS version number can be given in the Release 

policy, which stipulates to which version a UCS system is updated. The format of the version is that of the 

UCS version formats used elsewhere (2.0-0, 2.0-1 etc.). The time of the release update is specified by the 

Maintenance policy. If automatic package maintenance is activated for a computer (see Section 11.3.2), 

245


the univention-updater command is executed at a certain time. The package update is performed 

after the release update. 

The outputs of univention-updater during the automated release update are written to 

/var/log/univention/updater.log on the updated systems. 

11.3.6 Manual package maintenance 

All package maintenance processes can either be performed with the Univention Management Console 

package management (see Chapter 5.3.11) or using command line-based tools. The conventional Debian 

tools are used. 

Further information can be found in [17]. 

11.3.6.1 Installing packages 

Individual packages are installed using the command 

univention-install PACKAGENAME 

The repository server is used as the installation medium. When installing a package it is sometimes 

necessary to install additional packages, which are required for the proper functioning of the package. 

These are called packages dependencies. The installation can be simulated with the parameter -s to 

check in advance which dependencies are retrieved. 

Each system receives a local list of available packages. Before the installation of a package, the repository 

server’s package list should be updated to ensure that the up-to-date version is used and all dependencies 

are resolved: 

apt-get update 

11.3.6.2 Searching for available packages 

If the name of a package is known, 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. 

apt-cache search fax 

The package list must also be updated here to ensure that search is performed in the up-to-date package 

vault (see 11.3.6.1). 

11.3.6.3 Removing packages 

Individual packages are removed with the command 

apt-get remove PACKAGENAME 

Packages required by the package removed are also removed in turn. 

This procedure can be simulated using the -s parameter. 

246

11.3.6.4 Information about installed packages 

11.4 Software monitor 

Information regarding the installed packages can be shown using the command dpkg. The run parameter 

-l and the package name can be entered to show the version number of an installed package. Using 

the run parameter -l without package names will result in the display of a list of all known packages. 

Wildcards in package names can be used to limit the search to certain packages. Wildcards can be an 

asterisk (’*’ - for no or many characters) or a question mark (’?’ - for exactly one character). It may be 

necessary to escape the wildcard when using asterisks as these may otherwise be interpreted by the shell. 

dpkg -l univention-config-registry 

dpkg -l 

dpkg -l univention-\* 

dpkg with the run parameter -L and a package name can be used to discover which files are contained 

in an installed package. No wildcards can be used with the run parameter -L. 

dpkg -L univention-ldap-server 

dpkg with the run parameter -S and a file name can be used to discover which package a file belongs 

to. The search can take some time as it encompasses the complete databases of the installed packages. 

Files that have been created by packages following installation cannot be assigned to a package by dpkg 

-S. 

dpkg -S /var/lib/univention-ldap/replog 

Further information on the dpkg command can be found on the man page (man dpkg). 

11.4 Software monitor 

The software monitor is a database in which information is stored concerning the software packages 

installed across the domain. This database offers an administrator an overview of which release and 

package versions are installed in the domain and offers information for the step-by-step updating of a UCS 

domain and for use in identifying problems. 

UCS systems update their entries automatically when software is installed, uninstalled or updated. 

The database can be set up by selecting the Software monitor component in the Univention Installer. As 

standard, the component is only preselected on the domain controller master. 

The system on which the database is operated is set up by the DNS service record _pkgdb._tcp during 

installation of the packageunivention-pkgdb. If it is installed subsequently on other system roles, the 

DNS service record 

pkgdb tcp 0 0 5432 

must be created manually. Further information can be found in the Chapter 4.5.9.4. 

The software monitor’s web-based interface integrates in the Univention Management Console. (General 

information on Univention Management Console can be found in Chapter 5.1) The following software 

monitor functions can be used: 

247


• Search systems lists all systems with the set filter features. System names, UCS versions or system 

roles can be combined flexibly as filters. Search filter can be saved permanently. 

• Search packages lists all systems where a certain package is installed. This allows searches for 

the installation status of individual packages as well as package names. Search filters can be saved 

permanently. 

The following gives an overview of the search possibilities available for the installation status of 

packages: 

– The Package selection state influences the action taken when updating a package. Install is 

used to select a package for installation. If a package is configured to Hold it will be excluded 

from further updates. There are two possibilities for uninstalling a package: A package re- 

moved with DeInstall keeps locally created configuration data, whilst a package removed with 

PurgePurge is completely deleted. 

– The Installation state describes the status of an installed package in relation to upcoming 

updates. The normal status is Ok, which leads to a package being updated when a newer 

version exists. If a package is configured to Hold it will be excluded from the update. 

– The Current package state describes the status of a set-up package. The normal status here 

is Installed for installed packages and ConfigFiles for removed packages. All other statuses 

appear when the package’s installation was cancelled in different phases. 

• Identify problems allows automatic identification of installation problems: 

– The installed package version can be compared with the expected package status of any cho- 

sen release. This allows the efficient discovery of out-of-date software in large environments. 

– Incompletely installed software packages can be identified. 

If you do not wish UCS systems to store installation processes in the software monitor (e.g., when there 

is no network connection to the database), this can be arranged by setting the Univention Configuration 

Registry variable pkgdb/scan to no. 

Should storing be reactivated at a later date, the command univention-pkgdb-scan must be executed 

to ensure that package versions installed in the meanwhile are also adopted in the database. 

As standard only systems from the database server subnet can store their configuration in the soft- 

ware monitor. To grant systems from other subnets access, an appropriate network range or network 

mask must be entered in the Univention Configuration Registry variables pgsql/pkgdb/network and 

pgsql/pkgdb/netmask. An example: 

univention-config-registry set pgsql/pkgdb/network=10.200.0.0 

univention-config-registry set pgsql/pkgdb/netmask=255.255.0.0 

Following these changes the Postgresql service must be restarted (e.g. using the Univention Management 

Console). 

11.5 Repository management 

A repository contains the software packages and updates and makes them available to other UCS sys- 

tems. Repositories can be set up on UCS domain controllers and member servers. A server which offers 

248


a repository is known as a repository server. The univention-debmirror package must be installed 

on repository servers. 

As of UCS 2.2 UCS domains can also be operated without a local repository server. In this case, 

the systems access the online repository. If local repository servers are used, the synchronisation be- 

tween the servers must be configured. For this, the repository serves as the master repository and all 

other repositories are slave repositories which contain a copy of the master repository or another slave 

repository. The hierarchies of repositories are dealt with in Section 11.5.5. The repository is under the 

/var/lib/univention-repository/mirror directory on UCS servers. 

The Univention Configuration Registry variable local/repository can activate/deactivate the local 

repository (yes/no). 

The software packages stored in the repository are provided in the Debian package format. 

The tools described in Section 11.2.1 and 11.2.2 are used when UCS security or release updates are 

imported. 

An example software distribution architecture for a UCS domain with two locations can be seen in Fig- 

ure 11.3. Three repository servers are operated. The domain controller master updates its repository from 

the online repository. The domain controller backup retrieves updated packages from the DC Master ex- 

clusively via repository synchronisation. The domain controller slave as the location server retrieves these 

packages from the DC backup via repository synchronisation. 

A repository server is set for each UCS system in the domain, from which packages are downloaded for 

subsequent installation or updating. To distribute the loads the UCS systems from the central location are 

shared amongst the repository servers. The UCS systems from the external location use the repository 

server. All UCS systems report changes to installed packages to the software monitor on the DC master. 

The repository on the DC master can retrieve new updates directly from the online repository. 

11.5.1 Creating a repository 

Repositories can be created during the installation of UCS server systems using Univention Installer. 

The univention-repository-create command is used to create a local repository (also subse- 

quently). The command must be run as user root. To set up a repository, the univention-debmirror 

package must be installed. 

11.5.2 Adding packages 

Generally, packages are added to repositories with the corresponding tools after the initialisation of a 

repository via security updates or release updates. Further packages can be added to the master reposi- 

tory using the univention-repository-addpackage program. The newly added packages can then 

be automatically distributed or installed in the UCS domain. The program receives the target directory and 

the packets which were added as parameters. Example: 

univention-repository-addpackage \ 

--dest /var/lib/univention-repository/mirror/2.2/maintained/2.2-0/ \ 

--file kde-profiles-test1.deb kde-profiles-test2.deb 

249


11.5.3 Removing packages 

Figure 11.3: Example setup of software distribution 

Packages are removed from the master repository with univention-repository-delpackage pro- 

gram. The package must also be removed from all slave repositories. The program receives the packages 

to be deleted as parameters. Example: 

univention-repository-delpackage --file \ 

/var/lib/univention-repository/mirror/2.2/maintained/2.2-0/all/profile\_*.deb 

11.5.4 Merging repositories 

The univention-repository-merge program is used to move all the packages from one directory to 

another. If it already contains other versions of a package, the program ensures that the up-to-date version 

is saved automatically and all older versions are deleted. 

In principle, univention-repository-merge can be used with any directories. As standard it is used 

to merge packages from the update directory with packages from the package directory and only keep the 

up-to-date package version. 

Attention: 

Before update directories can be merged, all UCS systems must be updated to the same release status. 

The update directories are required for future updates, even when they no longer contain packages. The 

must therefore not be deleted! 

The univention-repository-merge program is executed as follows: 

250

univention-repository-merge --dest \ 

--src 


In this, the parameter stipulates the directory in which the packages should be 

merged, whilst the parameter is the directory out of which the packages should be 

moved. Example: 

univention-repository-merge --dest /var/lib/univention-repository/new --src \ 

/var/lib/univention-repository/mirror/2.2/maintained/2.2-0/ --src \ 

/var/lib/univention-repository/mirror/2.1/maintained/2.1-0/ 

When cleaning several update directories, the highest version number should be used first. This speeds 

up the merge as only newer versions are moved. Older package versions are simply deleted without the 

index file of the target directory needing to be updated, which takes time. 

If repository synchronisation is active, the merge of the update directories must be performed on the 

master repository. Otherwise the original status will be restored the next time synchronisation runs. When 

merges are carried out on the master repository, the changes are adopted by the subordinate repositories. 

11.5.5 Repository synchronisation 

Operation of several local repository servers can prove practical in certain scenarios. For example, in UCS 

domain with several locations, a repository server can be run at each location. Without repository syn- 

chronisation, the administrator must ensure himself that all repositories are up-to-date, i.e., all repositories 

must be updated manually by the administrator. This applies for release updates, security updates and 

additional packages. Repository synchronisation reduces maintenance down to one repository server. 

Alternatively, environments can also do without local repository servers entirely and set up a direct access 

to the online repository or synchronisation of the local repository servers can be configured with the online 

repository. 

One repository server is designated the master repository server in the repository synchronisation. Only 

changes such as security and release updates are performed in this repository; packages are added and 

removed individually. Other repository servers, so-called slave repository servers, check regularly to see 

if changes have been made on the master repository server and adopt them. When synchronisation is 

performed with the online repository, this is regarded as the master repository. If additional packages are 

required which are not available over the online repository, a locally repository server must be used for this 

purpose. All other local repository servers should be synchronised over this repository server. 

A slave repository server does not need to access the master directly. Slave repository servers can be used 

for the synchronisation of another slave repository server which retrieves changes from a superordinate 

repository server. 

The tool univention-repository-update is used to import a package from a UCS release update 

onto the master repository server. This supports two modes: 

univention-repository-update cdrom Here the repository is updated with an update DVD. 

251


univention-repository-update net Here the repository is synchronised with another spec- 

ified repository server. This is defined in the Univention Configuration Registry variable 

repository/mirror/server. 

The possibility also exists of integrating a release update into the repository without directly starting an 

update using the univention-repository-update command. This can be done from another repos- 

itory with the net option (this can also be the online repository) or from an update DVD with the cdrom 

option. 

univention-repository-update net 

univention-repository-update cdrom --cdrom --iso ucs_update.iso 

When setting up repository synchronisation, the assignment to a superordinate server and the time will be 

configured by policies. 

As described in Section 11.3.1, the repository server policy can be used to specify which repository server 

should be used for package installations for each UCS system. This policy sets which repository server 

should be used as the superordinate repository for the synchronisation on all UCS systems with an active 

local repository at the same time. For this reason, no repository server is entered for a master repository 

server. 

The time for the automatic repository replication of the individual slave repository servers can be defined 

in the Repository synchronisation policy. The month, weekday, day, hour and minute can be specified. 

The synchronisation with the superordinate repository server will be started whenever all of the settings 

are met. 

Repository synchronisation can also be configured locally on the systems using Univention Configura- 

tion Registry variables. The Univention Configuration Registry variable repository/mirror/server 

defines the repository server which will serve as the source for the synchronisation. For example, to syn- 

chronise directly with the online repository, the Univention Configuration Registry variable must be set to 

apt.univention.de. Alternatively, to synchronise with another local repository server, the fully qualified 

computer name of the system is given. 

univention-config-registry set repository/mirror/server=apt.univention.de 

As standard, the repository is only initialised with packages for the architecture of the repository server. 

If the UCS domain is operated with systems of differing architectures, the architectures can be specified 

through the Univention Configuration Registry variable repository/mirror/architectures. The 

format is to be used in a list separated by blanks. 

Which standard repositories are synchronised is defined by the Univention Con- 

figuration Registry variables repository/online/maintained for the maintained 

section, repository/online/unmaintained for the unmaintained section and 

repository/online/hotfixes for the hotfixes. As standard, only the variable 

repository/online/maintained is set to yes. 

If repositories for components are set on the system, these are also synchronised by the specified server. 

The Univention Configuration Registry variable repository/mirror/version/start is used to de- 

termine as of which Univention Corporate Server version the repositories should be synchronised. For 

252

example, synchronisation as of UCS 2.1-0 can be confirmed by: 

univention-config-registry set repository/mirror/version/start=2.1-0 


All changes which are made during synchronisation on a repository server are documented locally in the 

/var/log/univention/repository.log file. 

253


254

12 Mail 

Contents 

12.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 

12.2 Basic mail services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 

12.3 Setting up the mail server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 

12.3.1 SMTP server (Postfix) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 

12.3.2 IMAP/POP3 server (Cyrus) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 

12.3.3 Mail quota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 

12.3.4 Log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 

12.4 Spam filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 

12.5 Virus filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 

12.6 Configuring mail clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 


12.6.1 Kontact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 

12.6.2 Outlook Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 

The UCS mail system provides mail services in two variants. 

Basic mail services are installed on all UCS server systems and managed and mobile clients (Package 

univention-mail-postfix-forward). These deliver local e-mails UNIX typically in the /var/spool/mail 

directory. E-mails for other recipients are forwarded to a relay host defined in the LDAP directory, which 

proceeds to provide them via POP/IMAP or forward them other servers. 

The mail component is available for DC master/backup and slave servers during installation. This installs 

expanded mail services, which are made available to all users registered in UCS and other UCS systems 

as a relay host. Services like SMTP, POP and IMAP are preconfigured. 

Installation of the mail component is also possible on UCS member servers, but this is not recommended. 

This component is closely linked to the LDAP directory and should thus only be installed on systems with 

a local LDAP server. It can otherwise become quite stretched when there is a lot of e-mail traffic. 

In typical installations only one mail server is used; in small networks this role can be adopted by the DC 

master. If the mail service is also installed on the DC backup, it will be deactivated initially. Due to the data 

quantity no automatic calibration of the mailboxes is performed. 

Alongside the UCS mail system there are also further groupware systems based on UCS, which also offer 

integration into the UCS management system, for example: Kolab2 for UCS [18], Scalix for UCS [19], 

Zarafa or Open-Xchange. 

255

12 Mail 

12.2 Basic mail services 

The basic configuration allows the sending of e-mails via local programs. The relay host used for non-local 

addresses can be entered overall for all clients in Univention Directory Manager. The respective listener 

module then sets the Univention Configuration Registry variable mail/relay and prompts the mail server 

(Postfix) to reimport its configuration files. 

If this variable is not set or no relay host is entered in the LDAP directory, an attempt will be made to 

resolve the responsible mail server via DNS (MX record) for non-local e-mails. If the delivery fails, the 

e-mail is returned to the sender. 

In addition, mail/alias/= Univention Configuration Registry variables maintain 

aliases. The preset is: 

mail/alias/root=systemmail@. 

mail/alias/postmaster=root 

For this the user systemmail is set up in the system, so that e-mails which are sent locally to root or 

postmaster are stored in the /var/spool/mail/systemmail mailbox. 

The variables can be configured to collect e-mails from the UCS systems on the relay host, for example. 

For this, the following should be entered in the UCS system command line: 

univention-config-registry set mail/alias/root=administrator@ 

newaliases 

should be replaced with the DNS domain. The e-mails to root are no longer treated as 

local e-mails, but rather forwarded to the relay host. As postmaster is an alias for root, this also applies to 

the e-mails addressed to him. That is also possible when setting any new alias. The command newaliases 

is necessary to publish the changed Postfix settings. 

12.3 Setting up the mail server 

Selecting the Mail component during installation installs the necessary packages for configuring a com- 

plete mail server. 

The required functions are provided by the installed packages Postfix (sends e-mails via SMTP) and Cyrus 

(provides e-mail access via POP and IMAP). 

During the installation the server is automatically entered in the LDAP directory on the domain object as 

the relay host. 

If mail services are not set up in the scope of the initial installation, this set-up can be effected subsequently 

by installing the univention-mail-postfix and univention-mail-cyrus packages. 

12.3.1 SMTP server (Postfix) 

The configurations preset by the univention-mail-postfix package use Postfix to offer all users registered 

in the domain with a SMTP service. 

256


To assign a user an e-mail address, his primary e-mail address must be entered in Primary e-mail ad- 

dress of the the Mail tab of a user object in Univention Directory Manager. This is used for authentication 

on the mail server. Additionally any number of further addresses under which the user should be reachable 

can be entered in the Alternative e-mail addresses field. The e-mails sent to the entered user addresses 

are all delivered to the same inbox. If two users have the same alternative e-mail address, they both 

receive all the e-mails which are sent to this address. Primary e-mail addresses on the other hand must 

always be unique. 

Postfix differentiates between the delivery of e-mails between local and external domains. Delivery to 

mailboxes defined in the LDAP directory is only conducted for e-mail address from local domains. The 

DNS domain of the mail server is preset for this. If e-mail addresses should be assigned to local mailboxes 

which are not from the server’s domain, a list of the domains to be used can be defined using the Univention 

Configuration Registry variable mail/hosteddomains. Example: 

univention-config-registry set mail/hosteddomains="mydomain.com \ 

myotherdomain.com subdomain.mydomain.com" 

In this it must be noted that the otherwise preset domains of the server must be a component of this list to 

process e-mails from the local domain. Then the command 

postmap /etc/postfix/transport 

must be executed to adopt the changes via Postfix. 

For incoming e-mails Postfix performs a validity test in the form of a search of the LDAP directory for 

domains from the thus defined field of responsibility. That means that e-mails are only accepted for e-mail 

addresses defined in the LDAP directory or via an alias. 

Following the optional filtering for spam and viruses, the received e-mails are forwarded to the local 

POP/IMAP server Cyrus. 

E-Mails to foreign domains are sent directly to the responsible server as standard, which is resolved 

via MX records. If the output should be taken over by a relay host, e.g., the Internet provider, the fully 

qualified domain name of the relay host must be entered in the Univention Configuration Registry variable 

mail/relayhost. 

If authentication is necessary on the relay host for sending, the Univention Configuration Registry variable 

mail/relayauth must be set to yes and the /etc/postfix/smtp_auth file edited. The relay host, 

user name and password must be saved in this file in one line. 

: 

The following command must then be executed for this file to adopt the changes via Postfix. 

postmap /etc/postfix/smtp_auth 

The Univention Configuration Registry variable mail/messagesizelimit can be used to set the maxi- 

mum size in bytes for incoming and outgoing e-mails. The preset maximum size is 10240000 bytes. If the 

value is configured to 0 the limit is effectively removed. 

After modifying configuration settings Postfix must be restarted to ensure correct functioning in accordance 

with the settings. This is done with: 

257

12 Mail 

/etc/init.d/postfix restart 

If the Univention Configuration Registry variable mail/archivefolder is set to an e-mail address, Post- 

fix sends a blind carbon copy of all incoming and outgoing e-mails to this address. This results in an 

archiving of all e-mails. As standard the variable is not set. If there is no mailbox for this address, one will 

be created automatically. 

The Univention Configuration Registry variable mail/postfix/dnslookups (yes/no) is used to config- 

ure the DNS resolution of hostnames for the delivery via SMTP and LMTP. If the variable is set to no the 

resolution occurs over the standard system routine, which typically also enters entries in the /etc/hosts 

file. 

In a number of error situations (e.g., for non-existent users) the result may lead to a mail bounce, i.e., 

the mail cannot be delivered and is returned to the sender. When the Univention Configuration Registry 

variable mail/postfix/softbounce is set to yes mails are never returned after a bounce, but instead 

are held in the queue. This setting is particularly useful during configuration work on the mail server. 

Mail routing is usually effected via MX records saved in DNS. In special cases - for example, the operation 

of a tunnel between two servers which cannot be resolved via DNS - it may be necessary to configure a 

manual transport route. Thus can be added to the file /etc/postfix/transport using the Univention 

Configuration Registry variable mail/maps/transport/IDENTIFIER. An example: 

mail/maps/transport/1="somedomain.org smtp:[mail.somedomain.com]" 

Sometimes it is necessary to rewrite e-mail addresses, for example when new e-mail addresses are 

added during a restructuring operation. This can be effected using canonical mappings. The Univen- 

tion Configuration Registry variable mail/maps/canonical/sender/enable can be used to rewrite 

on the server side either using the file /etc/postfix/canonical_sender (file) or via access to the 

LDAP (ldap). The settings for reformulating recipient addresses are performed over Univention Configu- 

ration Registry variable mail/maps/canonical/recipient/enable. If it is configured to file, the file 

/etc/postfix/canonical_recipient is read out; access to the LDAP (ldap) is also possible here. 

Univention Configuration Registry variable mail/maps/canonical/sender/classes can be config- 

ured to specify which address information should be converted. The options available for selection are 

envelope_sender and/or header_sender. 

If the package univention-mail-cyrus is installed, SMTP authentication is available as standard. 

If univention-mail-postfix is intended to be operated independently, the configuration for the au- 

thentication service saslauthd must be adjusted manually and the following entry entered in the 

/etc/default/saslauthd file: 

START=yes 

Postfix then uses the saslauthd for the authentication. 

12.3.2 IMAP/POP3 server (Cyrus) 

Cyrus offers IMAP and POP services preconfigured using the univention-mail-cyrus package. The au- 

thentication is performed using the primary e-mail address. That means that the e-mail address should be 

258


entered as the user name in mail clients for POP or IMAP access. Configuration examples for Kontact and 

Outlook can be found at the end of this Chapter. 

The services can be deactivated separately with Univention Configuration Registry. If no access should be 

available via POP, Univention Configuration Registry variable mail/cyrus/pop must be set to no. The 

same applies to IMAP and Univention Configuration Registry variable mail/cyrus/imap. 

As soon as a user in the LDAP directory is assigned a primary e-mail address, a listener module 

creates a mailbox on the Cyrus server under /var/spool/cyrus/mail/domain in the subdirectory 

//

12 Mail 

12.3.4 Log files 

As standard, Postfix, Cyrus and where used spam and virus scanners write information pertaining to 

each e-mail in the log files saved in /var/log/mail.. It is advisable to limit these out- 

puts on servers with high e-mail traffic. This is done by adapting the configuration of Syslog in the file 

/etc/syslog.conf. 

The following lines are found in the file: 

mail.info -/var/log/mail.info 

mail.warn -/var/log/mail.warn 

mail.err /var/log/mail.err 

For example, messages from the info category containing several notes on each successfully processed 

e-mail can be re-routed to /dev/null and thus the space used on the hard drive and system loads 

reduced. For this, the line with mail.info is replaced with: 

mail.info /dev/null 

The changes must then be made known to the Syslog service: 

/etc/init.d/sysklogd reload 

Attention: It is not recommended to direct all of the mail server’s messages to /dev/null. If this is the 

case, there is no way to receive an overview of the e-mails already affected in the case of an error. 

12.4 Spam filters 

The term “spam” refers to all e-mails which the recipient neither requested nor appreciated. They demand 

recipients’ work time and abuse their trust in the medium of e-mail. 

In the standard configuration the univention-spamassassin is installed on a UCS mail server. The pack- 

age can, however, be deactivated during installation in the advanced selection possibilities. 

Spamassassin is a program which attempts to identify whether an e-mail is desirable or not based on 

its origin, form and content. It operates a scoring system, which uses an increasing number of points to 

express a high probability of the e-mail being spam. Points are awarded according to different criteria, for 

example, keywords within the e-mail or a lacking layout. There is also the possibility of evaluating e-mails 

with a bayesian classificator. It compares an incoming e-mail with statistical data already gathered from 

previously processed e-mails and uses this to adapt it’s evaluation to e-mail tendencies. 

When modifying Univention Configuration Registry variables concerning spam detection, the Amavis ser- 

vice und Postfix must be restarted subsequently. 

The installed package includes a filtering of all e-mails received via SMTP using a preconfigured Spamas- 

sassin. In the standard configuration only mails with a size of up to 300 kilobytes are scanned, this can be 

adjusted using the Univention Configuration Registry variable mail/antispam/bodysizelimit. 

E-mails which are classified as spam because they exceed a certain number of points are not deliv- 

ered in the recipient’s inbox by Cyrus, but rather in the spam folder below it. This standard procedure 

260

12.5 Virus filters 

can be changed in the Univention Directory Manager user management on the Mail tab of a user ob- 

ject via Use global spam folder. If the attribute is set, all e-mails identified as spam are sent to the 

spam@ address and can be checked in the appropriate IMAP directory, but are no longer 

available for the original recipient to access. The e-mail address for the global spam recipient can be 

configured in the Univention Configuration Registry variable mail/antispam/globalfolder. 

The scoring threshold at which the e-mails are declared to be spam can also be configured. To do this, 

Univention Configuration Registry variable mail/antispam/requiredhits must be set to a number: 

the preset is 5. This value is practical for processing with an active Bayes classifier, which generally leads 

to higher point numbers. Depending on experience in your personal environment, this value can also be 

set lower. This will, however, result in more e-mails being incorrectly designated as spam. 

The Bayes classifier will only become active when a sufficient number of undesirable (spam) and desirable 

(ham) e-mails are converted into a learning algorithm. To allow the users to pass on their spam and falsely 

classified e-mails to the learning algorithm, the Spam and Ham folders are created for each user when 

setting up his inbox. These must be created manually for the user accounts created with a UCS version 

lower than 2.3. 

If the Univention Configuration Registry variable mail/antispam/learndaily on the server is set to 

yes, the Cyrus service searches the Spam and Ham folders of all users and the global spam recipient 

daily for unknown e-mails. If data are found which have not yet been collected or were previously classified 

incorrectly, these are used to update a shared database of collected, statistical data. This function is 

deactivated as default. 

Alternatively, the learning process can be executed manually using the program sa-learn. If e-mails are 

in a file in Mbox format, as is often used or exported by mail programs, the e-mails contained therein can 

be classified as spam using the following command: 

sa-learn --spam --mbox 

or as ham, i.e., desirable e-mails, using 

sa-learn --ham --mbox 

For the classification of e-mails it is advisable to provide the same quantity of desirable and undesirable 

e-mails as is processed via the server. If no manual learning is performed, Spamassassin learns automat- 

ically during the filtering procedure. That means that Spamassassin learns incorrectly classified e-mails 

incorrectly. 

The spam filtering can be deactivated by setting Univention Configuration Registry variable 

mail/antivir/spam to no or reactivated by setting it to yes. 

Postfix must be subsequently restarted. (See Chapter 12.3.1) When set to no every incoming e-mail is 

sent to respective user without being checked first. 

12.5 Virus filters 

The package univention-antivir-mail sets up the program Amavisd-new as an interface between Postfix 

and different virus scanners. The free virus scanner ClamAV is included in the package and enters op- 

eration immediately after installation. Other virus scanners can be mounted alternatively or additionally 

261

12 Mail 

by entering them in the Univention Configuration Registry variable mail/antivir/scanner. Kaspersky 

and Sweep (Sophos) are currently tested. The configuration for numerous other scanners is prepared 

untested, the settings can be requested from UCS support. 

Following installation, the virus scanner ClamAV is active as standard. If another virus scanner 

is to be used in addition to or instead of ClamAV, the Univention Configuration Registry variable 

mail/antivir/scanner must be set accordingly. If several virus scanners are given they are sepa- 

rated by blank spaces. Example: 

univention-config-registry set mail/antivir/scanner="clamav sweep" 

The Univention Configuration Registry variable mail/antivir is used to activate virus scanners with 

(yes) or deactivate them with (no). Changes to mail/antivir/scanner and mail/antivir will only take effect 

the next time Postfix and Amavis are restarted. 

All incoming and outgoing e-mails are scanned for viruses. If the scanner recognises a virus, the e-mail is 

sent to quarantine. That means that the e-mail is stored on the server where it is not accessible to the user. 

The original recipient receives a message per e-mail stating that this measure has been taken. If neces- 

sary, the administrator can restore or delete this from the /var/lib/amavis/virusmails directory. 

Automatic deletion is not performed. 

12.6 Configuring mail clients 

The following uses Kontact and Outlook Express as examples for which settings are necessary to use the 

UCS mail server. Note that the Cyrus inbox server expects the user name to be the primary e-mail address 

in lowercase. 

Detailed instructions on the configuration possibilities can be taken from the separate documentation avail- 

able on the Univention groupware server at http://www.univention.de/download_doku.html. 

12.6.1 Kontact 

Kontact 1.2.4 (enterprise 20071102-731871) was used for the documentation. 

When Kontact is started the component E-Mail should be selected in the left margin. The configuration 

dialogue for the mail component of Kontact is executed via Settings ➞Configure KMail. 

For this, the following listed settings should be performed as described and any other settings performed 

as necessary. 

262 

• A standard identity is already set up under Identities. This can be edited by selecting [Modify]. The 

user’s primary e-mail address configured on the Mail tab in Univention Directory Manager must be 

entered in the Email address field. 

• A new outbox must be set up under Accounts on the Sending tab. After selecting [Modify] the 

mailing type SMTP must be selected. In the following dialogue window all relevant settings for the 

mail server must be performed.

Field Value to be entered 

12.6 Configuring mail clients 

Name This name signifies the name of the new outbox and be chosen 

freely. It is best to choose a short name which makes it easy 

to see that the mails are sent over the UCS mail server (e.g., 

"ucs-mail"). 

Host The name of the UCS mail server on the network. This can 

either only be given with the host name, the FQDN or the IP 

address of the mail server. 

Port 25 should be entered here. 

Server requires authentication This field must be activated. 

Login The primary e-mail address should be entered here as when 

editing the user’s identity 

Password The user’s password. 

Store SMTP password If this field is activated, the user password is saved in an acces- 

sible file, which means the user does not need to reenter his 

password every time he sends an e-mail. Saving a password in 

a file may present a security risk. 

Table 12.1: Configuration options for the new outbox 

• The [Check What the server supports] point should then be selected on the Security tab and the 

determined value adopted. A note may be displayed here that authentication of the server certificate 

has failed. After checking the certificate via [Details], [Continue] and then in the next dialogue 

[Permanently] can be selected to make the UCS mail server trust the certificate permanently. 

Clicking [OK] completes the set-up of the new outbox. An inbox must also be created to retrieve e-mails 

from the UCS mail server. 

• The [Add] button must be selected on the Receiving tab. 

• The type of new mailbox must the be selected. The concrete selection is then dependent on the 

personal requirements; IMAP is normally selected here. 

• In the following dialogue window all relevant settings for mail receipt are performed. 

Field Value to be entered 

Name This name signifies the name of the new inbox and be chosen 

freely. It is best to choose a short name which makes it clearly 

visible that the mails are retrieved from the UCS mail server 

(e.g., "ucs-mail"). 

Login The primary e-mail address should be entered here as when 

editing the user’s identity. 

Password The user’s password. 

Host The name of the UCS mail server on the network. This can 

either only be given with the host name, the FQDN or the IP 

address of the mail server. 

263

12 Mail 

Port IMAP 143 should be specified here. 

Store IMAP password The same notes for saving passwords apply here as to when 

setting up an outbox. 

Table 12.2: Configuration options for the new inbox 

• The advanced options are dependent on the type of the new mailbox. For a IMAP, DIMAP or POP3 

account [Check What the server supports] should be selected again on the Security tab and the 

determined value adopted. 

• Clicking [OK] completes the set-up of the new inbox account. 

The Settings ➞Configure KMail set-up dialogue is set up using the [OK] button. E-mails can now be 

retrieved from the mail server using the symbol showing an envelope and a green and white arrow. 

12.6.2 Outlook Express 

Outlook Express 6 in Windows XP Professional Service Pack 2 was used for this documentation. 

To create a new e-mail account, the assistant for Internet access must be started. This opens automatically 

when Outlook Express is started as long as no e-mail account has been set up in Outlook Express yet. 

It can otherwise be opened via Extras ➞Accounts ➞E-Mail tab ➞Add ➞E-Mail. For this, the following 

listed settings should be performed as described and any other settings performed as necessary. 

The primary e-mail address as entered for this user on the Mail tab in Univention Directory Manager must 

also be entered here in the Email address input field. 

POP3 or IMAP must be selected in the selection list in the phrase The server for incoming mail is a ... 

server. The FQDN of the UCS mail server responsible for the receipt of e-mails must be entered in the 

inbox server (POP3, IMAP or HTTP). 

The fully qualified domain name of the UCS mail server set up to send e-mails must be entered in the 

Server for outgoing mail (SMTP) input field. 

The e-mail address given as the primary e-mail address for this user on the Mail tab in Univention Directory 

Manager should be entered in lowercase in the Account name input field. The password entered for the 

user on the General tab in Univention Directory Manager should be entered in the Password input field. 

The checkbox Login through secure password authentication (SPA) should not be selected. 

If an existing e-mail account is to be reconfigured for the use of the UCS mail server, Extras > Accounts 

must be run in Outlook Express. The account should be selected on the E-mail tab and Properties clicked. 

The inbox server (IMAP or POP3), outbox server (STMP), account name and password input field must 

be filled in on the following Server tab as described above. Changing from IMAP to POP3 or vice versa 

requires the creation of a new e-mail account. 

264

13 Print services 

Contents 

13.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 

13.2 Installing print servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 

13.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 

13.2.2 Server systems as print servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 

13.2.3 Windows systems as print servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 

13.2.4 Thin clients as print servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 

13.2.5 Managed/mobile clients as print servers . . . . . . . . . . . . . . . . . . . . . . . . . 267 

13.2.6 Policy-based assignment of a print server . . . . . . . . . . . . . . . . . . . . . . . . 268 

13.3 Configuring printer shares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 

13.3.1 Configuring a locally connected printer . . . . . . . . . . . . . . . . . . . . . . . . . . 268 

13.3.2 Setting up network printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 

13.3.3 Setting up PDF printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 

13.3.4 Setting up printer groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 

13.4 Adding printer shares in Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 

13.5 Print quota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 

13.5.1 Activating the print quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 

13.5.2 Creating a print quota policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 

13.5.3 Analysing the print quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 

13.5.4 Modifying the print quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 

13.6 Univention Configuration Registry variables . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 


13.6.1 Settings for print clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 

13.6.2 Settings for the authentication on printer shares . . . . . . . . . . . . . . . . . . . . . 276 

13.6.3 Settings for printer shares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 

13.6.4 Settings for print quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 

Univention Corporate Server includes a print system, which can also be used to realise complex en- 

vironments. Printers and printer groups can be created and configured conveniently in ucsUDM (see 

Section 4.5.7). Extensions for cost calculation and page limitation can be installed subsequently using the 

print quota system. 

The print services are based on CUPS (Common Unix Printing System). CUPS manages print jobs in 

queues and where needed converts them to file formats that the respective printer can read. A wide range 

of filters are provided in the foomatic-filters package so that many printers can be employed without the 

need to install additional drivers. 

265


Not all print jobs are converted by CUPS. Print jobs in formats which are not recognised by CUPS or 

which can be read directly by the printer are forwarded on to the printer as (raw) files. This feature 

enables printing over a CUPS print server with Windows printer drivers. 

The connection to the printer is defined using the printer URI. For example, a printer on a local parallel 

port receives the printer URI parallel:/dev/lp0, which is composed of the protocol parallel: and 

the target /dev/lp0. Further documentation on URI formats can be found in the Section 4.5.7. 

The packages in the overview: 

• cupsys contains the CUPS print server. 

• foomatic-filters, foomatic-db, foomatic-filters-ppds provide a wide range of different printer 

drivers and filters. 

• univention-printclient composes the configuration for print clients in UCS. 

• univention-printserver depends on the cupsys and foomatic packages and composes the con- 

figuration for print servers in UCS. 

• univention-winprinters allows the import of Windows printer shares in UCS. 

• pykota provides a quota system for printer services. 

• univention-printquota integrates quota support for print services in UCS. 

• univention-printquotadb saves the information about print quotas in a database. 

• univention-printserver-pdf integrates the cups-pdf package in Univention Corporate Server, 

which is used in the creation of PDFs on the server. 

13.2 Installing print servers 

All system roles can be used as print servers and/or spool hosts in UCS. Initially in Univention Directory 

Manager, however, only server systems are available for selection (master, backup, slave and member 

servers). The command line can also be used to employ managed and mobile clients as print servers. 

Further information can be found in the Univention Directory Manager command line description [6]. 

13.2.1 Requirements 

The univention-printserver package must be installed to operate a print server. This pack- 

age installs and configures the required components. During the system installation the Print 

server component can also be selected. Post-installation it is possible to perform the set-up using 

univention-system-setup-software or installing the univention-printserver package via Univen- 

tion Management Console (see Section 5.3.11). 

13.2.2 Server systems as print servers 

There is a possibility for UCS server systems to store and configure printers and printer groups in Univen- 

tion Directory Manager. The printers stored there are then available to the network for Linux and Windows 

clients as printer shares. 

266

13.2.3 Windows systems as print servers 

13.2 Installing print servers 

Printer shares on Windows systems can also be mounted. This share can be set up on the print server in 

Univention Directory Manager. 

For example, to integrate the laser01 printer share from Windows system win01 via Univention Directory 

Manager, a printer share must be created with the protocol smb:// and the target win01/laser01. The 

manufacturer and model must be selected according to the unit in question. 

The print server uses the printer model settings to convert the print jobs where necessary and send these 

directly to the URI smb://win01/laser01. No Windows drivers are used in this. 

Independant of these settings, the printer share can be mounted by other Windows systems with the 

corresponding printer drivers. 

13.2.4 Thin clients as print servers 

As standard, a print server is operated on a thin client, which is preconfigured for the connection of printers 

via parallel or USB ports. This print server forwards print jobs to the respective port without performing 

any conversions. 

The thin client accepts print jobs from its own subnet and the desktop server on which the thin client 

session was started. Where necessary these print jobs must be converted to a format which the printer 

can read on the print server in advance as thin clients cannot perform filtering. 

To operate a printer on the parallel port of the thin client thin01, the printer share must be created on, for 

example, the responsible desktop server and assigned to the following printer URI: 

ipp://thin01.firma.com/printers/lp0 

For operation via a USB port it must be: 

ipp://thin01.firma.com/printers/usb0 

13.2.5 Managed/mobile clients as print servers 

To use a workstation as a print server, the univention-printserver package must firstly be installed. 

Clients cannot be selected as servers in the Univention Directory Manager printer management. However, 

printer shares can also be set to clients in the command line using univention-directory-manager. 

For example, the following command can be entered to add the laser01.domain.net printer as a printer 

share on the client01.domain.net client. 

univention-directory-manager shares/printer create --set name=laser01 \ 

--set spoolHost=client01.domain.net \ 

--set uri=parallel:/dev/lp0 --set model=None \ 

--position cn=printers,dc=domain,dc=net 

The printer share created can now be configured further in Univention Directory Manager. 

267


13.2.6 Policy-based assignment of a print server 

The Print server policy can be used to assign certain printer servers to the different server and client 

systems explicitly. The installation of the univention-printclient package on the respective system is a 

requirement for this. 

For general information on policies, please see Section 4.5.11. 

These settings configured through the policy are activated following the first policy evaluation (once an 

hour by default). 

As a result of the policy evaluation the configured print server is written in the Univention Configuration 

Registry variable cups/server on the client. 

13.3 Configuring printer shares 

New printer shares can be easily set up using Univention Directory Manager. The Univention Directory 

Manager module for printer management is described in detail in Section 4.5.7. 

As the type of printer share can vary considerably, the following examples should serve to illustrate some 

possibilities. 

13.3.1 Configuring a locally connected printer 

A HP laserjet 2100 is connected to the parallel port of the member01.domain.net member server and 

should be shared as laser01 in the domain domain. 

A new Printer object must be created in Univention Directory Manager under Printer ➞ Add. laser01 

should be entered as the name and the corresponding server added to the server list. The protocol 

parallel:/ and target dev/lp0 are combined to give the printer URI (parallel:/dev/lp0). Once 

the manufacturer HP and corresponding printer model Laserjet 2100 have been selected, the entry must 

be confirmed with [OK]. The printer is then shared in the domain as laser01. 

The stored printer laser01 should also be set as a printer share for the member02.domain.net member 

server. It should be known here as laser02. 

The printer is connected locally to member01. member02 forwards its print jobs to member01, which 

converts them for laser01 and prints them on laser01. 

The following steps set up the example: 

A new Printer object with the name laser02 must be set up in Univention Directory Manager. mem- 

ber02.domain.net should be selected as the server. The printer URI in this case is composed of the 

protocol http:// and the target member01.domain.net:631/printers/laser01. misc is selected 

as the manufacturer and None as the model, which means that no filters are installed for the printer and 

the print jobs are forwarded without conversion. After confirming the entry with [OK], the printer is now 

shared as laser01 on member01 and as laser02 on member02. 

The printer should now be connected to a Windows system in another room. The Windows system is 

known in the domain as win06 and shares the printer in the domain as laser03. 

268

13.3 Configuring printer shares 

Once laser01 changes the printer URI from parallel:/dev/lp0 to smb://win06/laser03, the 

printer is still available as laser01 on member01 and as laser02 on member02. In addition, Windows 

systems with the correct drivers can also use the laser03 share on win06. 

13.3.2 Setting up network printers 

To integrate network-capable printers as shared printers, these must firstly be added to the domain as IP 

managed clients. This is necessary to avoid IP conflicts and to make use of the DHCP/DNS services. 

To configure the network printer as a printer share, a new Printer object must be created in Univention 

Directory Manager giving the name and server of the share. In addition, the protocol used by the net- 

work printer (e.g., ipp:// or lpd://), the target (the name of the IP managed client) and, as required, 

expansions specific to the unit must also be configured. 

As an example, the later01 network printer, which supports the lpd protocol and accepts LPT jobs ac- 

cording to the manufacturer’s handbook, is to be shared. The complete printer URI is composed of the 

protocol, the name of the managed client and the expansion specific to the lpd://laser01/LPT unit. 

13.3.3 Setting up PDF printers 

Installing the univention-printserver-pdf package expands the print server with a special cups-pdf 

printer type, which converts incoming print jobs into PDF documents and add them in a specified directory 

on the printer server where they are readable for the respective user. 

The cups-pdf:/ protocol must be selected when storing a PDF printer in Univention Directory Manager; the 

target field remains empty. The target directory is set using the Univention Configuration Registry variable 

cups/cups-pdf/directory. As standard it is set to /var/cache/cups-pdf/%U so that cups-pdf 

uses a different directory for each user. Print jobs coming in anonymously are printed in the directory spec- 

ified by the Univention Configuration Registry variable cups/cups-pdf/anonymous (standard setting: 

/var/cache/cups-pdf). 

13.3.4 Setting up printer groups 

CUPS offers the possibility to group printers into Classes. These are implemented in UCS as printer 

groups. Printer groups are provided in the working environment like printers. The aim of such a printer 

group is to create a higher availability of printer services. If the printer group is used to print, the job is sent 

to the first printer in the printer group to become available. The printers are selected based on the round 

robin principle so that the degree of utilisation is kept uniform. 

A printer group must have at least one printer as a member. Only printers from the same server can be 

members of the group. 

The following examples emphasise the possibilities when creating printer groups: 

• Four identical printers are connected to the server member01. These are referred to as laser01, 

laser02, laser03 and laser04 and set up as printer shares. These printers are to be grouped under 

the laserprinters printer group. 

269


To do this, select the Printer group type under the menu item Printer ➞ Add in Univention Di- 

rectory Manager and confirm with [Next]. laserprinters is given as the name and the appropriate 

server name added to the server list. The printers known for this printer server are now listed in the 

Group members selection field. The printers can now be added to the printer group individually; 

the selected members are listed in the field below. When the details are confirmed with [OK], the 

laserprinters printer group is made available to the domain as a printer share. 

• The printer shares laser01 on member01 and ink02 on member02 are to be grouped into the 

Attention: 

colorprinters printer group on the member server member03. This can only be done in one way 

as - as mentioned above - only printers from the same serve can be grouped in printer groups. 

A printer share with the name laser01v2 and the printer URI 

http://member01.domain.net:631/printers/laser01 and a further printer share with the 

name ink01v2 and the printer URI http://member02.domain.net:631/printers/ink02 

should be created on member03. Both printer shares are set up using the misc manufacturer and 

None model. A new printer group can now be added as in the example above and laser01v2 and 

ink02v2 selected as group members. 

The possibility described in the last example of grouping printers shares from different printer servers in a 

printer group makes it possible to select printer groups as members of a printer group. This could result in 

a printer group adopting itself as a group member. This must not be allowed to happen. 

13.4 Adding printer shares in Windows 

The printer shares set up in Univention Directory Manager can be added to Windows systems as network 

printers. The network printer must simply be set up on the Windows side with a standard Postscript printer 

driver. If a colour printer should be accessed, a driver for a Postscript-compatible colour printer should be 

used on the Windows side, e.g., HP Color Laserjet 8550. Printer shares can also be operated using the 

Windows printer drivers provided. If printer quotas are in place, it must be checked in advance whether 

the data format of the driver is supported (see also Section 13.5). 

Attention: 

The printer can only be accessed by a regular user when he has local permissions for driver installation or 

the respective printer drivers were stored on the printer server. If this is not the case, Windows may issue 

an error warning that the permissions are insufficient to establish a connection to the printer. 

The following steps make it possible to install a new printer driver on the printer server: 

270 

1. When logged on to Windows as Administrator you can open the printer server and the printer 

directory it contains. 

2. Right clicking in a free area of the window opens the context menu where you can open the Server 

properties dialogue. Clicking on Add on the Drivers tab allows you to select a printer driver for the 

system architecture required and load this onto the server all via menus. 

3. A right click on the printer will now run the Eigenschaften dialogue. The Properties tab contains a 

selction field for the drivers already installed. Clicking on [OK] assigns the driver to the printer and 

means that even users without privileges can access the printer without the need to install a driver.

13.5 Print quota 


The univention-printquota package allows print quotas to be set for printer groups and printers. The 

quota policies can be defined for certain users and user groups either per each user or per user group. 

The print quota system switches automatically between CUPS and the respective printer. In doing so 

it checks the user’s permissions and print limits. In addition the costs are calculated for each print job 

and documented in a print job history. Different reports can be created from this collected data using the 

appropriate programs. 

When operating a printer with a quota, the print job history in the CUPS web interface loses its validity. To 

ensure that CUPS operates correctly, it always receives a report that the print was successful. 

A page counter is updated for each user after every print. When a user excesses his soft limit, he receives 

an e-mail - in so far as Univention Configuration Registry is configured in this way (see Section 13.6.4) - 

which informs him that he is nearing his hard limit. If the user’s page counter reaches the hard limit, the 

print job which exceeds the limit will not be finished. An e-mail informs the user that he can no longer print 

on the printer in question. This e-mail is sent to the user’s primary e-mail address. 

Attention: 

The possibility to set quotas for users and user groups on printers and printer groups can result in confusing 

quota policies. Printer quotas should thus be planned thoroughly in order to avoid later overlaps in the 

policies. 

The print quota system determines the size of the print job during printing. This is done by analysing the 

data sent to the printer after conversion by CUPS. If the data format is not recognised or the quote limits 

are exceeded the print job is interrupted. The following data formats are analysed correctly: 

• PostScript 

• PDF 

• PCL1, PCL2, PCL3, PCL4, PCL5 

• PCLXL ( PCL6 ) 

• ESC/P2 

The print quota system saves all data in a database. For this it uses a PostgreSQL database, which is 

installed with the univention-printquotadb package. 

Now when a user prints, the quota set for the user for the printer used is requested firstly. It is then checked 

whether the print job exceeds the quota and if necessary the print job cancelled and the user informed by 

e-mail. 

If a user does not have a quota for a printer in the database, the print quota policies set in Univention 

Directory Manager are requested. When there are entries here for the user, these are entered in the 

database and the print job carried out as along as it does not exceed the quota. When the user has no 

policy, the print job is cancelled. 

271


13.5.1 Activating the print quotas 

Activating the print quotas provokes an internal change to the printer URI. If a quote is activated for a 

printer on a print server without univention-printquota, the printer will be deactivated with the first print 

job. 

To activate the print quota for a printer, the respective printer or printer group must be selected in Univention 

Directory Manager using the printer menu item and the Activate quota entry selected on the General 

tab. An existing policy can now be selected in the Configuration selection field or a new policy created 

for the current printer share on the [Print quota] policy tab. 

Attention: 

The quota system cannot be used for printer shares which print in a file (file:/) or via a parallel port 

(parallel:/). This can otherwise lead to the printer being deactivated. 

13.5.2 Creating a print quota policy 

A Print quota policy object can be added in the Univention Directory Manager policy wizard to create print 

quota policies. 

The policy must be set in the input mask which opens and then individual ucsMenuEntryPrint quota for 

users, Print quota for groups or Print quota for groups per user added with the appropriate page limits 

(see also Section 4.5.11). Soft-Limit can be used to define a page limit where the user is informed when 

he exceeds the limit. Hard-Limit can be used to set the limit of the page contingent for the user. The 

quota system interprets the values set minus 1. I.e., if the user has a Hard-Limit of 100, a maximum of 99 

pages can be printed. This gives the following special values: 

0 - No limit 

1 - No page contingent 

The following examples should emphasise the possibilities available with print quota policies: 

272 

• To set each user from the Domain Users group a soft limit of 200 pages and a hard limit of 250 pages 

for the laser01 printer, the laser01 printer must be selected in the Printer module in Univention 

Directory Manager and a soft limit of 201 pages and a hard limit of 251 pages entered in the Print 

quota for groups per user field for the Domain Users group on the [Print Quota] tab. Confirming 

with the [Add] and [OK] buttons enters the quota policy and saves it. 

• As a member of the Domain Users group, the user user01 is then subject to the print quota policies 

in place for the printer laser01. If the user is assigned another user-specific print quota with a soft 

limit of 400 pages and a hard limit of 450 pages in the same manner as described above, he may 

still only print a maximum of 250 pages. The print quota system does not allow the limit of the other 

policy to be exceeded. 

• Each user of the Power Printers group should be assigned a Soft-Limit of 1000 pages and a Hard- 

Limit of 1200 pages for all inkjet printers in the domain. A new Ink jet printer group needs to be 

created for this and all the inkjet printers in the domain added to it (see Section 13.3.4). Soft and 

hard limits are now assigned to the Power Printers group in the Print quota for groups per user 

field using a Print quota policy with the name PP limit as already described above. Once the added


entry is confirmed with [OK], the PP limit can be assigned to the Ink jet printer group and all inkjet 

printers in the printer management on the Print quota tab and the details confirmed with [OK]. 

13.5.3 Analysing the print quotas 

repykota generates a report about the print quota set. The command can be used by each user to request 

details of his current page use. 

Command Description 

repykota output of all quotas per user for each printer 

repykota -P printer01 output of all quotas per user for the unit printer01 

repykota -g -P 

printer01 

output of all quotas per user group for the unit printer01 

repykota -g output of all quotas per group for each printer 

repykota user01 output of quotas for user01 on all printers 

repykota user* 

repykota -P laser* 

output of all quotas for the users whose name begins with user 

output of the quotas for all users on the printers with names 

beginning with laser 

dumpykota offers the possibility of exporting different information from the print quota system in different 

formats: 

dumpykota -d type -f format -o file 

Variable Decription 

typ determines the data to be output 

history print job history 

users users 

groups user groups 

printers printers 

upquotas User quota 

gpquotas User group quota 

payments Costs per user 

pmembers Printer group members 

umembers User group members 

format determines the output format: 

csv columns separated by commas 

csv columns separated by semicolons 

csv columns separated by tabs 

xml output in XML format 

Example: 

273


dumpykota -d upquotas -f csv -o userquota.csv 

Output of all user quotas in CSV format in the userquota.csv file 

13.5.3.1 pykotme 

The program pykotme can be used to determine the page contents of a Postscript file and the costs 

incurred through its printing. 

pykotme --printer printer01,laser01 < file01.ps 

Lists the respective costs for the printing of file01.ps on printer01 and laser01. 

pykotme --printer laser01 file01.ps file02.ps 

Lists the costs for the printing of file01.ps and file02.ps on laser01. 

13.5.4 Modifying the print quotas 

13.5.4.1 edpykota 

The program edpykota is used to alter the quotas of individual users or groups directly. It also offers 

possibilities for storing printers and assigning printers and users to groups. 

Attention: 

Printers and the assigning of printers and the assignment of printers and users to groups should only be 

specified with Univention Directory Manager wherever possible. As edpykota only changes the entries 

in the quota system, these changes are not passed on to the CUPS print system. 

edpykota [options] user1 user2 ... userN 

edpykota [options] group1 group2 ... groupN 

274 

Parameter Description 

-v –version Outputs the version number 

-h –help Help on command usage with syntax and examples 

-a –add Add users and/or printers to the quota database 

-d –delete Deletes users/user groups out of the quota database 

-c –charge p[,j] Fixes the price per page (p) and per job (j) for a specific printer. 

The price per job is optional. Values are separated with commas 

when they are set. Floating point number are permitted and 

input with a decimal point (e.g., 3.412). 

-i –ingroups g1[,g2...] Places a user in each specified user group (e.g., g1). The user 

groups must already exist in the quota database. 

-u –users Edit user quota (standard) 

-P –printer p Only the quota for printer p is edited. Wild cards (e.g., p*) are 

permitted. Multiple entries are separated by commas.


-G –pgroups pg1[,pg2...] Add the printer to the printer groups pg1,pg2.... The printer 

groups must already exist. 

-g –groups Edit user groups. 

-p –prototype u|g Uses user u or user group g as the prototype for setting the 

quotas. 

-n –noquota No quotas are set, but the costs and print history activated. 

-r –reset Resets the counter for the current page usage. The life time 

counter is not changed. 

-R –hardreset Resets all counters for page usage. 

-S –softlimit X Sets the soft limit to X pages. 

-H –hardlimit X Sets the hard limit to X pages. 

edpykota --add -S 50 -H 60 user01 

user01 receives a soft limit of 50 pages and a hard limit of 60 pages on all printers. If user01 has yet to 

be created, it will be created in the print quota system. In other cases the entry will be adapted. 

edpykota --add --printer printer01 -S 50 -H 60 user01 

user01 receives a soft limit of 50 pages and a hard limit of 60 pages on printer01. If both printer01 and 

user01 are yet to be created, they are created. In other cases the entries will be adapted. 

edpykota --reset user01 

Resets the counter for current page usage foruser01 to 0 on all printers. The life time counter for user01 

remains unchanged. 

edpykota --add -g testgroup01 

Creates the user group testgroup01 in the print quota system. 

edpykota -g -S 500 -H 650 testgroup01 

The group testgroup01 receives a soft limit of 500 pages and a hard limit of 650 pages. 

edpykota -i testgroup01 user01 

Adds user01 to the testgroup01 group. 

edpykota --add --printer printer01 -i testgroup01 -S 50 -H 60 user01 

Sets user01 a soft limit of 50 pages and a hard limit of 60 pages for printer01 and assigns him to the 

testgroup01 group. If printer01 or user01 is not yet in the quota system, it is created. 

edpykota --delete user01 

Completely removes user01 from the quota system. 

edpykota --printer lp --charge 12,7 

Sets the price per page at 12 and the price per print job at 7 for lp. 

275


13.6 Univention Configuration Registry variables 

13.6.1 Settings for print clients 

cups/server: The print server the system should use. This value is overwritten by the Print server 

policy and should thus be set in Univention Directory Manager. 

13.6.2 Settings for the authentication on printer shares 

cups/restrictedprinters: A list of printers with access restrictions. 

cups/automaticrestrict: If this variable is set to no, the list of printers in 

cups/restrictedprinters is no longer automatically modified by the Cups listener mod- 

ule if printers are created, modified or deleted. 

13.6.3 Settings for printer shares 

samba/printmode/usergroup/GROUPNAME: These variables makes it possible to prohibit or provide 

certain groups access to printers via Samba printer shares. If the corresponding variable is set to 

all for a group with the name GROUPNAME, it will be noted as an approved group on all local 

printer shares in Samba. If on the contrary the variable is set to none, the corresponding group 

will be entered as invalid for all local printer shares. Access rights given with these Univention 

Configuration Registry"=Variablen apply in addition to those which were set on the individual printer 

objects by Univention Directory Manager on the Access control tab (see Section 4.5.7). The way in 

which Samba analyses share permissions means that a user who is a member of both an approved 

group and an invalid group cannot print. 

13.6.4 Settings for print quotas 

cups/quota/account: The quota information are saved in a PostgreSQL database. This setting regis- 

ters the PostgreSQL user for access. The standard setting is pykotaadmin. 

cups/quota/admin/mail: The e-mail address of the quota administrator. The standard setting is 

root@. 

cups/quota/inform: (De)activates the e-mail notification that a quota has been exceeded. Possible 

values are no (standard) and yes. 

cups/quota/secret: Path entry to the password file for the quota database. The standard setting is 

/etc/pykota/pykota.secret 

cups/quota/server/access: The methods of accessing the quota database. The standard setting is 

local. 

cups/quota/server/name: The name of the server where the quota database is operated. The stan- 

276 

dard setting is localhost.

14 Univention Configuration Registry 

Contents 

14.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 

14.2 Displaying current settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 

14.3 Using variables in shell scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 

14.4 Changing Univention Configuration Registry variables . . . . . . . . . . . . . . . . . . . . . 280 

14.5 Creating new Univention Configuration Registry variables . . . . . . . . . . . . . . . . . . . 281 

14.6 Deleting Univention Configuration Registry variables . . . . . . . . . . . . . . . . . . . . . . 281 

14.7 Registering Univention Configuration Registry variables . . . . . . . . . . . . . . . . . . . . 281 

14.8 Regeneration of configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 

14.9 Policy-based configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 

14.9.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 

14.9.2 Configuring the policy in Univention Directory Manager . . . . . . . . . . . . . . . . 284 

14.10Univention Configuration Registry in manually created packages . . . . . . . . . . . . . . . 284 

14.11Including additional configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 

14.12Integrating Python code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 


Univention Configuration Registry is the central tool for managing the local system configuration of a UCS- 

based system. Univention Configuration Registry is a registry mechanism for system settings similar to 

other operating systems. Individual settings are managed via so-called Univention Configuration Registry 

variables, which are comparable to the environment variables of the shell regarding the setting and reading, 

and their fields of application. Univention Configuration Registry variables are managed by the command 

univention-config-registry or via Univention Management Console. 

The Univention Configuration Registry mechanism makes connection between the Univention Configura- 

tion Registry variables and the configuration files of various services. 

The Univention Configuration Registry mechanism makes sure that in case of a change in a Univention 

Configuration Registry variable, all configuration files referenced by the changed variable, will be created 

anew. This process releases the system administrator from editing the configuration files of the various 

services himself (under consideration of the syntax applicable in each case). During this process, the 

configuration files are retained in their original form, and can be manually edited under consideration of 

the functions of the Univention Configuration Registry mechanism if the need should arise. 

During the installation of a UCS system, a number of central, low-level settings are generated via Univen- 

tion Configuration Registry variables, e. g. the name of a client which is listed in the system configuration 

itself under /etc/hostname and, at the same time, in the configuration of system services such as the 

277


LDAP server. Further settings and configuration files can be included in the Univention Configuration 

Registry mechanism if necessary. 

Apart from managing configuration files, Univention Configuration Registry variables can be used very 

efficiently in low-level shell scripts for accessing current settings. In combination with the Univention Con- 

figuration Registry command line in particular, there are a range of possibilities for managing a UCS 

system. 

14.2 Displaying current settings 

The univention-config-registry command can be run with three different parameters to display the Uni- 

vention Configuration Registry variables and their current assignments. The short form ucr can also be 

given instead of univention-config-registry. 

The parameter dump can be used to display all currently registered variables. 

# univention-config-registry dump 

admin/cmd/debug/level: 0 

admin/cmd/timeout: 300 

admin/timeout: 300 

admin/web/debug/level: 0 

admin/web/language: de 

apache/accessfilename: .htaccess 

apache/documentroot: /var/www 

apache/userdir: public_html 

auth/admin/methods: krb5 ldap unix 

... 

One Univention Configuration Registry variable and the currently assigned value are displayed per line. 

The Univention Configuration Registry 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. 

Univention Configuration Registry supports a variable name search function using the parameter search: 

univention-config-registry search 

This command searches for variable names which contain and displays these with their current 

assignments. Alternatively, searches can also be performed for set variable values: 

univention-config-registry search --value 

# univention-config-registry search debug 

admin/cmd/debug/level: 0 

console/web/debug/level: 0 

listener/debug/level: 2 

samba/debug/level: 0 

# univention-config-registry search --value yes 

nsswitch/ldap: yes 

pkgdb/scan: yes 

postfix/autostart: yes 

278

sshd/permitroot: yes 

sshd/xforwarding: yes 

14.3 Using variables in shell scripts 

Regular expressions can be used when searching for Univention Configuration Registry variables in order 

only to display variables which correspond to a predetermined search template. Univention Configuration 

Registry supports all regular expressions which are supported by the python module re. An extensive 

explanation of the syntax can be found in the documentation of the re module. It can also be displayed 

with the command pydoc re in the command line on UCS systems. The following gives some examples: 

• Search for all Univention Configuration Registry variables which begin with ’ldap’ or ’ssl’: 

univention-config-registry search ’^(ldap|ssl)’ 

• Search for all Univention Configuration Registry variables which include ’ssl’ or ’ssh’: 

univention-config-registry search ’ss(l|h)’ 

• Search for all Univention Configuration Registry variables with a current value composed of the 

string ’mail’, any character string and the string ’Address’. The asterisk (*) is used to determine that 

preceding characters should occur never, once or more than once. To use the asterisk for different 

characters as in the bash shell, it must be used in combination with the full stop (.) as a wildcard for 

an alphanumeric character. 

univention-config-registry search --value ’mail.*Address’ 

Individual Univention Configuration Registry variables can be displayed with the parameter get. Unlike the 

parameters dump and search only the current value of the Univention Configuration Registry variable is 

shown here without variable names. 

# univention-config-registry get ldap/server/name 

master.firma.de 

# univention-config-registry get ldap/server/ip 

192.168.0.2 

14.3 Using variables in shell scripts 

The parameter shell is used to display Univention Configuration Registry variables and their current as- 

signments in a format that can be used in shell scripts. 

univention-config-registry shell 

This command displays the values of all Univention Configuration Registry variables as a pair per line as 

variablenname="wert" 

Different conversions are involved in this: forward slashes in variable names are replaced with underscores 

and characters in the values which have a particular significance in shell scripts are included in quotation 

marks to ensure they are not altered. 

Individual values can be displayed when the shell parameter is expanded with the desired variable name: 

univention-config-registry shell ldap/server/name 

279


Univention Configuration Registry must be executed via the command eval for Univention Configuration 

Registry variables to be able to be read in a shell script as environment variables: 

# eval $(univention-config-registry shell ldap/server/name) 

# echo $ldap_server_name 

master.firma.de 

14.4 Changing Univention Configuration Registry variables 

The command 

univention-config-registry set ="" 

can be used to change a variable’s value. This initiates a syntax check. In the following example, the value 

of the variable nameserver1 is set to 192.168.0.1: 

univention-config-registry set nameserver1="192.168.0.1" 

The change to a Univention Configuration Registry variable results in all configuration files for which the 

Univention Configuration Registry variable is registered (see Chapter 14.8), being rewritten immediately. 

The files in question are output on the terminal output: 

# univention-config-registry set sshd/xforwarding=yes 

Setting sshd/xforwarding 

File: /etc/ssh/sshd_config 

In doing so it must be noted that although the configuration of a service is updated, the system service 

in question is not restarted automatically. These services must generally be restarted manually using the 

corresponding init scripts below /etc/init.d. The execution of scripts to follow changes to Univention 

Configuration Registry variables is described in Chapter 14.10. 

If, for example, the debug level of the Samba service is changed, this must then be restarted: 

# univention-config-registry set samba/debug/level=2 

Setting samba/debug/level 

Multifile: /etc/samba/smb.conf 

# /etc/init.d/samba restart 

Stopping Samba daemons: nmbd smbd. 

Starting Samba daemons: nmbd smbd. 

Simultaneous changes to more than one variable are possible in one command line (in so far as they refer 

to the same configuration file, this will only be rewritten once): 

# univention-config-registry set \ 

dns/forwarder1=192.168.0.2 \ 

sshd/xforwarding="no" \ 

sshd/port=2222 

280

14.5 Creating new Univention Configuration Registry variables 

14.5 Creating new Univention Configuration Registry variables 

A new variable can be registered with univention-config-registry and the parameter set. The 

variable can be given any name consisting exclusively of lowercase letters, full stops, figures, hyphens 

and forward slashes. If the newly created Univention Configuration Registry variable is to be automatically 

used in configuration files it should be registered (see Chapter 14.7). 

# univention-config-registry set test/variable=neu 

Create test/variable 

A conditional setting of variables is also possible. For example, if a value should only be saved in a 

Univention Configuration Registry variable when the variable is empty, this can be done by entering a 

question mark instead of the equals sign when assigning values. 

univention-config-registry set dns/forwarder1?192.168.0.2 

In this example, the variable dns/forwarder1 is only set to the value 192.168.0.2 when it was previously 

empty. When the variable already contains a value, this is not changed. 

When setting and changing Univention Configuration Registry variables, numerous variables can be en- 

tered in one execution. 

14.6 Deleting Univention Configuration Registry variables 

The parameter unset is used to delete a variable. The following example deletes the variable dns/for- 

warder2. It is also possible here to specify several variables to be deleted. 

univention-config-registry unset dns/forwarder2 

When deleting a variable, univention-config-registry displays which files are affected by the change and 

rewritten. 

14.7 Registering Univention Configuration Registry variables 

The Univention Configuration Registry system guarantees the regeneration of the configuration files for 

which a variable is registered when a change is made to this variable. This is done using Univention 

Configuration Registry templates. Essentially, a Univention Configuration Registry template is a copy of 

the original configuration file in which the lines in which the value of a Univention Configuration Registry 

variable are entered are partially replaced with program code. 

The Univention Configuration Registry variables used in the configuration files are registered in info files 

in /etc/univention/templates/info which are named after the package name with the file ending 

.info. An example for the package univention-dhcp: 

Type: file 

File: etc/dhcp3/dhcpd.conf 

Variables: ldap/base 

Variables: dhcpd/ldap/base 

281


Variables: ldap/server/name 

Variables: dhcpd/enable 

Type: file 

File: etc/init.d/dhcp3-server 

The templates for all configuration files managed with Univention Configuration Registry can be 

found in the /etc/univention/templates/files. The path to the templates is the abso- 

lute path to the configuration file with the prefixed path to the template directory. For ex- 

ample, the template for the /etc/dhcp3/dhcpd.conf configuration file can be found under 

/etc/univention/templates/files/etc/dhcp3/dhcpd.conf. 

The templates contain wildcards for the variables used in the registration. If the value of a variable is 

changed, Univention Configuration Registry reads the template and replaces the wildcard with the corre- 

sponding variable value before rewriting the configuration file. 

The following excerpt serves as an example of a line with wildcards from the template for the file 

/etc/ssh/sshd_config. The name of the Univention Configuration Registry variable framed by the 

string @%@ represents the wildcard. 

X11Forwarding @%@sshd/xforwarding@%@ 

The original configuration file is overwritten when a registered Univention Configuration Registry variable 

is changed, which means that manual changes previously made to the configuration file will be lost. If 

these changes are to be permanent, they must be made to the template. Once the template has been 

changed, the configuration file needs to be rewritten (see Chapter 14.8). 

Attention: 

For the configuration files to be processed correctly by Univention Configuration Registry they must be 

in UNIX format. If configuration files are edited in DOS or Windows, for example, control characters are 

inserted to indicate line breaks, which can disrupt the way Univention Configuration Registry uses the file. 

The string @!@ can also be used alongside the string @%@ for individual Univention Configuration Reg- 

istry variables. It is used to mark Python codes embedded in blocks. The Python code is also executed 

when a registered Univention Configuration Registry variable is changed. For example, these blocks can 

be used to set it so that when a parameter is changed via a variable, further dependent settings in are au- 

tomatically adopted in the configuration file. The following code sequence configures for example network 

settings using the Univention Configuration Registry settings: 

@!@ 

for i in range(0,4): 

if baseConfig[’interfaces/eth%s/address’ % i]: 

print ’%s\tunivention-directory-manager.%s univention-directory-manager’ % \ 

(baseConfig[’interfaces/eth%s/address’ % i],baseConfig[’domainname’]) 

@!@ 

If new Python code is entered into the templates or the existing code changed in such a way that it requires 

additional or different variable, the .info files in /etc/univention/templates/info will need to be 

expanded or changed accordingly (see Chapter 14.10). 

Attention: 

Univention Configuration Registry templates are included in the corresponding software packages as 

282

14.8 Regeneration of configuration files 

configuration files. When packages are updated, a check is performed for whether any changes have 

been made to the configuration files. If configuration files are no longer there in the form in which they 

were delivered, they will not be overwritten. Instead a new version will be created in the same directory 

with the ending .debian.dpkg-new. If changes are to be made on the Univention Configuration Reg- 

istry templates, these templates are also not overwritten during the update and are instead resaved in 

the same directory with the ending .dpkg-new or .dpkg-dist. Corresponding notes are written in the 

/var/log/univention/actualise.log log file. 

14.8 Regeneration of configuration files 

The command 

univention-config-registry commit 

is used to regenerate configuration files from their templates, which may be necessary, for example, if a 

change is made to a configuration file as a test or the corresponding Univention Configuration Registry 

template has been edited. 

If no file name is given when running univention-config-registry, all of the files managed by Univention 

Configuration Registry will be regenerated from the templates. It is, however, not generally necessary to 

regenerate all the configuration files. 

The command 

univention-config-registry commit /etc/samba/smb.conf 

is used to rewrite the configuration file for the Samba service, for example. 

14.9 Policy-based configuration 

14.9.1 Overview 

Part of the settings stored in Univention Configuration Registry are system-specific (e.g., the computer 

name); many other settings can, however, be used on more then one computer. To automate the distribu- 

tion of the settings, you can configure the Univention Configuration Registry variables using a policy in the 

directory service. General information on policies can be found in Chapter4.5.11. 

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

• First the local Univention Configuration Registry variables are evaluated. 

• The local variables are overruled by policy variables which are usually sourced from the directory 

service using unvention-policy-result. 

• The schedule option is used to set local variables which are only intended to apply for a certain 

period of time. This level of the Univention Configuration Registry is reserved for local settings which 

are automated by time-controlled mechanisms in Univention Corporate Server. 

283


• When the force option is used in setting a local variable, settings adopted from the directory service 

and variables from the schedule level are overruled and the given value for the local system fixed 

instead. An example: 

univention-config-registry set --force mail/messagesizelimit=1000000 

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

14.9.2 Configuring the policy in Univention Directory Manager 

When creating the policy object, Univention Configuration Registry needs to be selected. Firstly a 

name must be set for the policy which is to be created, under which the variables will later be assigned to 

the individual computer objects. 

In addition, at least one Univention Configuration Registry variable must be configured. Firstly, the name 

of the variable must be entered under Name of the new Configuration Registry variable. Clicking the 

plus sign next to the input field changes the input field to Variable: NAME. The value to be set must now 

be entered here. 

Clicking on Ok saves the policy; alternatively, further variables can also be created. 

This policy can then be assigned to a computer object. Note that the display of configured values dif- 

fers from the remaining policies: the values are not display directly in Univention Directory Manager but 

rather written on the assigned computer by Univention Directory Policy. The time interval used for this is 

configured by the Univention Configuration Registry variable ldap/policy/cron and set at one hour as 

standard. 

14.10 Univention Configuration Registry in manually created packages 

Configuration files can also be integrated in the Univention Configuration Registry system when creating 

individual software packages for use in UCS. The complete procedure for package creation in UCS is 

documented separately (see [20]). 

A subdirectory with the name conffiles must be created in the directory with the package 

sources. The configuration files and any subdirectories are copied here. For example, if the file 

/etc/ldap/slapd.conf should be managed by Univention Configuration Registry, it is copied to 

conffiles/etc/ldap/slapd.conf. 

Wildcards can now be integrated into the configuration files in conffiles for the variables and any neces- 

sary Python code. 

In any case default values for the variables used by the respective binary package can be issued 

in debian/postinst or debian/.postinst through certain settings (see 

Chapter 14.5). 

The line 

univention-install-config-registry 

284

14.10 Univention Configuration Registry in manually created packages 

must be added in the install section of the debian/rules file so that Univention Configuration Registry is 

integrated when creating the package. 

In addition, the debian/control file must be adapted, the source package expanded with a dependency on 

univention-config-dev and all binary packages using Univention Configuration Registry expanded with a 

dependency on univention-config-registry. 

Each binary package also requires a file called debian/.univention-config-registry 

to be created, in which is must be specified which files and scripts are to be managed by Univention 

Configuration Registry and which variables are contained therein. 

The syntax of the file can be seen in the following examples: 

• Two configuration files and the variables used in them. The assignment of variables to files can be 

omitted if no Python code is used in the corresponding configuration file. 

# cat univention-dhcp.info 

Type: file 

File: etc/dhcp3/dhcpd.conf 


Variables: dhcpd/ldap/base 

Variables: ldap/server/name 

Variables: dhcpd/enable 

Type: file 

File: etc/init.d/dhcp3-server 

• Scripts can also be integrated in Univention Configuration Registry alongside configuration files. 

These scripts can be run when certain variables are set. Scripts installed with packages are saved 

in /etc/univention/templates/scripts. Further scripts which should be created individually 

and then registered with Univention Configuration Registry must also be copied in the directory. 

Additional scripts must also be entered in the Univention Configuration Registry info files. They must 

be executable and also copied in the conffiles directory. 

In the following example the interfaces.sh script is run when the values of the inter- 

faces/eth0/address or interfaces/eth0/network variables are changed: 

Type: script 

Script: interfaces.sh 

Variables: interfaces/eth0/address 

Variables: interfaces/eth0/network 

• The following example shows a file (multifile), which is compiled from several individual files (subfile) 

if the value of a variable is changed. In this way, different packages can combine individual parts of 

a configuration file, which are thus merged. 

Type: multifile 

Multifile: etc/ldap/slapd.conf 

Type: subfile 


Subfile: etc/ldap/slapd.conf.d/10schema-core 


285


Type: subfile 


Subfile: etc/ldap/slapd.conf.d/20acl 


A multifile template must be created to generate a configuration file from several templates. To do this 

a directory is created with a name composed of the template name and the endung .d. Several part 

templates can be saved in this directory. 

The file names of these part templates must begin with double-digit figures, which determine the order 

according to which the parts will be evaluated and merged. This is particularly useful if the individual parts 

are from different packages, are to be managed or individual expansions are to be integrated. 

For example, /etc/univention/templates/files/etc/ contains the directory config.d. This 

contains the files 00header, 05base and 11extensions. These are merged and evaluated by Univen- 

tion Configuration Registry in ascending order according to their numerical prefix in order to create the 

/etc/config file. 

If the template (single or multifile) were created, they must be registered before they can be used by 

Univention Configuration Registry (see Chapter 14.11). 

14.11 Including additional configuration files 

Configuration files that do not originate from an installation package can also be registered in Univention 

Configuration Registry. The following description only applies to configuration files which are not installed 

from a package. 

Firstly, one or more template files must be created or adapted and saved under the 

/etc/univention/templates/files directory. The syntax and exact saving location of the template 

files are described in Chapter 14.7. 

A file must be saved in the /etc/univention/templates/info directory listing the con- 

figuration files used and the variables used in them. The name of file can be chosen 

freely as long as it ends in .info. The syntax corresponds to the scheme named for the 

debian/.univention-config-registry file in Chapter 14.10. 

The /var/cache/univention-config/cache cache file must then be deleted. The additional con- 

figuration files are registered the next time it is run. As soon as a Univention Configuration Registry 

variable registered for this file is changed or the command univention-config-registry commit 

is executed for this file, a new configuration file is created from the template file taking into account the 

Univention Configuration Registry variables. 

14.12 Integrating Python code 

If integrating individual Univention Configuration Registry variables proves insufficient for creating a con- 

figuration file, Python code can be integrated directly in the file. A Python code block is introduced and 

286

closed with the string @!@. 

14.12 Integrating Python code 

In the following example the template /etc/univention/templates/files/etc/issue (from which 

the /etc/issue file is created) is expanded with Python code. Before it looks like this: 

@!@ 

if baseConfig[’version/version’] and baseConfig[’version/patchlevel’]: 

print ’UCS \%s-\%s \BS\BSn \BS\BSl’ \% \ 

(baseConfig[’version/version’], \ 

baseConfig[’version/patchlevel’]) 

@!@ 

If the value of a Univention Configuration Registry variable should be queried in Python code, the baseC- 

onfig Python object can be used as shown in the example. When using Python code it is important to note 

that the variables used in the Python code are specified when creating the package (see Chapter 14.10). 

Two Univention Configuration Registry variables, hostname and domainname, are now added outside of 

the Python code, while the /etc/univention/templates/files/etc/issue template is edited as 

follows: 

@!@ 





@!@ 

The host name is: @%@hostname@%@ 

The domain name is: @%@domainname@%@ 

The /etc/issue file can now be regenerated from its template using the following command: 

univention-config-registry commit /etc/issue 

If new variables are introduced, it is important to follow the naming scheme (see Chapter 14.5). The 

following example introduces two new variables, my/variable1 and my/variable2: 

@!@ 





@!@ 

My first variable: @%@my/variable1@%@ 

My second variable: @%@my/variable2@%@ 

To fill the new variables defined in inline Python code with values, the cache file must be deleted once from 

Univention Configuration Registry. 

rm /var/cache/univention-config/cache 

The new variables can then be set as described in Chapter 14.5. 

univention-config-registry set my/variable1="foo" set my/variable2="bar" 

The /etc/issue file is now regenerated from its template. 

287


288

15 Univention System Setup 

Contents 

15.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 

15.2 Univention System Setup modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 

15.2.1 Basic settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 

15.2.2 Keyboard settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 

15.2.3 Language settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 

15.2.4 Network settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 

15.2.5 Software components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 

15.2.6 Time zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 

15.3 Univention System Setup event registration . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 

15.4 Configuration for executing at system start . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 

15.5 Changing machine passwords/SSL certificates during system start . . . . . . . . . . . . . . 299 


Univention System Setup is a tool for reconfiguring a UCS system. It can be used for adapting system 

characteristics to changed circumstances as well as for preparing system installations. 

User guidance is keyboard-based: The active menu item is displayed on a red background; the arrow keys 

UP/DOWN, or the TAB/Shift+TAB keys can be used for navigating between the items. 

The input for a Univention System Setup module can be finished by the F12 key; the F11 key can be 

used for returning to the previous module (provided that several modules are active). The F8 key is for 

exiting Univention System Setup; selection fields can be activated by pressing the space bar. Online help 

is accessible via the F1 key. 

If Univention System Setup is run on system roles other than domain controller master and information 

cannot be written to the LDAP directory, Univention System Setup emits a warning and only performs the 

configuration steps which are possible without network access. The computer must then be re-joined in 

the domain using univention-join at a later point. 

Error analyses are possible by using the log file /var/log/univention/setup.log. 

Univention System Setup is based on the Curses library which is used for terminal-based screen display. 

The setup requires certain minimum dimensions for the terminal window for proper display. Should the 

start be aborted with an error message, then the terminal window is to be enlarged. 

289


Figure 15.1: The selected menu item in this example is Europe/Berlin 

15.2 Univention System Setup modules 

Univention System Setup has a modular design and presently consists of seven modules. These modules 

can be started all together (univention-setup-all) as well as separately; for example, univention- 

system-setup-net for the network settings. Apart from this, there is the possibility of loading a selection 

of modules: The univention-system-setup -modules net,basis command, for example, loads 

solely the modules for basic and network configuration. 

15.2.1 Basic settings 

Central system properties can be configured with univention-system-setup-basis: 

The host name and domain name can be changed by Univention System Setup. For this purpose, adjust- 

ments for several server services are also made in Univention Configuration Registry (e.g. Mail aliases at 

the mail server). 

In addition, a new SSL certificate will be created on a domain controller master. Other system roles obtain 

a new certificate from the DC master. 

Changing the domain name may require the adaption of further systems. If the name of the entire DNS 

domain is to be changed, the change must be implemented on all systems. If the domain name of individual 

systems is changed, service records for example, which are responsible for locating the domain controller 

master amongst other things, may no longer be correctly resolved. In such cases, the corresponding 

service records must be created manually in Univention Directory Manager. The changed system should 

be restarted following these changes. 

290

Figure 15.2: Basic settings in Univention System Setup 


The LDAP basis can also be changed at a later date by Univention System Setup. Changing the LDAP 

basis requires the installation of an adapted licence, a repeated join and a restart of all systems. 

Changes to the LDAP base cannot be replicated in all scenarios, other systems in the domain need to be 

adapted manually. 

Changing the DNS domain name or the LDAP base on the domain controller master changes fundamental 

parameters of the other systems of the domain. The computer objects of the other UCS systems should 

be deleted in Univention Directory Manager and the computers should join the domain anew (see also 

Chapter 2.4.1). 

Windows domain names can be changed. For reasons of compatibility, the name of a domain is not 

case-sensitive and should not exceed a maximum of 14 characters. 

The password for the local root user can also be changed by Univention System Setup. In addition, the 

password for the administrator account in LDAP is changed on domain controller master systems. It must 

be pointed out that this process does not include any checks regarding either the length of the password 

or the passwords used in the past. To avoid subsequent errors by misspelling, the password has to be 

entered twice. 

15.2.2 Keyboard settings 

The keyboard layout used on the computer can be changed by 

univention-system-setup-keyboard. 

291


15.2.3 Language settings 

Figure 15.3: Keyboard settings in Univention System Setup 

In UCS, localisation properties for software are defined in so-called locales. Configuration includes, among 

other things, settings for date and currency format, and the set of characters in use. Apart from this, the lan- 

guage used for internationalised programs is specified. With univention-system-setup-language 

the locales for a system can be created. 

Moreover, a standard locale can be defined with univention-system-setup-defaultlocale. The 

locales created via univention-system-setup-language are available for selection. 

292

Figure 15.4: Language settings in Univention System Setup 


293


15.2.4 Network settings 

univention-system-setup-net is a comfortable means for changing the network settings of a com- 

puter. Up to four physical network adapters can be configured with static as well as dynamical address 

allocation. 

Figure 15.5: Network settings in Univention System Setup 

With static configuration, apart from the IP addresses there are also the routing-relevant settings for the 

net mask, broadcast address, and network address to be made. For this purpose, standard values are 

proposed based on the IP address, in order to simplify configuration. 

The allocation of the IP address can also be achieved dynamically via the Dynamic Host Configuration 

Protocol (DHCP). DC Master, DC Backup, DC Slave, and member server can be operated by static 

addressing exclusively. 

The standard gateway can also be configured. DC Master should be configured as a name server (it is 

possible to register multiple hosts), further servers for DNS lookups can be configured as DNS forwarders 

(e. g. the DNS server of the internet service provider). 

Furthermore, access via a web proxy can be set. 

Changes in computer properties are adopted in the LDAP and in Univention Configuration Registry and 

become valid immediately. This also concerns changes in the routing properties, a fact which is to be 

taken into consideration for remote access. 

The change of an IP address of a DC master cannot be replicated in all replication scenarios; other 

systems in the domain are usually required to rejoin the domain using univention-join. 

294


Figure 15.6: Network interface configuration in Univention System Setup 

295


15.2.5 Software components 

The univention-system-setup-software command can be used for subsequent, menu-controlled 

installation of software components. Besides the components, individual packages can also be selected. 

Switching columns is possible via the arrow keys LEFT/RIGHT. The software packages are then installed 

from the repository. 

296 

Figure 15.7: Software selection in Univention System Setup

15.2.6 Time zone 

Time zones can be configured with univention-system-setup-timezone. 

15.3 Univention System Setup event registration 

Figure 15.8: Configuring time zones in Univention System Setup 

15.3 Univention System Setup event registration 

Any necessary changes will be made for standard system features of a Univention Corporate Server 

system when a system feature is changed. For local extensions there is the possibility of storing shell 

scripts, which are then run by Univention System Setup when system features are changed. 

Scripts in the following directories are run before or after the changing of a system feature in alphabetical 

order: 

/var/lib/univention-system-setup/hostname.pre Host name 

/var/lib/univention-system-setup/hostname.post Host name 

/var/lib/univention-system-setup/domainname.pre Domain name 

/var/lib/univention-system-setup/domainname.post Domain name 

/var/lib/univention-system-setup/ldapbase.pre LDAP base 

/var/lib/univention-system-setup/ldapbase.post LDAP base 

/var/lib/univention-system-setup/windowsdomain.pre Windows domain 

/var/lib/univention-system-setup/windowsdomain.post Windows domain 

/var/lib/univention-system-setup/interfaces.post Network interface settings 

/var/lib/univention-system-setup/gateway.post Network gateway 

297


/var/lib/univention-setup/nameserver.post Name server 

/var/lib/univention-setup/dnsforwarder.post DNS forwarder 

/var/lib/univention-setup/httpproxy.post HTTP proxy 

Scripts with file names which end in pre are run before the change is adopted, and scripts with post 

afterwards. The file names of the scripts must not include any additional full stops. 

For the respective shell script the old value is taken as the first and the new value as the second parameter. 

For some module several values must be transferred to the scripts. These are summarised to one value 

in a special syntax. 

The syntax for network interfaces is: 

#DEVICE-IP-NETWORK-NETMASK(..) 

For example, if the user changes the IP address of the first network card eth0 from 10.200.3.100 

to 10.200.3.200 whilst keeping the network properties the same, the parameters #eth0-10.200.3.100- 

10.200.100.0-255.255.255 and #eth0-10.200.3.200-10.200.100.0-255.255.255 would be transferred to 

the shell script. 

The syntax for forwarders and name servers is: 

#SERVER1#SERVER2#SERVER3 

For example, if two name servers are configured for one system, the value #name- 

server1.firma.com#nameserver2.firma.com would be transferred to the shell script. 

15.4 Configuration for executing at system start 

There is a possibility to run Univention System Setup automatically during the system start. This is done by 

installing the univention-system-setup-boot package and setting the Univention Configuration Registry 

variable boot/setup/start to true. 

Furthermore, the modules to be started can be defined in the Univention Configuration Registry 

variable boot/setup/modules. The values correspond to the file name components behind 

univention-system-setup. For example, if only the modules for network and keyboard layout should 

be shown, the variable should be set to net,keyboard. If the keyboard module has been selected, it is 

always run firstly so that the changed setting applies directly for the following modules. 

If Univention System Setup was run at the system start, the Univention Configuration Registry variable 

boot/setup/start variable will then be automatically reset to false. For example, this allows precon- 

figuration of a system so that only the locally required parameters need to be changed during set-up. 

298

15.5 Changing machine passwords/SSL certificates during system start 

15.5 Changing machine passwords/SSL certificates during system start 

The univention-system-setup-appliance package is available for the operation of preconfigured UCS 

installations. This offers the possibility of regenerating the SSL certificates and host passwords during the 

next system start. 

If the Univention Configuration Registry variable system/setup/appliance/start is set to true, the 

passwords in the /etc/ldap.secret and /etc/ldap-backup.secret files will be reset the next time 

that univention-system-setup-boot is run. In addition, the passwords for the join-slave and join-backup 

system users will also be reset. 

If ssl is set in the Univention Configuration Registry variable boot/setup/modules, the root cer- 

tificate and host certificates are regenerated the next time univention-system-setup-boot is started 

on a domain controller master. The settings for the new certificate are read out of the Univention 

Configuration Registry variables ssl/country, ssl/email, ssl/locality, ssl/organization, 

ssl/organizationalunit and ssl/state. 

299


300

16 Frequently asked questions 

Contents 

16.1 How do I replace the DC master with a DC backup? . . . . . . . . . . . . . . . . . . . . . . 301 

16.2 How can I install Microsoft TrueType fonts subsequently? . . . . . . . . . . . . . . . . . . . 302 

16.3 How does a user change his password? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 

16.3.1 On a Linux workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 

16.3.2 On a Windows workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 

16.3.3 When logging on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 

16.3.4 Via Univention Directory Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 

16.4 How is the password for root changed? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 

16.5 What criteria must a password satisfy? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 

16.6 Individual websites cannot be accessed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 

16.7 Thin clients experience log-in problems in a domain spread over several locations . . . . . 305 

16.8 How do I change the Univention Directory Manager timeout? . . . . . . . . . . . . . . . . . 305 

16.9 Why are NFS shares not mounted during boot-up? . . . . . . . . . . . . . . . . . . . . . . . 305 

16.10What does ”No DB server name found.” mean? . . . . . . . . . . . . . . . . . . . . . . . . . 306 

16.11Computer name and network settings in Windows XP Prof. . . . . . . . . . . . . . . . . . . 306 

16.12Avoiding double log-ins on Windows terminal servers . . . . . . . . . . . . . . . . . . . . . . 307 

Further documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 

16.1 How do I replace the DC master with a DC backup? 

To promote a DC backup to a DC master, the command 

/usr/lib/univention-ldap/univention-backup2master 

must be executed on the DC backup. 

Attention: 

There can only be one DC master within a LDAP domain. The script can only be run if the original DC 

master is not available. 

The script switches off replication on the former DC backup. It activates the WINS service, configures the 

system as a Kerberos admin server and changes the LDAP server to write mode. The OpenLDAP, Samba, 

Kerberos, Univention Directory Listener and Univention Directory Notifier services are then restarted. 

Samba then works as the primary domain controller (PDC). 

Then the script replaces the former DC master with the former DC backup in the DNS service record for 

the Kerberos admin. The _domaincontroller_master._tcp DNS service record is also transferred to the 

previous DC backup. In so far as the former DC master was entered in the DNS alias records for univention 

301


directory manager and univention repository and as the name server in the SOA records for forward and 

reverse zones, the script also exchanges it in these sites for the former DC backup. 

Attention: 

If an external DNS service is being used, the entries must be adapted there manually. 

If the former DC master was entered in the LDAP directory as a mail relay host, the script also changes 

this entry to the former DC backup. This change is performed with Univention Directory Manager; the 

LDAP replication automatically adapts the Univention Configuration Registry variable mail/relay on all 

systems. 

The script changes the server role entered in the LDAP directory of the former DC backup to DC master 

and deletes the former DC master and, where applicable, its DNS host entry in the forward lookup zone, 

its pointer in the reverse lookup zone and its DHCP host entry from the LDAP directory. 

Note that the former DC backup is entered as the name server on all computers in the domain if the internal 

DNS service is switched on. Usually, the DC backup should be entered as the second name server after 

the DC master during the installation of each computer. 

Along with the automatic changes, some changes must be performed manually: 

1. Further DNS settings which point to the former DC master. 

2. DHCP settings which point to the former DC master (e.g., name server and WINS server). 

3. Univention Configuration Registry settings which point to the former DC master. 

The respective entries in the LDAP directory must be adapted with Univention Directory Manager and 

those on the computers with Univention Configuration Registry. 

The univention-backup2master script only ensures that the domain controller master function is 

adopted by the DC backup. The script does not set up replacements for other services that the former DC 

master may have provided, e.g., groupware or terminal services. 

A new DC backup should be put in place to reinstate system redundancy. 

16.2 How can I install Microsoft TrueType fonts subsequently? 

Some applications use Microsoft TrueType fonts as standard. When these are not available they are 

usually replaced with other fonts automatically. 

For licensing reasons the Microsoft TrueType fonts cannot be delivered on the UCS installation CD. An 

attempt is made during the installation to download these from the Internet from sourceforge.net. 

If this attempt fails during the installation, e.g., when there is no Internet connection available, the fonts 

can be installed at any other time using the command update-ms-fonts. 

If installation of the Microsoft TrueType fonts was deselected during the installation, it can be made avail- 

able by subsequent installation of the msttcorefonts package. 

302

16.3 How does a user change his password? 

16.3 How does a user change his password? 

There are a number of ways for users to change their password. The new password must always comply 

with the security policy. If this is not the case, this may result in different error messages depending on 

the mechanism used. If you have problems changing your password, you should firstly check whether the 

security requirements are complied with. 

16.3.1 On a Linux workstation 

If the user is logged on to a Linux workstation, he can open the program with which he can change his 

password via K menu ➞ Control Center ➞ Security & Privacy ➞ Password & User Account ➞ Change 

Password. The program requests the old password first and then the new password. If the new password 

is longer than eight characters a warning is given, which can be confirmed by clicking on the [Use As Is] 

button. 

If the password does not comply with the security requirements, the message Your password has not 

been changed appears together with an explanation of why the change failed. 

The user can also change his password using kpasswd on the command line. More detailed error mes- 

sages are given there. (see Chapter 16.5). 

16.3.2 On a Windows workstation 

If the user is logged on to a Windows workstation he can open the dialogue for changing his password 

with ”Ctrl + Alt + Del”. 

16.3.3 When logging on 

If a user’s password is no longer valid and the user tries to log on to the domain, a window opens automat- 

ically asking him to change his password. For setting the password expiry interval see Chapter 4.5.11. 

16.3.4 Via Univention Directory Manager 

The ucsUCRVldap/acl/user/password/change must be set to yes on the DC master for the user to be able 

to change his password via Univention Directory Manager. 

After logging on to Univention Directory Manager, the dialogue for changing a user password can be 

opened by choosing Password in the left screen margin. The new password must be given identically in 

the Password (*) and Password (retype) (*) fields. 

16.4 How is the password for root changed? 

Each UCS computer has a root user. Its password is changed locally on the computer using the passwd 

command. 

303


16.5 What criteria must a password satisfy? 

The following security requirements are implemented in UCS as standard: 

• The password must be at least as long as the minimum length stipulated in the password length 

policy. The preset value is eight characters. 

• The password must not be the same as any other password saved in the user’s password history. 

• As standard no further requirements with regard to the password quality are set through the pass- 

word policy. 

The security requirements of the pam_cracklib.so PAM module also apply when changing a password 

with kdepasswd or passwd. These include: 

• The password must not be too similar to the previous password, i.e., at least a minimum number 

of the characters must be different. The minimum number is usually ten characters or half of the 

characters in the new password (the lower of the two applies). 

• The password must not be a ”normal” word. This is checked using a dictionary which contains 

predominantly English terms. 

• The password must not only be different from the previous password in that formerly uppercase 

letters are now lowercase and vice-versa. 

The libpam_doc package contains further information on Cracklib. 

16.6 Individual websites cannot be accessed 

Problem: 

It is not possible to connect to certain websites although other websites on the Internet and computers in 

the Internet are accessible. 

Potential cause: 

The router to the Internet does not support ECN. 

Background: 

ECN (Explicit Congestion Notification) is an extension of the Internet protocol, which has replaced TOS and 

now represents the standard. ECN recognises possible network connection overloads early and adapts 

the flow of files sent per time unit accordingly. This means that fewer file packages go missing and fewer 

files need to be resent. The file quantities are reduced on the whole and file transfer accelerated. 

UCS is configured as standard that ECN is used. 

ECN is supported by almost all network components (hardware and software). Nevertheless, for data 

exchange via the Internet, a computer wishing to use ECN will always check first that the communications 

partner understands ECN to be on the safe side. If one of the computers does not understand ECN, ECN 

will not be used. 

Problems can still occur when one of the connecting links between the sending and receiving computers 

does not support ECN and changes the data package. (Normally connecting links simply pass on the 

304

16.7 Thin clients experience log-in problems in a domain spread over several locations 

package unchanged so that any lack of ECN support in the connecting links will not have any negative 

consequences. If the router to the Internet is what is causing the disruptions, websites which use ECN will 

not be accessible. To-date we have had a report of this from a Netgear router. 

Solution: If the router to the Internet is what is causing the disruptions, the router’s firmware must be 

updated. 

Alternatively, ECN can be deactivated on a UCS server by including the line 

net/ipv4/tcp_ecn=0 

in the /etc/sysctl.conf file. 

16.7 Thin clients experience log-in problems in a domain spread over several 

locations 

If no authentication server (Kerberos server) is specified for thin clients in the Thin client configuration 

tab or via a policy, this is determined by the thin client using service records in DNS. The thin client attempts 

to authenticate itself over the determined Kerberos server. Log-in problems may be experienced when not 

all users can be authenticated via all the Kerberos servers in a domain. 

This situation typically occurs in organisations with several locations, where users are only allowed to log- 

in at certain locations, but where the Kerberos servers for all locations can be located over DNS. This 

problem can be avoided when the Kerberos server(s) for the location where the thin client is connected 

are entered there. 

16.8 How do I change the Univention Directory Manager timeout? 

The timeout for the Univention Directory Manager web interface can be set using the Univention Config- 

uration Registry variable directory/manager/timeout. The desired length is given in seconds. The 

command 

univention-config-registry set directory/manager/timeout=3600 

is used to set the timeout, e.g., at one hour. Is is also possible to set the Univention Configuration Registry 

variable with Univention Management Console. 

16.9 Why are NFS shares not mounted during boot-up? 

This problem can occur when the NFS shares are entered in the /etc/fstab file with the computer name 

instead of the IP address. 

The directories which are entered in the /etc/fstab file are mounted right at the beginning when the 

computer is started. Services such as the BIND DNS service are only started later. For this reason, 

computer names in the /etc/fstab file can not yet be resolved by the internal DNS service and NFS 

shares without an IP address cannot be mounted. So that these NFS shares can be mounted in the future, 

305


• the computer name must be replaced with the IP address or 

• an external DNS server must be used which can resolve the computer name 

• the server must be entered in the /etc/hosts file. 

The /etc/hosts file is generated from several files under UCS. The server must thus be entered in a 

customer-specific file below /etc/univention/templates/files/etc/hosts.d/. 

Example: 

The NFS share can be found on a server with the FQDN ucs-file-server.company.com and the IP ad- 

dress 192.168.0.34. A /etc/univention/templates/files/etc/hosts.d/20-custom file with 

the following contents must be created: 

192.168.0.34 ucs-file-server.firma.com ucs-file-server 

The new Univention Configuration Registry file must then be published and the configuration file rewritten 

(see Chapter 14). 

16.10 What does ”No DB server name found.” mean? 

The following message may appear when installing software with the univention-install command: 

Cannot find Service-Record of _pkgdb._tcp. 

No DB-Server-Name found. 

The message states that no DNS service record with the name _pkgdb._tcp has been found and the 

computer thus does not know the name of the package status database server. 

As standard, all UCS systems attempt to share their installation status with the software monitor. For 

this reason, they search for the DNS service record of the package status database following software 

installation. If the software monitor is not used, there is no corresponding DNS service record and the 

message appears. By setting the Univention Configuration Registry variable pkgdb/scan to no, the the 

affected computer can be configured to not send information to the software monitor. The DNS request is 

then not run and the message will not be shown. There is no urgency in changing this setting as the failed 

DNS request for the service record does not cause a notable time delay or any particular network load. 

16.11 Computer name and network settings in Windows XP Prof. 

The current network configuration can be displayed on a Windows computer via Start ➞ Run ➞ Open ➞ 

cmd ➞ [OK] ➞ ipconfig /all. 

The MAC address is designated as Physical address in the display. Ensure that the individual parts of 

the MAC address in Univention Directory Manager are saved separated by colons (“:”). MAC addresses 

that are input separated by (“-”) will also later be shown with colons. 

The DHCP activated output shows whether the IP address was retrieved over a DHCP server or entered 

locally on the computer. The network configuration can be changed as follows: 

306

16.12 Avoiding double log-ins on Windows terminal servers 

• Opening Start ➞ System control ➞ Network- and internet connections ➞ Network connections 

➞ LAN connection 

• Select the [Settings] button in the dialogue that opens on the General tab. 

• The Settings of LAN connection dialogue opens, in which Internet protocol (TCP/IP) must be 

ticked and the [Properties] button selected. 

• To deactivate local settings, the Retrieve IP address automatically and Retrieve DNS Ssrver ad- 

dress automaticallly checkboxes on the General tab must be activated and the change confirmed 

with [OK]. 

For a computer to join a domain, the locally entered computer name must also match the name entered 

in the LDAP directory with Univention Directory Manager. Right click on System in the Start menu and 

select the entry Properties to adapt the computer name. A dialogue for changing the computer name can 

then be opened via the Modify button on the Computer name tab. The new name should be entered in 

the Computer name input field and the change confirmed with OK. Windows computers then need to be 

restarted for the changes to take effect. 

16.12 Avoiding double log-ins on Windows terminal servers 

If a connection to a Windows terminal server is selected as the type of session on an UCS thin client, 

the user normally needs to log in twice. In the first step he logs in to the GDM log-in manager and the 

second step is a renewed log-in to the terminal server. This is necessary as Windows terminal servers 

with standard settings do not allow transferral of the password from the accessing application (in this case: 

rdesktop) to the user log-in. This prevents rdesktop from using the user password transferred from the 

gdm log-in manager directly for the log-in. 

To avoid the renewed log-in request on the terminal server, select Start ➞ System Services ➞ Terminal 

services configurationn ➞ Connections (Windows 2000) or Start ➞ Programs ➞ Connections ➞ 

Terminal services configuration ➞ Connection (Windows 2003) RDP TCP connection with a right 

click. The Login settings can be found under Properties. Selecting Login settings and deactivating 

the Always request password control box adopts the change. It is now no longer necessary to enter the 

password a second time when choosing the ”Windows terminal server” session type. 

307


308

Bibliography 

[1] Univention. Overview of available UCS documentation. 2010. 

http://www.univention.de/en/download/documentation/documentation/. 

[2] Univention. Listener/Notifier replication (currently only available in German). 2010. 

http://www.univention.de/fileadmin/download/dokumentation_2.4/ucs- 

listener-notifier.pdf. 

[3] Univention. Profile-based UCS installations (currently only available in German) . 2010. 


installation-profil.pdf. 

[4] Univention. UCS Windows Installer (currently only available in German). 2010. 


windows-installer.pdf. 

[5] Univention. UCS Fax services (currently only available in German) . 2010. 

http://www.univention.de/fileadmin/download/dokumentation_2.4/ucs-fax.pdf. 

[6] Univention. Administrating Univention Directory Manager on the command line (currently only 

available in German). 2010. 

http://www.univention.de/fileadmin/download/dokumentation_2.4/univention- 

directory-manager-cli.pdf. 

[7] Univention. Univention Directory Reports (currently only available in German). 2010. 


directory-reports.pdf. 

[8] Univention. Univention Corporate Server - Manual for users and administrators. 2010. 

http://www.univention.de/fileadmin/download/documentation_english/ 

handbuch_ucs24_en.pdf. 

[9] Jelmer R. Vernooij, John H. Terpstra, and Gerald (Jerry) Carter. The Official Samba 3.2.x HOWTO 

and Reference Guide. 2010. 

http://samba.org/samba/docs/Samba3-HOWTO.pdf. 

[10] Univention. Managing KDE desktop profiles (currently only available in German). 2010. 

http://www.univention.de/fileadmin/download/dokumentation_2.4/ucs-kde- 

profile.pdf. 

[11] Univention. Filesystem quota (currently only available in German). 2010. 


benutzer-quota.pdf. 

309

Bibliography 

[12] Univention. Nagios with UCS (currently only available in German). 2010. 


nagios.pdf. 

[13] Univention. Univention Wiki - UVMM - Quickstart Guide (currently only available in German). 2011. 

http://http://wiki.univention.de/index.php?title=UVMM_Quickstart. 

[14] Univention. Univention Wiki - UVMM - Technische Details (currently only available in German). 2011. 

http://wiki.univention.de/index.php?title=UVMM_Technische_Details. 

[15] Univention. Migrating Windows domains to UCS (currently only available in German). 2010. 


windows-migration.pdf. 

[16] Univention. Univention Active Directory Connector. 2010. 

http://www.univention.de/fileadmin/download/documentation_english/ucs-ad- 

connector_en.pdf. 

[17] Gustavo Noronha Silva. APT HOWTO . 2010. 

http://www.debian.org/doc/manuals/apt-howto/. 

[18] Univention. Kolab2 for UCS document (currently only available in German). 2010. 

http://www.univention.de/fileadmin/download/dokumentation_2.4/kolab2- 

ucs.pdf. 

[19] Univention. Scalix for UCS (currently only available in German). 2010. 

http://www.univention.de/fileadmin/download/dokumentation_2.2/ucs- 

scalix.pdf. 

[20] Univention. Creating software package for UCS (currently only available in German). 2010. 

http://wiki.univention.de/index.php?title=Paketierung_von_Software_f%C3% 

BCr_UCS. 

[21] Univention. Univention Corporate Desktop - Manual for aministrators. 2011. 

http://www.univention.de/fileadmin/download/dokumentation_ucd/handbuch- 

ucd-3.1_en.pdf. 

[22] Univention. UVMM - Windows-Systeme mit virtIO installieren (currently only available in German). 

2011. 

http://wiki.univention.de/index.php?title=UVMM-Windows-Systeme-mit- 

virtio-Treibern-installieren. 

[23] Univention. Univention Wiki - DVS - Technische Details (currently only available in German). 2011. 

http://wiki.univention.de/index.php?title=DVS-Technische-Details. 

[24] Univention. Software RAID with UCS (currently only available in German). 2010. 

http://www.univention.de/fileadmin/download/dokumentation_2.4/ucs-expert- 

partition.pdf. 

[25] Univention. Opsi (open pc server integration). 2011. 

310 

http://wiki.univention.de/index.php?title=Opsi_%28open_pc_server_integration% 

29.

[26] Univention. Web proxies with UCS (currently only available in German). 2010. 


proxy.pdf. 

[27] Univention. UCS Backup (currently only available in German). 2010. 


backup.pdf. 

[28] Univention. Managing SSL certificates with UCS (currently only available in German). 2010. 

Bibliography 

http://www.univention.de/fileadmin/download/dokumentation_2.4/ucs-ssl.pdf. 

[29] Univention. Integrating external Unix/Linux systems (currently only available in German). 2010. 


einbindung-unix-systeme.pdf. 

[30] Univention. UCS Performance guide (currently only available in German). 2010. 


performance-guide.pdf. 

[31] Univention. Usage scenarios for Univention Corporate Server. 2010. 

http://www.univention.de/fileadmin/download/documentation_english/ucs- 

szenarien_en.pdf. 

[32] Tobias Doerffel. iTALC - Intelligent Teaching And Learning with Computers. 2010. 

http://italc.sourceforge.net/. 

[33] Univention. UCS Thin Client Services 3.1 - Manual (currently only available in German). 2010. 

http://www.univention.de/fileadmin/download/dokumentation_ucs_tcs/ucs- 

tcs_3_1.pdf. 

311

UCS 2.4 - Univention

Create successful ePaper yourself

Delete template?

Save as template?