\section{Configuration of LDAP ACLs}

\subsection{Introduction}

Access to the information contained in the LDAP directory is controlled by
Access Control Lists (ACLs) on the server side. The ACLs are defined in the
central configuration file \ucsURL{/etc/ldap/slapd.conf} and managed using
\ucsUCR{}. The \ucsURL{slapd.conf} is managed using a multifile
template; further ACL elements can be added below
\ucsURL{/etc/univention/templates/files/etc/ldap/slapd.conf.d/} between the
\ucsURL{60univention-ldap-server\_acl-master} and
\ucsURL{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 \emph{Domain Admins} group. Nested groups
are also supported. The \ucsUCRV{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:

\begin{itemize}
\item Which object in the LDAP is the rule applied to?
\item Which users will be assigned the permission?
\item Which permission will be assigned?
\item How should further rules be handled?
\end{itemize}

If errors should be investigated during ACL processing, it is advisable to set
the log level of the LDAP server to \emph{129} using the
\ucsUCRV{ldap/debug/level} and restart the LDAP server. The debug output can
be found in \ucsURL{/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.

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 recommended to start a new replication on the slave
domain controller and backup systems using the
\ucsCommand{univention-directory-listener-ctrl resync replication} command.

\subsection{Definition of objects for which a rule applies (\emph{access to})}

Access rules are implemented via \emph{access to} access directives. Rules can
be defined on three different classes of objects. These can be used in any
combination:

\begin{itemize}
\item 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:

\begin{ucsConsoleInput}
access to dn="uid=databaseadmin,cn=users,dc=company,dc=com"
\end{ucsConsoleInput}

The DNs can also be defined with a regular expression. The regular expressions
are given here in the POSIX standard:

\begin{ucsConsoleInput}
access to dn.regex="cn=.*,cn=dc,cn=computers,dc=company,dc=com"
\end{ucsConsoleInput}

\item The directive can be defined using a LDAP filter. For example, the
  access can be limited to MAC addresses using an object class.

\begin{ucsConsoleInput}
access to filter="(objectClass=macAddress)"
\end{ucsConsoleInput}

\item The attributes affected by the directive can be defined using
  \emph{attrs}, the following uses the user and group IDs as an example:

\begin{ucsConsoleInput}
access to attrs=uidNumber,gidNumber
\end{ucsConsoleInput}
\end{itemize}

\subsection{Definition of the access permissions on the objects}

Each permission directive starts with the \emph{by} statement.  It
determines which user can access the object specified in the \emph{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:

\begin{itemize}

\item \emph{*} applies the rule to all users.

\item Non-authenticated accesses are covered by
  \emph{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.

\item The opposite to the above-mentioned \emph{anonymous} is \emph{users}.

\item The \emph{self} rule defines the accessing object's access to its own
  attributes. This allows a user or computer object to change its own
  attributes.

\item \emph{dn} can be used to specify the access using the accessing
  object's DN. This can be entered in different forms:

\begin{itemize}
\item Using a concrete DN via \emph{dn.base}, e.g., via
\begin{ucsConsoleInput}
by dn.base="uid=database-admin,cn=users,dc=company,dc=com"
\end{ucsConsoleInput}
\item Using a regular expression, e.g., via
\begin{ucsConsoleInput}
by dn.regex="cn=.*,cn=dc,cn=computers,dc=company,dc=com"
\end{ucsConsoleInput}
\end{itemize}

\item \emph{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:

\begin{ucsConsoleInput}
by group/univentionGroup/uniqueMember="cn=Domain Admins,cn=groups,dc=company,dc=com"
\end{ucsConsoleInput}

\item \emph{peername}, \emph{sockname} and \emph{domain} allow the definition
  of the socket file name or the network origin of the accessing user. Some
  examples:

\begin{ucsConsoleInput}
by sockname="PATH=/var/run/slapd/ldapi"
by peername.ip=127.0.0.1
by domain.subtree=example.com
\end{ucsConsoleInput}

\end{itemize}

\subsection{Definition of the permission on the objects}

Each \emph{by} directive is completed with the assigned permission. The rules
are ordered hierarchically with each following rule receiving all the
privileges of its predecessor.

\begin{itemize}

\item \emph{none} denies every access.

\item \emph{disclose} denies the access but still issues an error warning.

\item \emph{auth} limits access to authentication and authorisation requests.

\item \emph{compare} limits the access to compare operations.

\item \emph{search} limits the access to search requests.

\item \emph{none} allows read-only access.

\item \emph{write} allows write access.

\end{itemize}

\subsection{Definition of the handling of further rules with applied rules}

For each \emph{by} directive there are three possibilities for controlling how
further rules are handled:

\begin{itemize}
\item As standard the processing of further \emph{access} rules is stopped
  when a rule applies. This can also be fixed explicitly using a \emph{stop}
  directive.

\item \emph{continue} allows the processing of further permission rules within an access rule.

\item \emph{break} checks further access rules to see whether they apply.
\end{itemize}

\subsection{Delegation of the privilege to reset user passwords}

To facilitate the delegation of the privilege to reset user passwords, the
\ucsName{univention-admingrp-user-passwordreset} package can be
installed. It uses a join script to create the \emph{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 \emph{User Password Admins} group, the DN of
the group to be used can be entered in the
\ucsUCRV{ldap/acl/user/passwordreset/accesslist/groups/dn}.

Passwords can be reset via \ucsUDM{}. In the default setting, \ucsUDM{}
only offers the user wizard to the \ucsName{Administrator} user, which allows
the setting of new passwords. During the installation a new
\ucsName{default-user-password-admins} policy is created automatically, which
can be linked to the members of the \emph{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, \ucsUDM{} denies him write access with
the message \emph{Permission denied}.

\ucsExclamation \ucsAttention{The package should be installed on the domain
  controller master and the domain controller backup systems. 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
\ucsUCRV{ldap/acl/user/passwordreset/protected/uid}. Once a variable has been
changed, it is necessary to restart the LDAP directoy service using the
\ucsCommand{/etc/init.d/slapd restart} command for the changed LDAP ACLs to
take effect. In the default setting, the \emph{Administrator} user is
protected against having his password changed by the \emph{User Password
  Admins} group.

If access to additional LDAP attributes should be necessary for changing the
password, the attribute names can be expanded in
\ucsUCRV{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. 

% Diese Zeilen bitte am Ende des Dokuments stehenlassen und 
% nicht entfernen - sie helfen bei der Arbeit mit vi und emacs.
% vim:tw=78:ts=8:nocindent:noautoindent
% Local Variables:
% fill-column: 78
% End:

