(ITS#4692) ppolicy.c module doesn't respect Draft policy
by alexandrelabiche＠yahoo.com
Full_Name: Alexandre LABICHE
Version: 2.3.27
OS: linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (82.120.54.227)
Hello,
draft-behera-ldap-password-policy-xx.txt says:
5.3.2 pwdChangedTime
This attribute specifies the last time the entry's password was
changed. This is used by the password expiration policy. If this
attribute does not exist, the password will never expire.
And ppolicy.c overlay says contrary
/*
* Hmm. No password changed time on the
* entry. This is odd - it should have
* been provided when the attribute was added.
*
* However, it's possible that it could be
* missing if the DIT was established via
* an import process.
*/
Debug( LDAP_DEBUG_ANY,
"ppolicy_bind: Entry %s does not have
valid pwdChangedTime attribute - assuming password expired\n",
e->e_name.bv_val, 0, 0);
pwExpired = 1;
Regards.
Alexandre LABICHE
16 years, 7 months
Re: (ITS#4691) syncrepl in refreshOnly dies when bind to provider fails
by hyc＠symas.com
I don't see any indication of an OpenLDAP software bug here.
Use the "retry" parameter if your connections are unreliable.
bgmilne(a)staff.telkomsa.net wrote:
> Full_Name: Buchan Milne
> Version: 2.3.27
> OS: Linux 2.4 (RHEL 3)
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (196.15.129.131)
>
>
> One of our replicas sits on the other side of a relatively congested WAN link
> (with multiple firewalls in between, which I have no control over).
>
> Since switching to syncrepl, it has been difficult to achieve a configuration
> that supports replication reliably to any extent.
>
> Using syncrepl consumer configuration with:
>
> syncrepl rid=124
> provider=ldaps://<master hostname>
> type=refreshOnly
> interval="00:00:01:00"
> searchbase="<suffix>"
> scope=sub
> attrs="*"
> schemachecking=off
> bindmethod=simple
> binddn="<dn for consumer>"
> credentials="<password for consumer>"
>
> I see replication dies frequently, it seems to occur when (for whatever reason)
> the consumer fails to bind:
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
16 years, 7 months
(ITS#4691) syncrepl in refreshOnly dies when bind to provider gails
by bgmilne＠staff.telkomsa.net
Full_Name: Buchan Milne
Version: 2.3.27
OS: Linux 2.4 (RHEL 3)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (196.15.129.131)
One of our replicas sits on the other side of a relatively congested WAN link
(with multiple firewalls in between, which I have no control over).
Since switching to syncrepl, it has been difficult to achieve a configuration
that supports replication reliably to any extent.
Using syncrepl consumer configuration with:
syncrepl rid=124
provider=ldaps://<master hostname>
type=refreshOnly
interval="00:00:01:00"
searchbase="<suffix>"
scope=sub
attrs="*"
schemachecking=off
bindmethod=simple
binddn="<dn for consumer>"
credentials="<password for consumer>"
I see replication dies frequently, it seems to occur when (for whatever reason)
the consumer fails to bind:
ct 2 12:03:36 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:03:36 leda slapd2.3[1332]: syncrepl_entry: uid=lere1
Oct 2 12:03:37 leda slapd2.3[1332]: syncrepl_entry: be_add (0)
Oct 2 12:03:37 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 2 12:03:43 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE -
SYNC_ID_SET
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete
uid=deleted/telkomsa133309,ou=radius,o=intekom,c=za (0)
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete
uid=telkomsa158118
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete
uid=online517446
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: uid=online517446
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_add (0)
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: uid=telkomsa158118
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_add (0)
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: uid=online564666
Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_add (0)
Oct 2 12:03:46 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 2 12:04:25 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 2 12:04:25 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 2 12:04:37 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE -
SYNC_ID_SET
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete
uid=telkomsa220585
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=online188476
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_modify (0)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=mail109585
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_modify (0)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=telkomsa196118
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_modify (0)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=online313812
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_modify (0)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=online519355
Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: be_modify (0)
Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: uid=online536857
Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: be_modify (0)
Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: uid=telkomsa233527
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0)
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: uid=mail140571
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0)
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: uid=online564379
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0)
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: uid=online564667
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_add (0)
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: uid=ihatechromium
Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_add (0)
Oct 2 12:04:40 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 2 12:04:46 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE -
SYNC_ID_SET
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete
uid=online556601
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete
uid=online519355
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: uid=online519355
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_add (0)
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: uid=online556601
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_add (0)
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: uid=online564667
Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_add (0)
Oct 2 12:04:47 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 2 12:05:25 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 2 12:05:25 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 2 12:05:40 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE -
SYNC_ID_SET
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete
uid=online534772
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete
uid=online18609
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: uid=online188476
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0)
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: uid=telkomdsl56797
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0)
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: uid=mail140571
Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_modify (0)
Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: uid=hotkaj
Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_add (0)
Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: uid=magda22
Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_add (0)
Oct 2 12:05:41 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 2 12:05:47 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE -
SYNC_ID_SET
Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete
uid=online561383
Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete
uid=online534772
Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_entry:
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_entry: be_search (0)
Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_entry: uid=online561383
Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_entry: be_add (0)
Oct 2 12:05:47 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT
Oct 2 12:06:27 leda slapd2.3[1332]: do_syncrep1: ldap_sasl_bind_s failed (-1)
16 years, 7 months
Re: (ITS#4690) segfault in ldap_count_values() with PHP
by Kurt＠OpenLDAP.org
At 06:12 PM 10/1/2006, ando(a)sys-net.it wrote:
>madcoder(a)gmail.com wrote:
>...
>You know, what makes me mad about PHP is that it internally uses
>something comparable to bervals, since the abstract type they use to
>wrap strings takes care of the length of the string itself; but in the
>LDAP extension, ldap_get_values() is used everywhere, and then strlen is
>run to compute the length of the values! Why on earth don't they get
>ldap_get_values_len() should be used instead? Somehow it got hardwired
>in people's brain that ldap_get_values_len() is only good for "binary"
>(that is, non-printable) stuff, and not for strings as well!
Folks also tend to forget that U+0000 is a valid Unicode
character, as is ASCII 0... but I digress.
Kurt
16 years, 7 months
Re: (ITS#4690) segfault in ldap_count_values() with PHP
by ando＠sys-net.it
madcoder(a)gmail.com wrote:
...
You know, what makes me mad about PHP is that it internally uses
something comparable to bervals, since the abstract type they use to
wrap strings takes care of the length of the string itself; but in the
LDAP extension, ldap_get_values() is used everywhere, and then strlen is
run to compute the length of the values! Why on earth don't they get
ldap_get_values_len() should be used instead? Somehow it got hardwired
in people's brain that ldap_get_values_len() is only good for "binary"
(that is, non-printable) stuff, and not for strings as well!
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
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
------------------------------------------
16 years, 7 months
Re: (ITS#4690) segfault in ldap_count_values() with PHP
by ando＠sys-net.it
madcoder(a)gmail.com wrote:
> What more can I do to debug this problem?
>
Well, I've posted a bug to PHP about their using deprecated LDAP code,
but it was basically bounced with "mind your own business" or sort of
(and this __IS__ my own business, by the way :). You could try
rebuilding PHP's LDAP stuff defining -DLDAP_DEPRECATED=1 and see what
happens. I've seen similar problems with AMD64 when functions got
linked without a prototype, and ldap_get_values does not have a
prototype in ldap.h unless the above is defined.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
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
------------------------------------------
16 years, 7 months
(ITS#4690) segfault in ldap_count_values() with PHP
by madcoder＠gmail.com
Full_Name: Joe H
Version: 2.3.24
OS: gentoo linux (2.6.17) on amd64 Athlon X2
URL: http://bugs.php.net/bug.php?id=38819
Submission from: (NULL) (70.245.125.224)
I'm not certain yet whether this is a bug in openldap, or in PHP, but my bug
report with PHP has stalled, so I am hoping that cross-posting it here might
garnish some further insight into the problem.
The PHP bug report should explain the segfault I'm experiencing, and where the
segfault occurs. It can be found at http://bugs.php.net/bug.php?id=38819
The segfault occurs in libraries/libldap/getvalues.c, in the ldap_count_values()
function. The value for vals that is passed to the function cannot be read for
some reason. At first I thought this might be a PHP problem, since the
ldapsearch utility works fine performing the same search. However, it should
also be mentioned that the value that is sent to ldap_get_values, is a value
returned directly from ldap_get_values():
> ldap_value = ldap_get_values(ldap, ldap_result_entry, attribute);
> num_values = ldap_count_values(ldap_value);
While in ldap_count_values(), the backtrace shows that the segfault occurs
during the first iteration of the for() loop:
> Program received signal SIGSEGV, Segmentation fault.
> 0x00002b2871ad210b in ldap_count_values (vals=0x55a170c0) at getvalues.c:152
> 152 for ( i = 0; vals[i] != NULL; i++ )
Further investigating the problem shows:
> (gdb) p i
> $1 = 0
> (gdb) p vals
> $2 = (char **) 0x55a170c0
> (gdb) p vals[0]
> Cannot access memory at address 0x55a170c0
The memory address changes obviously, but the segfault always occurs at that
point.
In PHP's ldap_get_entries() function, ldap_values is defined as:
> char **ldap_value;
which is the data type expected by ldap_count_entries(). Fetching the entry
reference itself, or counting the number of entries, does not cause the segfault
-- only when getting values from the entry. For example, PHP's
ldap_first_entry($result) works fine (as well as iterating over the entries
using ldap_next_entry()), but trying to read any of the values within the entry
will cause the segfault.
Again, the fact that it works fine with ldapsearch, but segfaults in PHP, lead
me to believe that it would be a PHP problem, but looking more into the source
code of both applications makes me lean more and more to some obscure problem in
OpenLDAP's code. The value of 'vals' is declared and returned from this
function:
> char **
> ldap_get_values( LDAP *ld, LDAPMessage *entry, LDAP_CONST char *target )
> {
>>...
> char **vals;
>>...
> if ( (res = ber_scanf( &ber, "[v]", &vals )) == LBER_ERROR ) {
> ld->ld_errno = LDAP_DECODING_ERROR;
> return( NULL );
> }
> return( vals );
The return value of ber_scanf is 4, but I haven't investigated what that value
indicates (it is obviously not LBER_ERROR). In any case, that value of 'vals'
is allocated inside OpenLDAP's code, and that makes me believe that it is not a
problem with PHP's code. The same test script functions properly on a similar
32-bit system (as similar as 32- and 64-bit systems can be).
What more can I do to debug this problem?
16 years, 7 months
