openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#5618) better error messages for syncrepl failure
by hyc＠symas.com 09 Aug '08

09 Aug '08

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/

1 0

Re: (ITS#5628) dereferencing user with translucent overlay
by ando＠sys-net.it 09 Aug '08

09 Aug '08

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 -----------------------------------

1 0

Re: (ITS#5627) set syntax in ACI's
by ando＠sys-net.it 09 Aug '08

09 Aug '08

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 -----------------------------------

1 0

Re: (ITS#5637) dynacl broken when an access mask has been already applied by previous ACL rule
by ando＠sys-net.it 09 Aug '08

09 Aug '08

Fixed in HEAD, 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 -----------------------------------

1 0

Re: (ITS#5636) performance improvement in ACI evaluation
by ando＠sys-net.it 09 Aug '08

09 Aug '08

Applied to HEAD, 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 -----------------------------------

1 0

Re: (ITS#5641) Segmentation fault - slaptest and slapd
by ando＠sys-net.it 09 Aug '08

09 Aug '08

Fixed 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 -----------------------------------

1 0

ITS#5581 reopened
by ando＠sys-net.it 09 Aug '08

09 Aug '08

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 -----------------------------------

1 0

(ITS#5649) overlay_register_control doesn't work
by hyc＠OpenLDAP.org 09 Aug '08

09 Aug '08

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.

1 0

Re: (ITS#5648) ppolicy controls entries without objectclass pwdPolicy
by hyc＠symas.com 08 Aug '08

08 Aug '08

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/

1 0

Re: (ITS#5648) ppolicy controls entries without objectclass pwdPolicy
by dieter＠dkluenter.de 08 Aug '08

08 Aug '08

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

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs