openldap-technical

openldap-technical@openldap.org

14 participants
9795 discussions

question mark at the beggining of the search
by Angel L. Mateo 27 Oct '18

27 Oct '18

Hi, I'm having searchs like this in my openldap logs: Oct 25 12:46:41 canis30 slapd[25736]: conn=1192458 op=1 SRCH base="ou=Usuarios,dc=Telematica" scope=2 deref=0 filter="(&(?objectClass=posixGroup)(objectClass=irisInetEntity)... What does this "?" mean? -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información y las Comunicaciones Aplicadas (ATICA) http://www.um.es/atica Tfo: 868889150 Fax: 868888337

2 1

Re: ACL contextCSN
by Lirien Maxime 25 Oct '18

25 Oct '18

Thanks !! Have a nice day !! On Thu, Oct 25, 2018 at 5:02 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Thursday, October 25, 2018 10:25 AM +0200 Lirien Maxime > <maxime.lirien(a)gmail.com> wrote: > > > OK thanks Quanah ! > > I removed the "*" on ACL except for the last rule. > > I don't understand : it is rejected by the last rule. Why does it not > > match rule #3 ? Normally it may stop at the first match ? > > > Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_mask: access to entry > > "dc=fr", attr "objectClass" requested > > Hi Lirien, > > It's clearly asking for access to the objectClass attribute in "dc=fr", > which is not a part of your ACL#3, so it's correctly denied: > > # 3) ********* CONTEXTCSN ********* > access to dn.base="dc=fr" attrs=entry,children,contextcsn > by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read > by dn.exact="cn=supervision,ou=Comptes Clients,dc=fr" read > by * none > > You need to modify the access to line to include objectClass. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: ACL contextCSN
by Lirien Maxime 25 Oct '18

25 Oct '18

OK thanks Quanah ! I removed the "*" on ACL except for the last rule. I don't understand : it is rejected by the last rule. Why does it not match rule #3 ? Normally it may stop at the first match ? Here's my request and the ACL log : ldapsearch -x -H ldap://127.0.0.1 -b "dc=fr" -D "cn=supervision,ou=Comptes clients,dc=fr" -s base contextCSN Oct 25 08:31:08 apsim-qualif slapd[27308]: => access_allowed: result not in cache (userPassword) Oct 25 08:31:08 apsim-qualif slapd[27308]: => access_allowed: auth access to "cn=supervision,ou=Comptes Clients,dc=fr" "userPassword" requested Oct 25 08:31:08 apsim-qualif slapd[27308]: => dn: [1] ou=comptes admin,dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_get: [2] attr userPassword Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_mask: access to entry "cn=supervision,ou=Comptes Clients,dc=fr", attr "userPassword" requested Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_mask: to value by "", (=0) Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: cn=admingdr,ou=comptes admin,dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: cn=ldapsynchro,ou=comptes admin,dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: users Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: anonymous Oct 25 08:31:08 apsim-qualif slapd[27308]: <= acl_mask: [4] applying auth(=xd) (stop) Oct 25 08:31:08 apsim-qualif slapd[27308]: <= acl_mask: [4] mask: auth(=xd) Oct 25 08:31:08 apsim-qualif slapd[27308]: => slap_access_allowed: auth access granted by auth(=xd) Oct 25 08:31:08 apsim-qualif slapd[27308]: => access_allowed: auth access granted by auth(=xd) Oct 25 08:31:08 apsim-qualif slapd[27308]: => access_allowed: search access to "dc=fr" "entry" requested Oct 25 08:31:08 apsim-qualif slapd[27308]: => dn: [1] ou=comptes admin,dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: => dn: [3] dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_get: [3] matched Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_get: [3] attr entry Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_mask: access to entry "dc=fr", attr "entry" requested Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_mask: to all values by "cn=supervision,ou=comptes clients,dc=fr", (=0) Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: cn=ldapsynchro,ou=comptes admin,dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: cn=supervision,ou=comptes clients,dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: <= acl_mask: [2] applying read(=rscxd) (stop) Oct 25 08:31:08 apsim-qualif slapd[27308]: <= acl_mask: [2] mask: read(=rscxd) Oct 25 08:31:08 apsim-qualif slapd[27308]: => slap_access_allowed: search access granted by read(=rscxd) Oct 25 08:31:08 apsim-qualif slapd[27308]: => access_allowed: search access granted by read(=rscxd) Oct 25 08:31:08 apsim-qualif slapd[27308]: => access_allowed: search access to "dc=fr" "objectClass" requested Oct 25 08:31:08 apsim-qualif slapd[27308]: => dn: [1] ou=comptes admin,dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: => dn: [3] dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_get: [3] matched Oct 25 08:31:08 apsim-qualif slapd[27308]: => dn: [5] dc=gouv,dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_get: [6] attr objectClass Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_mask: access to entry "dc=fr", attr "objectClass" requested Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_mask: to all values by "cn=supervision,ou=comptes clients,dc=fr", (=0) Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: cn=root,dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: ou=comptes admin,dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: cn=ldapsynchro,ou=comptes admin,dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: self Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: users Oct 25 08:31:08 apsim-qualif slapd[27308]: <= acl_mask: [5] applying none(=0) (stop) Oct 25 08:31:08 apsim-qualif slapd[27308]: <= acl_mask: [5] mask: none(=0) Oct 25 08:31:08 apsim-qualif slapd[27308]: => slap_access_allowed: search access denied by none(=0) Oct 25 08:31:08 apsim-qualif slapd[27308]: => access_allowed: no more rules On Wed, Oct 24, 2018 at 5:15 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Wednesday, October 24, 2018 5:17 PM +0200 Lirien Maxime > <maxime.lirien(a)gmail.com> wrote: > > ># 2) userPassword accessible by all > > access to * attrs=userPassword > > by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read > > by users auth > > by anonymous auth > > by * none > > This should be just access to attrs=userPassword, no need for the *. > > Similar comment for some of your other ACLs using the same format. > > I would generaly advise enabling "acl" level logging to see how things are > being processed so you can determine what additional access is needed or > which rule(s) are blocking access. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

2 1

two subtrees replication
by Miroslav Misek 24 Oct '18

24 Oct '18

Hi, I am trying setup replication of two subtrees: olcDatabase={-1}frontend,cn=config cn=schema,cn=config I was advised at #openldap channel to set syncrepl for whole cn=config and restrict it by ACL at provider side. Which looks like elegant solution to me. I tried it, but without success. As long, as replication user does not have access to cn=config, replication fails. And I don`t want replicate it, because of TLS settings etc. So I tried this: olcAccess: {0}to dn.subtree="olcDatabase={-1}frontend,cn=config" by dn.exact="uid=replicator,dc=ententee,dc=com" read by * break olcAccess: {1}to dn.subtree="cn=schema,cn=config" by dn.exact="uid=replicator,dc=ententee,dc=com" read by * break olcAccess: {2}to dn.subtree="cn=config" by dn.exact="uid=replicator,dc=ententee,dc=com" search by * break But it didn`t help either. Does anyone have any advice please? Thank you, Miroslav Misek

3 3

ACL contextCSN
by Lirien Maxime 24 Oct '18

24 Oct '18

Hi all, sorry for this second post. I have a "supervision" account on all my ldap servers. With the plugin nagios , it check the synchro. I would like this account read only contextcsn at the top (dc=fr). And only contextcsn not the other entries. Quanah helped me (and thanks again) but it not seems to work. It's my bad, I don't see something... In the log it seems that "supervision" can't access dc=fr and it starts browsing from dc=gouv,dc=fr. Without rule#3, it's ok because of rule #5. But with rule#3 it's supposed to match contextCSN ?! Thanks guys. PS : "supervision" is in "Comptes Admin" Here are my ACL : # 1) Admin's branch access to dn.subtree="ou=Comptes Admin,dc=fr" by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read by self auth by users auth by anonymous auth # 2) userPassword accessible by all access to * attrs=userPassword by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read by users auth by anonymous auth by * none *# 3) ********* CONTEXTCSN *********access to dn.base="dc=fr" attrs=entry,children,contextcsn by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read by dn.exact="cn=supervision,ou=Comptes Clients,dc=fr" read by * none* # 4) Certificate access to * attrs=userCertificateAuthentication,userCertificateConfidentiality,userCertificateSigning by dn.exact="cn=clienttest,ou=Comptes Clients,dc=fr" read by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read by * none # 5) Branch dc=gouv,dc=fr access to dn.subtree="dc=gouv,dc=fr" by dn.subtree="ou=Comptes Clients,dc=fr" read by dn.subtree="ou=Comptes Admin,dc=fr" write by * none # 6) All the tree access to * by dn.exact="cn=root,dc=fr" write by dn.subtree="ou=Comptes Admin,dc=fr" read by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read by self none by users none by anonymous none by * none

2 1

Adding read-only consumers to a Mirror Mode Replication setup?
by Jean-Francois Malouin 24 Oct '18

24 Oct '18

Hi, Is it possible, or even sane to consider adding read-only consumers to a MMR setup? If so, any recommendations, pitfalls or gotchas? Or should I simply re-start from scratch -- I'm still not in production. Just for the record, I'm using 2.4.46 on Debian/Stretch 9.5. Both mirrors are backends to an HA haproxy server. Thanks, jf

6 12

Re: Permissions required to perform OU/DN filtering?
by Philip Colmer 24 Oct '18

24 Oct '18

So, in the end, it was literally the "ou" attribute that I needed to grant read access to. Just in case anyone else needs to do something similar in the future … Regards Philip On Tue, 23 Oct 2018 at 23:05, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > Hi Philip, > > --On Tuesday, October 23, 2018 2:21 PM +0100 Philip Colmer > <philip.colmer(a)linaro.org> wrote: > > > Yes, I can run slapd in debug mode but this is a production system so > > that means scheduling a maintenance window in several weeks' time. I > > was rather hoping to have a solution in place sooner than that thanks > > to the kind support of this list but, if I don't have it, I'll figure > > it out for myself. > > I don't know the answer off the top of my head, but I would imagine you > could set up a test/dev server fairly quickly to figure this out? Should > be pretty straight forward. If you have the cn=config database enabled, > you could change the loglevel to ACL on the fly (just to note). > > Warm regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 0

Permissions required to perform OU/DN filtering?
by Philip Colmer 24 Oct '18

24 Oct '18

I'm trying to use the following search filter: (&(objectClass=organizationalPerson)(!(ou:dn:=external-community))(memberOf=cn=users,ou=mailing,ou=groups,dc=linaro,dc=org)) If I use an admin account, the search works. If I use a restricted account, the search doesn't work. The restricted account is only allowed to retrieve a subset of attributes, e.g.: add: olcAccess olcAccess: to dn.children="dc=linaro,dc=org" filter=(objectClass=organizationalUnit) attrs=entry,description,organizationalStatus,mail,jpegPhoto,@organizationalUnit by group="cn=binder-group,ou=binders,dc=linaro,dc=org" read add: olcAccess olcAccess: to dn.children="dc=linaro,dc=org" filter=(objectClass=inetOrgPerson) attrs=businessCategory,jpegPhoto,labeledURI,roomNumber,modifyTimestamp,employeeNumber,memberOf by group="cn=binder-group,ou=binders,dc=linaro,dc=org" read (That is only a snippet of our configuration) What do I need to grant read access to in order to get the search filter to work with restricted accounts? Thanks. Philip

4 7

granting write privileges to alternate updatedn
by Heinemann, Peter G 24 Oct '18

24 Oct '18

Running Openldap 2.4.40 under RHEL 6.10 Trying to get this to work without success (from the slapd.access man page): " One useful application is to easily grant write privileges to an updatedn that is different from the rootdn. In this case, since the updatedn needs write access to (almost) all data, one can use access to * by dn.exact="cn=The Update DN,dc=example,dc=com" write by * break " I have this as the only access rule in slapd.conf but any write operation using this dn gives me insufficient access, and slapacl verifies that read access only is permitted. access to dn.subtree="dc=university,dc=edu" by dn.exact="cn=grouper-admin,dc=university,dc=edu" write by * break Standard rootdn works fine. This system is a master for two consumers, but there's no external access to the master so a stripped-down acl list is appropriate. Thanks for any direction for what I've missed. Peter

2 1

nonpresent_callback present UUID in logs
by Florent LARTET 23 Oct '18

23 Oct '18

Hello, I migrated my OpenLDAP data from bdb to mdb in a Multi-Master Replication architecture that is working for years now. Unfortunately using only 2.4.31-2+deb7u2 from Debian 7. In the 2nd server (yyyyyy in the configuration below), I noticed new log lines for each LDAP entry. nonpresent_callback: rid=002 present UUID 345d766c-b2d5-1030-9b6b-85786c41386a, dn uid=tve0320,ou=people,dc=univ-tlse2,dc=fr It occurs if the server yyyyyy is down, a modification is done on the server xxxxx and yyyy is started. I saw it's related to the "PRESENT" step on replication. I haven't the sync logs for long so I cannot say if it happened with the previous backend. So, is this a warning about a data problem or does it only mean "I'm looking for the existence on rid=002 and that's fine, here are the UUID and dn" ? Here is part of my conf, also replicated : /etc/ldap/slapd.d/cn=config.ldif:olcServerID: 1 ldap://xxxxxxx/ /etc/ldap/slapd.d/cn=config.ldif:olcServerID: 2 ldap://yyyyyyy/ olcSyncrepl: {0}rid=002 provider=ldap://xxxxxxx/ binddn="--------" bindmethod=simple credentials=---- searchbase="dc=univ-tlse2,dc=fr" type=refreshAndPersist retry="5 5 300 +" attrs="*,+" tls_reqcert=never olcSyncrepl: {1}rid=003 provider=ldap://yyyyyyy/ binddn="--------" bindmethod=simple credentials=---- searchbase="dc=univ-tlse2,dc=fr" type=refreshAndPersist retry="5 5 300 +" attrs="*,+" tls_reqcert=never olcMirrorMode: TRUE olcDbCacheSize: 10000 olcDbCheckpoint: 512 5 olcDbNoSync: TRUE olcDbMaxSize: 3221225472 olcIndex: entryUUID,entryCSN,contextCSN eq Thanks for your advices, Florent Lartet University of Toulouse Jean Jaurès

3 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical