openldap-bugs August 2021

openldap-bugs@openldap.org

1 participants
254 discussions

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 31 Aug '21

31 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=6949 --- Comment #7 from Ondřej Kuzník <ondra(a)mistotebe.net> --- It seems this is limited to slapd main.c so a standalone lloadd keeps the original logging configuration/code/format. Maybe the logging code could move to a separate file so it can be shared between the two. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9657] New: Different access privileges required for SIMPLE BIND (attr: userPassword) and SASL BIND (whole entry)
by openldap-its＠openldap.org 31 Aug '21

31 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9657 Issue ID: 9657 Summary: Different access privileges required for SIMPLE BIND (attr: userPassword) and SASL BIND (whole entry) Product: OpenLDAP Version: 2.5.6 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- I configure a database with: dn: cn=config objectClass: olcGlobal cn: config olcAuthzRegexp: uid=([^@,]+)(@aegee.org)?(,cn=aegee.org)?,cn=[^,]*,cn=auth uid=$1,ou=persons,o=AEGEE olcSaslSecProps: none ####################################################################### # LMDB database definitions ####################################################################### # dn: olcDatabase=mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcDbMaxSize: 10485760 olcSuffix: o=AEGEE olcRootDN: uid=zzz,ou=persons,o=AEGEE olcRootPW: zzz olcDbDirectory: /home/d/ldap/aegee olcDbIndex: objectClass eq olcAccess: to dn.one="ou=persons,o=AEGEE" attrs=userPassword by anonymous auth olcAccess: to dn.one="ou=persons,o=AEGEE" by self read fill the database with /usr/local/bin/ldapadd -x -w zzz -D "uid=zzz;ou=persons;o=AEGEE" -H ldap://localhost <<ABC dn:o=AEGEE o:AEGEE objectClass:organization telephoneNumber:+32 2 246 0320 street:Rue du Noyer / Notelaarsstraat 55 st:Brussels postalAddress:Rue du Noyer / Notelaarsstraat 55, 1000 Brussels, Belgium dn:ou=persons,o=AEGEE objectClass:organizationalUnit description:AEGEE members (persons) with account at https://my.aegee.eu/ dn: uid=lui.veve,ou=persons,o=AEGEE objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson sn: Veve cn: Lui Veve uid: lui.veve employeeNumber: 444 givenName: Lui mail: lui.veve@zzzz userPassword:: dXAx structuralObjectClass: inetOrgPerson ABC Its content is ( slapcat -n1 -F conf/ ) ---- dn: o=AEGEE o: AEGEE objectClass: organization telephoneNumber: +32 2 246 0320 street: Rue du Noyer / Notelaarsstraat 55 st: Brussels postalAddress: Rue du Noyer / Notelaarsstraat 55, 1000 Brussels, Belgium structuralObjectClass: organization entryUUID: 223703d3-812e-405c-b57e-4233b55847c3 creatorsName: uid=zzz,ou=persons,o=AEGEE createTimestamp: 20210830161645Z entryCSN: 20210830161645.797291Z#000000#000#000000 modifiersName: uid=zzz,ou=persons,o=AEGEE modifyTimestamp: 20210830161645Z dn: ou=persons,o=AEGEE objectClass: organizationalUnit description: AEGEE members (persons) with account at https://my.aegee.eu/ structuralObjectClass: organizationalUnit ou: persons entryUUID: 17f8ff72-250b-4cbd-873f-340aaed2f0d9 creatorsName: uid=zzz,ou=persons,o=AEGEE createTimestamp: 20210830161645Z entryCSN: 20210830161645.802430Z#000000#000#000000 modifiersName: uid=zzz,ou=persons,o=AEGEE modifyTimestamp: 20210830161645Z dn: uid=lui.veve,ou=persons,o=AEGEE objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson sn: Veve cn: Lui Veve uid: lui.veve employeeNumber: 444 givenName: Lui mail:: bHVpLnZldmVAenp6eiA= userPassword:: dXAx structuralObjectClass: inetOrgPerson entryUUID: 2e37d641-6865-4a08-87f9-b12653f52d12 creatorsName: uid=zzz,ou=persons,o=AEGEE createTimestamp: 20210830161645Z entryCSN: 20210830161645.806532Z#000000#000#000000 modifiersName: uid=zzz,ou=persons,o=AEGEE modifyTimestamp: 20210830161645Z ---- When I try to authenticate with SIMPLE BIND, OpenLDAP requests only access to the userPassword attribute: ldapwhoami -x -D "uid=lui.veve;ou=persons;o=AEGEE" -v -w up1 -H ldap://localhost/ logs: 612d04f3.27f67994 0x7f50731ac640 <= ldap_dn2bv(uid=lui.veve,ou=persons,o=AEGEE)=0 612d04f3.27f6a83b 0x7f50731ac640 => ldap_dn2bv(272) 612d04f3.27f6cbf9 0x7f50731ac640 <= ldap_dn2bv(uid=lui.veve,ou=persons,o=aegee)=0 612d04f3.27f6e92a 0x7f50731ac640 <<< dnPrettyNormal: <uid=lui.veve,ou=persons,o=AEGEE>, <uid=lui.veve,ou=persons,o=aegee> 612d04f3.27f7035b 0x7f50731ac640 conn=1001 op=0 BIND dn="uid=lui.veve,ou=persons,o=AEGEE" method=128 612d04f3.27f744d5 0x7f50731ac640 do_bind: version=3 dn="uid=lui.veve,ou=persons,o=AEGEE" method=128 612d04f3.27f77c7c 0x7f50731ac640 ==> mdb_bind: dn: uid=lui.veve,ou=persons,o=AEGEE 612d04f3.27f82a00 0x7f50731ac640 mdb_dn2entry("uid=lui.veve,ou=persons,o=aegee") 612d04f3.27f847bd 0x7f50731ac640 => mdb_dn2id("uid=lui.veve,ou=persons,o=aegee") 612d04f3.27f8a6f4 0x7f50731ac640 <= mdb_dn2id: got id=0x3 612d04f3.27f916cf 0x7f50731ac640 => mdb_entry_decode: 612d04f3.27f942bb 0x7f50731ac640 <= mdb_entry_decode 612d04f3.27f96490 0x7f50731ac640 => access_allowed: result not in cache (userPassword) 612d04f3.27f97b35 0x7f50731ac640 => access_allowed: auth access to "uid=lui.veve,ou=persons,o=AEGEE" "userPassword" requested 612d04f3.27f9ab7f 0x7f50731ac640 => dn: [1] ou=persons,o=aegee 612d04f3.27f9ccc7 0x7f50731ac640 => acl_get: [1] matched 612d04f3.27f9ddb2 0x7f50731ac640 => acl_get: [1] attr userPassword 612d04f3.27f9f63f 0x7f50731ac640 => acl_mask: access to entry "uid=lui.veve,ou=persons,o=AEGEE", attr "userPassword" requested 612d04f3.27fa0913 0x7f50731ac640 => acl_mask: to value by "", (=0) 612d04f3.27fa24a1 0x7f50731ac640 <= check a_dn_pat: anonymous 612d04f3.27fa492f 0x7f50731ac640 <= acl_mask: [1] applying auth(=xd) (stop) 612d04f3.27fa5bbd 0x7f50731ac640 <= acl_mask: [1] mask: auth(=xd) 612d04f3.27fa721c 0x7f50731ac640 => slap_access_allowed: auth access granted by auth(=xd) 612d04f3.27fa8306 0x7f50731ac640 => access_allowed: auth access granted by auth(=xd) 612d04f3.27fa9f20 0x7f50731ac640 conn=1001 op=0 BIND dn="uid=lui.veve,ou=persons,o=AEGEE" mech=SIMPLE bind_ssf=0 ssf=0 612d04f3.27fb0385 0x7f50731ac640 do_bind: v3 bind: "uid=lui.veve,ou=persons,o=AEGEE" to "uid=lui.veve,ou=persons,o=AEGEE" When I try to SASL connect, then OpenLDAP requests access to the whole uid=lui.veve,ou=persons,o=AEGEE entry: ldapwhoami -Y LOGIN -U"lui.veve" -v -w up1 -H ldap://localhost/ logs: 612d053d.03ab64b8 0x7f50731ac640 => ldap_bv2dn(uid=lui.veve,ou=persons,o=AEGEE,0) 612d053d.03abb462 0x7f50731ac640 <= ldap_bv2dn(uid=lui.veve,ou=persons,o=AEGEE)=0 612d053d.03abddda 0x7f50731ac640 => ldap_dn2bv(272) 612d053d.03abf0ad 0x7f50731ac640 <= ldap_dn2bv(uid=lui.veve,ou=persons,o=aegee)=0 612d053d.03ac070c 0x7f50731ac640 <<< dnNormalize: <uid=lui.veve,ou=persons,o=aegee> 612d053d.03ac2626 0x7f50731ac640 <==slap_sasl2dn: Converted SASL name to uid=lui.veve,ou=persons,o=aegee 612d053d.03ac68fe 0x7f50731ac640 slap_sasl_getdn: dn:id converted to uid=lui.veve,ou=persons,o=aegee 612d053d.03ac82e9 0x7f50731ac640 SASL Canonicalize [conn=1002]: slapAuthcDN="uid=lui.veve,ou=persons,o=aegee" 612d053d.03acd965 0x7f50731ac640 => mdb_search 612d053d.03ada119 0x7f50731ac640 mdb_dn2entry("uid=lui.veve,ou=persons,o=aegee") 612d053d.03adcf7a 0x7f50731ac640 => mdb_dn2id("uid=lui.veve,ou=persons,o=aegee") 612d053d.03ae10f4 0x7f50731ac640 <= mdb_dn2id: got id=0x3 612d053d.03ae33e0 0x7f50731ac640 => mdb_entry_decode: 612d053d.03ae6313 0x7f50731ac640 <= mdb_entry_decode 612d053d.03ae845b 0x7f50731ac640 => access_allowed: auth access to "uid=lui.veve,ou=persons,o=AEGEE" "entry" requested 612d053d.03aea02f 0x7f50731ac640 => dn: [1] ou=persons,o=aegee 612d053d.03aeba1a 0x7f50731ac640 => acl_get: [1] matched 612d053d.03aed0bf 0x7f50731ac640 => dn: [2] ou=persons,o=aegee 612d053d.03aee392 0x7f50731ac640 => acl_get: [2] matched 612d053d.03aef47c 0x7f50731ac640 => acl_get: [2] attr entry 612d053d.03af0c39 0x7f50731ac640 => acl_mask: access to entry "uid=lui.veve,ou=persons,o=AEGEE", attr "entry" requested 612d053d.03af2f6a 0x7f50731ac640 => acl_mask: to all values by "", (=0) 612d053d.03af45c9 0x7f50731ac640 <= check a_dn_pat: self 612d053d.03af513f 0x7f50731ac640 <= acl_mask: no more <who> clauses, returning =0 (stop) 612d053d.03af626f 0x7f50731ac640 => slap_access_allowed: auth access denied by =0 612d053d.03af7a71 0x7f50731ac640 => access_allowed: no more rules This is inconsistent. SASL bind shall also request only AUTH access to the userPassword, just as SIMPLE BIND does. Moreover, https://www.openldap.org/doc/admin25/access-control.html#Basic%20ACLs does suggest: Generally one should start with some basic ACLs such as: access to attrs=userPassword by self =xw by anonymous auth by * none access to * by self write by users read by * none So the suggestion is to grant "by anonymous auth" access only to attrs=userPassword , before granting any other access. If I change to olcAccess: to dn.one="ou=persons,o=AEGEE" by self read by anonymous auth then both SASL BIND and SIMPLE BIND work. Version 2.5.7-g22d1c5954e8629b. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9655] New: Expose the SNI hostname to olcAccess
by openldap-its＠openldap.org 30 Aug '21

30 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9655 Issue ID: 9655 Summary: Expose the SNI hostname to olcAccess Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- Since OpenLDAP now supports SNI, it apparently knows to which Host the client has connected, when the server is reachable under many names. • Expose the negotiated hostname to oclAccess and provide example how to limit the namingContext on the root DSE based on the requested host Rationale: HTTP servers offer the concept of virtual domains, where they serve different content behind the same IP, based on the Host: header. I want to offer public, anonymous LDAP access, but the returned results shall be completely different, and depend on the contacted host. The statements in the <WHO> field peername=<peername>, sockname=<sockname>, domain=<domain>, and sockurl=<sockurl> are evaluated only based on the contacting system (do not depend on the requested domain). (Maybe the “contacting sockurl” can do this, but this is not very clear from the documentation). So they serve similar purpose, but ignore SNI. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9654] New: Allow using both Elliptic curves and RSA certificate
by openldap-its＠openldap.org 30 Aug '21

30 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9654 Issue ID: 9654 Summary: Allow using both Elliptic curves and RSA certificate Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- sendmail and Cyrus IMAP allow to set two TLS server certificates -one RSA and EC. When the client supports Elliptic curves, the smaller EC certificate is used. Likewise it accepts two private keys, in case the private key is not included in the certificate file. In sendmail and Cyrus IMAP, two certificates are set in the same directive, separated with comma: define(`confSERVER_CERT', `/etc/zzz/fullchain.pem,/etc/zzz/fullchain_ec.pem') define(`confSERVER_KEY', `/etc/zzz/privkey.pem,/etc/zzz/privkey_ec.pem') In Cyrus IMAP the code dealing with this for OpenSSL is at https://github.com/cyrusimap/cyrus-imapd/blob/master/imap/tls.c#L453 : cf1/kf1 is the fist public/private key, cf2/kf2 are the second. In sendmail the code is in sendmail/tls.c:inittls() - it calls SSL_CTX_use_PrivateKey_file twice - once with keyfile and once with kf2 (keyfile 2). • Extend OpenLDAP to accept several certificates (RSA/EC) - either per permitting several (comma separated) values in olcTLSCertificateFile/olcTLSCertificateKeyFile , or by allowing several occurrences of the property. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9587] New: Admin guide: Need example partial replication configuration
by openldap-its＠openldap.org 27 Aug '21

27 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9587 Issue ID: 9587 Summary: Admin guide: Need example partial replication configuration Product: OpenLDAP Version: 2.5.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The admin guide states: Syncrepl supports partial, sparse, and fractional replications but there are no example configurations for partial replication to draw from. This needs to be added to the guide. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9156] latest ppolicy draft support
by openldap-its＠openldap.org 26 Aug '21

26 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9156 --- Comment #13 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • c4d399c2 by Quanah Gibson-Mount at 2021-08-26T15:43:24+00:00 ITS#9156 - Remove ppolicy.schema from README Also remove nadf.schema, that got removed some time long ago -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8862] typos manual slapd-mdb
by openldap-its＠openldap.org 26 Aug '21

26 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=8862 --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to Quanah Gibson-Mount from comment #6) > (In reply to dpa-openldap(a)aegee.org from comment #5) > > For me “as large a value as possible…” sounds without “a” better. > > Then it would no longer be grammatically correct. > > "as large a value as possible" is correct. An alternative way to phrase it would be "as large of a value as possible", but both are correct statements. "as large value as possible" is not a correct statement in any form in this context. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8862] typos manual slapd-mdb
by openldap-its＠openldap.org 26 Aug '21

26 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=8862 --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to dpa-openldap(a)aegee.org from comment #5) > For me “as large a value as possible…” sounds without “a” better. Then it would no longer be grammatically correct. "as large a value as possible" is correct. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8862] typos manual slapd-mdb
by openldap-its＠openldap.org 26 Aug '21

26 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=8862 --- Comment #5 from dpa-openldap(a)aegee.org <dpa-openldap(a)aegee.org> --- For me “as large a value as possible…” sounds without “a” better. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8862] typos manual slapd-mdb
by openldap-its＠openldap.org 26 Aug '21

26 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=8862 --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to dpa-openldap(a)aegee.org from comment #3) > How about this sentence: > > > It is important to set this to as large a value as possible… What about it? It's a correct statement. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
26
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2021