Logged in as guest
Viewing Software Enhancements/3037 Full headers
Major security issue: yes no
Notes: interop issue fixed in mozilla, not yet fixed in MS-LDAP. Notification:
Date: Wed, 24 Mar 2004 13:41:14 GMT From: boba@softerra.com To: openldap-its@OpenLDAP.org Subject: Start TLS operation issue
Full_Name: Dmitry A. Version: 2.1.25 OS: Linux RH 9.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.144.66.190) Hello. Let me make a reservation that under no circumstances this issue could be said is a bug of OpenLDAP server because it works pretty fine with .native. (OpenLDAP) client. But at least it could be a subject for some improvements. So the issue concerns the Start TLS extended operation performed by other LDAP clients. When I use ldap_start_tls_s function of MS API client or perform an extended operation with START_TLS_OID (since there is no ldap_start_tls_s function at all) with help of Netscape API the server returns LDAP_PROTOCOL_ERROR accompanied with the message .no request data expected.. Short investigation showed inconsistency on binary level of LDAP packets sent by OpenLDAP and other clients. Below is the hexadecimal representation of ASN1 sequences for extended LDAP requests had been cut out from network packets. OpenLDAP API: 30 1D 02 01 01 77 18 80 16 31 2E 33 2E 36 2E 31 2E 34 2E 31 2E 31 34 36 36 2E 32 30 30 33 37 MS API, Netscape API: 30 84 00 00 00 23 02 01 0E 77 84 00 00 00 1A 80 16 31 2E 33 2E 36 2E 31 2E 34 2E 31 2E 31 34 36 36 2E 32 30 30 33 37 81 00 ASN1 viewing tool revealed an empty .redundant. tag at the end of the MS/Netscape API packets. I think it would be great if OpenLDAP server could be able to display more tolerance to such clients (like it does Novell server for example: www.nldap.com) With respect, Dmitry.
Date: Wed, 24 Mar 2004 10:31:38 -0800 To: boba@softerra.com From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> Subject: Re: Start TLS operation issue (ITS#3037) Cc: openldap-its@OpenLDAP.org
We are pretty liberal in accepting the other 8 octets of bogusity in the PDU. The problem I see here is that even if we were to ignore the bogus empty sequence, would the client accept a properly formed response (with no sequence). That is, I don't mind being liberal in what we accept, but we need to remain strict in what we produce. Kurt At 05:41 AM 3/24/2004, boba@softerra.com wrote: >Full_Name: Dmitry A. >Version: 2.1.25 >OS: Linux RH 9.0 >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (217.144.66.190) > > >Hello. Let me make a reservation that under no circumstances this issue could be >said is a bug of OpenLDAP server because it works pretty fine with .native. >(OpenLDAP) client. But at least it could be a subject for some improvements. > >So the issue concerns the Start TLS extended operation performed by other LDAP >clients. When I use ldap_start_tls_s function of MS API client or perform an >extended operation with START_TLS_OID (since there is no ldap_start_tls_s >function at all) with help of Netscape API the server returns >LDAP_PROTOCOL_ERROR accompanied with the message .no request data expected.. >Short investigation showed inconsistency on binary level of LDAP packets sent by >OpenLDAP and other clients. Below is the hexadecimal representation of ASN1 >sequences for extended LDAP requests had been cut out from network packets. > >OpenLDAP API: >30 1D 02 01 01 77 18 80 16 31 2E 33 2E 36 2E 31 2E 34 2E 31 2E 31 34 36 36 2E 32 >30 30 33 37 > >MS API, Netscape API: >30 84 00 00 00 23 02 01 0E 77 84 00 00 00 1A 80 16 31 2E 33 2E 36 2E 31 2E 34 2E >31 2E 31 34 36 36 2E 32 30 30 33 37 81 00 > >ASN1 viewing tool revealed an empty .redundant. tag at the end of the >MS/Netscape API packets. I think it would be great if OpenLDAP server could be >able to display more tolerance to such clients (like it does Novell server for >example: www.nldap.com) > >With respect, >Dmitry.
From: "Dimson" <boba@softerra.com> To: <openldap-its@OpenLDAP.org> Subject: Re: Start TLS operation issue (ITS#3037) Date: Tue, 30 Mar 2004 12:46:10 +0300
>> We are pretty liberal in accepting the other 8 octets >> of bogusity in the PDU Do you mean that the latest version of your server will accept such message formed by MS or Netscape API? >> The problem I see here is that even if we were to >> ignore the bogus empty sequence, would the client >> accept a properly formed response (with no sequence) I don't think there will be any problems. Tests with Novell server revealed that client accepts properly formed responses. And even if it wasn't so it couldn't be a problem of OpenLDAP server anyway. But the fact is that there is no possibility to send extended request to OpenLDAP server with help of two most popular client LDAP APIs (MS, Natscape). Thanx in advance. Dmitry
Date: Thu, 01 Apr 2004 21:09:41 -0800 To: boba@softerra.com From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> Subject: Re: Start TLS operation issue (ITS#3037) Cc: openldap-its@OpenLDAP.org
At 01:46 AM 3/30/2004, boba@softerra.com wrote: >But the fact is that there >is no possibility to send extended request to OpenLDAP server with help of >two most popular client LDAP APIs (MS, Natscape). I note that if these API implementations are not capable of sending an LDAP extended request without extension data, they are significantly flawed. That is, you should report a bug to the developers of these API implementations. Your request to be liberal here remains under consideration. Kurt
From: "Dimson" <boba@softerra.com> To: <openldap-its@OpenLDAP.org> Subject: Re: Start TLS operation issue (ITS#3037) Date: Wed, 28 Apr 2004 18:48:53 +0300
Hello, With all respect let me draw your attention to the fact that practically this situation leads us to the absence of interoperability between OpenLDAP server and huge amount of client installations that are already took their place and it's hardly possible now to update any of them. Thanx again. Dmitry
Date: Thu, 27 May 2004 07:51:47 -0700 To: "Kirill Kovalenko" <kirill@softerra.com> From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> Subject: Re: StartTLS issues (ITS#3037) Cc: <openldap-its@OpenLDAP.org>
In this response, which I forward to <openldap-its> with an appropriate subject so it will be attached to the ITS, I'll discuss only the ITS#3037 issue. The other issue should be separately discussed as part of ITS#1590. I believe the first to resolving this issue should be to report the bugs in the APIs to the API developers. Once aware of the problem, I suspect they would fix their bug. It's unclear to me whether the original submitter of ITS#3037 ever attempted to report the bugs to the API developers. While this particular bug doesn't directly affect me (as I don't use any of the APIs mentioned), I did notified Mozilla LDAP folks of their bug and they fixed it quickly. I'll leave the reporting and tracking of bug reports with vendor-developed APIs to those who have relationships with those vendors. I assume they will fix their bugs in a reasonable amount of time. Have you (or anyone else) reported the problem to Microsoft? If so, what did they say they would do about it? I'm not warm to the idea of adding a workaround in the meantime. I would be more receptive to the idea if I knew that the bug was reported to the vendors and the vendors agreed that it was a bug and agreed to fix it (hence my encouragement to report these API implementation bugs to the API developers). I'm quite concerned that if we don't get them to fix their bug now, we'll have repeats of this problem with numerous other extended operations, like WhoAmI?, which send no data in requests. Kurt At 06:45 AM 5/27/2004, Kirill Kovalenko wrote: >Hello, > >We've spent some time digging into the issue. Here is the results; > >1. Request > >The following table illustrates how parameters passed to the >ldap_extended_operation_s() influence upon the ANS.1 data being transferred >on wire. > >Client API |ldap_extended_operation_s() | Sent Message >======================================================================= >OpenLDAP | requestdata = NULL | w/o data octets >----------------------------------------------------------------------- >OpenLDAP | requestdata = struct berval{0, NULL} | an empty berval >----------------------------------------------------------------------- >Netscape | requestdata = NULL | N/A (crash) >----------------------------------------------------------------------- >Netscape | requestdata = struct berval{0, NULL} | the empty berval >----------------------------------------------------------------------- >Microsoft | requestdata = NULL | the empty berval >----------------------------------------------------------------------- >Microsoft | requestdata = struct berval{0, NULL} | the empty berval >----------------------------------------------------------------------- > >Form this table you can see that Netscape and Microsoft API always send >empty an berval structure even if request data has to be absent (i.e. NULL). > >Unfortunately, OpenLDAP server does not accept such requests for the >'StartTLS' extended operation because of the following code: > >starttls.c (starttls_extop() function): > > if ( op->ore_reqdata != NULL ) { > /* no request data should be provided */ > rs->sr_text = "no request data expected"; > return LDAP_PROTOCOL_ERROR; > } > >This code makes it impossible to execute 'StartTLS' operation if it is made >by clients who compiled against Netscape or Microsoft APIs. (The same is >true for the 'Who Am I' operation) > >The fix for the problem is trivial: > > if ( op->ore_reqdata != NULL && op->ore_reqdata->bv_len > 0) { > /* no request data should be provided */ > rs->sr_text = "no request data expected"; > return LDAP_PROTOCOL_ERROR; > } > >We completely understand that this workaround contradicts RFC2830 >(Lightweight Directory Access Protocol (v3): Extension for Transport Layer >Security) >saying: >... > A Start TLS extended request is formed by setting the requestName > field to the OID string given above. The requestValue field is > absent. >... >Still, we believe that the fix should be applied because of the huge amount >of mentioned clients installed worldwide.
From: "Kirill Kovalenko" <kirill@softerra.com> To: "'Kurt D. Zeilenga'" <Kurt@OpenLDAP.org> Cc: <openldap-its@OpenLDAP.org> Subject: RE: StartTLS issues (ITS#3037) Date: Thu, 27 May 2004 18:20:22 +0300
Kurt, > Have you (or anyone else) reported the problem to Microsoft? Yes, I have. http://groups.google.com.ua/groups?hl=uk&lr=&ie=UTF-8&th=8acf9a3c907b33b6&se ekm=b3f80464.0404280733.75c0401%40posting.google.com&frame=off As you can see the status is unclear for now. Kirill > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Thursday, May 27, 2004 5:52 PM > To: Kirill Kovalenko > Cc: openldap-its@OpenLDAP.org > Subject: Re: StartTLS issues (ITS#3037) > > > In this response, which I forward to <openldap-its> with > an appropriate subject so it will be attached to the ITS, > I'll discuss only the ITS#3037 issue. The other issue > should be separately discussed as part of ITS#1590. > > I believe the first to resolving this issue should be to > report the bugs in the APIs to the API developers. Once > aware of the problem, I suspect they would fix their bug. > It's unclear to me whether the original submitter of > ITS#3037 ever attempted to report the bugs to the API developers. > > While this particular bug doesn't directly affect me (as I > don't use any of the APIs mentioned), I did notified Mozilla > LDAP folks of their bug and they fixed it quickly. I'll > leave the reporting and tracking of bug reports with > vendor-developed APIs to those who have relationships with > those vendors. I assume they will fix their bugs in a > reasonable amount of time. > > Have you (or anyone else) reported the problem to Microsoft? > If so, what did they say they would do about it? > > I'm not warm to the idea of adding a workaround in the > meantime. I would be more receptive to the idea if I knew > that the bug was reported to the vendors and the vendors > agreed that it was a bug and agreed to fix it (hence my > encouragement to report these API implementation bugs to the > API developers). I'm quite concerned that if we don't get > them to fix their bug now, we'll have repeats of this problem > with numerous other extended operations, like WhoAmI?, which > send no data in requests. > > Kurt > > > > At 06:45 AM 5/27/2004, Kirill Kovalenko wrote: > >Hello, > > > >We've spent some time digging into the issue. Here is the results; > > > >1. Request > > > >The following table illustrates how parameters passed to the > >ldap_extended_operation_s() influence upon the ANS.1 data being > >transferred on wire. > > > >Client API |ldap_extended_operation_s() | Sent Message > >============================================================= > ========== > >OpenLDAP | requestdata = NULL | > w/o data octets > >------------------------------------------------------------- > ---------- > >OpenLDAP | requestdata = struct berval{0, NULL} | an > empty berval > >------------------------------------------------------------- > ---------- > >Netscape | requestdata = NULL | N/A (crash) > >------------------------------------------------------------- > ---------- > >Netscape | requestdata = struct berval{0, NULL} | the > empty berval > >------------------------------------------------------------- > ---------- > >Microsoft | requestdata = NULL | the > empty berval > >------------------------------------------------------------- > ---------- > >Microsoft | requestdata = struct berval{0, NULL} | the > empty berval > >------------------------------------------------------------- > ---------- > > > >Form this table you can see that Netscape and Microsoft API > always send > >empty an berval structure even if request data has to be > absent (i.e. > >NULL). > > > >Unfortunately, OpenLDAP server does not accept such requests for the > >'StartTLS' extended operation because of the following code: > > > >starttls.c (starttls_extop() function): > > > > if ( op->ore_reqdata != NULL ) { > > /* no request data should be provided */ > > rs->sr_text = "no request data expected"; > > return LDAP_PROTOCOL_ERROR; > > } > > > >This code makes it impossible to execute 'StartTLS' > operation if it is > >made by clients who compiled against Netscape or Microsoft > APIs. (The > >same is true for the 'Who Am I' operation) > > > >The fix for the problem is trivial: > > > > if ( op->ore_reqdata != NULL && > op->ore_reqdata->bv_len > 0) { > > /* no request data should be provided */ > &g
Date: Thu, 27 May 2004 08:41:08 -0700 To: "Kirill Kovalenko" <kirill@softerra.com> From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> Subject: RE: StartTLS issues (ITS#3037) Cc: <openldap-its@OpenLDAP.org>
Is this newsgroup a formal bug reporting mechanism? At 08:20 AM 5/27/2004, Kirill Kovalenko wrote: >Kurt, > >> Have you (or anyone else) reported the problem to Microsoft? > >Yes, I have. >http://groups.google.com.ua/groups?hl=uk&lr=&ie=UTF-8&th=8acf9a3c907b33b6&se >ekm=b3f80464.0404280733.75c0401%40posting.google.com&frame=off > >As you can see the status is unclear for now. > >Kirill > >> -----Original Message----- >> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >> Sent: Thursday, May 27, 2004 5:52 PM >> To: Kirill Kovalenko >> Cc: openldap-its@OpenLDAP.org >> Subject: Re: StartTLS issues (ITS#3037) >> >> >> In this response, which I forward to <openldap-its> with >> an appropriate subject so it will be attached to the ITS, >> I'll discuss only the ITS#3037 issue. The other issue >> should be separately discussed as part of ITS#1590. >> >> I believe the first to resolving this issue should be to >> report the bugs in the APIs to the API developers. Once >> aware of the problem, I suspect they would fix their bug. >> It's unclear to me whether the original submitter of >> ITS#3037 ever attempted to report the bugs to the API developers. >> >> While this particular bug doesn't directly affect me (as I >> don't use any of the APIs mentioned), I did notified Mozilla >> LDAP folks of their bug and they fixed it quickly. I'll >> leave the reporting and tracking of bug reports with >> vendor-developed APIs to those who have relationships with >> those vendors. I assume they will fix their bugs in a >> reasonable amount of time. >> >> Have you (or anyone else) reported the problem to Microsoft? >> If so, what did they say they would do about it? >> >> I'm not warm to the idea of adding a workaround in the >> meantime. I would be more receptive to the idea if I knew >> that the bug was reported to the vendors and the vendors >> agreed that it was a bug and agreed to fix it (hence my >> encouragement to report these API implementation bugs to the >> API developers). I'm quite concerned that if we don't get >> them to fix their bug now, we'll have repeats of this problem >> with numerous other extended operations, like WhoAmI?, which >> send no data in requests. >> >> Kurt >> >> >> >> At 06:45 AM 5/27/2004, Kirill Kovalenko wrote: >> >Hello, >> > >> >We've spent some time digging into the issue. Here is the results; >> > >> >1. Request >> > >> >The following table illustrates how parameters passed to the >> >ldap_extended_operation_s() influence upon the ANS.1 data being >> >transferred on wire. >> > >> >Client API |ldap_extended_operation_s() | Sent Message >> >============================================================= >> ========== >> >OpenLDAP | requestdata = NULL | >> w/o data octets >> >------------------------------------------------------------- >> ---------- >> >OpenLDAP | requestdata = struct berval{0, NULL} | an >> empty berval >> >------------------------------------------------------------- >> ---------- >> >Netscape | requestdata = NULL | N/A (crash) >> >------------------------------------------------------------- >> ---------- >> >Netscape | requestdata = struct berval{0, NULL} | the >> empty berval >> >------------------------------------------------------------- >> ---------- >> >Microsoft | requestdata = NULL | the >> empty berval >> >------------------------------------------------------------- >> ---------- >> >Microsoft | requestdata = struct berval{0, NULL} | the >> empty berval >> >------------------------------------------------------------- >> ---------- >> > >> >Form this table you can see that Netscape and Microsoft API >> always send >> >empty an berval structure even if request data has to be >> absent (i.e. >> >NULL). >> > >> >Unfortunately, OpenLDAP server does not accept such requests for the >> >'StartTLS' extended operation because of the following code: >> > >> >starttls.c (starttls_extop() function): >> > >> > if ( op->ore_reqdata != NULL ) { >> > /* no request data should be provided */ >> > rs->sr_text = "no request data expected"; >> >
From: "Kirill Kovalenko" <kirill@softerra.com> To: "'Kurt D. Zeilenga'" <Kurt@OpenLDAP.org> Cc: <openldap-its@OpenLDAP.org> Subject: RE: StartTLS issues (ITS#3037) Date: Thu, 27 May 2004 18:51:27 +0300
Kurt, Well I'm not sure. I was told by an insider to post it there and I definitely don't want to pay $99 for their official support request. Kirill > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Thursday, May 27, 2004 6:41 PM > To: Kirill Kovalenko > Cc: openldap-its@OpenLDAP.org > Subject: RE: StartTLS issues (ITS#3037) > > > Is this newsgroup a formal bug reporting mechanism? > > At 08:20 AM 5/27/2004, Kirill Kovalenko wrote: > >Kurt, > > > >> Have you (or anyone else) reported the problem to Microsoft? > > > >Yes, I have. > >http://groups.google.com.ua/groups?hl=uk&lr=&ie=UTF-8&th=8acf > 9a3c907b33 > >b6&se > >ekm=b3f80464.0404280733.75c0401%40posting.google.com&frame=off > > > >As you can see the status is unclear for now. > > > >Kirill > > > >> -----Original Message----- > >> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > >> Sent: Thursday, May 27, 2004 5:52 PM > >> To: Kirill Kovalenko > >> Cc: openldap-its@OpenLDAP.org > >> Subject: Re: StartTLS issues (ITS#3037) > >> > >> > >> In this response, which I forward to <openldap-its> with > >> an appropriate subject so it will be attached to the ITS, I'll > >> discuss only the ITS#3037 issue. The other issue should be > >> separately discussed as part of ITS#1590. > >> > >> I believe the first to resolving this issue should be to > report the > >> bugs in the APIs to the API developers. Once aware of the > problem, I > >> suspect they would fix their bug. It's unclear to me whether the > >> original submitter of ITS#3037 ever attempted to report > the bugs to > >> the API developers. > >> > >> While this particular bug doesn't directly affect me (as I > >> don't use any of the APIs mentioned), I did notified Mozilla > >> LDAP folks of their bug and they fixed it quickly. I'll > >> leave the reporting and tracking of bug reports with > >> vendor-developed APIs to those who have relationships with > >> those vendors. I assume they will fix their bugs in a > >> reasonable amount of time. > >> > >> Have you (or anyone else) reported the problem to > Microsoft? If so, > >> what did they say they would do about it? > >> > >> I'm not warm to the idea of adding a workaround in the > >> meantime. I would be more receptive to the idea if I knew > >> that the bug was reported to the vendors and the vendors > >> agreed that it was a bug and agreed to fix it (hence my > >> encouragement to report these API implementation bugs to the > >> API developers). I'm quite concerned that if we don't get > >> them to fix their bug now, we'll have repeats of this problem > >> with numerous other extended operations, like WhoAmI?, which > >> send no data in requests. > >> > >> Kurt > >> > >> > >> > >> At 06:45 AM 5/27/2004, Kirill Kovalenko wrote: > >> >Hello, > >> > > >> >We've spent some time digging into the issue. Here is the results; > >> > > >> >1. Request > >> > > >> >The following table illustrates how parameters passed to the > >> >ldap_extended_operation_s() influence upon the ANS.1 data being > >> >transferred on wire. > >> > > >> >Client API |ldap_extended_operation_s() | > Sent Message > >> >============================================================= > >> ========== > >> >OpenLDAP | requestdata = NULL | > >> w/o data octets > >> >------------------------------------------------------------- > >> ---------- > >> >OpenLDAP | requestdata = struct berval{0, NULL} | an > >> empty berval > >> >------------------------------------------------------------- > >> ---------- > >> >Netscape | requestdata = NULL | N/A (crash) > >> >------------------------------------------------------------- > >> ---------- > >> >Netscape | requestdata = struct berval{0, NULL} | the > >> empty berval > >> >------------------------------------------------------------- > >> ---------- > >> >Microsoft | requestdata = NULL | the > >> empty berval > >> >-------------------------------------------------------------
Date: Thu, 27 May 2004 09:03:58 -0700 To: kirill@softerra.com From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> Subject: RE: StartTLS issues (ITS#3037) Cc: openldap-its@OpenLDAP.org
Your description of 4) which relates to this issue is misleading. The issue is not with their encoding of empty data, but their inability to encode a PDU with no data. empty != no (much like "" != NULL in C). Kurt At 08:21 AM 5/27/2004, kirill@softerra.com wrote: >Kurt, > >> Have you (or anyone else) reported the problem to Microsoft? > >Yes, I have. >http://groups.google.com.ua/groups?hl=uk&lr=&ie=UTF-8&th=8acf9a3c907b33b6&se >ekm=b3f80464.0404280733.75c0401%40posting.google.com&frame=off > >As you can see the status is unclear for now. > >Kirill > >> -----Original Message----- >> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >> Sent: Thursday, May 27, 2004 5:52 PM >> To: Kirill Kovalenko >> Cc: openldap-its@OpenLDAP.org >> Subject: Re: StartTLS issues (ITS#3037) >> >> >> In this response, which I forward to <openldap-its> with >> an appropriate subject so it will be attached to the ITS, >> I'll discuss only the ITS#3037 issue. The other issue >> should be separately discussed as part of ITS#1590. >> >> I believe the first to resolving this issue should be to >> report the bugs in the APIs to the API developers. Once >> aware of the problem, I suspect they would fix their bug. >> It's unclear to me whether the original submitter of >> ITS#3037 ever attempted to report the bugs to the API developers. >> >> While this particular bug doesn't directly affect me (as I >> don't use any of the APIs mentioned), I did notified Mozilla >> LDAP folks of their bug and they fixed it quickly. I'll >> leave the reporting and tracking of bug reports with >> vendor-developed APIs to those who have relationships with >> those vendors. I assume they will fix their bugs in a >> reasonable amount of time. >> >> Have you (or anyone else) reported the problem to Microsoft? >> If so, what did they say they would do about it? >> >> I'm not warm to the idea of adding a workaround in the >> meantime. I would be more receptive to the idea if I knew >> that the bug was reported to the vendors and the vendors >> agreed that it was a bug and agreed to fix it (hence my >> encouragement to report these API implementation bugs to the >> API developers). I'm quite concerned that if we don't get >> them to fix their bug now, we'll have repeats of this problem >> with numerous other extended operations, like WhoAmI?, which >> send no data in requests. >> >> Kurt >> >> >> >> At 06:45 AM 5/27/2004, Kirill Kovalenko wrote: >> >Hello, >> > >> >We've spent some time digging into the issue. Here is the results; >> > >> >1. Request >> > >> >The following table illustrates how parameters passed to the >> >ldap_extended_operation_s() influence upon the ANS.1 data being >> >transferred on wire. >> > >> >Client API |ldap_extended_operation_s() | Sent Message >> >============================================================= >> ========== >> >OpenLDAP | requestdata = NULL | >> w/o data octets >> >------------------------------------------------------------- >> ---------- >> >OpenLDAP | requestdata = struct berval{0, NULL} | an >> empty berval >> >------------------------------------------------------------- >> ---------- >> >Netscape | requestdata = NULL | N/A (crash) >> >------------------------------------------------------------- >> ---------- >> >Netscape | requestdata = struct berval{0, NULL} | the >> empty berval >> >------------------------------------------------------------- >> ---------- >> >Microsoft | requestdata = NULL | the >> empty berval >> >------------------------------------------------------------- >> ---------- >> >Microsoft | requestdata = struct berval{0, NULL} | the >> empty berval >> >------------------------------------------------------------- >> ---------- >> > >> >Form this table you can see that Netscape and Microsoft API >> always send >> >empty an berval structure even if request data has to be >> absent (i.e. >> >NULL). >> > >> >Unfortunately, OpenLDAP server does not accept such requests for the >> >'StartTLS' extended operation because of the following code: >> > >> >starttls.c (starttls_extop() function): >> > >> > if ( op->ore_reqdata != NULL
______________ © Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org
