How to use LDAP ACLs for selective replication
Important Note
This article describes the possibility of selective replication but in most cases you pobably should not use it, as it may not offer the advantages your are expecting. Instead, it will have a couple of side effects or drawbacks.
Recommendation is not to change LDAP ACLs to configure selective replication!
Situations where you might consider using selective replication
-
In order to reduce traffic between sites (and to UCS slave servers) you may want to synchronize only a part of the LDAP information to a remote site.
-
For security reasons you may want to only have a dedicated part of the directory tree available at branch offices or remote company sites.
Important Note:
In case you are using Samba/AD it is not enough to restrict OpenLDAP replication using LDAP ACLs because Samba/AD will synchronize between all Samba/AD domain controllers independent from the OpenLDAP replication. You will always have all information in Samba/AD on all sites. Samba/AD does not support selective replivation.
For reducing traffic restricting OpenLDAP replication is helpful, but again as Samba synchronizes the data anyways only a minor percentage of the data will be blocked for synchronization by using OpenLDAP ACLs. Additionally if a user from a filtered OU logs in (i.e. someone switching working locations) some things will not work as expected, as this user is not known to the local UCS. In particular the users Posix-UserID will not be known and files created by the user will be stored with an arbitrary numerical uidNumber, that is only valid on a specific server.
So in most of the cases you will not get the result you have expected, especially if you are using Samba/AD!
If you still want to do this after carefully onsidering the warnings above, you can follow the steps documented in our developer guide.
Note:
As developers are the target audience, the following is only a rough description of the procedure. You will have to read further and add your own steps.
Step 1
Separate your directory into organizational units ("ou="). Move the objects as needed to theses OUs.
Step 2
Create additional OpenLDAP ACLs to prevent reading from the slave UCS (except the right one) and allow read access to this OU only by the one slave assigned to it. Be sure master and backup servers still need full access!
Important Note:
Also be aware that the following adjustments need to be done not only on the UCS master but also on each UCS Backup server in the same way. The reason for this is, that UCS Slave servers are free to dynamically chose Master and Backup servers as their source of OpenLDAP replication.
You need to identify the allowed servers based on their DNs to generate the ACLs. Here a short example for an UCS template in case the container cn=example,cn=users should not be replicated at all to any slave server:
access to dn.subtree=cn=example,cn=users,@%@ldap/base@%@" by group /univentionGroup/uniqueMember="cn=DC Slave Hosts,cn=groups,@%@ldap/base@%@" none by * +0 break
Step 3
For UCS you will need a so called UCR-subtemplate for the slapd.conf so it has to fit to the naming conventions () which would be located at /etc/univention/templates/files/etc/ldap/slapd.conf.d which will contain your additional ACLs defined as above.
Once created you have to register the extension to your OpenLDAP server with the help of a script called ucs_registerLDAPExtension.
Additional information
man slapd.access
OpenLDAP Access Control
Stanford Example