(ITS#6559) About Referrals and BIND
by jet＠hf.webex.com
Full_Name: Jet Du
Version: openldap-2.4.21
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (61.191.27.34)
Because ther are some typo in some description of (ITS#6558). So, I submit a new
ITS as below.
There are two openLDAP Directory.
10.224.39.165 openLDAP has suffix dc=cisco,dc=com
10.224.39.172 openLDAP has suffix dc=webex,dc=com
In 10.224.39.172 OpenLDAP, I configure referral in slapd.conf like below:
referral ldap://10.224.39.165:389/
Connect 10.224.39.172 to BIND entry existing in 10.224.39.165. Code like
following:
lc.connect("10.224.39.172", 389);
lc.bind(LDAPConnection.LDAP_V3,
"uid=xxx(a)hf.cisco.com,ou=People,dc=cisco,dc=com", "pass".getBytes("UTF8"));
But, I can not BIND successfully. Exception like below:
Connect ERRORLDAPException: Invalid Credentials (49) Invalid Credentials
LDAPException: Matched DN: ......
How to do BIND based on Referral? Thanks ...
13 years, 4 months
(ITS#6558) About Referrals and BIND
by jet＠hf.webex.com
Full_Name: Jet Du
Version: openldap-2.4.21
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (61.191.27.34)
There are two openLDAP Directory.
10.224.39.165 openLDAP has suffix dc=cisco,dc=webex
10.224.39.172 openLDAP has suffix dc=webex,dc=webex
In 10.224.39.172 OpenLDAP, I configure referral in slapd.conf like below:
referral ldap://10.224.39.165:389/
Connect 10.224.39.172 to BIND entry existing in 10.224.39.165. Code like
following:
lc.connect("10.224.39.172", 389);
lc.bind(LDAPConnection.LDAP_V3,
"uid=xxx(a)hf.cisco.com,ou=People,dc=cisco,dc=com", "pass".getBytes("UTF8"));
But, I can not BIND successfully. Exception like below:
Connect ERRORLDAPException: Invalid Credentials (49) Invalid Credentials
LDAPException: Matched DN: ......
How to do BIND based on Referral? Thanks ...
13 years, 4 months
Re: (ITS#6553) Test043 oddities under Windows
by masarati＠aero.polimi.it
Isn't ldif-filter supposed to deal with this? Probably, test043 needs to
sort entries (-s bdb=a,hdb=a).
p.
> Full_Name: Matt Hardin
> Version: 2.4.22
> OS: Windows 7
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (74.38.117.141)
>
>
> test043 fails under Windows because the contextCSN attribute for the entry
> dc=example,dc=com are returned in different places within the entry for
> the
> producer and consumer. To wit:
>
> server1.flt-
>
> dn: dc=example,dc=com
> dc: example
> objectClass: organization
> objectClass: domainRelatedObject
> objectClass: dcObject
> l: Anytown, Michigan
> st: Michigan
> o: Example, Inc.
> o: EX
> o: Ex.
> description: The Example, Inc. at Anytown
> postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US
> telephoneNumber: +1 313 555 1817
> associatedDomain: example.com
> structuralObjectClass: organization
> entryUUID: 1602452e-3d10-4fb1-9d55-efb8c08ac643
> creatorsName: cn=Manager,dc=example,dc=com
> createTimestamp: 20100518161938Z
> entryCSN: 20100518161938.140191Z#000000#000#000000
> modifiersName: cn=Manager,dc=example,dc=com
> modifyTimestamp: 20100518161938Z
> entryDN: dc=example,dc=com
> subschemaSubentry: cn=Subschema
> contextCSN: 20100518162026.443250Z#000000#000#000000
> hasSubordinates: TRUE
>
>
>
> server2.flt-
>
> dn: dc=example,dc=com
> dc: example
> objectClass: organization
> objectClass: domainRelatedObject
> objectClass: dcObject
> l: Anytown, Michigan
> st: Michigan
> o: Example, Inc.
> o: EX
> o: Ex.
> description: The Example, Inc. at Anytown
> postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US
> telephoneNumber: +1 313 555 1817
> associatedDomain: example.com
> structuralObjectClass: organization
> entryUUID: 1602452e-3d10-4fb1-9d55-efb8c08ac643
> creatorsName: cn=Manager,dc=example,dc=com
> createTimestamp: 20100518161938Z
> entryCSN: 20100518161938.140191Z#000000#000#000000
> modifiersName: cn=Manager,dc=example,dc=com
> modifyTimestamp: 20100518161938Z
> contextCSN: 20100518162026.443250Z#000000#000#000000
> entryDN: dc=example,dc=com
> subschemaSubentry: cn=Subschema
> hasSubordinates: TRUE
>
>
> While this is not a problem in operation, and is not specifically a bug
> according to the RFCs, test043 nonetheless fails because it expects an
> exact
> match in the ordering between the producer and consumer. It's not clear
> whether
> the desired fix is in slapd or in the test itself.
>
> This test does not fail on any other platforms with which we are currently
> working (HP-UX, Linux, Solaris, AIX), nor does it appear to be related to
> ITS#6549, which is now fixed (thanks Ando!).
>
>
>
>
13 years, 4 months
(ITS#6556) test031 core dumps after applying first filter
by dieter＠dkluenter.de
Full_Name: Dieter Kluenter
Version: HEAD
OS: openSuSE
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (84.142.11.71)
I have enabled slapd-modules/comp_match and properly installed all relevant
files to tests/data/comp_libs. When running test031, slapd segfaults:
Running ./scripts/test031-component-filter for bdb...
running defines.sh
Running slapadd to build slapd database...
Running slapindex to index slapd database...
Starting slapd on TCP/IP port 9011...
Testing slapd searching...
Testing Component Filter Match RFC3687 Certificate searching:
f=(userCertificate:componentFilterMatch:=item:{ component
"toBeSigned.serialNumber", rule allComponen
tsMatch, value 0 }) ...
f=(userCertificate:componentFilterMatch:=item:{ component
"toBeSigned.version", rule allComponentsMat
ch, value 2 }) ...
./scripts/test031-component-filter: Zeile 105: 5312 Speicherzugriffsfehler
(Speicherabzug geschrieben) $SLA
PD -f $ADDCONF -h $URI1 -d $LVL $TIMING > $LOG1 2>&1
ldapsearch failed (255)!
./scripts/test031-component-filter: Zeile 110: kill: (5312) - Kein passender
Prozess gefunden
(gdb) core-file core
Core was generated by `/home/dieter/build/openldap/servers/slapd/.libs/lt-slapd
-s0 -f /home/dieter/bu'.
Program terminated with signal 11, Segmentation fault.
(gdb) file /home/dieter/build/openldap/servers/slapd/.libs/lt-slapd
Reading symbols from
/home/dieter/build/openldap/servers/slapd/.libs/lt-slapd...done.
(gdb) where
#0 0x080e6525 in slap_sl_free (ptr=0x87ba173, ctx=0x89aa3c0) at
sl_malloc.c:492
#1 0x080a0f5b in ch_free (ptr=0x87ba173) at ch_malloc.c:137
#2 0x080e3e3a in mra_free (op=0x89adc80, mra=0x87ba218, freeit=1) at mra.c:43
#3 0x08085621 in filter_free_x (op=0x89adc80, f=0x87ba258, freeme=1) at
filter.c:556
#4 0x0808373e in do_search (op=0x89adc80, rs=0xb71190c4) at search.c:230
#5 0x080805f9 in connection_operation (ctx=0xb7119198, arg_v=0x89adc80) at
connection.c:1109
#6 0x08080b18 in connection_read_thread (ctx=0xb7119198, argv=0x11) at
connection.c:1245
#7 0xb7f963b7 in ?? ()
#8 0xb7cf86e5 in ?? ()
(gdb) bt full
#0 0x080e6525 in slap_sl_free (ptr=0x87ba173, ctx=0x89aa3c0) at
sl_malloc.c:492
sh = 0x89aa3c0
size = 543520108
p = 0x87ba16f
nextp = 0x28e116db
tmpp = 0xb7119198
__PRETTY_FUNCTION__ = "slap_sl_free"
#1 0x080a0f5b in ch_free (ptr=0x87ba173) at ch_malloc.c:137
ctx = 0x89aa3c0
#2 0x080e3e3a in mra_free (op=0x89adc80, mra=0x87ba218, freeit=1) at mra.c:43
No locals.
#3 0x08085621 in filter_free_x (op=0x89adc80, f=0x87ba258, freeme=1) at
filter.c:556
p = 0x8214680
next = 0x89adcac
#4 0x0808373e in do_search (op=0x89adc80, rs=0xb71190c4) at search.c:230
base = {bv_len = 17, bv_val = 0x89aff28 "dc=example,dc=com"}
siz = 0
off = 0
i = 0
#5 0x080805f9 in connection_operation (ctx=0xb7119198, arg_v=0x89adc80) at
connection.c:1109
rc = 80
cancel = 0
op = 0x89adc80
rs = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 2, sr_err = 0,
sr_matched = 0x0,
sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search =
{r_entry = 0x0,
r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0,
r_nentries = 2, r_v2ref = 0x0},
sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0,
r_rspdata = 0x0}}, sr_flags = 0}
tag = 99
opidx = SLAP_OP_SEARCH
conn = 0x8433e04
memctx = 0x89aa3c0
memctx_null = 0x0
memsiz = 1048576
__PRETTY_FUNCTION__ = "connection_operation"
#6 0x08080b18 in connection_read_thread (ctx=0xb7119198, argv=0x11) at
connection.c:1245
---Type <return> to continue, or q <return> to quit---
rc = 0
cri = {op = 0x89adc80, func = 0, arg = 0x0, ctx = 0xb7119198, nullop =
0}
s = 17
#7 0xb7f963b7 in ?? ()
No symbol table info available.
#8 0xb7cf86e5 in ?? ()
No symbol table info available.
(gdb)
-Dieter
13 years, 4 months
Re: (ITS#6555) Syncprov (refreshAndPersist) loses deletes
by hyc＠symas.com
ralf(a)OpenLDAP.org wrote:
> Am Freitag 21 Mai 2010 05:52:31 schrieb Howard Chu:
>> Ralf Haferkamp wrote:
>>> A fix is now in syncprov.c r1.312. Would be great if someone could
>>> review it if it makes sense. Testing results look good so far.
>>
>> Not sure why this makes the difference. After all, mincsn will be set
>> to the consumer's cookie, and any writes that occur during the
>> refresh phase will naturally have an entryCSN greater than mincsn and
>> still be queued.
> That doesn't seem to be true for deletes of entries that have an entryCSN
> less than the value from the cookie. What I did to reproduce the problem
> was:
>
> 1. load provider with about 100 entries
> 2. start consumer wait for it to get synced.
> 3. stop consumer
> 4. load more entries in to the provider (in my test case about 1000)
> 5. restart consumer (the consumer will start a ldapsync session with a
> cookie)
> 6. use ldapdelete to delete in an entry for the initial 100 entries.
> (those that have an entryCSN< csn provide in the cookie). This ldap
> delete as to happened during the refresh part of the ldapsync session
> (when the 1000 new entries are sent)
> 7. watch it fail
>
> What happens is that when syncprov_op_mod() calls syncprov_matchops() it
> tests the to be deleted entry against the syncrepl filter (which has the
> entryCSN>=cookie filter prepended currently as we are in refresh). That
> test fails because of the older entryCSN value. Because of that the
> syncoperation will not be inserted into the smatches queue of the
> opcookie and the delete will not get synched in the syncprov_op_response
> callback (as the smatches queue is empty).
>
> (As a side note: Modification that happen during the refresh phase will
> get synched as LDAP_SYNC_ADD instead of LDAP_SYNC_MODIFY for the above
> reasons. This doesn't cause any failure AFAICS but seemed wrong as well.)
OK, that explanation makes sense. Just wanted to make sure we didn't regress
on ITS#4622, which seems to be the last time these filters were tweaked.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
13 years, 4 months
Re: (ITS#6555) Syncprov (refreshAndPersist) loses deletes
by ralf＠OpenLDAP.org
Am Freitag 21 Mai 2010 05:52:31 schrieb Howard Chu:
> Ralf Haferkamp wrote:
> > A fix is now in syncprov.c r1.312. Would be great if someone could
> > review it if it makes sense. Testing results look good so far.
>
> Not sure why this makes the difference. After all, mincsn will be set
> to the consumer's cookie, and any writes that occur during the
> refresh phase will naturally have an entryCSN greater than mincsn and
> still be queued.
That doesn't seem to be true for deletes of entries that have an entryCSN
less than the value from the cookie. What I did to reproduce the problem
was:
1. load provider with about 100 entries
2. start consumer wait for it to get synced.
3. stop consumer
4. load more entries in to the provider (in my test case about 1000)
5. restart consumer (the consumer will start a ldapsync session with a
cookie)
6. use ldapdelete to delete in an entry for the initial 100 entries.
(those that have an entryCSN < csn provide in the cookie). This ldap
delete as to happened during the refresh part of the ldapsync session
(when the 1000 new entries are sent)
7. watch it fail
What happens is that when syncprov_op_mod() calls syncprov_matchops() it
tests the to be deleted entry against the syncrepl filter (which has the
entryCSN>=cookie filter prepended currently as we are in refresh). That
test fails because of the older entryCSN value. Because of that the
syncoperation will not be inserted into the smatches queue of the
opcookie and the delete will not get synched in the syncprov_op_response
callback (as the smatches queue is empty).
(As a side note: Modification that happen during the refresh phase will
get synched as LDAP_SYNC_ADD instead of LDAP_SYNC_MODIFY for the above
reasons. This doesn't cause any failure AFAICS but seemed wrong as well.)
13 years, 4 months
Re: (ITS#6554) OpenLDAP + TLS multiple server certificates
by hyc＠symas.com
stepan.kipel(a)ab-group.biz wrote:
> Full_Name: Stepan Kipel
> Version: 2.4.19
> OS: Red Hat Enterprise Linux AS release 4
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (79.140.224.210)
>
>
> In our network there are 2 servers running slapd, one is syncrepl-provider and
> other is consumer. Both have identical IP address for LDAP requests and
> configured in manner that when one goes down, second takes over (configured
> externally, by routing). Also, TLS is configured and works transparently for
> client machines (DNS resolves their "common" IP), but it`s hard to use their
> Domain Name for TLS syncrepl - DNS resolves IP, that is up on local machine. We
> decided to put up other interface on syncrepl-provider for replication purposes,
> mapped another Domain Name on this interface and appended CA, server and private
> server certs created for this Domain Names to files included by
> TLSCACertificateFile, TLSCertificateFile and TLSCertificateKey in slapd.conf
> file, respectively. We`ve tried to execute ldapsearch with two different
> ldap.conf configs - for first and second domain name of the server, one works
> and another - not? error looks like "TLS: hostname (first_srv_name) does not
> match common name in certificate (second_srv_name)."
>
> The question is - can slapd server use more than 2 server certificates or we
> should use another technology (tunneling, etc...) for encrypted syncrepl?
>
A server cert file and key file may only contain one item; that's a constraint
from the underlying TLS library. You should not have needed to create a new CA
for this situation. You should look at using a single server cert with a
subjectAltName matching the the alternate interface name.
The ITS is for bug reports, not for hetting help on using the software. This
ITS will be closed. Use the -software mailing list.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
13 years, 4 months
