openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

RE: (ITS#6985) sssvlv / greaterThanOrEqual problem
by ctcard＠hotmail.com 18 Jul '11

18 Jul '11

> >>>> Looking at the code in sssvlv.c, it uses tavl_find3() to search the values, but the > >>>> code in tavl_find3() looks to me that it only works properly with an exact match > >>>> type of matching rule: > >>>> > >>>> Avlnode * > >>>> tavl_find3( Avlnode *root, const void *data, AVL_CMP fcmp, int *ret ) > >>>> { > >>>> int cmp = -1, dir; > >>>> Avlnode *prev = root; > >>>> > >>>> while ( root != 0&& (cmp = (*fcmp)( data, root->avl_data )) != 0 ) { > >>>> prev = root; > >>>> dir = cmp> 0; > >>>> root = avl_child( root, dir ); > >>>> } > >>>> *ret = cmp; > >>>> return root ? root : prev; > >>>> } > >>>> > >>>> since the while loop terminates when the fcmp function returns 0 (i.e. exact match). > >>>> > >>> > >>> I think I've worked out where the problem is. > >>> Firstly, there's a comment before tavl_find3() saying > >>> /* > >>> * tavl_find2 - returns Avlnode instead of data pointer. > >>> * tavl_find3 - as above, but returns Avlnode even if no match is found. > >>> * also set *ret = last comparison result, or -1 if root == NULL. > >>> */ > >>> > >>> but the "or -1 if root == NULL" is not done. > > Not true; since cmp is initialized to -1, it will return -1 when the function > is entered with root == NULL. There is no bug in this part.It depends how you read the comment. If the function is *entered* with root == NULL, then I agree that -1 is returned, but if the while loop exits with root == NULL then the last comparison result is returned, which causes problems to the call in sssvlv.c.> > >>> Secondly, if no exact match is found, prev is returned which may point to a node which is less than the search > >>> node, depending on what the tree looks like, but we really want a pointer to the last node which was greater than > >>> the search node to be returned. > >>> > >>> Once these fixes are done, the correct node is returned by tavl_find3 to the call in send_list() in sssvlv.c (line 523). > > This fix is also not correct. Possibly tavl_find3() has been misused in the > sssvlv code, but this function works as designed. >Possibly. But with the patch as suggested, the sssvlv code works correctly and gets the correct node.If you think these changes might break other uses of tavl_find3() (of which there didn't seem to be many), perhapstavl_find4() could be added. > >>> There is another bug in send_list() in sssvlv.c, at lines 535-544: > >>> > >>> if ( i> 0 ) { > >>> tmp_node = tavl_end(so->so_tree, TAVL_DIR_RIGHT); > >>> dir = TAVL_DIR_LEFT; > >>> } else { > >>> tmp_node = tavl_end(so->so_tree, TAVL_DIR_LEFT); > >>> dir = TAVL_DIR_RIGHT; > >>> } > >>> for (i=0; tmp_node != cur_node; > >>> tmp_node = tavl_next( tmp_node, dir ), i++); > >>> so->so_vlv_target = i; > >>> This code is ok if the cur_node is in the left hand side of the tree, but if it is in the rhs of the tree so_vlv_target is set > >>> to an offset from the end of the list, rather than the beginning. > > OK, looks like you have a good patch for this. > > >> One more issue: the most recent draft spec for vlv (http://tools.ietf.org/html/draft-ietf-ldapext-ldapv3-vlv-09) states that the offset field in the vlv request has range 1..maxInt whereas the targetPosition in the vlv response has range 0..maxInt. > >> > >> However, my interpretation of the spec is that offset and targetPosition represent the same thing, i.e. the position of the target entry in the list, with the first entry having offset/targetPosition = 1. > >> > >> If that interpretation is correct, the assignment of so_vlv_target in the code above is off by one, since i will be zero if cur_node is at the beginning of the list. > >> > > > > I've uploaded a patch to ftp.openldap.org, incoming/Chris-Card-110708.ITS-6985-fix.patch

1 0

Re: (ITS#6985) sssvlv / greaterThanOrEqual problem
by hyc＠symas.com 18 Jul '11

18 Jul '11

ctcard(a)hotmail.com wrote: >>>> Looking at the code in sssvlv.c, it uses tavl_find3() to search the values, but the >>>> code in tavl_find3() looks to me that it only works properly with an exact match >>>> type of matching rule: >>>> >>>> Avlnode * >>>> tavl_find3( Avlnode *root, const void *data, AVL_CMP fcmp, int *ret ) >>>> { >>>> int cmp = -1, dir; >>>> Avlnode *prev = root; >>>> >>>> while ( root != 0&& (cmp = (*fcmp)( data, root->avl_data )) != 0 ) { >>>> prev = root; >>>> dir = cmp> 0; >>>> root = avl_child( root, dir ); >>>> } >>>> *ret = cmp; >>>> return root ? root : prev; >>>> } >>>> >>>> since the while loop terminates when the fcmp function returns 0 (i.e. exact match). >>>> >>> >>> I think I've worked out where the problem is. >>> Firstly, there's a comment before tavl_find3() saying >>> /* >>> * tavl_find2 - returns Avlnode instead of data pointer. >>> * tavl_find3 - as above, but returns Avlnode even if no match is found. >>> * also set *ret = last comparison result, or -1 if root == NULL. >>> */ >>> >>> but the "or -1 if root == NULL" is not done. Not true; since cmp is initialized to -1, it will return -1 when the function is entered with root == NULL. There is no bug in this part. >>> Secondly, if no exact match is found, prev is returned which may point to a node which is less than the search >>> node, depending on what the tree looks like, but we really want a pointer to the last node which was greater than >>> the search node to be returned. >>> >>> Once these fixes are done, the correct node is returned by tavl_find3 to the call in send_list() in sssvlv.c (line 523). This fix is also not correct. Possibly tavl_find3() has been misused in the sssvlv code, but this function works as designed. >>> There is another bug in send_list() in sssvlv.c, at lines 535-544: >>> >>> if ( i> 0 ) { >>> tmp_node = tavl_end(so->so_tree, TAVL_DIR_RIGHT); >>> dir = TAVL_DIR_LEFT; >>> } else { >>> tmp_node = tavl_end(so->so_tree, TAVL_DIR_LEFT); >>> dir = TAVL_DIR_RIGHT; >>> } >>> for (i=0; tmp_node != cur_node; >>> tmp_node = tavl_next( tmp_node, dir ), i++); >>> so->so_vlv_target = i; >>> This code is ok if the cur_node is in the left hand side of the tree, but if it is in the rhs of the tree so_vlv_target is set >>> to an offset from the end of the list, rather than the beginning. OK, looks like you have a good patch for this. >> One more issue: the most recent draft spec for vlv (http://tools.ietf.org/html/draft-ietf-ldapext-ldapv3-vlv-09) states that the offset field in the vlv request has range 1..maxInt whereas the targetPosition in the vlv response has range 0..maxInt. >> >> However, my interpretation of the spec is that offset and targetPosition represent the same thing, i.e. the position of the target entry in the list, with the first entry having offset/targetPosition = 1. >> >> If that interpretation is correct, the assignment of so_vlv_target in the code above is off by one, since i will be zero if cur_node is at the beginning of the list. >> > > I've uploaded a patch to ftp.openldap.org, incoming/Chris-Card-110708.ITS-6985-fix.patch > > Chris -- -- 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#6985) sssvlv / greaterThanOrEqual problem
by ctcard＠hotmail.com 16 Jul '11

16 Jul '11

[And this time in plain text ...][I thought I'd send this to the ITS list, but I only sent it to myself :-( ] > > > > > > > > > > I am running slapd built from HEAD on June 30th 2011, with back-sql > > > > > > > > Can you confirm this issue with another backend, e.g. back-bdb? Bugs > > > > specific to back-sql or to interaction with it could receive only marginal > > > > attention. > > > > > > > > p. > > > > > > > > > > I've imported my data into a server with a bdb backend, and I see the same problem. > > > > > > Looking at the code in sssvlv.c, it uses tavl_find3() to search the values, but the > > > code in tavl_find3() looks to me that it only works properly with an exact match > > > type of matching rule: > > > > > > Avlnode * > > > tavl_find3( Avlnode *root, const void *data, AVL_CMP fcmp, int *ret ) > > > { > > > int cmp = -1, dir; > > > Avlnode *prev = root; > > > > > > while ( root != 0 && (cmp = (*fcmp)( data, root->avl_data )) != 0 ) { > > > prev = root; > > > dir = cmp > 0; > > > root = avl_child( root, dir ); > > > } > > > *ret = cmp; > > > return root ? root : prev; > > > } > > > > > > since the while loop terminates when the fcmp function returns 0 (i.e. exact match). > > > > > > > I think I've worked out where the problem is. > > Firstly, there's a comment before tavl_find3() saying > > /* > > * tavl_find2 - returns Avlnode instead of data pointer. > > * tavl_find3 - as above, but returns Avlnode even if no match is found. > > * also set *ret = last comparison result, or -1 if root == NULL. > > */ > > > > but the "or -1 if root == NULL" is not done. > > > > Secondly, if no exact match is found, prev is returned which may point to a node which is less than the search > > node, depending on what the tree looks like, but we really want a pointer to the last node which was greater than > > the search node to be returned. > > > > Once these fixes are done, the correct node is returned by tavl_find3 to the call in send_list() in sssvlv.c (line 523). > > > > There is another bug in send_list() in sssvlv.c, at lines 535-544: > > > > if ( i > 0 ) { > > tmp_node = tavl_end(so->so_tree, TAVL_DIR_RIGHT); > > dir = TAVL_DIR_LEFT; > > } else { > > tmp_node = tavl_end(so->so_tree, TAVL_DIR_LEFT); > > dir = TAVL_DIR_RIGHT; > > } > > for (i=0; tmp_node != cur_node; > > tmp_node = tavl_next( tmp_node, dir ), i++); > > so->so_vlv_target = i; > > This code is ok if the cur_node is in the left hand side of the tree, but if it is in the rhs of the tree so_vlv_target is set > > to an offset from the end of the list, rather than the beginning. > > > > One more issue: the most recent draft spec for vlv (http://tools.ietf.org/html/draft-ietf-ldapext-ldapv3-vlv-09) states that the offset field in the vlv request has range 1..maxInt whereas the targetPosition in the vlv response has range 0..maxInt. > > However, my interpretation of the spec is that offset and targetPosition represent the same thing, i.e. the position of the target entry in the list, with the first entry having offset/targetPosition = 1. > > If that interpretation is correct, the assignment of so_vlv_target in the code above is off by one, since i will be zero if cur_node is at the beginning of the list. > I've uploaded a patch to ftp.openldap.org, incoming/Chris-Card-110708.ITS-6985-fix.patch Chris

1 0

RE: (ITS#6985) sssvlv / greaterThanOrEqual problem
by ctcard＠hotmail.com 16 Jul '11

16 Jul '11

--_3d71bf45-bf8f-4026-9c30-d39291bf9f56_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [I thought I'd send this to the ITS list=2C but I only sent it to myself :-= ( ] > > > > > > > > > > I am running slapd built from HEAD on June 30th 2011=2C with back= -sql > > > > > > > > Can you confirm this issue with another backend=2C e.g. back-bdb? B= ugs > > > > specific to back-sql or to interaction with it could receive only m= arginal > > > > attention. > > > > > > > > p. > > > > > > > > > > I've imported my data into a server with a bdb backend=2C and I see t= he same problem. > > > > > > Looking at the code in sssvlv.c=2C it uses tavl_find3() to search the= values=2C but the > > > code in tavl_find3() looks to me that it only works properly with an = exact match > > > type of matching rule: > > > > > > Avlnode * > > > tavl_find3( Avlnode *root=2C const void *data=2C AVL_CMP fcmp=2C int = *ret ) > > > { > > > int cmp =3D -1=2C dir=3B > > > Avlnode *prev =3D root=3B > > > > > > while ( root !=3D 0 && (cmp =3D (*fcmp)( data=2C root->avl_data )) != =3D 0 ) { > > > prev =3D root=3B > > > dir =3D cmp > 0=3B > > > root =3D avl_child( root=2C dir )=3B > > > } > > > *ret =3D cmp=3B > > > return root ? root : prev=3B > > > } > > > > > > since the while loop terminates when the fcmp function returns 0 (i.e= . exact match). > > > > > > > I think I've worked out where the problem is. > > Firstly=2C there's a comment before tavl_find3() saying > > /* > > * tavl_find2 - returns Avlnode instead of data pointer. > > * tavl_find3 - as above=2C but returns Avlnode even if no match is foun= d. > > * also set *ret =3D last comparison result=2C or -1 if root =3D=3D NULL= . > > */ > > > > but the "or -1 if root =3D=3D NULL" is not done. > > > > Secondly=2C if no exact match is found=2C prev is returned which may po= int to a node which is less than the search > > node=2C depending on what the tree looks like=2C but we really want a p= ointer to the last node which was greater than > > the search node to be returned. > > > > Once these fixes are done=2C the correct node is returned by tavl_find3= to the call in send_list() in sssvlv.c (line 523). > > > > There is another bug in send_list() in sssvlv.c=2C at lines 535-544: > > > > if ( i > 0 ) { > > tmp_node =3D tavl_end(so->so_tree=2C TAVL_DIR_RIGHT)=3B > > dir =3D TAVL_DIR_LEFT=3B > > } else { > > tmp_node =3D tavl_end(so->so_tree=2C TAVL_DIR_LEFT)=3B > > dir =3D TAVL_DIR_RIGHT=3B > > } > > for (i=3D0=3B tmp_node !=3D cur_node=3B > > tmp_node =3D tavl_next( tmp_node=2C dir )=2C i++)=3B > > so->so_vlv_target =3D i=3B > > This code is ok if the cur_node is in the left hand side of the tree=2C= but if it is in the rhs of the tree so_vlv_target is set > > to an offset from the end of the list=2C rather than the beginning. > > > > One more issue: the most recent draft spec for vlv (http://tools.ietf.org= /html/draft-ietf-ldapext-ldapv3-vlv-09) states that the offset field in the= vlv request has range 1..maxInt whereas the targetPosition in the vlv resp= onse has range 0..maxInt. > > However=2C my interpretation of the spec is that offset and targetPositio= n represent the same thing=2C i.e. the position of the target entry in the = list=2C with the first entry having offset/targetPosition =3D 1. > > If that interpretation is correct=2C the assignment of so_vlv_target in t= he code above is off by one=2C since i will be zero if cur_node is at the b= eginning of the list. > I've uploaded a patch to ftp.openldap.org=2C incoming/Chris-Card-110708.ITS= -6985-fix.patch Chris = --_3d71bf45-bf8f-4026-9c30-d39291bf9f56_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style></style> </head> <body class=3D'hmmessage'><div dir=3D'ltr'> [I thought I'd send this to the ITS list=2C but I only sent it to myself :-= ( ] <div> &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt= =3B &gt=3B &gt=3B I am running slapd built from HEAD on June 30th 2011=2C w= ith back-sql &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B = Can you confirm this issue with another backend=2C e.g. back-bdb? Bugs &= gt=3B &gt=3B &gt=3B &gt=3B specific to back-sql or to interaction with it c= ould receive only marginal &gt=3B &gt=3B &gt=3B &gt=3B attention. &gt= =3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B p. &gt=3B &gt=3B= &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B I've importe= d my data into a server with a bdb backend=2C and I see the same problem.<b= r>&gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B Looking at the code in sssvl= v.c=2C it uses tavl_find3() to search the values=2C but the &gt=3B &gt= =3B &gt=3B code in tavl_find3() looks to me that it only works properly wit= h an exact match &gt=3B &gt=3B &gt=3B type of matching rule: &gt=3B &= gt=3B &gt=3B &gt=3B &gt=3B &gt=3B Avlnode * &gt=3B &gt=3B &gt=3B tavl= _find3( Avlnode *root=2C const void *data=2C AVL_CMP fcmp=2C int *ret ) = &gt=3B &gt=3B &gt=3B { &gt=3B &gt=3B &gt=3B int cmp =3D -1=2C dir=3B = &gt=3B &gt=3B &gt=3B Avlnode *prev =3D root=3B &gt=3B &gt=3B &gt=3B &= gt=3B &gt=3B &gt=3B while ( root !=3D 0 &amp=3B&amp=3B (cmp =3D (*fcmp)( da= ta=2C root-&gt=3Bavl_data )) !=3D 0 ) { &gt=3B &gt=3B &gt=3B prev =3D ro= ot=3B &gt=3B &gt=3B &gt=3B dir =3D cmp &gt=3B 0=3B &gt=3B &gt=3B &gt= =3B root =3D avl_child( root=2C dir )=3B &gt=3B &gt=3B &gt=3B } &gt= =3B &gt=3B &gt=3B *ret =3D cmp=3B &gt=3B &gt=3B &gt=3B return root ? roo= t : prev=3B &gt=3B &gt=3B &gt=3B } &gt=3B &gt=3B &gt=3B &gt=3B &gt= =3B &gt=3B since the while loop terminates when the fcmp function returns 0= (i.e. exact match). &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt= =3B I think I've worked out where the problem is. &gt=3B &gt=3B Firstly= =2C there's a comment before tavl_find3() saying &gt=3B &gt=3B /* &gt= =3B &gt=3B * tavl_find2 - returns Avlnode instead of data pointer. &gt= =3B &gt=3B * tavl_find3 - as above=2C but returns Avlnode even if no match = is found. &gt=3B &gt=3B * also set *ret =3D last comparison result=2C or= -1 if root =3D=3D NULL. &gt=3B &gt=3B */ &gt=3B &gt=3B &gt=3B &gt= =3B but the "or -1 if root =3D=3D NULL" is not done. &gt=3B &gt=3B &g= t=3B &gt=3B Secondly=2C if no exact match is found=2C prev is returned whic= h may point to a node which is less than the search &gt=3B &gt=3B node= =2C depending on what the tree looks like=2C but we really want a pointer t= o the last node which was greater than &gt=3B &gt=3B the search node to = be returned. &gt=3B &gt=3B &gt=3B &gt=3B Once these fixes are done=2C= the correct node is returned by tavl_find3 to the call in send_list() in s= ssvlv.c (line 523). &gt=3B &gt=3B &gt=3B &gt=3B There is another bug = in send_list() in sssvlv.c=2C at lines 535-544: &gt=3B &gt=3B &gt=3B = &gt=3B if ( i &gt=3B 0 ) { &gt=3B &gt=3B tmp_node =3D tavl_end(so-&gt=3B= so_tree=2C TAVL_DIR_RIGHT)=3B &gt=3B &gt=3B dir =3D TAVL_DIR_LEFT=3B = &gt=3B &gt=3B } else { &gt=3B &gt=3B tmp_node =3D tavl_end(so-&gt=3Bso_t= ree=2C TAVL_DIR_LEFT)=3B &gt=3B &gt=3B dir =3D TAVL_DIR_RIGHT=3B &gt= =3B &gt=3B } &gt=3B &gt=3B for (i=3D0=3B tmp_node !=3D cur_node=3B &g= t=3B &gt=3B tmp_node =3D tavl_next( tmp_node=2C dir )=2C i++)=3B &gt=3B = &gt=3B so-&gt=3Bso_vlv_target =3D i=3B &gt=3B &gt=3B This code is ok if = the cur_node is in the left hand side of the tree=2C but if it is in the rh= s of the tree so_vlv_target is set &gt=3B &gt=3B to an offset from the e= nd of the list=2C rather than the beginning. &gt=3B &gt=3B &gt=3B = &gt=3B One more issue: the most recent draft spec for vlv (http://tools.iet= f.org/html/draft-ietf-ldapext-ldapv3-vlv-09) states that the offset field i= n the vlv request has range 1..maxInt whereas the targetPosition in the vlv= response has range 0..maxInt. &gt=3B &gt=3B However=2C my interpreta= tion of the spec is that offset and targetPosition represent the same thing= =2C i.e. the position of the target entry in the list=2C with the first ent= ry having offset/targetPosition =3D 1. &gt=3B &gt=3B If that interpre= tation is correct=2C the assignment of so_vlv_target in the code above is o= ff by one=2C since i will be zero if cur_node is at the beginning of the li= st. &gt=3B I've uploaded a patch to ftp.openldap.org=2C incoming/= Chris-Card-110708.ITS-6985-fix.patch </div><div>Chris </div> = </div></body> </html>= --_3d71bf45-bf8f-4026-9c30-d39291bf9f56_--

1 0

(ITS#6996) Bad cn=config quotes in Admin Guide
by h.b.furuseth＠usit.uio.no 15 Jul '11

15 Jul '11

Full_Name: Hallvard B Furuseth Version: master, 2.4.26 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard http://www.openldap.org/doc/admin24/slapdconf2.html contains a number of examples with quoted DNs in cn=config attributes: olcSuffix, olcRootDN. This is wrong, likely a cut&paste from slapd.conf.

1 0

Re: (ITS#6770) Proxy authorization fails with SASL-GSSAPI
by c.waeschenfelder＠websale.de 15 Jul '11

15 Jul '11

Same problem here: If I use the cn=config style, proxy authorization works directly after configuring it. If I reboot the slave server the authorization fails to work and the bindmethod switches from SASL/GSSAPI to SIMPLE. If I delete the configuration directory /etc/ldap/slapd.d and use a simple /etc/ldap/slapd.conf and make the same configuration the old way everything keeps working after reboots. So I think there is a Problem while loading the cn=config configuration.

1 0

(ITS#6995) Request for Contribution of Identity Access Management Software to OpenLDAP Project
by shawn.mckinney＠jtstools.com 14 Jul '11

14 Jul '11

Full_Name: Shawn McKinney Version: All OS: All URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (99.34.198.251) Hello, We have created a new Identity and Access Management SDK, called Fortress, that uses Java and OpenLDAP to provide authentication, RBAC, ARBAC, password policies, auditing and more. It has taken us 2.5 years of steady work to get it ready for this 1.0 release. This SDK has approximately 50K lines of Java code of which approximately 25K are dedicated to testing using JUnit automated tests to ensure it works correctly. There are in excess of 100 public APIs available for use. There is also a Java EE container plug-in that provides authentication and authorization services to Websphere, Tomcat and JBoss app servers in a declarative fashion. This product has not been published and we would like to release it as one of the products under OpenLDAP family of products. The product will be released under New BSD open source license (license information is contained in the source archives on ftp server). I have uploaded seven packages to our FTP server that contain the source, documentation and other items for you to look at. host: jtstools.com user: jtsguest1 pw: OpenLd@p1 The packages are as follows: Fortress Core SDK 1. source - fortressSrc-1.0.0-rc1.zip - 352K bytes 2. source - fortressTestSrc-1.0.0-rc1.zip - 159K bytes 3. tutorial/doc - fortressSamples-1.0.0-rc1.zip - 766K bytes 4. javadoc - fortressDoc-1.0.0-rc1.zip - 1.4M bytes 5. ldap (folder) - Fortress schema and OpenLDAP slapd.conf Fortress Realm (Java EE Container plug-ins) 6. source - fortressRealmSrc-1.0.0-rc1.zip - 45K bytes 7. javadoc - fortressRealmDoc-1.0.0-rc1.zip - 76K bytes Package 4 contains complete javadoc for the APIs. In package 4, this link, ./fortressDoc-1.0.0-rc1/index.html, contains the overall summary of the SDK. this link, ./oamCore/trunk/dist/docs/api/index.html, contains package descriptions along with detailed documentation describing the contents of the SDK. What we are requesting from the OpenLDAP foundation: 1. Source code repository to host the SDK and Realm packages. 2. Bug tracking. 3. Developer and User forums. 4. Wiki (this is a nice to have) Our goal is to run the open source project with your organization and cultivate a healthy developer and user community. We have high hopes for this product (and OpenLDAP) and consider the 2 products together as an open source alternative for IAM products that will compete with the commercial vendor offerings. Once 1.0 is released, we will begin working on 2.0 which will include UI's to control Fortress and OpenLDAP along with a policy server to wrap the Fortress Java APIs with HTTP/REST Web APIs to make it available to all platforms. Thanks in advance for your consideration. Shawn McKinney JoshuaTree Software shawn.mckinney(a)jtstools.com

1 0

(ITS#6994) Syncrepl with MozNSS inherits TLS context form main configuration breaking some syncrepl setups
by thibault.lemeur＠supelec.fr 11 Jul '11

11 Jul '11

Full_Name: Thibault Le Meur Version: 2.4.23-15 OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (160.228.28.55) Previously on my FC13 installation (openldap-servers-2.4.21-11) the main slapd process used an X509 "server" while my syncrepl processes were using the /etc/openldap/ldap.conf client configuration file in order to connect to my LDAPs Syncrepl providers. In my new RHEL6 setup (openldap-servers-2.4.23-15.el6.x86_64) is linked to MozNSS and Syncrepl can't connect to my LDAPs providers anymore because it complains about the TLS context not beeing intitialized correctly (the server's certificate isn't accepted as a client certificate). Here is the lightly obfuscated log: ---------------------------------------------------------- ldap_connect_to_host: Trying 10.10.10.10:636 ldap_pvt_connect: fd: 21 tm: -1 async: 0 TLS: loaded CA certificate file /etc/ssl/cacerts/cacert.pem. TLS: certificate [CN=myldap.mydom.fr,OU=myou,O=myorg,L=myloc,ST=myst,C=FR] is not valid - error -8101:Unknown code ___f 91. TLS: error: unable to set up client certificate authentication for certificate named PEM Token #0:myldap.mydom.fr-cert.pem - 0 TLS: error: unable to set up client certificate authentication using PEM Token #0:myldap.mydom.fr-cert.pem - 0 TLS: error: could not initialize moznss security context - error -8101:Unknown code ___f 91 TLS: can't create ssl handle. slap_client_connect: URI=ldaps://otherldap.mydom.fr DN="cn=myreplicationAccount,dc=mydom,dc=fr" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=125 rc -1 retrying (9 retries left) ---------------------------------------------------------- Here is my syncrepl setup: --------------------------------------------------------- syncrepl rid=125 provider=ldaps://otherldap.mydom.fr type=refreshOnly interval=00:00:03:00 retry="60 10 300 +" searchbase="dc=subranch,dc=mydom,dc=fr" filter="(objectClass=*)" scope=sub schemachecking=off bindmethod=simple binddn="cn=myreplicationAccount,dc=mydom,dc=fr" credentials="MyVerySecretPassword" --------------------------------------------------------- My setup related to TLS: --------------------------------------------------------- TLSCipherSuite HIGH TLSCertificateFile /etc/ssl/certs/myldap.mydom.fr-cert.pem TLSCertificateKeyFile /etc/ssl/keys/myldap.mydom.fr-key.pem TLSCACertificateFile /etc/ssl/cacerts/cacert.pem --------------------------------------------------------- And my /etc/openldap/ldap.conf: --------------------------------------------------------- TLS_CACERT /etc/ssl/cacerts/cacert.pem --------------------------------------------------------- Here is the obfuscated certificate: --------------------------------------------------------- Certificate: Data: Version: 3 (0x2) Serial Number: 221 (0xdd) Signature Algorithm: sha1WithRSAEncryption Issuer: C=FR, ST=myst, L=myloc, O=myorg, OU=myou, CN=myCA/emailAddress=myemail(a)mydom.fr Validity Not Before: Oct 2 16:42:15 2007 GMT Not After : Dec 14 16:42:15 2012 GMT Subject: C=FR, ST=myst, L=myloc, O=myorg, OU=myou, CN=myldap.mydom.fr Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: ... Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Server Netscape Comment: TinyCA Generated Certificate X509v3 Subject Key Identifier: ... X509v3 Authority Key Identifier: keyid:... DirName:/C=FR/ST=myst/L=myloc/O=myorg/OU=myou/CN=myCA/emailAddress=thibault.lemeur@supelec.fr serial:00 X509v3 Issuer Alternative Name: <EMPTY> Netscape SSL Server Name: myldap.mydom.fr X509v3 Subject Alternative Name: DNS:ldap, DNS:ldapalias1, DNS:ldapalias2, DNS:ldapalias1.mydom.fr, DNS:ldapalias2.mydom.fr, DNS:ldap.mydom.fr, DNS:myldap, DNS:myldap.mydom.fr X509v3 Extended Key Usage: critical TLS Web Server Authentication, Code Signing Signature Algorithm: sha1WithRSAEncryption ... ---------------------------------------------------------

1 0

(ITS#6993) Backend Connection problem
by yann.carre＠alcatel-lucent.com 11 Jul '11

11 Jul '11

Full_Name: Yann Carre Version: 2.4.26 OS: red hat 5 (64 bits) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.208.49.20) I work on a specific Backend I have provided in my back end a function to the bi_connection_init pointer. This function adds a context needed in the operation backend function (search, ...) When several connections start up, my LDAP server crashes. The crash arrives because the context is not created before the call to do_searh. The connection is provided to the application Backend before my Back end connection_init. I have checked it with the debugger and see that the thread with initialize the connection is suspend before the backend connection_init. In another thread, the search function is executed without any context attached to the connection. This problem seems to be bring because the connection mutex is freed before the calling of the Back end connection_init in the function connection_init (connection.c). I have moved this mutex after the backend connection_init and it seems to work. Would you confirm this analysis and take the correction in account? Thanks Regards Yann

1 0

Syncrepl using can't start ssl session because of refused certificate
by Thibault Le Meur 10 Jul '11

10 Jul '11

Hello, I'm trying to upgrade an openLdap server from FC9 (openldap-servers-2.4.10-2.fc9.i386) to Redhat Enterprise 6 (openldap-servers-2.4.23-15.el6.x86_64). In this new setup, my local database works but the Syncrepl replication process fails to establish the "ldaps://" session to my syncrepl-providers because the TLS layer fails. Indeed, the TLS layer complains that my _server's certificate_ isn't a valid _client certificate_ (with error 8101 - SEC_ERROR_INADEQUATE_CERT_TYPE): but I don't want client-side authentication! In the past syncrepl didn't try to use the server certificate as a client certificate, and I haven't seen any reference to this in the documentation. I first thought it could have been related to ITS#6791 but I don't think so anymore because it only affects Syncrepl. Don' hesitate to redirect me to the openldap-users list if I've missed something simple. Thanks in advance, Thibault Here is an excerpt of slapd in debug-mode: ---------------------------------------------------------- ldap_connect_to_host: Trying 10.10.10.10:636 ldap_pvt_connect: fd: 21 tm: -1 async: 0 TLS: loaded CA certificate file /etc/ssl/cacerts/cacert.pem. TLS: certificate [CN=myldap.mydom.fr,OU=myou,O=myorg,L=myloc,ST=myst,C=FR] is not valid - error -8101:Unknown code ___f 91. TLS: error: unable to set up client certificate authentication for certificate named PEM Token #0:myldap.mydom.fr-cert.pem - 0 TLS: error: unable to set up client certificate authentication using PEM Token #0:myldap.mydom.fr-cert.pem - 0 TLS: error: could not initialize moznss security context - error -8101:Unknown code ___f 91 TLS: can't create ssl handle. slap_client_connect: URI=ldaps://otherldap.mydom.fr DN="cn=myreplicationAccount,dc=mydom,dc=fr" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=125 rc -1 retrying (9 retries left) ---------------------------------------------------------- Here is my syncrepl setup: --------------------------------------------------------- syncrepl rid=125 provider=ldaps://otherldap.mydom.fr type=refreshOnly interval=00:00:03:00 retry="60 10 300 +" searchbase="dc=subranch,dc=mydom,dc=fr" filter="(objectClass=*)" scope=sub schemachecking=off bindmethod=simple binddn="cn=myreplicationAccount,dc=mydom,dc=fr" credentials="MyVerySecretPassword" --------------------------------------------------------- And eventually my /etc/openldap/ldap.conf: --------------------------------------------------------- TLS_CACERT /etc/ssl/cacerts/cacert.pem ---------------------------------------------------------

2 1

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