openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

ITS#9080 a further relevant ITS
by Norman.Gray＠glasgow.ac.uk 14 Sep '19

14 Sep '19

I should also note that ITS#4996 (2007, closed) appears to be the issue=20 which resulted in the support for `-H "<proto>:///DN"` being added to=20 the command-line clients. --=20 Norman Gray : https://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK

1 0

(ITS#9080) Feature request: support DNS SRV lookups in ldap.conf
by gray＠nxg.name 14 Sep '19

14 Sep '19

Full_Name: Norman Gray Version: 2.4.47 OS: FreeBSD 12.0 (but not OS-soecific) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:8b0:df5:af53:c1a5:cbb2:6a6a:3390) Feature request: support specification of DNS SRV records in ldap.conf, matching ldapsearch -H The `ldapsearch` tools supports specifying lookups of SRV records via a special case syntax in the argument to the `-H` option. A URI such as ldap:///dc=ldap,dc=example,dc=com (with the commas and equals signs suitably escaped) prompts ldapsearch to do a lookup of an SRV record for ldap.example.com. However the URI synatx in ldap.conf doesn't have a corresponding special case, so it's not possible to put such a spec in a ldap.conf file. The ldap.conf documentation doesn't claim any support for SRV records, so there isn't a bug here, but on a Principle of Least Astonishment it would be very useful if the same syntax that -H respects were respected by ldap.conf as well. Other LDAP clients have different ways of specifying this (eg, nslcd.conf supports a `DNS:<domain>` syntax; Linux automount's `autofs.conf` has a `ldap_uri` attribute which supports a very similar dc=xxx syntax), so an alternative ldap.conf syntax would be a good second best. As an auxiliary point, when `ldapsearch` sees `URI ldap:///dc%3D...` in the ldap.conf file, it silently ignores it, rather than producing an error. It doesn't even produce a warning when `ldapsearch` is invoked with `-d-1`. I had to use strace to reassure myself that the config file was actually being read. I feel that a library should make a _lot_ more noise about an attribute in a configuration file being seen but ignored (I can see that the `ldap://dc...` URI, which is of course syntactically OK, _might_ be inadvertently meaningful, and thus not necessarily a detectable error, but even in that case `-d-1` should produce _something_). A scan through ITS reports found the following: * ITS#5919 (2009, still open) discusses a similar request, and discusses a variety of issues with it. This is a useful cross-reference. * ITS#6462 (2010, open) and ITS#8610 (2017, open) both touch on SRV records, but aren't particularly relevant, since they're both about the handling of ldaps:// URIs specifying a SRV record. * ITS#7027 (2011, closed) and ITS#8196 (open) are concerned with the internal handling of SRV records, but not their configuration $ ldapsearch -VV ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.47 (Jul 25 2019 01:30:14) $ root@120amd64-quarterly-job-16:/wrkdirs/usr/ports/net/openldap24-sasl-client/work/openldap-2.4.47/clients/tools (LDAP library: OpenLDAP 20447)

1 0

Re: (ITS#9079 documentation: slapo-unique syntax explanation unclear
by quanah＠symas.com 13 Sep '19

13 Sep '19

--On Friday, September 13, 2019 6:07 PM +0000 gray(a)nxg.name wrote: > Full_Name: Norman Gray > Version: 2.4.48 > OS: FreeBSD 12.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.209.45.140) Note: this is now ITS#9079. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#9078) Indices MDB
by quanah＠symas.com 13 Sep '19

13 Sep '19

--On Friday, September 13, 2019 5:54 PM +0000 dpa-openldap(a)aegee.org wrote: Hello, The ITS system is for bug reports, not usage questions. Please redirect your questions to the openldap-technical(a)openldap.org mailing list. This ITS will be closed. <https://www.openldap.org/lists/mm/listinfo/openldap-technical> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#9077) slapo-unique spins its wheels on a non-trivial olcUniqueURI spec
by quanah＠symas.com 13 Sep '19

13 Sep '19

--On Friday, September 13, 2019 4:34 PM +0000 gray(a)nxg.name wrote: > Full_Name: Norman Gray > Version: 2.4.48 > OS: FreeBSD 12.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.209.45.140) Unrelated side note, ITS number fixed to be 9077. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9488) documentation: slapo-unique syntax explanation unclear
by gray＠nxg.name 13 Sep '19

13 Sep '19

Full_Name: Norman Gray Version: 2.4.48 OS: FreeBSD 12.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.209.45.140) Documentation bug The documentation for the `unique_uri` or `olcUniqueURI` attribute is very compact, with the result that it is not clear what counts as correct syntax, nor what are the semantics of the specification. I'm not suggesting that the text is necessarily _inaccurate_, but that it is too brief. That is, someone who already understand the syntax and semantics will probably not notice anything wrong with this paragraph; someone who doesn't already understand (eg, me) will struggle. slapo-unique(5) says that the syntax here is: unique_uri <[strict ][ignore ]URI[URI...]...> Configure the base, attributes, scope, and filter for uniqueness checking. Multiple URIs may be specified within a domain, allowing complex selections of objects. Multiple unique_uri statements or olcUniqueURI attributes will create independent domains, each with their own independent lists of URIs and ignore/strict settings. Keywords strict and ignore have to be enclosed in quotes (") together with the URI. The LDAP URI syntax is a subset of RFC-4516, and takes the form: ldap:///[base dn]?[attributes...]?scope[?filter] I understand from this text the following: * One can specify multiple URIs in the value of a olcUniqueURI attribute. I _guess_ these can be space-separated, even though that isn't shown in this syntax. * Each URI defines a set of object attributes * One can have multiple olcUniqueURI attributes, _each of which_ creates a 'domain' * This doesn't say what a 'domain' is, but I _guess_ that it means that all of the attributes which match the search are forced, by this overlay, to be unique, but that there are no mutual uniqueness requirements between separate olcUniqueURI/'domain' specifications * If multiple URIs are specified in a 'domain', or olcUniqueURI attribute, then (wild guess) the union of the attributes matched by each URI is unique; I doubt it means the intersection of the result sets (I guess that because that's the only thing that sounds sensible; the phrase 'complex selections of objects' doesn't clarify) * It's not clear where the quotes go, when combining with 'strict' or 'ignore' (I guess "strict ldap://..."). * Can 'strict' or 'ignore' be combined with the second or subsequent URIs? The syntax suggests not. I don't think the above understanding is correct, because when I specify a olcUniqueURI attribute with multiple URIs, I get an error (see ITS#9486 and thread <https://www.openldap.org/lists/openldap-technical/201909/msg00031.html>). At any rate, I have little confidence that I have interpreted the text correctly, and the above is the result of several careful readings and some guesswork. If the above, or something like it, is roughly correct, I could draft an alternative paragraph, if that would be useful. If the manpage included more than one example, that would be _extremely_ useful. I'll mention in passing that in servers/slapd/overlays/unique.c, the comment above `unique_new_domain` says instead * domain_specs look like * * [strict ][ignore ]uri[[ uri]...] * e.g. "ldap:///ou=foo,o=bar?uid?sub ldap:///ou=baz,o=bar?uid?sub" * "strict ldap:///ou=accounts,o=bar?uid,uidNumber?one" * etc

1 0

(ITS#9487) Indices MDB
by dpa-openldap＠aegee.org 13 Sep '19

13 Sep '19

Full_Name: &#1044;&#1080;&#1083;&#1103;&#1085; &#1055;&#1072;&#1083;&#1072;&#1091;&#1079;&#1086;&#1074; Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.118.146.153) How can I write to a ticket here, after I submit it? https://www.openldap.org/software/man.cgi?query=slapd-mdb&apropos=0&sektion… (man slapd-mdb) is not clear about indices. Is olcDbIndex A eq olcDbIndex B eq the same as olcDbIndex A,B eq and is the latter the same as oldDbIndex B,A eq ? In the SQL word these are different things and while Postgresql is supposed to handle "index A,B" and "index B.A" as equivalent, it does not, so a query has to be tuned to make use of existing indices. The particular use-case is the LDAP backend of MIT Kerberos and the indices it needs for this query, as discussed at https://github.com/krb5/krb5/pull/974#issuecomment-531167854. The debug output of OpenLDAP is: Sep 13 09:09:03 mail slapd[14296]: 5d7b5caf conn=1117 op=7 SRCH base="cn=X.NET,cn=krbContainer" scope=2 deref=0 filter="(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=krbtgt/X.NET(a)X.NET))" Sep 13 09:09:03 mail slapd[14296]: 5d7b5caf conn=1117 op=7 SRCH attr=krbprincipalname krbcanonicalname objectclass krbprincipalkey krbmaxrenewable age krbmaxticketlife krbticketflags krbprincipalexpiration krbticketpolicyreference krbUpEnabled krbpwdpolicyreference krbpasswordexpiration krbLastFailedAuth krbLoginFailedCount krbLastSuccessfulAuth krbLastPwdChange krbLastAdminUnlock krbPrincipalAuthInd krbExtraData krbObjectReferences krbAllowedToDelegateTo krbPwdHistory Sep 13 09:09:03 mail slapd[14296]: 5d7b5caf <= mdb_equality_candidates: (objectClass) not indexed Sep 13 09:09:03 mail slapd[14296]: 5d7b5caf conn=1117 op=7 SEARCH RESULT tag=101 err=0 nentries=1 text= Does it need one index on objectClass, one index on krbPrincipal, or one index on "first objectClass, then krbPrincipal"? If no mdb_candidate output can be triggered, does it mean, that creating an index is pointless? Moreover, it is not clear when changing the oldDbIndex on a database regenerates the index, and when running slapindex is necessary.

1 0

Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
by gv＠members.scinet.supercomputing.org 13 Sep '19

13 Sep '19

On Mon, Sep 09, 2019 at 04:01:59PM +0200, Ond??ej Kuzn??k wrote: > I mean the ber_str2bv(,,1,) in both new functions. Not sure which code > you think would overwrite parts of the buffer? ber_str2bv(,,0,) never > touches it, manually initialising the berval certainly wouldn't either. > And then you have fewer memory regions to scrub. > > Since you already know the length, you can also pass it in so ber_str2bv > can skip its strlen() check (and since anything can be in a {PLAINTEXT} > password, you're now embedded NUL safe). Ah, OK, I didn't realize that would be NUL safe. I made an updated patch with that change[1]. > I think I mentioned this before as something worth changing: rather > than call time(0L), you can use op->o_time which is stable and the > closest you can get to the time the operation was received. Yes, sorry I did see that before just forgot to do it. It's also included in the latest update[1]. > BTW, scinet.supercomputing.org's HTTPS cert is signed by Let's Encrypt > Authority X3 as an intermediate, but isn't sending it during the > handshake, so wget/curl aren't happy trusting it (I think browsers cache > it or already have a copy). Thank you, this has been corrected. [1] https://scinet.supercomputing.org/~gv/slapd-totp-v5.txt -- Greg Veldman

1 0

(ITS#9486) slapo-unique spins its wheels on a non-trivial olcUniqueURI spec
by gray＠nxg.name 13 Sep '19

13 Sep '19

Full_Name: Norman Gray Version: 2.4.48 OS: FreeBSD 12.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.209.45.140) A plausible-looking spec in olcUniqueURI causes slapadd to spin its wheels indefinitely. I want to specify something like: dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: unique olcUniqueURI: ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub If I do this, however, then slapadd spins its wheels when the `slapd.ldif` is loaded into an otherwise empty configuration (ie, this happens at configuration time, before any records/objects are loaded): $ rm -R /usr/local/etc/openldap/slapd.d/* $ su -m ldap -c "slapadd -d255 -n 0 -F /usr/local/etc/openldap/slapd.d -l /usr/local/etc/openldap/slapd.ldif" ... ... 5d77d377 >>> dnPrettyNormal: <olcOverlay=unique,olcDatabase={1}mdb,cn=config> 5d77d377 <<< dnPrettyNormal: <olcOverlay=unique,olcDatabase={1}mdb,cn=config>, <olcOverlay=unique,olcDatabase={1}mdb,cn=config> 5d77d377 <= str2entry(olcOverlay=unique,olcDatabase={1}mdb,cn=config) -> 0x800d4eca8 5d77d377 oc_check_required entry (olcOverlay=unique,olcDatabase={1}mdb,cn=config), objectClass "olcUniqueConfig" 5d77d377 oc_check_allowed type "objectClass" 5d77d377 oc_check_allowed type "olcOverlay" 5d77d377 oc_check_allowed type "olcUniqueURI" 5d77d377 oc_check_allowed type "structuralObjectClass" 5d77d377 >>> dnNormalize: <olcOverlay={1}unique> 5d77d377 <<< dnNormalize: <olcOverlay={1}unique> 5d77d377 ==> unique_db_init 5d77d377 ==> unique_new_domain <ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub> 5d77d377 >>> dnPrettyNormal: <ou=dept-A,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-A,o=example>, <ou=dept-A,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> ... ^C and so on and on and on, apparently indefinitely. The idea is that the uidnumber attribute should be unique across the two OUs, ou=dept-A and ou=dept-B. Whether or not this is a valid spec is another issue; even if it's invalid, it shouldn't cause this behaviour; if the spec is invalid, it should produce a terminal error. Looking at the code in servers/slapd/overlays/unique.c, nothing leaps out as an obvious error (ie, I'm not claiming I have a fix for this). There was a brief thread about this on openldap-technical: <https://www.openldap.org/lists/openldap-technical/201909/msg00031.html> Configuration: # /usr/local/libexec/slapd -VVV @(#) $OpenLDAP: slapd 2.4.48 (Sep 10 2019 13:30:19) $ root@hermite.physics.gla.ac.uk:/var/ports/usr/ports/net/openldap24-server/work/openldap-2.4.48/servers/slapd Included static overlays: constraint syncprov unique Included static backends: config ldif relay # freebsd-version 12.0-RELEASE-p9 This is the most recent currently-packaged version of OpenLDAP on FreeBSD.

1 0

Re: (ITS#9023) crash using ppolicy chaining from slave to master
by ondra＠mistotebe.net 11 Sep '19

11 Sep '19

Hi Jean-Philippe, I have just seen and fixed a crash that might be similar to yours (ITS#9076), could you try and see if the crash goes away if you apply commit a14fb731ac6e39cd037512ca63bcb021f0196e5b? Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs