openldap-technical October 2018

openldap-technical@openldap.org

29 participants
29 discussions

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

23 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 23 Oct '18

23 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

OpenLDAP and Google Cloud Directory Sync
by Brian Hill 19 Oct '18

19 Oct '18

I would like to get OpenLDAP to trigger a GCDS sync whenever either certain attributes are modified or even anything the DB, if it isn't possible to limit it to certain attributes. I am thinking along the lines of OpenLDAP calling some external program after a modification, but if there is another way to do this that I am missing, I am all ears. I have looked at the various overlays but none seem relevant. Has anyone done this or have general suggestions? Brian

5 4

Re: Check synchro : access only to contextcsn
by Lirien Maxime 18 Oct '18

18 Oct '18

Damn ! my ACL don't work despites your help :-/ In the log it seems that "supervision" can't access dc=fr, it starts 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. 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 On Tue, Oct 16, 2018 at 6:31 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Tuesday, October 16, 2018 6:54 PM +0200 Dieter Klünter > <dieter(a)dkluenter.de> wrote: > > > Am Tue, 16 Oct 2018 15:51:50 +0200 > > schrieb Lirien Maxime <maxime.lirien(a)gmail.com>: > > > >> Hi all, > >> thanks for reading. > >> 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 to check synchro. And only contextcsn not the other > >> entries. (plugin check nagios). > >> Can someone help me to write the right ACL ? > >> > >> Here what I tried but not really right :-/ > >> # ContextCSN > >> access to dn.subtree="dc=fr" attrs=contextCSN > >> by dn.subtree="cn=supervision,ou=Comptes Clients,dc=fr" read > >> by * none > > > > access to dn.base=dc=fr > > attrs=entry,children,contextCSN read > > I'd also be careful of doing "by * none" to the contextCSN, etc, as that > can break replication depending on the DN that binds to the master(s), > since the replication DN must be able to read the contextCSN. > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

2 1

Re: Adding read-only consumers to a Mirror Mode Replication setup?
by Quanah Gibson-Mount 18 Oct '18

18 Oct '18

--On Thursday, October 18, 2018 1:44 PM +0200 Ondřej Kuzník <ondra(a)mistotebe.net> wrote: > I can see cn=config is being replicated in that ticket. It makes more > sense that the 'unwilling to perform' issue would be limited to > replicating the config (which can be more picky about its modifications) > rather than regular databases. cn=config is not being replicated in that ticket. I simply said in one follow up that things broke after I made a change to cn=config. Later, I clearly stated that was entirely unrelated. ;) > That kind of setup is being used in a significant number of deployments > and by Linus' law we'd have more reports like this one. I've never seen that setup in any deployment. I've seen lots of deployments that say, have 2-way MMR, and 3 replicas that feed of Master #1 and 3 replicas that feed off of Master #2. But not where any replica feeds from *both* masters, as is discussed in the ticket. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

ODD #5 Proceedings
by Howard Chu 17 Oct '18

17 Oct '18

Proceedings are partially online now. http://www.openldap.org/conf/odd-tuebingen-2018/ (The last 2 talks are still missing, will be uploaded when available.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Check synchro : access only to contextcsn
by Lirien Maxime 16 Oct '18

16 Oct '18

Hi all, thanks for reading. 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 to check synchro. And only contextcsn not the other entries. (plugin check nagios). Can someone help me to write the right ACL ? Here what I tried but not really right :-/ # ContextCSN access to dn.subtree="dc=fr" attrs=contextCSN by dn.subtree="cn=supervision,ou=Comptes Clients,dc=fr" read by * none Thanks.

3 2

Password policy messages - how can I pass back
by Ervin Hegedüs 13 Oct '18

13 Oct '18

Hi there, there is a password policy external module with this config: dn: cn=default,ou=pwpolicies,dc=hu cn: default objectClass: pwdPolicy objectClass: pwdPolicyChecker objectClass: device pwdAllowUserChange: TRUE pwdInHistory: 5 pwdMinLength: 10 pwdAttribute: userPassword pwdCheckQuality: 1 pwdCheckModule: pwdCheckModule-poc.so I've grabbed this source: https://github.com/bindle/bofh-pwdCheckModules Everything works as well: I can change the password with ldappasswd tool, or ldap_exop() in PHP - the policy check works in both cases. I just have one question: is there any way to send back to the client the error message? I mean: # /usr/bin/ldappasswd -H ldaps://dev-ldap-01 -w "secret" -D "UID="dminuser,dc=hu" -s "abcdefghijkl" "uid=airween,ou=Users,dc=hu" Result: Constraint violation (19) There isn't any detailed information, what's the reason why the policy module drops the request, but I can see that in the logfile: Oct 10 20:05:21 dev-ldap-01 slapd[16312]: check_password_quality: module error: (pwdCheckModule-poc.so) Passwords less than 16 characters require at least 3 traits (upper case, lower case, digits, or special characters).[1] Oct 10 20:05:21 dev-ldap-01 slapd[16312]: send_ldap_result: conn=1742 op=1 p=3 Oct 10 20:05:21 dev-ldap-01 slapd[16312]: send_ldap_result: err=19 matched="" text="Passwords less than 16 characters require at least 3 traits (upper case, lower case, digits, or special characters)" It would be very good to catch this message at client side. Is it possible? Note, that in PHP side I'm using: ldap_get_option($ldapconn, LDAP_OPT_DIAGNOSTIC_MESSAGE, $_err); and $_err variable is empty. When I send the old password, which exists in history, I got: ldappasswd -H ldaps://... ... ... -s "oldpasswd" "uid=airween,..." Result: Constraint violation (19) Additional info: Password is not being changed from existing value in PHP: "Password is not being changed from existing value" In syslog I can see: Oct 10 20:09:36 dev-ldap-01 slapd[16312]: send_ldap_result: err=19 matched="" text="Password is not being changed from existing value" Oct 10 20:09:36 dev-ldap-01 slapd[16312]: send_ldap_extended: err=19 oid= len=0 Oct 10 20:09:36 dev-ldap-01 slapd[16312]: send_ldap_response: msgid=2 tag=120 err=19 Oct 10 20:09:36 dev-ldap-01 slapd[16312]: conn=1743 op=1 RESULT oid= err=19 text=Password is not being changed from existing value Should I fill some member of Entry struct in 3rd argument in policy module? int check_password (char *pPasswd, char **ppErrStr, Entry *pEntry) ....................................................^^^^^^^^^^^^^^ Thanks, a.

3 6

How to add a new schema on N-way multi-master with legacy config
by Martin Božič 12 Oct '18

12 Oct '18

Hello, We've inherited an N-way multi-master setup (based on CentOS OpenLDAP v. 2.4.39) which was setup with text conf in slapd.conf instead of online configuration in cn=config. Due to various dependencies from other internal systems we can't migrate to online configuration quickly, but we to urgently have to add an additional schema to our cluster. My Google-fu and wading through the openldap list archives was unsuccessful. I suppose that adding a new schema to such a setup would require the following steps: 1. stop all instances in the cluster 2. add schema to all instances to /etc/openldap/schema 3. start all instances in the cluster Would this be the correct approach or is there something else I should be aware of? Regards, Martin Božič

4 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical October 2018