Rails - Jul 2006 - Net::LDAP 0.0.3 released, adds TLS encryption

We''re pleased to announce version 0.0.3 of Net::LDAP, the first
pure-Ruby LDAP library. Net::LDAP intends to be a feature-complete
LDAP client which can access as much as possible of the functionality
of the most-used LDAP server implementations. This library does
not wrap any existing native-code LDAP libraries, creates no
Ruby extensions, and has no dependencies external to Ruby.

Version 0.0.3 adds support for encrypted communications to LDAP servers.
There is a new optional parameter for Net::LDAP#new and Net::LDAP#open
that allows you to specify encryption characteristics. Here''s a quick
example:

require ''net/ldap''
ldap = Net::LDAP.new(
:host => "an_ip_address",
:port => 636,
:auth => {:method => :simple, :username => "mickey",
:password =>
"mouse" },
:encryption => {:method => :simple_tls}
)
ldap.bind or raise "bind failed"
ldap.search( ... )
# etc, etc.

This release supports simple TLS encryption with no client or server
validation. Future versions will add support for the STARTTLS control,
and for certificate validation. Additional parameters will appear to
support these options.

Net::LDAP encryption requires Ruby''s openssl library. We''re
not
quite sure what happens when this library is present but the underlying
OpenSSL libraries are missing or not configured appropriately,
especially on back versions of Ruby. If anyone encounters problems
using encryption in Net::LDAP, please let us know and give us the
details of your platform and Ruby build info.

Thanks to Garett Shulman for helping to test the new code.

If anyone wants to contribute suggestions, insights or (especially)
code, please email me at garbagecat10 .. .. gmail.com.

-- 
Posted via http://www.ruby-forum.com/.

Francis Cianfrocca wrote:
> We''re pleased to announce version 0.0.3 of Net::LDAP, the first
> pure-Ruby LDAP library. Net::LDAP intends to be a feature-complete
> LDAP client which can access as much as possible of the functionality
> of the most-used LDAP server implementations. This library does
> not wrap any existing native-code LDAP libraries, creates no
> Ruby extensions, and has no dependencies external to Ruby.
This is great. But why is the use of modify deprecated? If I have a 
group membership attribute with, say, a hundred values, and I just want 
to add or remove one value, isn''t it more efficient and safer (in the 
presence of concurrent updates) to use modify?

thanks

   Justin

Justin Forder wrote:
> But why is the use of modify deprecated? If I have a
> group membership attribute with, say, a hundred values, and I just want
> to add or remove one value, isn''t it more efficient and safer (in
the
> presence of concurrent updates) to use modify?
> 
> thanks
> 
>    Justin
>From the Rdoc entry for Net::LDAP#modify:
DEPRECATED - Please use add_attribute, replace_attribute, or 
delete_attribute

#modify was deprecated because we thought the API was too complex, so we 
broke it up into three new functions. Under the covers, the three new 
attribute-modification APIs are just sugar on top of the original 
#modify, which might become private someday. The current Rdoc commentary 
is all still correct and valid.

To your specific point: "safer" is dependent on the LDAP server 
implementation. The vast majority of them don''t have the kind of 
concurrency you would expect in an RDBMS. As far as "efficient" goes, 
you''re not really going to get much help in your particular example, 
because LDAP doesn''t let you simply modify one attribute out of a 
hundred. You will end up deleting all of them and re-adding them with 
your changes reflected in the new set. That''s built into the LDAP wire 
protocol.

It''s been my experience that a lot of people expect LDAP servers to 
behave like database engines. Some of them in fact are implemented on 
top of DBMSs (Tivoli''s TDS is a good example, and is in fact one of the
better implementations, although it''s too damned expensive so I never 
recommend it). But the LDAP protocol itself works against RDBMS-like 
behaviors. LDAP is quite a different animal, and I think this is an 
underappreciated fact.

-- 
Posted via http://www.ruby-forum.com/.

Francis Cianfrocca wrote:
> Justin Forder wrote:
>> But why is the use of modify deprecated? If I have a
>> group membership attribute with, say, a hundred values, and I just want
>> to add or remove one value, isn''t it more efficient and safer
(in the
>> presence of concurrent updates) to use modify?
>>
>> thanks
>>
>>    Justin
> 
>>From the Rdoc entry for Net::LDAP#modify:
> 
> DEPRECATED - Please use add_attribute, replace_attribute, or 
> delete_attribute
> 
> #modify was deprecated because we thought the API was too complex, so we 
> broke it up into three new functions. Under the covers, the three new 
> attribute-modification APIs are just sugar on top of the original 
> #modify, which might become private someday. The current Rdoc commentary 
> is all still correct and valid.
> 
> To your specific point: "safer" is dependent on the LDAP server 
> implementation. The vast majority of them don''t have the kind of 
> concurrency you would expect in an RDBMS. 
I appreciate that, and am trying to design accordingly.

As far as "efficient" goes,
> you''re not really going to get much help in your particular
example,
> because LDAP doesn''t let you simply modify one attribute out of a 
> hundred. You will end up deleting all of them and re-adding them with 
> your changes reflected in the new set. That''s built into the LDAP
wire
> protocol.
I didn''t know that. So the interpretation of the modifications is done 
on the client side? And if I add one value to an attribute all the 
values are brought to the client, one is added, and the new set is sent 
back?

Take a scenario where I find the groups containing a user, and want to 
remove the user. I haven''t retrieved the full membership of those 
groups, but I can express removing the use as a modification on each 
group. What is the right way to implement this?
> It''s been my experience that a lot of people expect LDAP servers
to
> behave like database engines. Some of them in fact are implemented on 
> top of DBMSs (Tivoli''s TDS is a good example, and is in fact one
of the
> better implementations, although it''s too damned expensive so I
never
> recommend it). But the LDAP protocol itself works against RDBMS-like 
> behaviors. LDAP is quite a different animal, and I think this is an 
> underappreciated fact.
I am aware that it is a different animal, and I''m trying to make sure
we
use it appropriately. In our application, maintenance of user 
organisations, users, profiles, and functions is done under 
dual-operator control (one administrator makes a change, another 
authorises it) in DB2, and a subset of authorised data needs to be 
replicated to TDS. I''m prototyping in Ruby; the real implementation
will
be in Java.

Thanks very much for your help.

   Justin

Justin Forder wrote:
> In our application, maintenance of user
> organisations, users, profiles, and functions is done under
> dual-operator control (one administrator makes a change, another
> authorises it) in DB2, and a subset of authorised data needs to be
> replicated to TDS. I''m prototyping in Ruby; the real
implementation will
> be in Java.

TDS is already in DB2 under the covers, so you''re doing a bit of a 
two-step to maintain AZ tables in DB2 and partially propagate them to 
TDS.

To answer your question as you posed it: I''m going to assume
you''re
writing a trigger of some kind to modify your TDS data when your AZ 
tables change. LDAP defines an "attribute" as an attribute-name and a 
set of values. The set of values may be of any cardinality, including 
zero, depending on the constraints of your schema. When you search for 
an entry via LDAP, the protocol will return to you *all* of the values 
for each attribute you request. (This could be hundreds of values, of 
course.) You can modify the set locally using Net::LDAP APIs. When you 
update the attribute, *all* of the values, including the ones you
didn''t
modify, get sent back to the LDAP server.

Read the RDoc for Net::LDAP#modify carefully to understand the 
distinctive semantics that LDAP defines for these operations: they are 
well-defined, precise, rather complex, somewhat unintuitive, and quite 
unlike typical database operations.

Is this a problem? Well, how often do your AZ rules change? TDS is a 
fairly powerful LDAP implementation and can handle a fair amount of 
flux. (If you had to do this in Active Directory, I''d strongly advise 
you not even to try.) But the fact that you are running TDS tells me 
that you are probably a large company beholden somewhow to IBM. (Maybe 
they told you that they wouldn''t support Websphere unless you 
implemented TDS?) So you''ll have to experiment and see if this will 
work. I will say that Net::LDAP is going to be at least as fast as JNDI 
on the wire, so if you find that your prototype is slow, don''t expect
it
to be magically faster when you go to Java.

Now I''ll try to answer your question on somewhat different terms: why 
are you using an LDAP directory for authorization in the first place? 
You should be using it for authentication and identity-management, 
nothing more. There are other, far more effective approaches for AZ.

Feel free to send me a private email if you want to discuss your 
application in more detail.

-- 
Posted via http://www.ruby-forum.com/.

Francis Cianfrocca wrote:
> Justin Forder wrote:
>> In our application, maintenance of user
>> organisations, users, profiles, and functions is done under
>> dual-operator control (one administrator makes a change, another
>> authorises it) in DB2, and a subset of authorised data needs to be
>> replicated to TDS. I''m prototyping in Ruby; the real
implementation will
>> be in Java.
> 
> TDS is already in DB2 under the covers, so you''re doing a bit of a
> two-step to maintain AZ tables in DB2 and partially propagate them to 
> TDS.
Yes, indeed.
> To answer your question as you posed it: I''m going to assume
you''re
> writing a trigger of some kind to modify your TDS data when your AZ 
> tables change. LDAP defines an "attribute" as an attribute-name
and a
> set of values. The set of values may be of any cardinality, including 
> zero, depending on the constraints of your schema. When you search for 
> an entry via LDAP, the protocol will return to you *all* of the values 
> for each attribute you request. (This could be hundreds of values, of 
> course.) You can modify the set locally using Net::LDAP APIs. When you 
> update the attribute, *all* of the values, including the ones you
didn''t
> modify, get sent back to the LDAP server.
All our changes are timestamped in the application''s database (and all 
deletions are logical deletes), so we can replicate frequently, 
focussing on what has changed since the last successful replication, and 
retry on failure.

There is much more data being maintained (under dual-operator control) 
than the organisation/user/profile/function data that is needed for 
authentication/authorization.

After replying earlier, I had a quick look at RFC1777

   http://www.ietf.org/rfc/rfc1777.txt

and the description of modification (section 4.4) suggests that 
additions and deletions of attribute values can be done incrementally 
over the wire.

(Your Net::LDAP add_attribute method will add values to those already 
existing, but your delete_attribute method deletes all values.)
> Read the RDoc for Net::LDAP#modify carefully to understand the 
> distinctive semantics that LDAP defines for these operations: they are 
> well-defined, precise, rather complex, somewhat unintuitive, and quite 
> unlike typical database operations.
Yes. Given that it is not possible to wrap multiple operations in a 
transaction, it seems valuable to be able to make fine-grained 
modifications. Otherwise someone else could update a multi-valued 
attribute between our read and our write. (We should be the only source 
of updates to the directory content, but I''d like to make the solution 
as robust as possible.) If I can just say "remove this user''s DN
from
the members of the Admin group", that seems better (and exactly what the 
protocol was designed to be able to do).
> Is this a problem? Well, how often do your AZ rules change? TDS is a 
> fairly powerful LDAP implementation and can handle a fair amount of 
> flux. (If you had to do this in Active Directory, I''d strongly
advise
> you not even to try.) But the fact that you are running TDS tells me 
> that you are probably a large company beholden somewhow to IBM. (Maybe 
> they told you that they wouldn''t support Websphere unless you 
> implemented TDS?) So you''ll have to experiment and see if this
will
> work. I will say that Net::LDAP is going to be at least as fast as JNDI 
> on the wire, so if you find that your prototype is slow, don''t
expect it
> to be magically faster when you go to Java.
Our client is a large company, and IBM runs their applications. They 
(IBM) are pushing hard for the use of TDS with WebSphere 
container-managed authentication and authorization, and they have the 
client''s ear. This is happening in mid-project; we already had all the 
authentication and authorization working against DB2.
> Now I''ll try to answer your question on somewhat different terms:
why
> are you using an LDAP directory for authorization in the first place? 
> You should be using it for authentication and identity-management, 
> nothing more. There are other, far more effective approaches for AZ.
> 
> Feel free to send me a private email if you want to discuss your 
> application in more detail.
I''ll take you up on that (but not over the weekend) - thank you very 
much indeed.

   Justin

Justin Forder wrote:
> After replying earlier, I had a quick look at RFC1777
As a point of interest, the current LDAP standard is 2251, which 
obsoletes 1777.
> 
> and the description of modification (section 4.4) suggests that
> additions and deletions of attribute values can be done incrementally
> over the wire.
I''m going to re-read that section very carefully and change Net::LDAP 
accordingly, if possible. But my recollection is that LDAP uses the term 
"attribute value" to refer to the whole (possibly multi-valued) set,
not
the individual items in the set. Net::LDAP was implemented strictly from 
the RFC, and I don''t remember seeing any protocol support for changing 
individual items in an attribute value.
> Otherwise someone else could update a multi-valued
> attribute between our read and our write.
They sure can.
> Our client is a large company, and IBM runs their applications. They
> (IBM) are pushing hard for the use of TDS with WebSphere
> container-managed authentication and authorization, and they have the
> client''s ear. This is happening in mid-project; we already had all
the
> authentication and authorization working against DB2.
Everyone know Microsoft plays dirty, but they are amateurs compared to 
IBM.

-- 
Posted via http://www.ruby-forum.com/.

Francis Cianfrocca wrote:
> Justin Forder wrote:
> 
>> After replying earlier, I had a quick look at RFC1777
> 
> As a point of interest, the current LDAP standard is 2251, which 
> obsoletes 1777.
Yes, 1777 was for LDAP version 2, but it was the first one I found, and 
I thought it would be good enough for checking the semantics of modify.

[RFC4511 (June 2006) will obsolete 2251 (when taken together with 4510, 
4512, and 4513).]
>> and the description of modification (section 4.4) suggests that
>> additions and deletions of attribute values can be done incrementally
>> over the wire.
> 
> I''m going to re-read that section very carefully and change
Net::LDAP
> accordingly, if possible. But my recollection is that LDAP uses the term 
> "attribute value" to refer to the whole (possibly multi-valued)
set, not
> the individual items in the set. Net::LDAP was implemented strictly from 
> the RFC, and I don''t remember seeing any protocol support for
changing
> individual items in an attribute value.
The descriptions of add and delete semantics are:

     add: add values listed to the given attribute, creating
     the attribute if necessary;

     delete: delete values listed from the given attribute,
     removing the entire attribute if no values are listed, or
     if all current values of the attribute are listed for
     deletion;

In 2251, there is an additional stipulation that deletion of specific 
values is only permitted if the attribute type defines an equality match 
filter.

Note that the RFC requires the modifications to take place in the order 
in which they were specified, and that the overall operation is atomic. 
RFC1777 used "should": "The entire list of entry modifications
should be
performed in the order they are listed, as a single atomic operation." 
but 2251 uses "MUST".
>> Otherwise someone else could update a multi-valued
>> attribute between our read and our write.
> 
> They sure can.
> 
>> Our client is a large company, and IBM runs their applications. They
>> (IBM) are pushing hard for the use of TDS with WebSphere
>> container-managed authentication and authorization, and they have the
>> client''s ear. This is happening in mid-project; we already had
all the
>> authentication and authorization working against DB2.
> 
> Everyone know Microsoft plays dirty, but they are amateurs compared to 
> IBM.
:-)

regards

   Justin

Francis Cianfrocca wrote:
> Justin Forder wrote:
> 
>> After replying earlier, I had a quick look at RFC1777
> 
> As a point of interest, the current LDAP standard is 2251, which 
> obsoletes 1777.
> 
>> and the description of modification (section 4.4) suggests that
>> additions and deletions of attribute values can be done incrementally
>> over the wire.
> 
> I''m going to re-read that section very carefully and change
Net::LDAP
> accordingly, if possible. But my recollection is that LDAP uses the term 
> "attribute value" to refer to the whole (possibly multi-valued)
set, not
> the individual items in the set. Net::LDAP was implemented strictly from 
> the RFC, and I don''t remember seeing any protocol support for
changing
> individual items in an attribute value.
I believe you have implemented it correctly, and from playing with 
Net::LDAP in irb it seems straightforward (using modify) to delete a 
specific attribute value, leaving other values of the same attribute intact.

 > pp entries[0]
#<Net::LDAP::Entry:0x2d2c048
  @myhash   {:dn=>["cn=user_admin,ou=roles,o=xyz,c=uk"],
    :cn=>["user_admin"],
    :objectclass=>["top", "groupOfUniqueNames"],
    :description=>["User Administration"],
    :uniquemember=>
     ["cn=SuperUser,ou=profiles,o=xyz,c=uk",
      "cn=Administrator,ou=profiles,o=xyz,c=uk"]}>
=> nil
 > ldap.modify :dn => "cn=user_admin,ou=roles,o=xyz,c=uk",
*   :operations => [[:delete,
*                    ''uniquemember'',
*                   
''cn=Administrator,ou=profiles,o=xyz,c=uk'']]
=> true
 > ldap.search(:base => ''ou=roles,o=xyz,c=uk'',
*   :filter => Net::LDAP::Filter.eq(''cn'',
''user_admin'')) {|e| pp e}; nil
#<Net::LDAP::Entry:0x2f63bd8
  @myhash   {:dn=>["cn=user_admin,ou=roles,o=xyz,c=uk"],
    :cn=>["user_admin"],
    :objectclass=>["top", "groupOfUniqueNames"],
    :description=>["User Administration"],
    :uniquemember=>["cn=SuperUser,ou=profiles,o=xyz,c=uk"]}>
=> nil

Given the ordering and atomicity specified for the modify operation, it 
would be a pity to continue to deprecate it.

Thanks again for an excellent library. I hope it gets coverage in the 
next edition of "Enterprise Integration with Ruby". Maybe ActiveLDAP 
should move over to a pure Ruby implementation, too.

regards

   Justin

P.S. I''ll be offline now until Sunday evening.

Justin Forder wrote:
> 
> I believe you have implemented it correctly, and from playing with
> Net::LDAP in irb it seems straightforward (using modify) to delete a
> specific attribute value, leaving other values of the same attribute 
> intact.
>
Thanks for checking. I found basically the same thing. Net::LDAP follows 
the spec closely enough to enable the backend to do the right thing, so 
no changes needed. And my re-reading of both 1777 and 2251 supports your 
view of what the backend should be doing, so I''m glad we went through 
the exercise.
> Given the ordering and atomicity specified for the modify operation, it
> would be a pity to continue to deprecate it.
> 
That''s a very, very good point. I still dislike the API of #modify, too
complicated, not Ruby-esque enough. Maybe there''s a syntactic way (a 
block?) to specify sequences of add, changes, and deletes so they will 
go in a single LDAP Modify request and achieve the atomicity provided by 
the protocol. Does anyone have any suggestions? Patches gladly accepted.
> Thanks again for an excellent library. I hope it gets coverage in the
> next edition of "Enterprise Integration with Ruby". Maybe
ActiveLDAP
> should move over to a pure Ruby implementation, too.
> 
I corresponded briefly with Will Drewry about that and looked through 
his code. The native LDAP API is scattered pretty extensively through 
one of the modules in ActiveLDAP so it''s not a five-minute job. Anyone 
out there willing to help me do it?

-- 
Posted via http://www.ruby-forum.com/.

Justin Forder wrote:
> 
> Given the ordering and atomicity specified for the modify operation, it
> would be a pity to continue to deprecate it.
> 
I just remembered the other reason why I deprecated #modify: because of 
LDAP''s lack of transaction semantics. If you use Net::LDAP#modify to 
execute a chain of operations, perhaps on multiple attributes, and one 
of them fails in the middle, the preceding ones DON''T get rolled back. 
If this happens, most LDAP servers won''t give you a very useful error 
message, either. So I think it makes more sense to just code such 
operations discretely and handle any errors on a per-operation basis.

But we should keep #modify public, in case there are servers out there 
that observe some kind of nonstandard transaction semantics or 
concurrency guarantees, and I''m glad you pointed that out.
I''ll change
the Rdoc to reflect that.

-- 
Posted via http://www.ruby-forum.com/.

Francis Cianfrocca wrote:
> Justin Forder wrote:
> 
>> Given the ordering and atomicity specified for the modify operation, it
>> would be a pity to continue to deprecate it.
>>
> 
> I just remembered the other reason why I deprecated #modify: because of 
> LDAP''s lack of transaction semantics. If you use Net::LDAP#modify
to
> execute a chain of operations, perhaps on multiple attributes, and one 
> of them fails in the middle, the preceding ones DON''T get rolled
back.
> If this happens, most LDAP servers won''t give you a very useful
error
> message, either. So I think it makes more sense to just code such 
> operations discretely and handle any errors on a per-operation basis.
> 
> But we should keep #modify public, in case there are servers out there 
> that observe some kind of nonstandard transaction semantics or 
> concurrency guarantees, and I''m glad you pointed that out.
I''ll change
> the Rdoc to reflect that.
I haven''t quite got offline yet: I''m just packing to go down
to the
coast (UK South coast) for the rest of the weekend.

RFC2251 (and 4511) are quite clear that the sequence of modifications 
should be atomic:

    - modification: A list of modifications to be performed on the entry.
      The entire list of entry modifications MUST be performed
      in the order they are listed, as a single atomic operation.  While
      individual modifications may violate the directory schema, the
      resulting entry after the entire list of modifications is performed
      MUST conform to the requirements of the directory schema.

    [snip]

    The server will return to the client a single Modify Response
    indicating either the successful completion of the DIT modification,
    or the reason that the modification failed. Note that due to the
    requirement for atomicity in applying the list of modifications in
    the Modify Request, the client may expect that no modifications of
    the DIT have been performed if the Modify Response received indicates
    any sort of error, and that all requested modifications have been
    performed if the Modify Response indicates successful completion of
    the Modify Operation.  If the connection fails, whether the
    modification occurred or not is indeterminate.

Thanks again (and I shall get in touch off-list about the other points 
you have made)

   Justin

Justin Forder wrote:
> RFC2251 (and 4511) are quite clear that the sequence of modifications
> should be atomic:
> 
>     - modification: A list of modifications to be performed on the 
> entry.
>       The entire list of entry modifications MUST be performed
>       in the order they are listed, as a single atomic operation.  While
>       individual modifications may violate the directory schema, the
>       resulting entry after the entire list of modifications is 
> performed
>       MUST conform to the requirements of the directory schema.
> 
>     [snip]
> 
>     The server will return to the client a single Modify Response
>     indicating either the successful completion of the DIT modification,
>     or the reason that the modification failed. Note that due to the
>     requirement for atomicity in applying the list of modifications in
>     the Modify Request, the client may expect that no modifications of
>     the DIT have been performed if the Modify Response received 
> indicates
>     any sort of error, and that all requested modifications have been
>     performed if the Modify Response indicates successful completion of
>     the Modify Operation.  If the connection fails, whether the
>     modification occurred or not is indeterminate.
> 
I''ve specifically tested this against several different well-known LDAP
servers and found that most of them violate the atomicity requirement. I 
haven''t tested TDS for this. If you can do such a test against TDS,
I''d
be most interested in hearing the result.

Justin, you''d better hurry down to the coast while there is still some 
weekend left ;-). But thanks for all the attention you''re paying to 
this.

-- 
Posted via http://www.ruby-forum.com/.

Francis Cianfrocca wrote:
> I''ve specifically tested this against several different well-known
LDAP
> servers and found that most of them violate the atomicity requirement. I 
> haven''t tested TDS for this. If you can do such a test against
TDS, I''d
> be most interested in hearing the result.
That''s depressing. Are those servers certified for LDAP compliance? If 
you could send me a test I''ll see what I can do with respect to TDS.
> Justin, you''d better hurry down to the coast while there is still
some
> weekend left ;-). But thanks for all the attention you''re paying
to
> this.
:-) I enjoyed a bit of walking, swimming, and a few pints in the country 
pubs.

regards

   Justin

Justin Forder wrote:
> Francis Cianfrocca wrote:
> 
>> I''ve specifically tested this against several different
well-known LDAP
>> servers and found that most of them violate the atomicity requirement.
I
>> haven''t tested TDS for this. If you can do such a test against
TDS, I''d
>> be most interested in hearing the result.
> 
> That''s depressing. Are those servers certified for LDAP
compliance? If
> you could send me a test I''ll see what I can do with respect to
TDS.
> 
>> Justin, you''d better hurry down to the coast while there is
still some
>> weekend left ;-). But thanks for all the attention you''re
paying to
>> this.
> 
> :-) I enjoyed a bit of walking, swimming, and a few pints in the country
> pubs.
> 
> regards
> 
>    Justin

LOL! What is LDAP compliance certification? In practice there are only a 
few directory servers in wide use (a lot of iPlanet, some TDS and some 
Oracle in enterprises, OpenLDAP on all the scruffy Linux boxes, and 
ActiveDirectory *everywhere*). So I''d have to suppose as a practical 
matter that LDAP compliance comes down to what A/D does: an extremely 
low common denominator, extremely bad performance, and full of awful 
bugs that will probably never be fixed.

OpenLDAP is probably the most compliant LDAP server I''ve seen, although
it too has quirks. And it actually deserves its reputation for slowness. 
I once had to implement an LDAP server from scratch for a particular 
application (still in production), and query-performance is about 30 
times better than OpenLDAP.

-- 
Posted via http://www.ruby-forum.com/.

Francis Cianfrocca wrote:
> Justin Forder wrote:
>> Francis Cianfrocca wrote:
>>
>>> I''ve specifically tested this against several different
well-known LDAP
>>> servers and found that most of them violate the atomicity
requirement. I
>>> haven''t tested TDS for this. If you can do such a test
against TDS, I''d
>>> be most interested in hearing the result.
>> That''s depressing. Are those servers certified for LDAP
compliance? If
>> you could send me a test I''ll see what I can do with respect
to TDS.
> LOL! What is LDAP compliance certification? In practice there are only a 
> few directory servers in wide use (a lot of iPlanet, some TDS and some 
> Oracle in enterprises, OpenLDAP on all the scruffy Linux boxes, and 
> ActiveDirectory *everywhere*). So I''d have to suppose as a
practical
> matter that LDAP compliance comes down to what A/D does: an extremely 
> low common denominator, extremely bad performance, and full of awful 
> bugs that will probably never be fixed.
> 
> OpenLDAP is probably the most compliant LDAP server I''ve seen,
although
> it too has quirks. And it actually deserves its reputation for slowness. 
> I once had to implement an LDAP server from scratch for a particular 
> application (still in production), and query-performance is about 30 
> times better than OpenLDAP.
So you don''t rate the certification by the Open Group:

   http://www.opengroup.org/openbrand/register/dj.htm

I''m interested to know why, and I''d still like you to send me
a test for
atomicity.

regards

   Justin

(answering again, as my reply 16 hours ago hasn''t come back to me via 
the mailing list yet)

Francis Cianfrocca wrote:
> LOL! What is LDAP compliance certification? In practice there are only a 
> few directory servers in wide use (a lot of iPlanet, some TDS and some 
> Oracle in enterprises, OpenLDAP on all the scruffy Linux boxes, and 
> ActiveDirectory *everywhere*). So I''d have to suppose as a
practical
> matter that LDAP compliance comes down to what A/D does: an extremely 
> low common denominator, extremely bad performance, and full of awful 
> bugs that will probably never be fixed.
> 
> OpenLDAP is probably the most compliant LDAP server I''ve seen,
although
> it too has quirks. And it actually deserves its reputation for slowness. 
> I once had to implement an LDAP server from scratch for a particular 
> application (still in production), and query-performance is about 30 
> times better than OpenLDAP.
OK. I was thinking of the Open Group certification:

   http://www.opengroup.org/openbrand/register/dj.htm

I found more links relating to LDAP certification here:

   http://www.freelists.org/archives/ldapdata/05-2005/msg00000.html

Do you have a straightforward test for atomicity that you could share?

thanks

   Justin