openldap-devel

openldap-devel@openldap.org

1418 discussions

Start a nNew thread

todo items, still some are available?
by kalyanasundaram s 24 Oct '09

24 Oct '09

All the items in the todo list are up for grabs? I guess some are already done like the rfc 2891. -kalyan

2 1

Distributed ppolicy state
by Howard Chu 23 Oct '09

23 Oct '09

One of the major concerns I still have with password policy is the issue of the overhead involved in maintaining so many policy state variables for authentication failure / lockout tracking. It turns what would otherwise be pure read operations into writes, which is already troublesome for some cases. But in the context of replication, the problem can be multiplied by the number of replicas in use. Avoiding this write magnification effect is one of the reasons the initial versions of the ppolicy overlay explicitly prevented its state updates from being replicated. Replicating these state updates for every authentication request simply won't scale. Unfortunately the braindead account lockout policy really doesn't work well without this sort of state information. The problem is not much different from the scaling issues we have to deal with in making code run well on multiprocessor / multicore machines. Having developed effective solutions to those problems, we ought to be able to apply the same thinking to this as well. The key to excellent scaling is the so-called "shared-nothing" approach, where every processor just uses its own local resources and never has to synchronize with ( == wait for) any other processor, but for the most part it's a design ideal, not something you can do perfectly in practice. However, we have some recent examples in the slapd code where we've been able to use this approach to good effect. In the connection manager, we used to handle monitoring/counter information (number of ops, type of ops, etc) in a single counter, which required a lot of locking overhead to update. We now use an array of counters per thread, and each thread can update its own counters for free, completely eliminating the locking overhead. The trick is in recognizing that this type of info is written far more often than it is read, so optimizing the update case is far more important than optimizing the query case. When someone tries to read the counters that are exposed in back-monitor, then we simply iterate across the arrays and tally up the counters then. Since there's no particular requirement that all the counters be read in the same instant in time, all of these reads/updates can be performed without locking, so again we get it for free, no synchronization overhead at all. So, it should now be obvious where we should go with the replication issue... Ideally, you want password policy enforcement rules that don't even need global state at all. IMO, the best approach is still to keep policy state private to each DSA, and this still makes sense for DSAs that are topologically remote. E.g., assume you have a pair of servers, each in two separate cities. It's unlikely that a login attempt on one server will be in any way connected to a simultaneous login attempt on the other server. And in the face of bot attack, the rate of logins will probably be high enough to swamp the channel between the two servers, resulting in queueing delays that ultimately aggregate several of the updates on the attacked server into just a single update on the remote server. (E.g., N separate failure updates on one server will coalesce into a single update on the remote server.) Therefore, most of the time it's pointless for each server to try to immediately update the other with login failure info. In the case of a local, load-balanced cluster of replicas, where the network latency between DSAs is very low, the natural coalescing of updates may not occur as often. Still, it would be better if the updates didn't happen at all. And in such an environment, where the DSAs are so close together that latency is low, distributing reads is still cheaper than distributing writes. So, the correct way to implement this global state is to keep it distributed separately during writes, and collect it during reads. I'm looking for a way to express this in the schema and in the ppolicy draft, but I'm not sure how just yet. It strikes me that X.500 probably already has a type of distributed/collective attribute but I haven't looked yet. Also I think we can take this a step further, but haven't thought it through all the way yet. If you typically have login failures coming from a single client, it should be sufficient to always route that client's requests to the same DSA, and have all of its failure tracking done locally/privately on that DSA. At the other end, if you have an attack mounted by a number of separate machines, it's not clear that you must necessarily collect the state from every DSA on every authentication request. E.g., if you're setting a lockout based on the number of login failures, once the failure counter on a single DSA reaches the lockout threshold, it doesn't matter any more what the failure counter is on any other DSA, so that DSA no longer needs to look for the values on any other node. If a client comes along and does a search to retrieve the policy state, e.g. looking for the last successful login or the last failure, then you want whatever DSA receives the request to broadcast the search to all the other DSAs and collate the results for the client by default. (Note that simple aggregation only works for multivalued attributes; for single-valued attributes like pwdLastSuccess you have to know to pick the most recent value.) And probably you should be able to specify a control (like ManageDSAit) to disable this automatic broadcast and only retrieve the value from a single DSA. I realize that the points listed above about login attacks miss several attack scenarios. I think more of the scenarios need to be outlined and analyzed before moving forward with any recommendations on lockout behavior; the internet today is pretty different from when these lockout mechanisms were first designed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 4

small project
by Dmitry Kolesov 22 Oct '09

22 Oct '09

Hello. I would like to work on a small project from the TO DO list: - Add LDIFv2 (XML) support to command line tools. Could you tell more, what need I to do? Best regards. - Dmitry

3 4

response to bind
by masarati＠aero.polimi.it 20 Oct '09

20 Oct '09

ITS#6337 seems to indicate that it's time to move bind response inside the backends. Unfortunately right now the need to send bind response from outside the backends is well-bundled into slapd, so the whole thing might not be trivial. p.

2 2

random topics
by Howard Chu 14 Oct '09

14 Oct '09

Some of these should go onto the roadmap or TODO list. Just scribbling them down here before I forget. Had a chat with tridge and abartlet about the LDAP TXN support they're looking for with Samba4. One of their requirements was being able to do reads inside the TXN, and that is explicitly not supported by the LDAP TXN draft. But after talking a bit more about how they do things in LDB, we decided to take the same approach here - LDB only allows one writer when a TXN is active. We can write a (global) overlay that gives this same behavior, and then not have to worry about any of the other TXN details. While thinking about back-mdb, I realized that since we're mapping storage to memory we don't really need a traditional disk-DB structure. Instead we can just manage the space as its own heap and use in-memory structures like AVL trees and such. I've been thinking about extending our current AVL library to a T-tree implementation. Further reading along those lines led me to Cache-Sensitive T-trees (CST-Trees) which also have the important property of being friendly to CPU cacheline sizes, and so behaving a lot better in multi-processor systems. This is a pretty generic project - if anyone's been looking for a relatively self-contained bit of work they could contribute, this would be ideal. You can get the paper here: http://ids.snu.ac.kr/wiki/CST-Trees:_Cache_Sensitive_T-Trees (Note that these things are only good because they can fit all the keys into a single node - i.e., they only have their most desirable properties when keys are small. We could certainly use them for the id2entry index, and maybe a few others, but in the general case we need to be able to use pointers to arbitrary data as keys.) ITS#6301 also fed into this search, but I think we just want to use threaded AVL here instead of the Red-Black tree code. That would shrink the size of the patch down considerably, which would also be a good thing. Again, anyone looking for a relatively small project, this one is pretty straightforward. Also a completely fringe topic, but still interesting - we've got OpenLDAP running well on Android now; on a G1 phone. But it's still just a set of command-line tools. UnboundID showed off their Java LDAP SDK in a simple app also running on Android. A combination of these two would make an extremely powerful package: Develop a canned slapd config that uses syncrepl to sync with a remote LDAP address book. Use proxied multimaster, to allow local changes to be propagated back to the remote directory. Write a java app that uses LDAP for the G1's contact book backend instead of the SQLite ****stuff that it's currently using. Accomplishing this will necessitate writing a few GUI menus for configuring the handful of variables needed for the slapd config. This also brings me to another topic - adopting features from OpenDS... They expose a cn=Tasks tree which can be used for submitting tasks via LDAP. Currently we expose our runqueue under cn=Monitor but that's only read-only. It would be nice to be able to submit/schedule/trigger tasks on the fly... In particular, it would be nice to have a defined task for triggering a syncrepl refresh. The Android slapd config would be a refreshOnly syncrepl consumer. It would also have a hidden back-ldap refreshOnly consumer replicating from its local database and writing to the remote master. This way both push and pull would be under control of the Android device. (You have no idea how much of a bill you can rack up with fully automatic background synching. It's much better to have this under complete user control.) The GUI would just submit a request to cn=Tasks to trigger a synch. OpenDS also has matching rules defined for comparing timestamp attributes to "current server time". This is extremely handy for a lot of things. Again, this is a small, self-contained project that should be simple for someone to jump in on. More ideas later... -- -- 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 9

Re: commit: ldap/servers/slapd/overlays pcache.c
by Howard Chu 07 Oct '09

07 Oct '09

ando(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays > > Modified Files: > pcache.c 1.196 -> 1.197 > > Log Message: > make sure members are not used uninitialized Perhaps this should have just been changed to ch_calloc instead of ch_malloc... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

RE24 call for testing
by Quanah Gibson-Mount 07 Oct '09

07 Oct '09

Please test RE24 for 2.4.19 preparation. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

6 9

advertising compiled-but-not-instantiated overlays
by Aaron Richton 03 Oct '09

03 Oct '09

2.4.18 releases slapo-sssvlv. Now my servers are advertising VLV/sortKeyList as supportedControls. Thing is, I don't specify "overlay sssvlv" so they're not really "supported" in any meaningful way. Searches that specify the controls just error out fast. I'm not particularly inclined to enable the feature, but I'm not sure if somebody else might want it in their installation, so I'd prefer to keep it compiled in. This is the case with all overlays across the board. For example, configure --enable-modules --enable-overlays=mod and syncprov isn't advertised in test000. But if you just ./configure and run test000, you see 1.3.6.1.4.1.4203.1.9.1.1 despite the fact that there's no way test000 could provide LDAP Sync as configured. (Recall that --enable-syncprov defaults to yes.) To me it's counterintuitive and "false advertising": unless there's an "overlay syncprov" in slapd.1.conf, I don't see why that should show up in test000. Thoughts?

2 1

tls error messages
by Ralf Haferkamp 30 Sep '09

30 Sep '09

Hi, In case of certificate verification failures I'd like to include the verification error message ("certificate has expired", "unable to get issuer certificate", ...) in the diagnostic errormessage. For that I need pass the tls_session* as an extra argument to the TI_session_errmsg functions (for openssl I need the SSL* handle to get the verification error). Does anyone see a problem with this? -- Ralf

2 1

Problems compiling OpenLDAP in 64 bit due to old libtool version included
by Dagobert Michelsen 29 Sep '09

29 Sep '09

Hi, I have a problem compiling the current OpenLDAP (2.4.18) in 64 bit on Solaris. The problem occurs when building with modules and enabling 64 bit in CFLAGS rather than setting CC to the compiler including flags. The source of the problem is the old libtool version 1.5.x included in OpenLDAP. The libtool maintainers recommended upgrading libtool to at least 2.2 where the problem was fixed. It would be nice if it could be updated, or is there a specific reason why the old version is kept? See <http://lists.gnu.org/archive/html/bug-libtool/2009-09/msg00017.html> for details on identifying the bug. Best regards -- Dago

4 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel