Cool Solution - LDAP Policy use cases

From Univention Wiki

Jump to: navigation, search
Produktlogo UCS Version 4.3

Note: Cool Solutions are articles documenting additional functionality based on Univention products. Not all of the shown steps in the article are covered by Univention Support. For questions about your support coverage contact your contact person at Univention before you want to implement one of the shown steps.

Also regard the legal notes at Terms of Service.


This article tries to give an overview of typical uses cases for the management of UCS server instances using LDAP Policies.

What are LDAP policies?

LDAP Policies are a tool to define configuration parameters for a set of objects. In the upcoming use cases, the configurations of UCS server instances are defined as LDAP policies and apply to existing or newly deployed UCS instances.

LDAP policies are stored as objects in the UCS LDAP and then assigned somewhere in the LDAP structure. They apply to all objects in the LDAP subtree, starting with the LDAP object that has the policy assigned.

The default is to apply policies once per hour. To avoid service outages, changed settings might not be applied directly (policy updates in most cases don't trigger service restarts), so new settings defined by policies might apply after the next server reboot. If needed, service restarts can be automated using CRON settings applied by UCR policies.

Details about the concept can be found in the UCS documentation, starting with the chapter Policy concept

Overview of policies relevant to UCS server instances

Policies relevant to all UCS server roles

For the more detailed documentation see also the policies section of the UCS 4.3 documentation.

Policy "Automatic Updates"

The Policy can be used to activate automatic release updates. The recommendation is to do automatic point release updates, so "Update to this UCS version" should be set to the current UCS Minor release used in the environment (example: "4.3").

Policy "Maintenance"

Maintenance policies define the time and events for Automatic Updates. The recommendation is to make use of CRON settings and ensure, that the environment is actualized top-down (DC Master then DC Backup then DC Slave). Univention releases errata updates as soon as they pass our quality control. Consequently one should actualize instances within one day to avoid that instances actualized later retrieve newer UCS Errata Levels.

Example:

  • update DC Master at 10 pm
  • update DC Backups at 11 pm
  • update DC Slaves at 0 am
  • update memberservers at 1 am

Policy "<system role> packages"

Recommendation: use for typical tools in a domain, that are common for servers (like favorite editor or administration tools).

In large environments, the policies can define for individual package sets for each objective (example: the policy for the memberserver providing file services would include univention samba packages).

Policy "NFS mounts"

Can be used to automatically mount existing NFS shares, for example for shared storage based on NFS for UVMM virtualization nodes.

Policy "Print Server"

Historical, typically not needed.

Policy "Repository server"

In case a dedicated internal repository server is in place the policy should be used to make it a default for all servers.

Policy "repository synchronisation"

In case there are several dedicated repository servers the policy can be used to define the update events. This policy must not conflict with applicable server maintenance policy defined under "Automatic Update."

Policy "Univention Configuration Registry"

This policy allows to configure all settings defined as UCR variable. For use cases see separate section below.

Policies relevant for UCS member servers

Policy "LDAP Server"

The policy allows defining a list of LDAP servers. The first entry in the list is going to be the default, and all others are fallback servers. How these servers are accesses / the decision about the usage of fallback servers depends on the services installed on this UCS instance.

Recommendations: Depending on the segmentation of your datacenters or network infrastructure a dedicated policy for each segment is the recommendation. The listed LDAP servers should be in a segment close to the memberserver (for example same location or same network segment) to avoid network latency during LDAP requests. In huger environments, we recommend avoiding the concentration of many memberservers as clients of one LDAP server, defined by the first server in the list. One can avoid this problem by defining two or more LDAP policies for one location assigning the LDAP servers in a different order.

Univention Configuration Registry Policies

Generic recommendations

Univention Configuration Registry (UCR) policies are a generic tool to (pre-)configure any UCR variable. The settings defined by UCR policies are stored separately on each UCS instance. If needed, one can restore local and default settings by removing the applying policy. It is strongly recommended to include only variables in these policies that need to be adjusted to avoid conflicts in case an update changes the defaults.

UCR variables differ depending on the services installed on a UCS instance. The recommendations listed here are typical examples. A more generic approach is to check which UCR variables are defined on an instance and which of these are not the product default. Based on this analysis, one can define policies per location, network segment or server role.

Several standard policies listed above also modify UCR variables. Conflicts should be avoided here, so settings defined using a standard policy should not be defined using UCR policies and vice versa.

In contrast to other LDAP policies, it can make sense and is supported to assign several UCR policies to one LDAP Object (OU, container or server). The different UCR variables defined in the policies are merged and applied. Please note that assigning several policies to one LDAP object is currently only possible in the UDM command line tool.

Typicall use cases

  • restrict access to the machine or its services by define allowed groups for individual PAM authentication modules
    • UCR variables: auth/*
  • define cron jobs
    • UCR variables: cron/*
  • define settings for system mails
    • UCR variable mail/alias/root - mail addres for sending system mails (i.e. error messages from CRON jobs)
    • UCR variable mail/relayauth and mail/relayhost - mail relay configuration
  • define Nagios server instance
    • UCR Variable nagios/client/allowedhosts
  • deactivate unused services
    • UCR variables */autostart
    • example: nfs/autostart
  • define nameservers: UCS Instances, especially memberservers, should have several nameservers configured to avoid problems in case on DNS server instance is unavailable. For UCS DC instances, it is strongly recommended to use the internal IP as first nameserver.
    • UCR variables nameserver* - must point to a nameserver that knows all DNS records of the UCS domain, strongly recommended to use a UCS DC
  • define timeserver: primary and fallback timeservers
    • UCR variables: timeserver*
  • adjust sizing in case of bigger environments: UCS comes with defaults to address typical scenarios with several thousand users and devices. In case the environment is significantly larger or suffers performance issues, UCR policies should be used to enroll performance tweaks. Examples are:
    • NSCD cache sizes: UCR Variables nscd/*/size
    • LDAP database backend size: ldap/database/mdb/maxsize
    • Listener Cache size: listener/cache/mdb/maxsize
  • configure remote logging: log files written by "syslog" daemon can be send to a remote host for centralized logging
    • UCR variable: syslog/remote
  • Proxy server for internet access: UCS instances need internet access to retrieve updates from Univentions repository servers. In case a proxy server has to be used, it can be configured using LDAP policies
    • UCR variables: proxy/*
  • Firewall rules: if services provided by UCS instances should be limited by firewall rules, the settings can be configured by UCR. Anyway, in most situations it is recommended to do this on dedicated firewall / router appliances
    • UCR variables: security/packetfilter*
Personal tools