henson(a)acm.org wrote:
> Full_Name: Paul B. Henson
> Version: 2.3.40
> OS: Gentoo
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (134.71.248.24)
>
>
> I recently installed some updates and configuration changes on one of my
> LDAP slaves. Replication broke mysteriously after that. The only thing logged
> was "slapd[30723]: do_syncrepl: rid 001 retrying (9 retries left)"
>
> I finally figured out that the search was failing with a protocol error because
> derefAliases was set to always, a setting I had just added. It would be useful
> if replication failure provided better error messages, something in the logs
> indicating that a protocol error had occurred because of an invalid
> dereferencing setting would have saved me a lot of time.
An additional log message for this situation has been added.
> In addition, if it is a protocol error to dereference aliases in the context of
> syncrepl, shouldn't the server just ignore that global configuration setting and
> just do the right thing?
A patch has been applied to always set Deref to Never. These changes are in
CVS 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/
kouk(a)noc.uoa.gr wrote:
> Full_Name: Kostantinos Koukopoulos
> Version: 2.4.11
> OS: Solaris 9
> URL: ftp://ftp.openldap.org/incoming/kostantinos-koukopoulos-080723-2.patch
> Submission from: (NULL) (195.134.100.30)
>
>
> When using the translucent overlay, if one tries to use set syntax in an ACL or
> ACI rule, in order to dereference the bound user, like in the example below,
> then the user's entry is fetched from the local database only.
>
> Example <who> clause:
> by set="user/eduPersonOrgUnitDN & [ou=someunit,dc=someorg,dc=somecountry]"
>
> If the 'eduPersonOrgUnitDN' attribute has not been modified it will not be found
> in the local database. I believe it would be better if the remote database was
> also checked, like when a search operation is performed against the overlay.
>
> I found the problem was due to that acl_set_gather2 tries to fetch the attribute
> directly from the backend, but the translucent overlay does not support this, so
> the backend is used instead. I've attached a patch which makes acl_set_gather
> always use an internal search operation to fetch the attribute, instead of
> calling acl_set_gather2.
Although I understand the spirit of the patch you propose, I'm not sure
it is the right solution. In fact, running an internal search like that
implies that the whole overlay chain be run through. Probably, that's
correct in the case of the translucent overlay, though. I need to think
about it. Any comments by others?
> I've also tried to hack the translucent overlay so that it would support the
> bi_entry_get_rw callback but I haven't been able to provide something that would
> even satisfy me. I suppose I would have to use some sort of callback mechanism
> like translucent_search_cb but I haven't figured it out yet.
That's another problem I ran through when trying to add rewrite
capabilities to the slapo-rwm(5) overlay, so that authorization could be
rewrapped when performed through virtual data views. However, I believe
the API of bi_entry_get_rw be modified for overlays, since the current
API does not allow calls to modify their arguments. I'd leave that
alone by now.
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
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
Can't find the patch; however, the problem should now be fixed, thanks.
Please test. 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
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
Should be re-fixed now in HEAD; please test. 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
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
Full_Name: Howard Chu
Version: 2.3/2.4/HEAD
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (76.91.220.157)
Submitted by: hyc
For non-global overlays, overlay_register_control sets the control flags in the
temporary BackendDB structure, which is discarded shortly thereafter. It needs
to set the flags in the real BackendDB structure.
dieter(a)dkluenter.de wrote:
> Full_Name: Dieter Kluenter
> Version: 2.4.11
> OS: openSUSE-11.0
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (84.142.237.56)
>
>
> Hello,
> man slapo-ppolicy(5) says that the overlay depends on objectclass pwdPolicy and
> Every account that should be subject to password policy control should have
> pwdPolicySubentry...
As usual, it's important that you read every word in the manpage and not skip
over anything. The manpage says:
>>
Every account that should be subject to password policy control should have a
pwdPolicySubentry attribute containing the DN of a valid pwdPolicy entry, or
they can simply use the configured default.
<<
This means the pwdPolicy entry is some other entry, not that user entries must
have the pwdPolicy class. Yes, the overlay depends on the pwdPolicy class
because entries of pwdPolicy class must be used to store the policy
definitions. It doesn't say that user entries must have pwdPolicy class and it
would be stupid to store the policy definitions in the user entries. And it
would be pointless to require a pwdPolicySubentry attribute to point to the
relevant policy if the policy was simply stored in the user entry.
Use your brain.
This ITS will be closed.
> But ppolicy is controlling every enty, even those without attribute pwdPolicy
> and attribute pwdPolicySubentry.
> I have created a test entry, which is not subject to password policy but got
> locked out after 3 binds with wrong password.
>
> dn: cn=pw tester,o=avci,c=de
> cn: pw tester
> createTimestamp: 20080808132851Z
> creatorsName: cn=admin,o=avci,c=de
> description: Password Tester
> entryCSN: 20080808132851.203028Z#000000#000#000000
> entryDN: cn=pw tester,o=avci,c=de
> entryUUID: af06a7e2-f999-102c-8d8e-df96a2a401d4
> hasSubordinates: FALSE
> modifiersName: cn=admin,o=avci,c=de
> modifyTimestamp: 20080808132851Z
> objectClass: person
> pwdAccountLockedTime: 20080808133126Z
> pwdChangedTime: 20080808132851Z
> pwdFailureTime: 20080808133058Z
> pwdFailureTime: 20080808133109Z
> pwdFailureTime: 20080808133126Z
> sn: tester
> structuralObjectClass: person
> subschemaSubentry: cn=Subschema
> userPassword: tested
>
> -Dieter
>
>
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Michael Ströder <michael(a)stroeder.com> writes:
> dieter(a)dkluenter.de wrote:
>> man slapo-ppolicy(5) says that the overlay depends on objectclass pwdPolicy and
>> Every account that should be subject to password policy control should have
>> pwdPolicySubentry...
>> But ppolicy is controlling every enty, even those without attribute pwdPolicy
>> and attribute pwdPolicySubentry.
>> I have created a test entry, which is not subject to password policy but got
>> locked out after 3 binds with wrong password.
>
> Do you have 'ppolicy_default' set in slapd.conf?
> What happens if you remove that?
Yes, I do have
ppolicy_default "cn=user,cn=policies,o=avci,c=de"
but this should only be applicable if the entry belongs to
objectclass pwdPolicy but not without objectclass pwdPolicy
declaration.
-Dieter
--
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6
53°08'09,95"N
10°08'02,42"E