Disable or remove Bind DN syntax check

[Giuseppe]

Hi to all,

for my companty I'm triing to setup a LDAP proxy to our Active Direcory 
implementation, after some time I have found several problems on some critical 
application that does not support multiple OU anche CN formed by "Surname Name" 
caused by the bad structure and nomenclature on the AD, but we cant change it.
To work around the problem I have used the rwm module to rewrite the client 
binddn query part to AD format name.surname@domain, but the proxy return:

[root@client ~]# ldapsearch -H ldap://192.168.29.134 ??-D 
"CN=Name.Surname,OU=subou,OU=Users HOUSE,DC=domain,DC=int" -W
ldap_bind: Invalid syntax (21)
?? ?? ?? ?? additional info: bindDN massage error
 ?? ??
some logs:

Nov ??3 21:32:33 proxy slapd[1309]: conn=1001 op=0 do_bind
Nov ??3 21:32:33 proxy slapd[1309]: >>> dnPrettyNormal: 

Nov ??3 21:32:33 proxy slapd[1309]: <<< dnPrettyNormal: 
, 

Nov ??3 21:32:33 proxy slapd[1309]: conn=1001 op=0 BIND 
dn="cn=Name.Surname,ou=subou,ou=Users HOUSE,dc=domain,dc=int" method=128
Nov ??3 21:32:33 proxy slapd[1309]: do_bind: version=3 
dn="cn=Name.Surname,ou=subou,ou=Users HOUSE,dc=domain,dc=int" method=128
Nov ??3 21:32:33 proxy slapd[1309]: daemon: activity on 1 descriptor
Nov ??3 21:32:33 proxy slapd[1309]: daemon: activity on:
Nov ??3 21:32:33 proxy slapd[1309]: ==> rewrite_context_apply [depth=1] 
string='cn=Name.Surname,ou=subou,ou=Users HOUSE,dc=domain,dc=int'
Nov ??3 21:32:33 proxy slapd[1309]:
Nov ??3 21:32:33 proxy slapd[1309]: ==> rewrite_rule_apply 
rule='^([C,c][N,n]=)([^.]*)\.([^.]*)(,[O,o][U,u][^.]*)(,[O,o][U,u][^.]*)(,[O,o][U,u][^.]*)(,[O,o][U,u][^.]*)(,[O,o][U,u][^.]*)(,[O,o][U,u][^.]*)$'
 string='cn=Name.Surname,ou=subou,ou=Users HOUSE,dc=domain,dc=int' [1 pass(es)]
Nov ??3 21:32:33 proxy slapd[1309]: daemon: epoll: listen=7 active_threads=0 
tvp=NULL
Nov ??3 21:32:33 proxy slapd[1309]: daemon: epoll: listen=8 active_threads=0 
tvp=NULL
Nov ??3 21:32:33 proxy slapd[1309]: daemon: epoll: listen=9 active_threads=0 
tvp=NULL
Nov ??3 21:32:33 proxy slapd[1309]: daemon: epoll: listen=10 active_threads=0 
tvp=NULL
Nov ??3 21:32:33 proxy slapd[1309]: ==> rewrite_rule_apply 
rule='^([C,c][N,n]=)([^.]*)\.([^.]*)(,[O,o][U,u][^.]*)(,[O,o][U,u][^.]*)(,[O,o][U,u][^.]*)(,[O,o][U,u][^.]*)(,[O,o][U,u][^.]*)$'
 string='cn=Name.Surname,ou=subou,ou=Users HOUSE,dc=domain,dc=int' [1 pass(es)]
Nov ??3 21:32:33 proxy slapd[1309]: ==> rewrite_rule_apply 
rule='^([C,c][N,n]=)([^.]*)\.([^.]*)(,[O,o][U,u][^.]*)(,[O,o][U,u][^.]*)(,[O,o][U,u][^.]*)(,[O,o][U,u][^.]*)$'
 string='cn=Name.Surname,ou=subou,ou=Users HOUSE,dc=domain,dc=int' [1 pass(es)]
Nov ??3 21:32:33 proxy slapd[1309]: ==> rewrite_rule_apply 
rule='^([C,c][N,n]=)([^.]*)\.([^.]*)(,[O,o][U,u][^.]*)(,[O,o][U,u][^.]*)(,[O,o][U,u][^.]*)$'
 string='cn=Name.Surname,ou=subou,ou=Users HOUSE,dc=domain,dc=int' [1 pass(es)]
Nov ??3 21:32:33 proxy slapd[1309]: ==> rewrite_rule_apply 
rule='^([C,c][N,n]=)([^.]*)\.([^.]*)(,[O,o][U,u][^.]*)(,[O,o][U,u][^.]*)$' 
string='cn=Name.Surname,ou=subou,ou=Users HOUSE,dc=domain,dc=int' [1 pass(es)]
Nov ??3 21:32:33 proxy slapd[1309]: ==> rewrite_context_apply [depth=1] 
res={0,'name.surn...@domain.int'}
Nov ??3 21:32:33 proxy slapd[1309]: [rw] bindDN: 
"cn=Name.Surname,ou=subou,ou=Users HOUSE,dc=domain,dc=int" -> 
"name.surn...@domain.int"
Nov ??3 21:32:33 proxy slapd[1309]: >>> dnPrettyNormal: 

Nov ??3 21:32:33 proxy slapd[1309]: send_ldap_result: conn=1001 op=0 p=3
Nov ??3 21:32:33 proxy slapd[1309]: send_ldap_result: err=21 matched="" 
text="bindDN massage error"
Nov ??3 21:32:33 proxy slapd[1309]: send_ldap_response: msgid=1 tag=97 err=21
Nov ??3 21:32:33 proxy slapd[1309]: conn=1001 op=0 RESULT tag=97 err=21 
text=bindDN massage error


I have downloaded the source code for try to remove or skip this check, but 
with my few programming skills after a month I haven't find the solution.
So there is a way (or a better way) to accomplish this need?

Best regards,
Giuseppe.

Config file of my test env:

### Schema includes ###
#include ?? ?? ?? ?? /etc/ldap/schema/corba.schema
#include ?? ?? ?? ?? /etc/ldap/schema/core.schema
#include ?? ?? ?? ?? /etc/ldap/schema/cosine.schema
#include ?? ?? ?? ?? /etc/ldap/schema/duaconf.schema
#include ?? ?? ?? ?? /etc/ldap/schema/dyngroup.schema
#include ?? ?? ?? ?? /etc/ldap/schema/inetorgperson.schema
#include ?? ?? ?? ?? /etc/ldap/schema/java.schema
#include ?? ?? ?? ?? /etc/ldap/schema/misc.schema
#include ?? ?? ?? ?? /etc/ldap/schema/nis.schema
#include ?? ?? ?? ?? /etc/ldap/schema/openldap.schema
#include ?? ?? ?? ?? /etc/ldap/schema/ppolicy.schema
#include ?? ?? ?? ?? /etc/ldap/schema/collective.schema
#include ?? ?? ?? ?? /etc/openldap/schema/ad.schema


include ?? ?? ?? ?? /etc/openldap/schema/corba.schema
include ?? ?? ?? ?? /etc/openldap/schema/core.schema
include ?? ?? 

Re: OpenLDAP and Ansible

[Giuseppe De Marco]

Great, I wrote these
https://github.com/peppelinux/ansible-slapd-eduperson2016/tree/master/roles/slapd_configure

Il sab 29 ago 2020, 18:49 Stefan Kania  ha scritto:

> I wrote some Ansible roles to set up a testing environment, mybe someone
> is interested in testing the roles. You can find all files and a
> descripton on my page:
>
>
> https://www.kania-online.de/using-ansible-to-set-up-an-openldap-environment/
>
>
>
>

-- 
--

Il banner è generato automaticamente dal servizio di posta elettronica 
dell'Università della Calabria
 

Re: LDAP Tool Box packages [was: OpenLDAP 2.4.51 available, LMDB 0.9.26 available]

[Giuseppe De Marco]

Bad news Quanah,
I think that there would the need to have many pluggable storages with an
abstract layer in between.

NoSQL, SQL and others (like elastic search) are so many important storage
engines nowadays, It would be awesome to have them in slapd.

Replication would works only on mdb, because each storage engines would
have their own

Il lun 17 ago 2020, 17:37 Quanah Gibson-Mount  ha scritto:

>
>
> --On Monday, August 17, 2020 5:36 PM +0200 Clément OUDOT
>  wrote:
>
> > Is there any possibilities to have in ltb the SQL backend in future
> > releases?
>
> I would note that back-sql is considered experimental, is extremely buggy,
> and has been retired for the 2.5 release.  Unless someone steps up to
> maintain and fix it to a functional state, it will likely be removed
> entirely at some point in the future.
>
> Regards,
> Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> 
>

-- 
--

Il banner è generato automaticamente dal servizio di posta elettronica 
dell'Università della Calabria
 

Re: LDAP Tool Box packages [was: OpenLDAP 2.4.51 available, LMDB 0.9.26 available]

[Giuseppe De Marco]

Hi Clément, great job, awesome!

Is there any possibilities to have in ltb the SQL backend in future
releases?

Official Deb packages lacks of this, It seems a little bit Buffy so ltb
would be a great opportunità to have a well supported sql backend without
SRC compilations

Regards

Il lun 17 ago 2020, 15:50 Clément OUDOT  ha scritto:

> Hello,
>
> LDAP Tool Box packages for OpenLDAP 2.4.51 are released. They can be
> downloaded on https://ltb-project.org/download#openldap or installed
> with yum/apt
>
> Thanks again to OpenLDAP team for their great work!
>
> Clément.
>

-- 
--

Il banner è generato automaticamente dal servizio di posta elettronica 
dell'Università della Calabria
 

Re: TLSv1.3 support on openldap 2.4.44

[Giuseppe De Marco]

You can find slapd 2.4.50 in buster-backports

https://github.com/peppelinux/ansible-slapd-eduperson2016#debian-10-2447-memory-leakage

Il mar 11 ago 2020, 20:38 Shaheena Kazi  ha
scritto:

> My product is a security product and hence I would like to stick to 2.4.44
> or a version provided by buster i.e., 2.4.47.
>
> May be 2.4.47 is a better option. What do you think?
>
>
>
> On Tue, 11 Aug 2020 at 11:57 PM, Quanah Gibson-Mount 
> wrote:
>
>>
>>
>> --On Wednesday, August 12, 2020 12:43 AM +0530 Shaheena Kazi
>>  wrote:
>>
>> >
>> > Hi Team,
>> >
>> >
>> > I wanted to know if TLSv1.3 is supported on openldap 2.4.44.
>> > openssl packge which I would be using is - openssl-1.1.1d.tar.bz2 to
>> > compile openldap.
>>
>> If you are building OpenLDAP yourself, you should use the most current
>> release, not one that's over four years old.
>>
>> Build OpenLDAP 2.4.50, and it has TLS 1.3 support as long as the SSL
>> library does.
>>
>> Regards,
>> Quanah
>>
>>
>>
>> --
>>
>> Quanah Gibson-Mount
>> Product Architect
>> Symas Corporation
>> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
>> 
>>
> --
> Regards,
> Shaheena K
>

-- 
--

Il banner è generato automaticamente dal servizio di posta elettronica 
dell'Università della Calabria
 

Re: syncrepl does not work as expected

[Giuseppe De Marco]

Ciao kumar,

A fully working example, configurable with ansible with delta syncrepl
ready to go, for studies and prototyping, Is here:

https://github.com/peppelinux/ansible-slapd-eduperson2016

Run as It come in a container, for a replica node see delta repl readme,

Have fun and don't give up

Il lun 15 giu 2020, 21:29 Quanah Gibson-Mount  ha scritto:

>
>
> --On Monday, June 15, 2020 8:05 PM + Kumar Rahul
>  wrote:
>
> > dn: olcDatabase={1}mdb,cn=config
> > objectClass: olcMdbConfig
> > olcDatabase: {1}mdb
> > olcDbDirectory: /usr/local/var/openldap-data/data_db
> > olcSuffix: dc=smartsan
> > olcRootDN: cn=info,dc=data
> > olcAccess: {0}to * by dn.base="cn=info,dc=data" read by * break
>
> Assuming the above is your actual configuration, then..
>
> Your sync replication configuration uses:
>
> binddn="cn=admin,dc=smartsan"
>
> But this identity is given no access to your database, as it's not the
> rootDN, and there are no ACLs providing access to it.
>
> As an aside, your ACL {0} makes no sense since you have cn=info,cn=data as
> your rootdn, and rootdn's are not subject to access control.  The only
> other thing it does is break to the default ACL of to * by * none.
>
> Regards,
> Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> 
>

-- 
--

Il banner è generato automaticamente dal servizio di posta elettronica 
dell'Università della Calabria
 

olcAccess from b64 to plaintext

[Giuseppe De Marco]

Hi guys,
I wrote this simple script to have human readable olaAccess lists
https://github.com/peppelinux/slapd_acl

hope you'll enjoy

-- 

Dott. Giuseppe De Marco
CENTRO ICT DI ATENEO
University of Calabria
87036 Rende (CS) - Italy
Phone: +39 0984 496961
e-mail: giuseppe.dema...@unical.it

-- 
--

Il banner è generato automaticamente dal servizio di posta elettronica 
dell'Università della Calabria
 
<https://www.unical.it/portale/portaltemplates/view/view.cfm?100061>

Re: front end for openldap

[Giuseppe De Marco]

Hi Dieter,

I developed this for my needs:
https://github.com/peppelinux/django-ldap-academia-ou-manager

I think that it could be easily customized by other developers.
It's crafted on Research & Scholarship schemas

Il giorno mar 7 apr 2020 alle ore 11:29 Dieter Klünter 
ha scritto:

> Am Mon, 6 Apr 2020 14:58:07 -0300
> schrieb paulo bruck :
>
> > Hi All
> >
> > I have been using openldap for many years and I would like to thanks
> > to all .
> >
> > Is there a framewok to use with openldap as backend? Preferably based
> > on Python 80)
> >
> > I look at django-ldapdb but project is almost dead and does not have
> > all that I need.
>
>
> openldapjs
> https://github.com/6labs/openldapjs.git
> perl Net::LDAP
> python-ldap
> https://stroeder.com/software.html
>
> -Dieter
> --
> Dieter Klünter | Systemberatung
> http://sys4.de
> GPG Key ID: E9ED159B
> 53°37'09,95"N
> 10°08'02,42"E
>


-- 

Dott. Giuseppe De Marco
CENTRO ICT DI ATENEO
University of Calabria
87036 Rende (CS) - Italy
Phone: +39 0984 496961
e-mail: giuseppe.dema...@unical.it

Re: Openldap support SHA-256 or SHA-3.

[Giuseppe De Marco]

This Is quite cute,
https://github.com/P-H-C/phc-winner-argon2
Regards

Il mer 8 gen 2020, 03:08 Quanah Gibson-Mount  ha scritto:

>
>
> --On Tuesday, January 7, 2020 11:25 PM +0100 Michael Ströder
>  wrote:
>
> > AFAICS RFC 3112 was never implemented in OpenLDAP. Thus I'd consider
> > this to be rather irrelevant here.
>
> Incorrect, it's clearly implemented in slapd.  Whether it's enabled is a
> different question, as it's IFDEF'd behind SLAPD_AUTHPASSWD. ;)
>
> In any case, I've been advocating for several years now to get rid of SSHA
> as the default hashing mechanism and replace it with something that may
> actually have some security value.
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> 
>
>

Re: Openldap support SHA-256 or SHA-3.

[Giuseppe De Marco]

https://sha-mbles.github.io/

Probably it's time to consider the deprecation of SHA1

Il mar 7 gen 2020, 23:28 Michael Ströder  ha scritto:

> On 1/7/20 10:47 PM, Quanah Gibson-Mount wrote:
> > --On Tuesday, January 7, 2020 10:33 PM +0100 Michael Ströder
> >  wrote:
> >
> >> On 1/7/20 9:22 PM, Quanah Gibson-Mount wrote:
> >>> No.  As I said, SHA1 is mandated by RFC.
> >>
> >> Which RFC are you referring to?
> >
> > 
>
> AFAICS RFC 3112 was never implemented in OpenLDAP. Thus I'd consider
> this to be rather irrelevant here.
>
> Ciao, Michael.
>
>

Re: Openldap support SHA-256 or SHA-3.

[Giuseppe De Marco]

Ho

I made SSHA512 as default this way


dn: olcDatabase={-1}frontend,cn=config
replace: olcPasswordHash
olcPasswordHash: SSHA512
EOF

Once pw-sha2 module was loaded


https://github.com/peppelinux/ansible-slapd-eduperson2016/blob/master/roles/slapd_configure/templates/modules/pw-sha2.ldif



Il mar 7 gen 2020, 21:24 Quanah Gibson-Mount  ha scritto:

>
>
> --On Tuesday, January 7, 2020 11:52 AM -0800 rammohan ganapavarapu
>  wrote:
>
> >
> > Quanah,
> >
> >
> > Thanks for the quick reply, is there any plans to make SSHA512 default?
>
> No.  As I said, SHA1 is mandated by RFC.
>
> > also is there any migration steps to move from SHA-1 to SSHA512 ?
>
> After deploying the sha2 module, all users must change their password so
> the hash gets updated.  There is no way to magically convert existing
> hashes from SSHA1 to another scheme.
>
> --Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> 
>
>

Re: Issues with OpenLdap using OpenTLS

[Giuseppe De Marco]

Try to connect to ldaps://localhost:636
Cn must be localhost if that's configured in the certs, but... Are you sure
that localhost should be the fqdn?

Il gio 2 gen 2020, 17:39 Dunne, Kenneth  ha
scritto:

> All
>
>
>
>   I am able to connect to my home-built OpenSSL installation (from Dec-19
> sources) on CentOS-7 without the TLS bind.
>
> I am now trying to use OpenTLS with OpenSSL, which is not currently
> working.  From searching the internet I find this,
>
> Which indicates that maybe RH-based-unixes have unique issues with
> OpenTLS/OpenLdap:
>
>
> https://serverfault.com/questions/437546/centos-openldap-cert-trust-issues
>
>
>
> My slapd.conf now holds (as differs from the default installed slapd.conf)
>
>… snip…
>
> ### TLS
>
> # added per http://www.openldap.org/faq/data/cache/185.html
>
> TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
>
> TLSCertificateFile /usr/local/etc/openldap/servercrt.pem
>
> TLSCertificateKeyFile /usr/local/etc/openldap/serverkey.pem
>
> TLSCipherSuite DES-CBC3-SHA
>
>… snip…
>
>
>
> And my ldap.conf holds:
>
>… snip…
>
> ### TLS
>
> ### TLS
>
> # added per http://www.openldap.org/faq/data/cache/185.html
>
> TLS_CACERT /etc/pki/tls/certs/ca-bundle.crt
>
> ### fails:
>
> ## TLS_CACERT /usr/local/etc/openldap/ cacert.pem
>
>
>
> URI ldaps://localhost:636
>
> ### TLS
>
>… snip…
>
>
>
> …. Having added the ‘cacert.pem’ into the file “
> /etc/pki/tls/certs/ca-bundle.crt”
>
> I get farther in the authentication than using “/usr/local/etc/openldap/
> cacert.pem”:
>
>
>
> [root@kdunne-dev openldap]# /usr/local/bin/ldapsearch -Z -D
> "cn=Manager,dc=my-domain,dc=com" -d -1
>
> ldap_create
>
> ldap_extended_operation_s
>
> ldap_extended_operation
>
> ldap_send_initial_request
>
> ldap_new_connection 1 1 0
>
> ldap_int_open_connection
>
> ldap_connect_to_host: TCP localhost:636
>
> ldap_new_socket: 3
>
> ldap_prepare_socket: 3
>
> ldap_connect_to_host: Trying ::1 636
>
> ldap_pvt_connect: fd: 3 tm: -1 async: 0
>
> attempting to connect:
>
> connect errno: 111
>
> ldap_close_socket: 3
>
> ldap_new_socket: 3
>
> ldap_prepare_socket: 3
>
> ldap_connect_to_host: Trying 127.0.0.1:636
>
> ldap_pvt_connect: fd: 3 tm: -1 async: 0
>
> attempting to connect:
>
> connect success
>
> TLS trace: SSL_connect:before/connect initialization
>
> tls_write: want=289, written=289
>
>   :  16 03 01 01 1c 01 00 01  18 03 03 51 03 78 81 fc
> ...Q.x..
>
>   0010:  66 89 9c 91 10 b6 e9 3d  f1 12 66 27 c7 f5 80 e4
> f..=..f'
>
>   0020:  fb f6 5f 9d f8 bb 37 3b  84 cb 17 00 00 ac c0 30
> .._...7;...0
>
>   0030:  c0 2c c0 28 c0 24 c0 14  c0 0a 00 a5 00 a3 00 a1
> .,.(.$..
>
>   0040:  00 9f 00 6b 00 6a 00 69  00 68 00 39 00 38 00 37
> ...k.j.i.h.9.8.7
>
>   0050:  00 36 00 88 00 87 00 86  00 85 c0 32 c0 2e c0 2a
> .6.2...*
>
>   0060:  c0 26 c0 0f c0 05 00 9d  00 3d 00 35 00 84 c0 2f
> .&...=.5.../
>
>   0070:  c0 2b c0 27 c0 23 c0 13  c0 09 00 a4 00 a2 00 a0
> .+.'.#..
>
>   0080:  00 9e 00 67 00 40 00 3f  00 3e 00 33 00 32 00 31   ...g.@.?.>.3.2.1
>
>
>   0090:  00 30 00 9a 00 99 00 98  00 97 00 45 00 44 00 43
> .0.E.D.C
>
>   00a0:  00 42 c0 31 c0 2d c0 29  c0 25 c0 0e c0 04 00 9c
> .B.1.-.).%..
>
>   00b0:  00 3c 00 2f 00 96 00 41  c0 12 c0 08 00 16 00 13
> .<./...A
>
>   00c0:  00 10 00 0d c0 0d c0 03  00 0a 00 07 c0 11 c0 07
> 
>
>   00d0:  c0 0c c0 02 00 05 00 04  00 ff 01 00 00 43 00 0b
> .C..
>
>   00e0:  00 04 03 00 01 02 00 0a  00 0a 00 08 00 17 00 19
> 
>
>   00f0:  00 18 00 16 00 23 00 00  00 0d 00 20 00 1e 06 01   .#.
> 
>
>   0100:  06 02 06 03 05 01 05 02  05 03 04 01 04 02 04 03
> 
>
>   0110:  03 01 03 02 03 03 02 01  02 02 02 03 00 0f 00 01
> 
>
>   0120:  01
> .
>
> TLS trace: SSL_connect:SSLv2/v3 write client hello A
>
> tls_read: want=7, got=0
>
>
>
> TLS: can't connect: .
>
> ldap_err2string
>
> ldap_start_tls: Can't contact LDAP server (-1)
>
> ldap_sasl_bind
>
> ldap_send_initial_request
>
> ldap_send_server_request
>
> ldap_err2string
>
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>
>
>
>
>
>
>
> Additionally:
>
>
>
> I am reading the FAQ http://www.openldap.org/faq/data/cache/185.html to
> generate the certs
>
> but am wondering if I am correctly understanding the instruction “Remember
> that the Common Name for this cert should be the fully qualified domain
> name of the server:”
>
> If I run my ldap server as:
>
> /usr/local/libexec/slapd -F /usr/local/etc/openldap/slapd.d -h
> 'ldaps://127.0.0.1:636 ldap://127.0.0.1:389' -d -1
>
> Then would the ‘common name’ for use in the certificate be:
>
> cn=localhost:636
>
>
>
> Any assistance is greatly appreciated.
>
> Thanks!
>
> Ken Dunne
>
>
>
>
>
>
>

Re: slapd-sock as overlay

[Giuseppe De Marco]

Probably that error is something regarding socket read/write permissions

Il giorno gio 5 set 2019 alle ore 17:14 Giuseppe De Marco <
giuseppe.dema...@unical.it> ha scritto:

> Hi Shiva,
>
> Here you should find what you're looking for:
> https://github.com/peppelinux/pyMultiLDAP
>
> Il giorno gio 5 set 2019 alle ore 17:10 Shiva Prasad Thagadur Prakash <
> shivaprasad...@gmail.com> ha scritto:
>
>> 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
>>
>
>
> --
> 
> Dott. Giuseppe De Marco
> CENTRO ICT DI ATENEO
> University of Calabria
> 87036 Rende (CS) - Italy
> Phone: +39 0984 496961
> e-mail: giuseppe.dema...@unical.it
>


-- 

Dott. Giuseppe De Marco
CENTRO ICT DI ATENEO
University of Calabria
87036 Rende (CS) - Italy
Phone: +39 0984 496961
e-mail: giuseppe.dema...@unical.it

Re: slapd-sock as overlay

[Giuseppe De Marco]

Hi Shiva,

Here you should find what you're looking for:
https://github.com/peppelinux/pyMultiLDAP

Il giorno gio 5 set 2019 alle ore 17:10 Shiva Prasad Thagadur Prakash <
shivaprasad...@gmail.com> ha scritto:

> 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
>


-- 

Dott. Giuseppe De Marco
CENTRO ICT DI ATENEO
University of Calabria
87036 Rende (CS) - Italy
Phone: +39 0984 496961
e-mail: giuseppe.dema...@unical.it

Re: Socat tcp to local socket

[Giuseppe De Marco]

Hi Marc,
Slapd-proxy or slapd-meta could be the solution

Il dom 25 ago 2019, 14:42 Marc Roos  ha scritto:

>
> Anyone having some experience using socat (or something similar?) to
> connect to a remote slapd server tcp/tls with a local socket? I have a
> client that requires the local ldapi socket. But I do not want to
> install there an instance of slapd.
>
>
>
>
>
>
>

Re: Environment variable in slapd config

[Giuseppe De Marco]

Il ven 16 ago 2019, 12:20 Michael Ströder  ha scritto:

> On 8/16/19 12:02 PM, Marc Roos wrote:
> > Is it possible to reference an environment variable in olcSyncrepl:
> > {0}rid= ?
>
> No.
>
> My recommendation is to use a decent config managment (ansible, chef,
> puppet, salt, ..) for the job.
>

I agree, I made this ansible playbook with also a delta-syncrepl
configuration (see readme.delta-syncrepl.md)

https://github.com/peppelinux/ansible-slapd-eduperson2016

If someone want to contribute or change, suggest, share something, I'll
accept contributions and ideas.

Cheers

>

Re: slapd-sock v2.4.47 not returning LDIF

[Giuseppe De Marco]

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:/// < 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.
>
>

-- 

Dott. Giuseppe De Marco
CENTRO ICT DI ATENEO
University of Calabria
87036 Rende (CS) - Italy
Phone: +39 0984 496961
e-mail: giuseppe.dema...@unical.it

slapd-sock v2.4.47 not returning LDIF

[Giuseppe De Marco]

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:/// < 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/searchexample.pl

-- 

Dott. Giuseppe De Marco
CENTRO ICT DI ATENEO
University of Calabria
87036 Rende (CS) - Italy
Phone: +39 0984 496961
e-mail: giuseppe.dema...@unical.it

Re: slapd-sock v2.4.47 not returning LDIF

[Giuseppe De Marco]

Il giorno gio 25 lug 2019 alle ore 11:31 Giuseppe De Marco <
giuseppe.dema...@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  
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.

Re: ldapdelete: Invalid DN on an Accesslog generated DN

[Giuseppe Civitella]

Ciao, Michael,

Yes, it is a slapcat output and it is filtered: BASEDN is just a
replacement.
I had to remove slapo-accesslog because I was unable to login to the server
anymore. So properly delete these entries was not an option for me.
This is the origin of the problem.

Thanks,
Giuseppe

2018-05-17 10:57 GMT+02:00 Michael Ströder <mich...@stroeder.com>:

> Giuseppe Civitella wrote:
> > while doing some tests to enable accesslog in my directory, I did enable
> the
> > overlay and then disabled it because of login problems.
>
> I doubt that you had login problems caused by slapo-accesslog.
>
> > Once restored the directory, I found a few entries like this:
> >
> > dn: reqStart=20180509102412.00Z,BASEDN
> > objectClass: auditModify
> > structuralObjectClass: auditModify
> > REQSTART: 20180509102412.00Z
> > REQEND: 20180509102412.01Z
> > REQTYPE: modify
>
> Is this slapcat output? Did you obfuscate your e-mail with "BASEDN"?
>
> Note that removing slapo-accesslog also removed the object class and
> attribute type descriptions from your subschema. Typically slapcat
> outputs names of attribute types missing in subschema all with capital
> letters.
>
> > deleting entry "reqStart=20180509102412.00Z,BASEDN"
> > ldap_delete: Invalid DN syntax (34)
> > additional info: invalid DN
>
> OpenLDAP server checks schema even for DNs. Hence a DN containing
> 'reqStart' is an invalid DN if you don't have slapo-accesslog loaded.
>
> Ciao, Michael.
>
>

ldapdelete: Invalid DN on an Accesslog generated DN

[Giuseppe Civitella]

Hi all,

while doing some tests to enable accesslog in my directory, I did enable the 
overlay and then disabled it because of login problems.
Once restored the directory, I found a few entries like this:

dn: reqStart=20180509102412.00Z,BASEDN
objectClass: auditModify
structuralObjectClass: auditModify
REQSTART: 20180509102412.00Z
REQEND: 20180509102412.01Z
REQTYPE: modify
REQSESSION: 1679
REQAUTHZID: cn=admin,BASEDN
REQDN: cn=gcivitella,ou=users,BASEDN
REQRESULT: 0
REQMOD: description:= description utente gcivitella (update check accesslog)
REQMOD: entryCSN:= 20180509102412.246481Z#00#000#00
REQMOD: modifiersName:= cn=admin,BASEDN
REQMOD: modifyTimestamp:= 20180509102412Z
REQENTRYUUID: 53620528-9276-1037-8c51-e5b01d96303b
entryUUID: dc744658-e7be-1037-9c6f-71aa77ba1fb3
creatorsName: cn=admin,BASEDN
createTimestamp: 20180509102412Z
entryCSN: 20180509102412.246481Z#00#000#00
modifiersName: cn=admin,BASEDN
modifyTimestamp: 20180509102412Z

Now I'm unable to delete them. I get an "invalid DN" error:

ldapdelete -D "cn=admin,BASEDN" -W -H ldap://127.0.0.1 -v 
"reqStart=20180509102412.00Z,BASEDN"

ldap_initialize( ldap://127.0.0.1:389/??base )
Enter LDAP Password: 
deleting entry "reqStart=20180509102412.00Z,BASEDN"
ldap_delete: Invalid DN syntax (34)
additional info: invalid DN

Is there a way to force the deletion or temporary disable the schema check?

Best regards,
Giuseppe

ldapdelete: Invalid DN on an Accesslog generated DN

[Giuseppe Civitella]

Hi all,

while doing some tests to enable accesslog in my directory, I did enable the 
overlay and then disabled it because of login problems.
Once restored the directory, I found a few entries like this:

dn: reqStart=20180509102412.00Z,BASEDN
objectClass: auditModify
structuralObjectClass: auditModify
REQSTART: 20180509102412.00Z
REQEND: 20180509102412.01Z
REQTYPE: modify
REQSESSION: 1679
REQAUTHZID: cn=admin,BASEDN
REQDN: cn=gcivitella,ou=users,BASEDN
REQRESULT: 0
REQMOD: description:= description utente gcivitella (update check accesslog)
REQMOD: entryCSN:= 20180509102412.246481Z#00#000#00
REQMOD: modifiersName:= cn=admin,BASEDN
REQMOD: modifyTimestamp:= 20180509102412Z
REQENTRYUUID: 53620528-9276-1037-8c51-e5b01d96303b
entryUUID: dc744658-e7be-1037-9c6f-71aa77ba1fb3
creatorsName: cn=admin,BASEDN
createTimestamp: 20180509102412Z
entryCSN: 20180509102412.246481Z#00#000#00
modifiersName: cn=admin,BASEDN
modifyTimestamp: 20180509102412Z

Now I'm unable to delete them. I get an "invalid DN" error:

ldapdelete -D "cn=admin,BASEDN" -W -H ldap://127.0.0.1 -v  
"reqStart=20180509102412.00Z,BASEDN"
ldap_initialize( ldap://127.0.0.1:389/??base )
Enter LDAP Password: 
deleting entry "reqStart=20180509102412.00Z,BASEDN"
ldap_delete: Invalid DN syntax (34)
additional info: invalid DN

Is there a way to force the deletion or temporary disable the schema check?

Best regards,
Giuseppe

Acl on a replicated tree: unable to bind as user

[Giuseppe Civitella]

Hi all,

I've got a master / slave replica setup. I did use this tutorial to set
up the replica:

https://wiki.debian.org/LDAP/OpenLDAPSetup

My ldap tree is something like: Root -> o=(first level local branch),
o=(first level replicated branch).

The local branch is just a cut and paste of the replicated branch.

On the slave server I can use the replicated branch to authenticate
against a Radius server.

On the master server I realized I cannot let web users authenticate
against the replicated branch.

If I try to bind as a user from the replicated branch, on both the
master and the slave, I get:

ldapwhoami -H ldap://localhost -D
"uid=gcivitella,ou=users,o=isiline,dc=who,dc=is" -W

Enter LDAP Password:
ldap_bind: Invalid credentials (49)

On the master, on the local branch, I get:

ldapwhoami -H ldap://localhost -D
"cn=gcivitella,ou=users,o=area51,dc=who,dc=is" -W

Enter LDAP Password:
dn:cn=gcivitella,ou=users,o=area51,dc=who,dc=is


I did try to configure the acl on the server to disallow anonymous bind.

And, once found this problem, I did try to create a bind user
(uid=read_only) able to read the replicated branch, userPassword attrs
included.

Unfortunately this did not solve the problem.

My acl on the master are:

dn: olcDatabase={1}mdb
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=who,dc=is
olcAccess: {0}to dn.subtree="o=isiline,dc=who,dc=is" by dn="uid=read_only,ou
 =binds,dc=who,dc=is" read
olcAccess: {1}to dn.subtree="o=isiline,dc=who,dc=is" by dn="uid=isi_replica,
 ou=binds,dc=who,dc=is" read
olcAccess: {2}to attrs=userPassword by self write by anonymous auth by * non
 e
olcAccess: {3}to attrs=shadowLastChange by self write by * read
olcAccess: {4}to * by users read


I'm quite new to this kind of setup, is this something to be expected?
Is there a way to bind directly on the replicated branch?

Regards,
Giuseppe