hyc(a)symas.com wrote:
> vorlon(a)debian.org wrote:
>> This bug is marked as fixed in 2.4.8, but I still see the same problem in
>> the test suite in 2.4.10. Trying to start slapd with back-meta gives:
>>
>> /home/devel/openldap/build-area/openldap2.3-2.4.10/debian/build/servers/slapd/.libs/lt-slapd: symbol lookup error: ../servers/slapd/back-meta/.libs/back_meta-2.4.so.2: undefined symbol: slap_idassert_parse_cf
>>
>> Is this a regression since 2.4.8?
>
> Looks more like an incomplete fix. The functions in question haven't changed
> since 2006. Since we're not using a hacked libltdl the problem you're seeing
> doesn't show up here. I guess you should have tested this sooner...
Additional patches for back-ldap/back-meta are now in HEAD; please test.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
vorlon(a)debian.org wrote:
> This bug is marked as fixed in 2.4.8, but I still see the same problem in
> the test suite in 2.4.10. Trying to start slapd with back-meta gives:
>
> /home/devel/openldap/build-area/openldap2.3-2.4.10/debian/build/servers/slapd/.libs/lt-slapd: symbol lookup error: ../servers/slapd/back-meta/.libs/back_meta-2.4.so.2: undefined symbol: slap_idassert_parse_cf
>
> Is this a regression since 2.4.8?
Looks more like an incomplete fix. The functions in question haven't changed
since 2006. Since we're not using a hacked libltdl the problem you're seeing
doesn't show up here. I guess you should have tested this sooner...
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Andrew Findlay wrote:
> Indeed, though draft-behera-ldap-password-policy-xx.txt is a bit unclear
> on the subject of that attribute:
>
> 5.3.3 pwdAccountLockedTime
> The current implementation does allow
> admins to set the value, which appears to be the only way to
> lock/unlock an account without changing the password.
The current implementation allows pretty much anybody to set the attribute.
It's intended that it can only be set when using the Relax Constraints control.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
On Sat, Jun 28, 2008 at 07:21:44PM -0700, Howard Chu wrote:
> >pwdFailureTime cannot be modified directly, so I think there is a case for
> >clearing it when pwdAccountLockedTime is cleared explicitly.
>
> Technically, you're not supposed to be able to modify pwdAccountLockedTime
> directly either. The current behavior is a temporary hack. The only
> legitimate way to remove those attributes is by setting a new password. I'm
> rejecting this ITS.
Indeed, though draft-behera-ldap-password-policy-xx.txt is a bit unclear
on the subject of that attribute:
5.3.3 pwdAccountLockedTime
This attribute holds the time that the user's account was locked. A
locked account means that the password may no longer be used to
authenticate. A 000001010000Z value means that the account has been
locked permanently, and that only a password administrator can unlock
the account.
One reading of that clause is that *setting* pwdAccountLockedTime to
000001010000Z is the way to lock an account by administrative action.
There does not appear to be anything in the I-D that would cause the
server to set that value itself. The current implementation does allow
admins to set the value, which appears to be the only way to
lock/unlock an account without changing the password.
I would certainly prefer to have separate attributes for 'admin lock'
and 'auto lock'.
Andrew
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------
This bug is marked as fixed in 2.4.8, but I still see the same problem in
the test suite in 2.4.10. Trying to start slapd with back-meta gives:
/home/devel/openldap/build-area/openldap2.3-2.4.10/debian/build/servers/slapd/.libs/lt-slapd: symbol lookup error: ../servers/slapd/back-meta/.libs/back_meta-2.4.so.2: undefined symbol: slap_idassert_parse_cf
Is this a regression since 2.4.8?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek(a)ubuntu.com vorlon(a)debian.org
Howard Chu wrote:
> unix.gurus(a)gmail.com wrote:
>> If someone wants to accept or comment on what needs fixing in the
>> patch below, that would help me to generate the rest of the patches:
>> ftp://ftp.openldap.org/incoming/sean-burford-monitor-normalize-unified-0806…
>
> In back-monitor/database.c you don't need to normalize the DNs before
> comparing them. The stored values are already Prettied, so all you need is to
> use a case-insensitive compare here.
Duh. Or just compare a->a_vals and be->be_suffix instead.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
andrew.findlay(a)skills-1st.co.uk wrote:
> Full_Name: Andrew Findlay
> Version: 2.4.10
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (88.97.25.132)
>
>
> If an account becomes locked due to excessive failed authentications, its entry
> will contain the attributes pwdFailureTime and pwdAccountLockedTime. If the
> account is subsequently unlocked by setting a new password, all values of those
> attributes are automatically removed. However, if the password is left alone and
> the account is unlocked by removing pwdAccountLockedTime, values remain in
> pwdFailureTime. This means that a single authentication failure will immediately
> lock the account again.
>
> pwdFailureTime cannot be modified directly, so I think there is a case for
> clearing it when pwdAccountLockedTime is cleared explicitly.
Technically, you're not supposed to be able to modify pwdAccountLockedTime
directly either. The current behavior is a temporary hack. The only legitimate
way to remove those attributes is by setting a new password. I'm rejecting
this ITS.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/