openldap-technical September 2019

openldap-technical@openldap.org

20 participants
25 discussions

Re: search request not blocked by ACLs
by Manuela Mandache 09 Sep '19

09 Sep '19

Le mer. 4 sept. 2019 à 16:00, Quanah Gibson-Mount <quanah(a)symas.com> a écrit : > --On Wednesday, September 4, 2019 1:56 PM +0200 Manuela Mandache > <manuela3mandache(a)gmail.com> wrote: > > > olcAccess: {0}to * by dn.base="cn=admin,cn=config" manage by > > dn.base="cn=adm > > in,dc=example,dc=com" manage by * break > > olcAccess: {1}to dn.base="" by * read > > olcAccess: {2}to dn.base=cn=Subschema by * read > > olcAccess: {3}to dn.subtree="dc=example,dc=com" attrs=userPassword by * > > auth > > olcAccess: {4}to dn.subtree="dc=example,dc=com" attrs=entry by * read > > olcAccess: {5}to dn.subtree="dc=example,dc=com" attrs=cn,mail by * read > > olcAccess: {6}to * by anonymous none by * read > > On what cn=config entry have you set these ACLs? > They're on olcDatabase={2}mdb,cn=config This is the DB containing the actual data of the directory, with olcSuffix: dc=example,dc=com Regards, Manuela > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

Why is dc=my-domain,dc=com in my namingContext?
by Paul Pathiakis 09 Sep '19

09 Sep '19

Hi, Something is amiss and I decided to rebuild from the start. # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example,dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never TLS_CACERTDIR /etc/openldap/cacerts # Turning this off breaks GSSAPI used with krb5 when rdns = false SASL_NOCANON on #TLS_CACERT /etc/openldap/cacert.pem #TLSCACertificateFile /etc/openldap/cacert.pem #TLSCertificateFile /etc/openldap/server.crt #TLSCertificateKeyFile /etc/openldap/private.key ssl start_tls TLS_REQCERT allow BASE dc=joescompany,dc=com URI ldap://127.0.0.1/ I start the ldap server and go to see if everything is ok. ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: namingContexts # # dn: namingContexts: dc=joescompany,dc=com namingContexts: dc=my-domain,dc=com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Should that second line even be there? Where in the world is it getting my-domain from? Is it a default? Thank you, P.

2 2

slapo-memberof(5) confusing documentation
by Norman Gray 09 Sep '19

09 Sep '19

Greetings. The slapo-memberof(5) manpage mentions limitations on when it can be used, in the context of replication. The current text is very confusing, and possibly not self-consistent. This message might be more appropriate as an ITS PR, but I'm sending it here first, partly in case I've got the wrong end of the stick, and partly as google-bait for the benefit of anyone as puzzled as I was. The text currently says: > The memberof overlay may be used with any backend that provides full > read-write functionality, but it is mainly intended for use with local > storage backends. The maintenance operations it performs are internal > to the server on which the overlay is configured and are never > replicated. Replica servers should be configured with their own > instances of the memberOf overlay if it is desired to maintain these > memberOf attributes on the replicas. Fine -- that seems to me to say very clearly that the memberof attribute is OK to use across replicas, as long as each replica has its own memberof overlay. However, immediately after that, the text says: > Note that slapo-memberOf is not compatible with syncrepl based > replication, and should not be used in a replicated environment. An > alternative is to use slapo-dynlist to emulate slapo-memberOf > behavior. This seems to flatly contradict (my understanding of) the first part of the paragraph. So which is it? A 2009 list thread [1] seems to suggest that you can sort of get away with it, but only just. However another list thread (2015) [2] describes an apparently successful setup using simple syncrepl, with memberof in the provider and consumer, and where the memberof attribute is automatically excluded from the replication (there’s explicit advice not to exclude it using exattrs=memberof in the syncrepl setup). The latter posting refers to ITS issue 7400 [3], ‘Memberof and Syncrepl incompatibility’, which last had activity in 2012, but which still appears to be open. The latter issue notes in passing that ‘memberof must be configured on each replica’, which implies that this is a feasible setup. **However**: closed ITS 8613 (2017) [4] says baldly that > The slapo-memberOf overlay is not safe to use in a replicated > environment due to the way in which replication occurs. It also explains why, and gives a (compressed but complete) suggestion of how one might use the dynlist overlay to do something similar. A 2018 list message [5] says in passing > Unfortunately, there is no defined standard for the “memberOf” > functionality (it’s a MS hack) and so there’s nothing that details > how it should or shouldn’t behave with replication. Going with the most recent statement, therefore, it seems that this it's simply not possible to use memberOf in a replicated environment, unless (rather precariously, I'd have thought) you completely avoid 'refresh' mode in replication, as mentioned in [4]. I suggest adjusting the text in the slapo-memberof manpage. If the third sentence (‘Replica servers should...’) were simply removed, that would remove most of the contradiction. In the following sentence (‘Note that...’), the sentence first seems to suggest that it's only syncrepl replication that the overlay is incompatible with (ie, that there are other replication mechanisms which will work), but it goes on to state that it's incompatible with _all_ replication methods. Which is it? Finally, given the aside in [5], it might be worth indicating in the manpage that memberOf should only be used when other considerations force it, and should (by the sound of it) be avoided otherwise. Have I misunderstood something? Best wishes, Norman [1] https://www.openldap.org/lists/openldap-software/200910/msg00037.html [2] https://www.openldap.org/lists/openldap-technical/201505/msg00127.html [3] https://www.openldap.org/its/index.cgi/Software%20Bugs?id=7400;selectid=7400 [4] http://www.openldap.org/its/index.cgi/?findid=8613 [5] https://www.openldap.org/lists/openldap-technical/201809/msg00099.html -- Norman Gray : https://nxg.me.uk

2 2

slapd-sock as overlay
by Shiva Prasad Thagadur Prakash 09 Sep '19

09 Sep '19

Hello Guys, Could you please tell me where I could find a guide to configure slapd-sock as overlay for an existing database? I am not using slapd.conf but olc. I tried the configuring but I am getting "error 80, implementation error, could not open socket". Below is the configuration: dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=ericsec,dc=com olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to * by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=ericsec,dc=com olcRootPW: {SSHA}lxpvQanVD5GoVXKiDB1HNEInKYussacd .. dn: olcOverlay={0}sock,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: olcOvSocketConfig olcOverlay: {0}sock olcDbSocketPath: /tmp/sockoverlay-listener1 olcDbSocketExtensions: binddn peername ssf olcOvSocketOps: bind unbind search Eagerly waiting for the reply. Thanks, Shiva

2 3

search request not blocked by ACLs
by Manuela Mandache 04 Sep '19

04 Sep '19

Hello all, My previous email address doesn't seem able to communicate with the list anymore... I sent this question yesterday and I don't find it in the September list of submitted subjects - sorry if I got it wrong and I'm double-posting. On an OpenLDAP directory, the ACLs are olcAccess: {0}to * by dn.base="cn=admin,cn=config" manage by dn.base="cn=adm in,dc=example,dc=com" manage by * break olcAccess: {1}to dn.base="" by * read olcAccess: {2}to dn.base=cn=Subschema by * read olcAccess: {3}to dn.subtree="dc=example,dc=com" attrs=userPassword by * auth olcAccess: {4}to dn.subtree="dc=example,dc=com" attrs=entry by * read olcAccess: {5}to dn.subtree="dc=example,dc=com" attrs=cn,mail by * read olcAccess: {6}to * by anonymous none by * read For the requests, the behavior is the expected one from user's point of view : $ ldapsearch -LLL -x -H ldap://myServer:390 -b ou=people,dc=example,dc=com 'cn=Name*' dn: uid=someuid,ou=people,dc=example,dc=com mail: FirstName.Name(a)domain.com cn: Name FirstName $ ldapsearch -LLL -x -H ldap://myServer:390 -b ou=people,dc=example,dc=com 'sn=Name' Checking the log, the first requests appears as 2019-09-03T14:22:17.537815+02:00 myServer slapd[4765]: conn=1141654 fd=13 ACCEPT from IP=xxx.xxx.xxx.xxx:55188 (IP=0.0.0.0:390) 2019-09-03T14:22:17.538004+02:00 myServer slapd[4765]: conn=1141654 op=0 BIND dn="" method=128 2019-09-03T14:22:17.538044+02:00 myServer slapd[4765]: conn=1141654 op=0 RESULT tag=97 err=0 text= 2019-09-03T14:22:17.546713+02:00 myServer slapd[4765]: conn=1141654 op=1 SRCH base="ou=people,dc=example,dc=com" scope=2 deref=0 filter="(cn=Name*)" 2019-09-03T14:22:17.550421+02:00 myServer slapd[4765]: conn=1141654 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= 2019-09-03T14:22:17.562783+02:00 myServer slapd[4765]: conn=1141654 op=2 UNBIND 2019-09-03T14:22:17.562835+02:00 myServer slapd[4765]: conn=1141654 fd=13 closed which is once again the expected behavior. But the second request generates in the log 2019-09-03T14:22:04.293120+02:00 myServer slapd[4765]: conn=1141645 fd=13 ACCEPT from IP=xxx.xxx.xxx.xxx:55186 (IP=0.0.0.0:390) 2019-09-03T14:22:04.293262+02:00 myServer slapd[4765]: conn=1141645 op=0 BIND dn="" method=128 2019-09-03T14:22:04.293328+02:00 myServer slapd[4765]: conn=1141645 op=0 RESULT tag=97 err=0 text= 2019-09-03T14:22:04.302404+02:00 myServer slapd[4765]: conn=1141645 op=1 SRCH base="ou=people,dc=example,dc=com" scope=2 deref=0 filter="(sn=Name)" 2019-09-03T14:22:04.304850+02:00 myServer slapd[4765]: <= mdb_equality_candidates: (sn) not indexed 2019-09-03T14:22:04.334020+02:00 myServer slapd[4765]: conn=1141645 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= 2019-09-03T14:22:04.342618+02:00 myServer slapd[4765]: conn=1141645 op=2 UNBIND It actually looks as if the search was performed first, and the ACLs were checked only afterwards to prevent any return. As sn is not supposed to be used in the filter, it is not indexed (but we have no control over the requests sent to the directory to prevent the use of unauthorized filters). Am I misreading the log? And if I'm not, is there some parameter to be set to block the actual search on unauthorized filters? Thank you, and please let me know if I need to supply more configuration information. Regards, Manuela

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical September 2019