Re: (ITS#5980) libldap referral chasing now returns referral (10) and matchedDN
by ando@sys-net.it
ando(a)sys-net.it wrote:
> Probably a side-effect of fixing ITS#5853:
This seems to be unrelated from ITS#5853, actually.
Another note: if a search reference is received, it is returned by
libldap and additionally it is chased, so one gets both the search
reference and the chased search reference results.
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
-----------------------------------
14 years, 3 months
(ITS#5980) libldap referral chasing now returns referral (10) and matchedDN
by ando@sys-net.it
Full_Name: Pierangelo Masarati
Version: HEAD/re24
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (82.63.140.131)
Submitted by: ando
Probably a side-effect of fixing ITS#5853: when setting LDAP_OPT_REFERRALS,
libldap automatically chases any referrals, but at the end returns a response
with ld_errno set to 10 and ld_matched set to the portion of DN that was matched
in the initial request. This is because the corresponding fields in the parent
request are not cleared when the referral is successfully chased. I'm trying to
fix this, but it's not clear to me when success should be detected: at
successful referral chasing request submission, I guess?
p.
14 years, 3 months
Re: (ITS#5979) ppolicy & access log crashes server
by hyc@symas.com
Peter Giesin wrote:
> Since the database was corrupted (we were getting a Segmentation Fault
> when restarting the server) we simply removed the database. I guess if
> we recovered the database instead we would have gotten the same results.
Recovery is preformed automatically on startup. Wiping the DB and starting
over isn't necessary; if the disks holding the transaction logs don't burn
up/fail then corruption simply isn't an issue.
> Thanks for the quick fix.
You're welcome...
>
> Pete
>
> On Fri, Feb 27, 2009 at 10:44 PM, Howard Chu <hyc(a)symas.com
> <mailto:hyc@symas.com>> wrote:
>
> pgiesin(a)gmail.com <mailto:pgiesin@gmail.com> wrote:
>
> Full_Name: Peter Giesin
> Version: 2.4.13
> OS: Red Hat 5.2
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (24.187.213.234)
>
>
> Enabled both accesslog and ppolicy overlays (configurations
> included below). All
> attempts to bind with an invalid password causes the server to
> crash and
> database to be corrupted. If you disable either of the overlays
> or just the
> "logold" setting of the accesslog the behavior is no longer noticed.
>
>
> Interesting, for me only the first attempt crashed; after restarting
> the same attempt just failed normally. Anyway, thanks for the
> report, this is now fixed in HEAD.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 3 months
Re: (ITS#5979) ppolicy & access log crashes server
by pgiesin@gmail.com
--000e0cd4d91a91c2d40463f28568
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Since the database was corrupted (we were getting a Segmentation Fault when
restarting the server) we simply removed the database. I guess if we
recovered the database instead we would have gotten the same results.
Thanks for the quick fix.
Pete
On Fri, Feb 27, 2009 at 10:44 PM, Howard Chu <hyc(a)symas.com> wrote:
> pgiesin(a)gmail.com wrote:
>
>> Full_Name: Peter Giesin
>> Version: 2.4.13
>> OS: Red Hat 5.2
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (24.187.213.234)
>>
>>
>> Enabled both accesslog and ppolicy overlays (configurations included
>> below). All
>> attempts to bind with an invalid password causes the server to crash and
>> database to be corrupted. If you disable either of the overlays or just
>> the
>> "logold" setting of the accesslog the behavior is no longer noticed.
>>
>
> Interesting, for me only the first attempt crashed; after restarting the
> same attempt just failed normally. Anyway, thanks for the report, this is
> now fixed in HEAD.
>
> overlay ppolicy
>> ppolicy_default cn=Standard,ou=Policies,dc=amwater,dc=com
>> ppolicy_use_lockout TRUE
>> ppolicy_hash_cleartext TRUE
>>
>> overlay accesslog
>> logdb cn=log
>> logops all
>> logold (objectclass=*)
>> logpurge 5+00:00 1+00:00
>> logsuccess TRUE
>>
>> dn: cn=Standard,ou=Policies,dc=amwater,dc=com
>> cn: Standard
>> description: Standard password policy.
>> pwdAttribute: 2.5.4.35
>> pwdMinAge: 60
>> # 30 days: 60 sec * 60 min * 24 hr * 30 days
>> pwdMaxAge: 2592000
>> pwdCheckQuality: 1
>> pwdMinLength: 7
>> # Warn three days in advance
>> pwdExpireWarning: 259200
>> pwdGraceAuthNLimit: 3
>> pwdLockout: TRUE
>> pwdLockoutDuration: 1200
>> pwdMaxFailure: 3
>> pwdFailureCountInterval: 1200
>> pwdMustChange: TRUE
>> pwdAllowUserChange: TRUE
>> pwdSafeModify: TRUE
>> objectclass: device
>> objectclass: pwdPolicy
>>
>>
>>
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
>
--000e0cd4d91a91c2d40463f28568
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Since the database was corrupted (we were getting a Segmentation Fault when=
restarting the server) we simply removed the database. I guess if we recov=
ered the database instead we would have gotten the same results.<br><br>
Thanks for the quick fix.<br><br>Pete<br><br><div class=3D"gmail_quote">On =
Fri, Feb 27, 2009 at 10:44 PM, Howard Chu <span dir=3D"ltr"><<a href=3D"=
mailto:hyc@symas.com">hyc(a)symas.com</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); mar=
gin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<a href=3D"mailto:pgiesin@gmail.com" target=3D"_blank">pgiesin(a)gmail.com</a=
> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Full_Name: Peter Giesin<br>
Version: 2.4.13<br>
OS: Red Hat 5.2<br>
URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f=
tp.openldap.org/incoming/</a><br>
Submission from: (NULL) (24.187.213.234)<br>
<br>
<br>
Enabled both accesslog and ppolicy overlays (configurations included below)=
. All<br>
attempts to bind with an invalid password causes the server to crash and<br=
>
database to be corrupted. If you disable either of the overlays or just the=
<br>
"logold" setting of the accesslog the behavior is no longer notic=
ed.<br>
</blockquote>
<br>
Interesting, for me only the first attempt crashed; after restarting the sa=
me attempt just failed normally. Anyway, thanks for the report, this is now=
fixed in HEAD.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
overlay ppolicy<br>
ppolicy_default cn=3DStandard,ou=3DPolicies,dc=3Damwater,dc=3Dcom<br>
ppolicy_use_lockout TRUE<br>
ppolicy_hash_cleartext TRUE<br>
<br>
overlay accesslog<br>
logdb cn=3Dlog<br>
logops all<br>
logold (objectclass=3D*)<br>
logpurge 5+00:00 1+00:00<br>
logsuccess TRUE<br>
<br>
dn: cn=3DStandard,ou=3DPolicies,dc=3Damwater,dc=3Dcom<br>
cn: Standard<br>
description: Standard password policy.<br>
pwdAttribute: 2.5.4.35<br>
pwdMinAge: 60<br>
# 30 days: 60 sec * 60 min * 24 hr * 30 days<br>
pwdMaxAge: 2592000<br>
pwdCheckQuality: 1<br>
pwdMinLength: 7<br>
# Warn three days in advance<br>
pwdExpireWarning: 259200<br>
pwdGraceAuthNLimit: 3<br>
pwdLockout: TRUE<br>
pwdLockoutDuration: 1200<br>
pwdMaxFailure: 3<br>
pwdFailureCountInterval: 1200<br>
pwdMustChange: TRUE<br>
pwdAllowUserChange: TRUE<br>
pwdSafeModify: TRUE<br>
objectclass: device<br>
objectclass: pwdPolicy<br>
<br>
<br>
</blockquote>
<br>
<br>
-- <br>
=C2=A0-- Howard Chu<br>
=C2=A0CTO, Symas Corp. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http:=
//www.symas.com" target=3D"_blank">http://www.symas.com</a><br>
=C2=A0Director, Highland Sun =C2=A0 =C2=A0 <a href=3D"http://highlandsun.c=
om/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a><br>
=C2=A0Chief Architect, OpenLDAP =C2=A0<a href=3D"http://www.openldap.org/p=
roject/" target=3D"_blank">http://www.openldap.org/project/</a><br>
</blockquote></div><br>
--000e0cd4d91a91c2d40463f28568--
14 years, 3 months
Re: (ITS#5979) ppolicy & access log crashes server
by hyc@symas.com
pgiesin(a)gmail.com wrote:
> Full_Name: Peter Giesin
> Version: 2.4.13
> OS: Red Hat 5.2
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (24.187.213.234)
>
>
> Enabled both accesslog and ppolicy overlays (configurations included below). All
> attempts to bind with an invalid password causes the server to crash and
> database to be corrupted. If you disable either of the overlays or just the
> "logold" setting of the accesslog the behavior is no longer noticed.
Interesting, for me only the first attempt crashed; after restarting the same
attempt just failed normally. Anyway, thanks for the report, this is now fixed
in HEAD.
> overlay ppolicy
> ppolicy_default cn=Standard,ou=Policies,dc=amwater,dc=com
> ppolicy_use_lockout TRUE
> ppolicy_hash_cleartext TRUE
>
> overlay accesslog
> logdb cn=log
> logops all
> logold (objectclass=*)
> logpurge 5+00:00 1+00:00
> logsuccess TRUE
>
> dn: cn=Standard,ou=Policies,dc=amwater,dc=com
> cn: Standard
> description: Standard password policy.
> pwdAttribute: 2.5.4.35
> pwdMinAge: 60
> # 30 days: 60 sec * 60 min * 24 hr * 30 days
> pwdMaxAge: 2592000
> pwdCheckQuality: 1
> pwdMinLength: 7
> # Warn three days in advance
> pwdExpireWarning: 259200
> pwdGraceAuthNLimit: 3
> pwdLockout: TRUE
> pwdLockoutDuration: 1200
> pwdMaxFailure: 3
> pwdFailureCountInterval: 1200
> pwdMustChange: TRUE
> pwdAllowUserChange: TRUE
> pwdSafeModify: TRUE
> objectclass: device
> objectclass: pwdPolicy
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 3 months
RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart@informatique.gov.pf
Name of the tarball posted on ftp.openldap.org :
philippe_eychart_openldap_x-dnssrv_20090227.tgz.
Content:
- file1 : openldap-2.4.13-i486-1.x-dnssrv.open.c.20090227.patch (8918
bytes)
- file2 : openldap-2.4.13-i486-1.rfc2782-priOnly.dnssrv.c.20090227.patch
(5437 bytes) (necessary to patch1 because of the possible empty domain
argument option - and, of course, to implement the priority notion ...)
Regards
14 years, 3 months
RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart@informatique.gov.pf
I must be tired !... ;)
The good result is ... :
"ldap://ldap.gov.pf.:389/o=gov%2cc=pf \
ldap://ldap2.backup.gov.pf.:390/o=gov%2cc=pf \
ldap://ldap1.backup.gov.pf.:389/o=gov%2cc=pf"
yes!!!
-----Message d'origine-----
De : Philippe EYCHART [mailto:philippe.eychart@informatique.gov.pf]
Envoyé : vendredi 27 février 2009 13:39
À : openldap-its(a)openldap.org
Objet : RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
Sorry : error in the last warning example !...
"ldap:///o=gov%2cc=pf????x-dnssrv" correct, but because of the default
domain search (cf. resolv.conf) - not because of "o=gov,c=pf" (which isn't
the dn of a domaine) ...
-> give (of course):
"ldap://ldap.gov.pf:389/o=gov%2cc=pf \
ldap://ldap1.backup.gov.pf:390/o=gov%2cdc=pf \
ldap://ldap2.backup.gov.pf:389/o=gov%2cdc=pf"
--
PE
14 years, 3 months
RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart@informatique.gov.pf
Sorry : error in the last warning example !...
"ldap:///o=gov%2cc=pf????x-dnssrv" correct, but because of the default
domain search (cf. resolv.conf) - not because of "o=gov,c=pf" (which isn't
the dn of a domaine) ...
-> give (of course):
"ldap://ldap.gov.pf.:389/o=gov%2cc=pf \
ldap://ldap1.backup.gov.pf.:390/o=gov%2cdc=pf \
ldap://ldap2.backup.gov.pf.:389/o=gov%2cdc=pf"
--
PE
14 years, 3 months
RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart@informatique.gov.pf
Hi,
Here is the description of use of the current version of the "x-dnssrv"
extension through some examples:
CONTEXT OF EXAMPLE :
/etc/resolv.conf:
search gov.pf
nameserver localhost
/var/named/pz/gov.pf:
$ORIGIN gov.pf.
...
_ldap._tcp IN SRV 0 1 389 ldap
IN SRV 1 1 389 ldap1.backup.gov.pf.
IN SRV 1 1 390 ldap2.backup.gov.pf.
...
and /var/named/pz/backup.gov.pf:
$ORIGIN backup.gov.pf.
...
_ldap._tcp IN SRV 0 1 389 ldap0
IN SRV 0 1 389 ldap1
...
LDAP URI EXAMPLES FOR THE "x-dnssrv" EXTENSION:
For: "ldap:///ou=person,dc=gov,dc=pf??sub??x-dnssrv=dc=gov%2cdc=pf"
-> the result URI will be:
"ldap://ldap.gov.pf.:389/ou=person,dc=gov,dc=pf??sub \
ldap://ldap1.backup.gov.pf.:389/ou=person,dc=gov,dc=pf??sub \
ldap://ldap2.backup.gov.pf.:390/ou=person,dc=gov,dc=pf??sub"
For: "ldap:///????x-dnsSRV=gov.pf."
-> the result URI will be:
"ldap://ldap.gov.pf.:389 ldap://ldap2.backup.gov.pf.:390 /
ldap://ldap1.backup.gov.pf.:389"
For: "ldap:///dc=gov%2cdc=pf????x-dnssrv"
-> the result URI will be:
"ldap://ldap.gov.pf.:389/dc=gov%2cdc=pf \
ldap://ldap1.backup.gov.pf.:389/dc=gov%2cdc=pf \
ldap://ldap2.backup.gov.pf.:390/dc=gov%2cdc=pf"
For: "ldap://gov.pf.:389/????x-dnssrv"
-> the result URI will be:
"ldap://ldap.gov.pf.:389 ldap://ldap1.backup.gov.pf.:389"
For: "ldap:///????x-dnssrv[,extension]*"
-> because of resolv.conf, the result URI will be:
"ldap://ldap.gov.pf.:389/????[extension[,extension]*]* \
ldap://ldap1.backup.gov.pf.:389/????[extension[,extension]*]* \
ldap://ldap2.backup.gov.pf.:390/????[extension[,extension]*]*"
WARNING:
"ldap://goov.pf./????x-dnssrv"
-> give: ""
"ldap://gov.pf./????x-dnssrv,x-dnssrv=dc=backup%2cdc=gov%2cdc=pf"
-> give:
"ldap://ldap.gov.pf.:389/????x-dnssrv=dc=backup%2cdc=gov%2cdc=pf \
ldap://ldap2.backup.gov.pf.:389/????x-dnssrv=dc=backup%2cdc=gov%2cdc=pf \
ldap://ldap1.backup.gov.pf.:390/????x-dnssrv=dc=backup%2cdc=gov%2cdc=pf"
"ldap:///dc=gov%2cdc=pf???sub?x-dnssrv=dc=backup%2cdc=gov%2cdc=pf"
-> give:
"ldap://ldap0.backup.gov.pf.:389/dc=gov,dc=pf???sub \
ldap://ldap1.backup.gov.pf.:389/dc=gov,dc=pf???sub"
"ldap://ldap.gov.pf/dc=backup%2cdc=gov%2cdc=pf????x-dnssrv"
-> give:
"ldap://ldap.gov.pf.:389/dc=backup%2cdc=gov%2cdc=pf \
ldap://ldap2.backup.gov.pf.:389/dc=backup%2cdc=gov%2cdc=pf \
ldap://ldap1.backup.gov.pf.:390/dc=backup%2cdc=gov%2cdc=pf"
"ldap:///o=gov%2cc=pf????x-dnssrv" correct, but because of default the
domain research ...
-> give:
"ldap://ldap.gov.pf.:389/????x-dnssrv=dc=backup%2cdc=gov%2cdc=pf \
ldap://ldap1.backup.gov.pf.:390/????x-dnssrv=dc=backup%2cdc=gov%2cdc=pf \
ldap://ldap2.backup.gov.pf.:389/????x-dnssrv=dc=backup%2cdc=gov%2cdc=pf"
SYNTAX ERROR (the resultant URI will remain unchanged):
"ldap://ldap.gov.pf/dc=gov%2cdc=pf????x-dnssrv=dc=gov%2cdc=pf"
"ldap://ldap.gov.pf/????x-dnssrv=dc=gov%2cdc=pf"
"ldap://ldap.gov.pf/????x-dnssrv=gov.pf."
"ldap://dc=gov%2cdc=pf/????x-dnssrv"
"ldap://gov.pf[/[?[?[?[?]]]]]"
etc ...
I proceed in the last check of sources and I post patchs (open.c & dnssrv.c)
...
--
PE
14 years, 3 months
(ITS#5979) ppolicy & access log crashes server
by pgiesin@gmail.com
Full_Name: Peter Giesin
Version: 2.4.13
OS: Red Hat 5.2
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (24.187.213.234)
Enabled both accesslog and ppolicy overlays (configurations included below). All
attempts to bind with an invalid password causes the server to crash and
database to be corrupted. If you disable either of the overlays or just the
"logold" setting of the accesslog the behavior is no longer noticed.
overlay ppolicy
ppolicy_default cn=Standard,ou=Policies,dc=amwater,dc=com
ppolicy_use_lockout TRUE
ppolicy_hash_cleartext TRUE
overlay accesslog
logdb cn=log
logops all
logold (objectclass=*)
logpurge 5+00:00 1+00:00
logsuccess TRUE
dn: cn=Standard,ou=Policies,dc=amwater,dc=com
cn: Standard
description: Standard password policy.
pwdAttribute: 2.5.4.35
pwdMinAge: 60
# 30 days: 60 sec * 60 min * 24 hr * 30 days
pwdMaxAge: 2592000
pwdCheckQuality: 1
pwdMinLength: 7
# Warn three days in advance
pwdExpireWarning: 259200
pwdGraceAuthNLimit: 3
pwdLockout: TRUE
pwdLockoutDuration: 1200
pwdMaxFailure: 3
pwdFailureCountInterval: 1200
pwdMustChange: TRUE
pwdAllowUserChange: TRUE
pwdSafeModify: TRUE
objectclass: device
objectclass: pwdPolicy
14 years, 3 months