Hello everyone,
I made a configuration to get slapd-sock to work with a python3 server (gevent). The slapd configuration can be reproduced less then a minute using this ansible playbook: https://github.com/peppelinux/ansible-slapd-eduperson2016
the python3 server is available at the following resource, slapd-sock backend configuration can be found in the README file: https://github.com/peppelinux/pyMultiLDAP
It is the following:
ldapadd -Y EXTERNAL -H ldapi:/// <<EOF dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModuleLoad: back_sock.la EOF
ldapadd -Y EXTERNAL -H ldapi:/// <<EOF dn: olcDatabase={4}sock,cn=config objectClass: olcDbSocketConfig olcDatabase: {4}sock olcDbSocketPath: /var/run/multildap.sock olcSuffix: dc=proxy,dc=unical,dc=it olcDbSocketExtensions: binddn peername ssf EOF
I tested that this configuration doesn't have any problems in a Debian 9 installation (slapd 2.4.44) but in a Debian10 (2.4.47) does. Even if I use "servers/slapd/back-sock/searchexample.pl" [1] I get the same faulty result, described as follow:
```` # extended LDIF # # LDAPv3 # base <dc=proxy,dc=unical,dc=it> with scope subtree # filter: uid=mario # requesting: ALL #
# search result search: 2 result: 0 Success text: OK ````
As we can see RESULT was found but with any preceeding ldif. Looking into /var/log/slapd.log I found the same behaviour of Debian9 installation:
```` [25-07-2019 10:33:57] slapd debug conn=1036 fd=20 ACCEPT from IP= 127.0.0.1:54674 (IP=0.0.0.0:389) [25-07-2019 10:33:57] slapd debug conn=1036 op=0 BIND dn="cn=admin,dc=testunical,dc=it" method=128 [25-07-2019 10:33:57] slapd debug conn=1036 op=0 BIND dn="cn=admin,dc=testunical,dc=it" mech=SIMPLE ssf=0 [25-07-2019 10:33:57] slapd debug conn=1036 op=0 RESULT tag=97 err=0 text= [25-07-2019 10:33:57] slapd debug conn=1036 op=1 SRCH base="dc=proxy,dc=unical,dc=it" scope=2 deref=0 filter="(objectClass=*)" [25-07-2019 10:33:57] slapd debug conn=1034 op=5 SRCH base="ou=people,dc=testunical,dc=it" scope=2 deref=3 filter="(objectClass=*)" [25-07-2019 10:33:57] slapd debug conn=1034 op=5 SRCH attr=eduPersonPrincipalName schacHomeOrganization mail uid givenName sn eduPersonScopedAffiliation schacPersonalUniqueId schacPersonalUniqueCode userPassword [25-07-2019 10:33:57] slapd debug conn=1034 op=5 SEARCH RESULT tag=101 err=0 nentries=4 text= [25-07-2019 10:33:57] slapd debug sock: fgets failed: Success (0) [25-07-2019 10:33:57] slapd debug conn=1036 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= OK [25-07-2019 10:33:57] slapd debug conn=1036 op=2 UNBIND [25-07-2019 10:33:57] slapd debug conn=1036 fd=20 closed ````
I also tried to use admin credentials, as shown in the slapd log. I also tried to do a fresh slapd installation by hands, on Debian9 slapd-sock works (searchexample.pl https://github.com/openldap/openldap/blob/master/servers/slapd/back-sock/searchexample.pl and pyMultiLdap) but not Debian10. I read that there are two additional features regarding slapd-sock in openldap 2.4.47. These are:
- Added slapd-sock DN qualifier for subtrees to be processed (ITS#8051) - Added slapd-sock ability to send extended operations to external listeners (ITS#8714)
My doubts: Is there any need to change configuration, following ITS#8714 and ITS#8051, to get it to work in Debian10 ? or Am I facing a bug present in openldap 2.4.47 ?
Thank you in advance for everything you would tell me, Cheers
[1] https://github.com/openldap/openldap/blob/master/servers/slapd/back-sock/sea...
Il giorno gio 25 lug 2019 alle ore 11:31 Giuseppe De Marco < giuseppe.demarco@unical.it> ha scritto:
My doubts: Is there any need to change configuration, following ITS#8714 and ITS#8051, to get it to work in Debian10 ? or Am I facing a bug present in openldap 2.4.47 ?
Thank you in advance for everything you would tell me, Cheers
Looking into openldap git repository: git show 2fbecdd756a288c787d8326d6630ab8500058e2f
I read in "/doc/man/man5/slapd-sock.5"
""" [...] socksuffix <DN suffix> Specify subtrees for which the overlay will act. Only operations on DNs matching the specified suffix(es) will be processed. The default is empty (all DNs are processed). """
This should mean that DN suffixes is not mandatory.
Giuseppe De Marco wrote:
Hello everyone,
I made a configuration to get slapd-sock to work with a python3 server (gevent). The slapd configuration can be reproduced less then a minute using this ansible playbook: https://github.com/peppelinux/ansible-slapd-eduperson2016
I tested that this configuration doesn't have any problems in a Debian 9 installation (slapd 2.4.44) but in a Debian10 (2.4.47) does. Even if I use "servers/slapd/back-sock/searchexample.pl http://searchexample.pl" [1] I get the same faulty result, described as follow:
searchexample.pl works fine here. Most likely something like SELinux policy has changed between Debian 9 and Debian 10.
On 7/25/19 4:56 PM, Howard Chu wrote:
Most likely something like SELinux policy has changed between Debian 9 and Debian 10.
AFAIK Debian 10 enables AppArmor by default not SELinux. But not sure whether slapd is confined because AppArmor default policy is "targeted". Better check with ps auxZ.
E.g. on my system:
ae-dir-p1:~ # ps auxZ | grep slapd ae-slapd (enforce) ae-dir-+ 1313 [..]
If (enforce) is listed then the process is confined by an AppArmor profile. Otherwise the process is listed as "unconfined".
If AppArmor profile is causing the issue you might want to watch out for DENIED lines in auditd log and add the privileges listed as missing.
Ciao, Michael.
On 7/25/19 11:31 AM, Giuseppe De Marco wrote:
I made a configuration to get slapd-sock to work with a python3 server (gevent).
Is this an asyncio server?
[25-07-2019 10:33:57] slapd debug sock: fgets failed: Success (0)
Are you sure your back-sock listener really responded on the correct socket? Does it have an own debug log.
FWIW: My back-sock listeners just work fine with 2.4.47+. But on Debian Stretch/Buster I'm using the LTB builds.
Ciao, Michael.
Hi all, I answer to your replies, good news: I found the problem.
@ Howard Thank you for told me that this is not a bug, it was a good point to start from.
@ Michael the back-sock listener is the same for Debian9 and for Debian10, the most important information is that neither "servers/slapd/back-sock/ searchexample.pl" worked on Debian10, but only on Debian9. The back-sock listener is a gevent python3 server. Thank you for apparmor hints, I found this information reading openldap archives. On Debian10 we do not have SElinux but only apparmor, I confirm all you wrote.
I just made some mistake in ACL, because I can read results with "ldapsearch -H ldapi:// -Y EXTERNAL -b "dc=proxy,dc=myorg,dc=it""
but not with ldapsearch -H ldap://localhost:389 -D "cn=admin,dc=myorg,dc=it" -w slapdsecret -b "dc=proxy,dc=myorg,dc=it"
So I understood it was a silly ACL problem behind this. I just added an ACL as follow and everything works fine!
```` export BASEDC="dc=myorganization,dc=it"
ldapadd -Y EXTERNAL -H ldapi:/// <<EOF dn: olcDatabase={4}sock,cn=config changeType: modify add: olcAccess olcAccess: to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break olcAccess: to dn.subtree="ou=people,$BASEDC" by dn.children="ou=auth,$BASEDC" read by self read by * break olcAccess: to * by anonymous auth by * break EOF ````
the question about Debian9 / Debian10 derived from different ldapsearch authentication methods, Thank you all for your time
Il giorno gio 25 lug 2019 alle ore 17:28 Michael Ströder < michael@stroeder.com> ha scritto:
On 7/25/19 11:31 AM, Giuseppe De Marco wrote:
I made a configuration to get slapd-sock to work with a python3 server (gevent).
Is this an asyncio server?
[25-07-2019 10:33:57] slapd debug sock: fgets failed: Success (0)
Are you sure your back-sock listener really responded on the correct socket? Does it have an own debug log.
FWIW: My back-sock listeners just work fine with 2.4.47+. But on Debian Stretch/Buster I'm using the LTB builds.
Ciao, Michael.
openldap-technical@openldap.org
-
Giuseppe De Marco -
Howard Chu -
Michael Ströder