Re: (ITS#8501) OpenLdap not RFC 2891 complaint
by hyc＠symas.com
mblagoeva(a)axway.com wrote:
> Full_Name: Maria Blagoeva
> Version: openldap-2.4.31/debian/build/servers/slapd
> OS: docker image with 3.10.0-327.28.2.el7.x86_64
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (194.88.228.86)
>
>
> It seems that openldap as of 2.4.31 is not RFC complaint
> (https://www.ietf.org/rfc/rfc2891.txt) due to failure in response when ordering
> match rule is empty while doing server side sorting. Example below:
False. OpenLDAP is completely correct and RFC-compliant in its behavior.
> empty ordering rule:
>
> ldapsearch -E sss=cn '(cn=ccc*)' cn' (&(objectClass=inetOrgPerson)(cn=ccc*))' -H
> ldap://IP:389 -b "ou=Users,dc=openstack,dc=org" -D "cn=aaa1,
> ou=Users,dc=openstack,dc=org" -x -W
> # extended LDIF
> #
> # LDAPv3
> # base <ou=Users,dc=openstack,dc=org> with scope subtree
> # filter: (cn=ccc*)
> # requesting: cn (&(objectClass=inetOrgPerson)(cn=ccc*))
> # with server side sorting control
> #
>
> # search result
> search: 2
> result: 18 Inappropriate matching
> text: serverSort control: No ordering rule
This result is correct since the cn attribute has no ordering rule defined in
the schema.
>
> # numResponses: 1
>
> caseIgnoreOrderingMatch ordering rule:
>
> ldapsearch -E sss=cn:caseIgnoreOrderingMatch '(cn=ccc*)' cn'
> (&(objectClass=inetOrgPerson)(cn=ccc*))' -H ldap://IP:389 -b
> "ou=Users,dc=openstack,dc=org" -D "c3D3Daaa1, ou=Users,dc=openstack,dc=org" -x
> -W
> # extended LDIF
> #
> # LDAPv3
> # base <ou=Users,dc=openstack,dc=org> with scope subtree
> # filter: (cn=ccc*)
> # requesting: cn (&(objectClass=inetOrgPerson)(cn=ccc*))
> # with server side sorting control
> #
>
> # ccc0, Users, openstack.org
> dn: cn=ccc0,ou=Users,dc=openstack,dc=org
> # search result
> search: 2
> result: 0 Success
> control: 1.2.840.113556.1.4.474 false MAMKAQA=
> sortResult: (0) Success
>
>
> however the RFC states that the orderingRule is OPTIONAL as below:
>
> SortKeyList ::= SEQUENCE OF SEQUENCE {
> attributeType AttributeDescription,
> orderingRule [0] MatchingRuleId OPTIONAL,
> reverseOrder [1] BOOLEAN DEFAULT FALSE }
>
> however openldap fails to return entries.
The rule is optional in the control itself, but a valid ordering rule must
exist somewhere. Since the attribute schema doesn't define one then you must
provide one yourself.
Closing 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/
6 years, 6 months
(ITS#8501) OpenLdap not RFC 2891 complaint
by mblagoeva＠axway.com
Full_Name: Maria Blagoeva
Version: openldap-2.4.31/debian/build/servers/slapd
OS: docker image with 3.10.0-327.28.2.el7.x86_64
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (194.88.228.86)
It seems that openldap as of 2.4.31 is not RFC complaint
(https://www.ietf.org/rfc/rfc2891.txt) due to failure in response when ordering
match rule is empty while doing server side sorting. Example below:
empty ordering rule:
ldapsearch -E sss=cn '(cn=ccc*)' cn' (&(objectClass=inetOrgPerson)(cn=ccc*))' -H
ldap://IP:389 -b "ou=Users,dc=openstack,dc=org" -D "cn=aaa1,
ou=Users,dc=openstack,dc=org" -x -W
# extended LDIF
#
# LDAPv3
# base <ou=Users,dc=openstack,dc=org> with scope subtree
# filter: (cn=ccc*)
# requesting: cn (&(objectClass=inetOrgPerson)(cn=ccc*))
# with server side sorting control
#
# search result
search: 2
result: 18 Inappropriate matching
text: serverSort control: No ordering rule
# numResponses: 1
caseIgnoreOrderingMatch ordering rule:
ldapsearch -E sss=cn:caseIgnoreOrderingMatch '(cn=ccc*)' cn'
(&(objectClass=inetOrgPerson)(cn=ccc*))' -H ldap://IP:389 -b
"ou=Users,dc=openstack,dc=org" -D "c3D3Daaa1, ou=Users,dc=openstack,dc=org" -x
-W
# extended LDIF
#
# LDAPv3
# base <ou=Users,dc=openstack,dc=org> with scope subtree
# filter: (cn=ccc*)
# requesting: cn (&(objectClass=inetOrgPerson)(cn=ccc*))
# with server side sorting control
#
# ccc0, Users, openstack.org
dn: cn=ccc0,ou=Users,dc=openstack,dc=org
# search result
search: 2
result: 0 Success
control: 1.2.840.113556.1.4.474 false MAMKAQA=
sortResult: (0) Success
however the RFC states that the orderingRule is OPTIONAL as below:
SortKeyList ::= SEQUENCE OF SEQUENCE {
attributeType AttributeDescription,
orderingRule [0] MatchingRuleId OPTIONAL,
reverseOrder [1] BOOLEAN DEFAULT FALSE }
however openldap fails to return entries.
6 years, 6 months
(ITS#8500) typo in slapo-ppolicy(5)
by michael＠stroeder.com
Full_Name:
Version: git master
OS: -
URL:
Submission from: (NULL) (85.115.23.42)
diff --git a/doc/man/man5/slapo-ppolicy.5 b/doc/man/man5/slapo-ppolicy.5
index 91e0f8f..8306f97 100644
--- a/doc/man/man5/slapo-ppolicy.5
+++ b/doc/man/man5/slapo-ppolicy.5
@@ -104,7 +104,7 @@ object class. The definition of that class is as follows:
pwdLockout $ pwdLockoutDuration $
pwdMaxFailure $ pwdFailureCountInterval $
pwdMustChange $ pwdAllowUserChange $
- pwdSafeModify 4 pwdMaxRecordedFailure ) )
+ pwdSafeModify $ pwdMaxRecordedFailure ) )
.RE
This implementation also provides an additional
6 years, 6 months
Re: (ITS#8498) slapadd complains about missing attrs
by quanah＠zimbra.com
--On Friday, September 09, 2016 11:32 PM +0100 Howard Chu <hyc(a)symas.com>
wrote:
>> I'd generally expect the warning to be consistently shown (or not). I
>> don't think it's valid in the case of "".
>
> The warning is only printed in single-master replication configs.
My point is the warning is invalid, and it was printed on the replica,
nothing to do with a master...
--Quanah
--
Quanah Gibson-Mount
6 years, 6 months
Re: (ITS#8498) slapadd complains about missing attrs
by hyc＠symas.com
quanah(a)openldap.org wrote:
> Full_Name: Quanah Gibson-Mount
> Version: 2.4.44+ITS8432
> OS: Linux 3.13
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (75.111.52.177)
>
>
> When slapadding a database rooted at "" on a replica, it outputs the following
> warning:
>
> zimbra@zre-ldap014:~$ time ./libexec/zmslapadd
> /home/build/ldap.bak.20160909144406
> 57d32561 slapadd: warning, missing attrs entryUUID,entryCSN from entry dn=""
> -######## 42.58% eta 01m39s elapsed 01m13s spd 292.8 k/s
>
>
> Interestingly enough, when slapadded to a master with cn=accesslog in play, it
> doesn't output anything:
>
> zimbra@zre-ldap008:~$ ./libexec/zmslapadd /home/build/ldap.bak.20160909144406
> *#################### 100.00% eta none elapsed 02m45s spd 3.1 M/s
> Closing DB...
>
> I'd generally expect the warning to be consistently shown (or not). I don't
> think it's valid in the case of "".
The warning is only printed in single-master replication configs.
Closing 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/
6 years, 6 months
(ITS#8498) slapadd complains about missing attrs
by quanah＠openldap.org
Full_Name: Quanah Gibson-Mount
Version: 2.4.44+ITS8432
OS: Linux 3.13
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.111.52.177)
When slapadding a database rooted at "" on a replica, it outputs the following
warning:
zimbra@zre-ldap014:~$ time ./libexec/zmslapadd
/home/build/ldap.bak.20160909144406
57d32561 slapadd: warning, missing attrs entryUUID,entryCSN from entry dn=""
-######## 42.58% eta 01m39s elapsed 01m13s spd 292.8 k/s
Interestingly enough, when slapadded to a master with cn=accesslog in play, it
doesn't output anything:
zimbra@zre-ldap008:~$ ./libexec/zmslapadd /home/build/ldap.bak.20160909144406
*#################### 100.00% eta none elapsed 02m45s spd 3.1 M/s
Closing DB...
I'd generally expect the warning to be consistently shown (or not). I don't
think it's valid in the case of "".
6 years, 6 months
Re: (ITS#8490) changes not written to accesslog, causing replicas to loop syncing
by quanah＠zimbra.com
--On Thursday, September 01, 2016 9:50 AM +0000 quanah(a)zimbra.com wrote:
I finally was able to reproduce this in a new lab of servers I set up. The
easiest way to reproduce this problem is to have 2 masters, and 6 replicas.
3 replicas pointing to each master.
In my case, I have ldap07 through ldap014. 07/08 are the masters. Odd
number replicas (9,11,13) point to 07, even number replicas point to 08
(10, 12, 14).
What we find based on the logs is two MODRDNs coming in at approximately
the same time:
Sep 9 15:29:40 zre-ldap007 slapd[13794]: conn=1389 op=3179 MODRDN
dn="uid=user.345,ou=people,dc=zre-ldap007,dc=eng,dc=zimbra,dc=com"
Sep 9 15:29:40 zre-ldap007 slapd[13794]: conn=1120 op=2919 MODRDN
dn="uid=user.250404,ou=people,dc=zre-ldap007,dc=eng,dc=zimbra,dc=com"
Sep 9 15:29:40 zre-ldap007 slapd[13794]: slap_queue_csn: queueing
0xa046e80 20160909192940.809794Z#000000#001#000000
Sep 9 15:29:40 zre-ldap007 slapd[13794]: slap_queue_csn: queueing
0xa046a40 20160909192940.809794Z#000000#001#000000
Sep 9 15:29:40 zre-ldap007 slapd[13794]: slap_queue_csn: queueing
0xa07b740 20160909192940.810205Z#000000#001#000000
Sep 9 15:29:40 zre-ldap007 slapd[13794]: slap_graduate_commit_csn:
removing 0xa046a40 20160909192940.809794Z#000000#001#000000
Sep 9 15:29:40 zre-ldap007 slapd[13794]: slap_queue_csn: queueing
0xa07bdc0 20160909192940.810205Z#000000#001#000000
Sep 9 15:29:40 zre-ldap007 slapd[13794]: conn=1389 op=3179 RESULT tag=109
err=0 etime=0.001278 text=
Sep 9 15:29:40 zre-ldap007 slapd[13794]: slap_graduate_commit_csn:
removing 0xa046e80 20160909192940.809794Z#000000#001#000000
Sep 9 15:29:40 zre-ldap007 slapd[13794]: slap_graduate_commit_csn:
removing 0xa07bdc0 20160909192940.810205Z#000000#001#000000
Sep 9 15:29:40 zre-ldap007 slapd[13794]: conn=1120 op=2919 RESULT tag=109
err=0 etime=0.001597 text=
Sep 9 15:29:40 zre-ldap007 slapd[13794]: slap_graduate_commit_csn:
removing 0xa07b740 20160909192940.810205Z#000000#001#000000
But in the accesslog, we only find the one MODRDN logged:
dn: reqStart=20160909192940.809465Z,cn=accesslog
objectClass: auditModRDN
structuralObjectClass: auditModRDN
reqStart: 20160909192940.809465Z
reqEnd: 20160909192940.810148Z
reqType: modrdn
reqSession: 1389
reqAuthzID: uid=zimbra,cn=admins,cn=zimbra
reqDN: uid=user.345,ou=people,dc=zre-ldap007,dc=eng,dc=zimbra,dc=com
reqResult: 0
reqMod: entryCSN:= 20160909192940.809794Z#000000#001#000000
reqMod: modifiersName:= uid=zimbra,cn=admins,cn=zimbra
reqMod: modifyTimestamp:= 20160909192940Z
reqNewRDN: uid=renamed-user.345
reqDeleteOldRDN: TRUE
reqEntryUUID: c63b246a-0a20-1036-82cb-a772509d7f53
entryUUID: 7f740e6c-0b0f-1036-8c00-b1b4f08a59fc
creatorsName: cn=config
createTimestamp: 20160909192940Z
entryCSN: 20160909192940.809794Z#000000#001#000000
modifiersName: cn=config
modifyTimestamp: 20160909192940Z
Possibly a DN collision in writing the entry to the accesslog DB that
causes the second OP to get lost. Likely the same root issue as ITS#8493.
--Quanah
--
Quanah Gibson-Mount
6 years, 6 months
Re: (ITS#8497) userPassword attribute in password policy
by quanah＠zimbra.com
--On Friday, September 09, 2016 3:38 PM +0000 sagar437(a)gmail.com wrote:
> Full_Name: Sagar Bhattarai
> Version: 2.4.40-9
> OS: CentOS Linux release 7.2.1511
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (71.174.102.218)
The ITS system is for reporting bugs, not asking usage questions.
Questions should be sent to the openldap-technical(a)openldap.org email list.
This ITS will be closed.
--Quanah
--
Quanah Gibson-Mount
6 years, 6 months
(ITS#8497) userPassword attribute in password policy
by sagar437＠gmail.com
Full_Name: Sagar Bhattarai
Version: 2.4.40-9
OS: CentOS Linux release 7.2.1511
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (71.174.102.218)
I am trying to push the password policy with the following content of ldif
file.
dn: cn=passwordDefault4,ou=policy,dc=vivox,dc=com
objectClass: pwdPolicy
objectclass: device
objectClass: top
cn: passwordDefault4
pwdAttribu%3: userPassword
pwdCheckQuality: 0
pwdMinAge: 0
pwdMaxAge: 0
pwdMinLength: 5
pwdInHistory: 5
pwdMaxFailure: 3
pwdFailureCountInterval: 0
pwdLockout: TRUE
pwdLockoutDuration: 0
pwdAllowUserChange: TRUE
pwdExpireWarning: 0
pwdGraceAuthNLimit: 0
pwdMustChange: TRUE
pwdSafeModify: TRUE
I keep getting the following error when trying to add the above policy.
ldap_add: Invalid syntax (21)
additional info: pwdAttribute: value #0 invalid per syntax
However id i change the pwdattribute vae frfrom "userPassword" to OID number i
am able to add this policy but none of these policies work on my systems.
6 years, 6 months
