Hello,
How can I create an entry (in terms of ldif/ldapadd/ldapmodify), which is not returned on searches (apart from tweaking the olcAccess rules?
https://www.openldap.org/devel/admin/replication.html says:
Because a general search filter can be used in the syncrepl
specification, some entries in the context may be omitted from the synchronization content. The syncrepl engine creates a glue entry to fill in the holes in the replica context if any part of the replica content is subordinate to the holes. The glue entries will not be returned in the search result unless ManageDsaIT control is provided.
Rationale: I want to create a directory, containing contacts under:
cn=juridical persons,dc=me cn=natural persons,dc=me
The LDAP clients shall query base dc=me with scope SUB. The LDAP clients shall see all subentries of Juridical Persons and all subentries of Natural Persons, but not the cn=juridical persons,dc=me cn=natural persons,dc=me and dc=me entries itself. As the latter entries do not represent Contacts (mail, phone, address), the entries shall not appear in address books.
Greetings Дилян
--On Monday, September 13, 2021 2:33 PM +0300 Дилян Палаузов dpa-openldap@aegee.org wrote:
Hello,
How can I create an entry (in terms of ldif/ldapadd/ldapmodify), which is not returned on searches (apart from tweaking the olcAccess rules?
You need to tweak the olcAccess rules.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On Mon, Sep 13, 2021 at 01:33:50PM +0300, Дилян Палаузов wrote:
Hello,
How can I create an entry (in terms of ldif/ldapadd/ldapmodify), which is not returned on searches (apart from tweaking the olcAccess rules?
[...]
Rationale: I want to create a directory, containing contacts under:
cn=juridical persons,dc=me cn=natural persons,dc=me
The LDAP clients shall query base dc=me with scope SUB. The LDAP clients shall see all subentries of Juridical Persons and all subentries of Natural Persons, but not the cn=juridical persons,dc=me cn=natural persons,dc=me and dc=me entries itself. As the latter entries do not represent Contacts (mail, phone, address), the entries shall not appear in address books.
Hi, if you care that the clients just can't see them or some data in there, whatever they do, you need to set ACLs. Otherwise just have the clients send a suitable filter, based on your description, you should be able to match on objectclass at the very least. Worst case, matching on entryDN (like the example given in slapcat's manpage) or using the ":dn:" flag might help if you wanted to filter out certain subtrees.
Regards, Ondrej
openldap-technical@openldap.org