(ITS#5517) add superclass of existing class fails
by h.b.furuseth＠usit.uio.no
Full_Name: Hallvard B Furuseth
Version: HEAD
OS: Linux
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
If objectclass B is a subclass of A, and an entry contains objectclass B
but not A, slapd returns attributeOrValueExists to a request to add A.
OTOH it allows replace(objectClass: <A, B>), and after that it allows
delete(objectClass: A). This is inconsistent.
If the objectClass attribute contains B, does it "really" contain A as
well? I couldn't find such a statement in the RFCs, so my guess is
that add(objectClass: A) should be allowed. Though I haven't looked
all that hard.
Example:
ldapadd -cx <<'EOF'
# Create initial object
dn: c=NO
objectClass: friendlyCountry
c: NO
co: Norway
# error
dn: c=NO
changetype: modify
add: objectClass
objectClass: top
-
# error
dn: c=NO
changetype: modify
add: objectClass
objectClass: country
-
# success
dn: c=NO
changetype: modify
replace: objectClass
objectClass: top
objectClass: country
objectClass: friendlyCountry
-
# success
dn: c=NO
changetype: modify
delete: objectClass
objectClass: top
-
# success
dn: c=NO
changetype: modify
delete: objectClass
objectClass: country
-
EOF
15 years, 6 months
Re: (ITS#5515) v2.4.9 + GnuTLS fails with wildcard certificate, OpenSSL works correctly
by bpgoldsb＠gleim.com
We're using *.domain.tld in the CN and subjectAltName:DNS:*.domain.tld
This may be a GnuTLS issue, as I am able to reproduce it with the GnuTLS
server/client testing tools.
On Sat, 2008-05-17 at 23:23 -0700, Howard Chu wrote:
> bgoldsbury(a)gleim.com wrote:
> > Full_Name: Ben Goldsbury
> > Version: 2.4.9
> > OS: Debian
> > URL: ftp://ftp.openldap.org/incoming/
> > Submission from: (NULL) (209.208.68.2)
> >
> >
> > When OpenLDAP 2.4.9 is compiled against GnuTLS (version 2.2.1 in my testing) and
> > using a valid Wildcard SSL certificate, TLS connections to OpenLDAP fail with:
> >
> > TLS certificate verification: Error, unable to get local issuer certificate
> >
> > When OpenLDAP 2.4.9 is compiled against OpenSSL (version 0.9.8c in my testing)
> > and using the same certificate, connections work properly.
> >
> > Please contact me if you need any additional information.
>
> This sounds an awful lot like ITS#5361, which is a known defect in GnuTLS.
>
> What exactly do you mean by "Wildcard SSL certificate" ? There are a couple
> different approaches to that. One uses the subjectAltName extension, and that
> is the officially sanctioned approach. One uses "*" in the certificate CN, and
> that is non-standard and generally not supposed to work.
15 years, 6 months
Re: (ITS#5513) back-ldap+ppolicy bind assertion failure
by ando＠sys-net.it
mbackes(a)symas.com wrote:
> Thanks; this seems to fix the issue, at least in my test cases.
OK, I've applied the fix to re23/re24 as well.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 6 months
Re: (ITS#5515) v2.4.9 + GnuTLS fails with wildcard certificate, OpenSSL works correctly
by hyc＠symas.com
bgoldsbury(a)gleim.com wrote:
> Full_Name: Ben Goldsbury
> Version: 2.4.9
> OS: Debian
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (209.208.68.2)
>
>
> When OpenLDAP 2.4.9 is compiled against GnuTLS (version 2.2.1 in my testing) and
> using a valid Wildcard SSL certificate, TLS connections to OpenLDAP fail with:
>
> TLS certificate verification: Error, unable to get local issuer certificate
>
> When OpenLDAP 2.4.9 is compiled against OpenSSL (version 0.9.8c in my testing)
> and using the same certificate, connections work properly.
>
> Please contact me if you need any additional information.
This sounds an awful lot like ITS#5361, which is a known defect in GnuTLS.
What exactly do you mean by "Wildcard SSL certificate" ? There are a couple
different approaches to that. One uses the subjectAltName extension, and that
is the officially sanctioned approach. One uses "*" in the certificate CN, and
that is non-standard and generally not supposed to work.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 6 months
Re: (ITS#5513) back-ldap+ppolicy bind assertion failure
by mbackes＠symas.com
> I've been able to reproduce the issue, and I think it's solved
> (back-ldap/search.c 1.235 -> 1.236); however I'm afraid I didn't
> understand all the details of your configuration, so I might have
> tested something different.
>
> The bug was in ldap_back_entry_get() setting up a connection based
> on the o_tag field, which is that of the current operation (a bind,
> in your case). I fixed it by always re-setting the tag to
> LDAP_REQ_SEARCH, under the assumption that ldap_back_entry_get()
> doesn't need to know what operation required the entry to be looked
> up.
>
> Please test and report; in case of further issues, I might need the
> full slapd.conf of the proxy (unless the above is all, of course...)
Thanks; this seems to fix the issue, at least in my test cases.
Matthew Backes
Symas Corporation
mbackes(a)symas.com
15 years, 6 months
Re: (ITS#5513) back-ldap+ppolicy bind assertion failure
by ando＠sys-net.it
mbackes(a)symas.com wrote:
> A basic back-ldap configuration with the password policy overlay stacked on top
> results in an assertfail for the second bind. e.g. given a working (possibly
> empty db) on ldap://localhost:1389/...
>
> include ...../core.schema
> include ...../ppolicy.schema
>
> modulepath .....
> moduleload back_ldap.la
> moduleload ppolicy.la
>
> database ldap
> suffix ""
> uri ldap://localhost:1389/
>
> After performing a successful remote bind, the next bind attempt halts the
> back-ldap directory with:
>
> slapd: bind.c:905: ldap_back_getconn: Assertion `( li->li_idassert.si_flags &
> (0x02U) )' failed.
>
> where 0x02U here is LDAP_BACK_AUTH_OVERRIDE.
>
> This happens under both OpenLDAP 2.3 and 2.4.
I've been able to reproduce the issue, and I think it's solved
(back-ldap/search.c 1.235 -> 1.236); however I'm afraid I didn't
understand all the details of your configuration, so I might have tested
something different.
The bug was in ldap_back_entry_get() setting up a connection based on
the o_tag field, which is that of the current operation (a bind, in your
case). I fixed it by always re-setting the tag to LDAP_REQ_SEARCH,
under the assumption that ldap_back_entry_get() doesn't need to know
what operation required the entry to be looked up.
Please test and report; in case of further issues, I might need the full
slapd.conf of the proxy (unless the above is all, of course...)
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 6 months
Re: (ITS#5502) LDAP problem
by ando＠sys-net.it
javed_ansari(a)infosys.com wrote:
> Full_Name: Javed Ansari
> Version: 2.3.30
> OS: Sun
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (220.225.64.6)
>
>
> Since yesterday, we are facing LDAP problems while insertion of data. When we
> try to insert data in the ldap we get the following error:
>
> [LDAP: error code 80 - entry store failed]
>
> There however seems to be no problem with the login though, this occurs only
> during registration
You seem to be a little bit too confident on our capability to predict
the server's behavior based on a very limited amount of information.
Based on the accuracy of your issue report, all I can tell is that you
seem to have a problem.
Please follow guidelines at
<http://www.openldap.org/faq/data/cache/56.html> and provide a decent
issue report.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 6 months
(ITS#5515) v2.4.9 + GnuTLS fails with wildcard certificate, OpenSSL works correctly
by bgoldsbury＠gleim.com
Full_Name: Ben Goldsbury
Version: 2.4.9
OS: Debian
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (209.208.68.2)
When OpenLDAP 2.4.9 is compiled against GnuTLS (version 2.2.1 in my testing) and
using a valid Wildcard SSL certificate, TLS connections to OpenLDAP fail with:
TLS certificate verification: Error, unable to get local issuer certificate
When OpenLDAP 2.4.9 is compiled against OpenSSL (version 0.9.8c in my testing)
and using the same certificate, connections work properly.
Please contact me if you need any additional information.
15 years, 6 months
Re: (ITS#5510) Does GSSAPI failure kill slapd?
by h.b.furuseth＠usit.uio.no
hyc(a)symas.com writes:
> This looks like a pretty major compiler bug, assuming the trace is
> correct.
Not necessarily, valid optimizations can rearrange memory beyond a
debugger's ability to figure out what's going on. Still, this does
look like a strange optimization if it's a valid one.
> What version of compiler did you use, were you using optimization? Can
> you try with a different version and/or without optimization?
--
Hallvard
15 years, 6 months
