openldap-devel

openldap-devel@openldap.org

1418 discussions

Overlay supporting password syntax checking
by Mathieu 29 Mar '11

29 Mar '11

Hi, I am currently migrating a users database to an OpenLDAP solution. I have to deal with some constraints for this project, namely password policy and/or password syntax checking. Fortunately the ppolicy overlay already implements the draft-behera-ldap-password-policy, and offers the possibility to use pwdCheckModule to check password via external modules. Unfortunately, I did not find any module meeting all my requirements: The check_password() function, as defined in ppolicy, provides to the underlying module two parameters: - The entry being modified - The new password. Now to support per user settings, which is one of these requirements, I have to either store extra attributes among each entry, or the module has to perform a ldapsearch against the db. An option is to modify the check_password() function so it sends the ppolicy object itself: int check_password (char *pPasswd, char **ppErrStr, Entry *pEntry, Entry *ppolicyEntry); This way people using external modules would just need to store their settings attributes in it. As I don't want to break existing modules implementation, I have developed a simple overlay which enforces password syntax checking on a per user or per database basis. The overlay implements also the check_password() function so it can be used in conjunction with ppolicy. I believe the code is clean enough to be contributed and I will be glad to upload it if you think it can be of any interest. However, I have some questions first. The overlay allows me to define a default password constraints object at a database level, or a subentry in the user entry, in a similar way as the ppolicy_default setting and the pwdPolicySubentry attributes. This is so similar that I think it would be more relevant to extend the ppolicy overlay so it could support basic syntax checking. I understand the need to have the pwdCheckModule functionality, for those in need of exotics or platform dependent checks, but counting the characters belonging to a class is not harder than checking the min/max length of the password. So to summarize: - Could the check_password function be modified? - Could basic syntax checking be integrated in ppolicy? And If none of these options are acceptable, should I upload the overlay I developed? Of course I'm willing to help on the first two points. Regards, -- Mathieu

2 2

OpenLDAP git repo?
by Volker Lendecke 29 Mar '11

29 Mar '11

Hi! Out of several rumors I've heard that OpenLDAP converted it source repo to git. Is that true? www.openldap.org still speaks about cvs. If you changed to git, is the repo publically available? Thanks, Volker

5 12

git repo?
by Volker Lendecke 29 Mar '11

29 Mar '11

Hi! Being excited about the git repo, I had to try it: $ git clone git://git.OpenLDAP.org/module.git Initialized empty Git repository in /data/vlendec/git/module/.git/ fatal: The remote end hung up unexpectedly $ Is it possible that something is not set up right yet? Thanks, Volker

2 1

Re: openldap.git branch master updated. cf49e43f86de16f1cc84ab44f6d4fa3c7e18902f
by Hallvard B Furuseth 29 Mar '11

29 Mar '11

> commit cf49e43f86de16f1cc84ab44f6d4fa3c7e18902f > Merge: cd1f718 0adef98 > Author: Kurt Zeilenga <kurt(a)OpenLDAP.org> > Date: Mon Mar 28 18:42:22 2011 -0700 > > Merge branch 'master' of ssh://git-master.openldap.org/~git/git/openldap We'll need better messages for merges, this doesn't say much. -- Hallvard

3 5

RE 24 testing call (OL 2.4.25)
by Quanah Gibson-Mount 28 Mar '11

28 Mar '11

A few small fixes have been applied to the RE24 branch for a 2.4.25 release. Please test and report. Thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

5 5

Re: commit: ldap/build crupdate
by Hallvard B Furuseth 25 Mar '11

25 Mar '11

kurt(a)OpenLDAP.org writes: > Removed Files: > crupdate 1.12 -> NONE > Remove from CVS (now in openldap-etc.git) No big deal, but I think such changes belong in Git only. Might as well leave the frozen CVS repo in a working state, e.g. if we find we need to use it for one more release or want to play around with it to verify the transition to Git. -- Hallvard

1 0

authTimestamp and relax rules control
by Michael Ströder 19 Mar '11

19 Mar '11

HI! I'm using slapo-lastbind with 2.4.24 found under contrib/ which writes the operational attribute authTimestamp to an entry. Now I have a use-case where a LDAP client (connector continously pumping data from another non-OpenLDAP directory server) should write this attribute to the OpenLDAP server. But even when using the relax rules control this does not seem to be allowed. Section 3.6. of draft-zeilenga-ldap-relax-03 says: The subsections of this section discuss modification of various operational attributes where their NO-USER-MODIFICATION constraint may be relaxed. Future documents may specify where NO-USER-MODIFICATION constraints on other operational attribute may be relaxed. In absence of a document detailing that the NO-USER-MODIFICATION constraint on a particular operational attribute may be relaxed, implementors SHOULD assume relaxation of the constraint is not appropriate for that attribute. Hmm, since there's no formal spec for authTimestamp I'm lost here? Ciao, Michael.

2 2

Release testing
by Howard Chu 18 Mar '11

18 Mar '11

Since fermat.openldap.org which was to be the core of our build farm has been down almost from the time the machine arrived, we haven't been able to set up the automated builds we had envisioned. It's clear now that nobody tested RE24 on Windows before we released 2.4.24. Anybody willing to take responsibility for Windows testing in the future? -- -- 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

Generalize olcHidden -> olcLabel
by Hallvard B Furuseth 17 Mar '11

17 Mar '11

I'd like a simple way to manipulate an off-line database while slapd is running, e.g. to slapadd it from scratch and activate it when done. Here is one suggestion: Make olcHidden a dynamic attribute computed from an attribute olcLabel="some text" + a startup option -L "label to activate,...". Updates to olcHidden could fail or update olcLabel for backwards compatibility, depending on configuration. Then to rebuild database X off-line, maybe with a different config: - Copy ldapadd X's config to a new database Y, except set olcLabel = "offline" and olcDbDirectory = "<new dir>". - Set olcReadOnly=TRUE in X's config, so we won't lose any changes. - Slapcat <X> | slapadd -L offline - Set X's olcDbDirectory="<new dir>" and olcReadOnly=FALSE, to pick up the changes and resume normal operation. This doesn't cover all cases of reconfiguring a database, e.g. we can't modify a global option like olcIndexIntLen this way. But it's a start. Also instead of pointing X's olcDbDirectory at Y's directory, one might want to atomically hide database X and un-hide Y, by removing Y's label and then labelling X. That works if one can have two active databases with the same suffix where the former hides the latter. (Maybe the hidden database would be treated as if it had olcHidden.) Slapd does not currently accept that at startup, but does if one starts with olcHidden=TRUE in the first database and then removes olcHidden. That should probably be cleaned up anyway. The olcHidden machinery has some bugs, I'll ITS them after exploring abit. -- Hallvard

2 2

back-mdb notes
by Howard Chu 16 Mar '11

16 Mar '11

Thought this was an interesting read: http://www.varnish-cache.org/trac/wiki/ArchitectNotes Too bad he talks about his approach being "2006 era" programming. In fact the single-level store is 1964-era, from Multics. http://en.wikipedia.org/wiki/Single_level_store I guess they'll have to tweak Henry Spencer's quote ("Those who do not understand UNIX are condemned to reinvent it, poorly.") to Multics instead... I've been working on a new "in-memory" B-tree library that operates on an mmap'd file. It is a copy-on-write design; it supports MVCC and is immune to corruption and requires no recovery procedure. It is not an append-only design, since that requires explicit compaction, and also is not amenable to mmap usage. Also the append-only approach requires total serialization of write operations, which would be quite poor for throughput. The current approach simply reserves space for two root node pointers and flip flops between them. So, multiple writes may be outstanding at once, but commits are of course serialized; each commit causes the currently unused root node pointer to become the currently valid root node pointer. Transaction aborts are pretty much free; there's nothing to rollback. Read transactions begin by snapshotting the current root pointer and then can run without any interference from any other operations. Public commits have been waiting for our official transition to git, but since that's been going nowhere I will probably start publishing on github.com in the next couple of weeks. (With St. Patrick's Day right around the corner it may have to wait a bit.) Unfortunately I realized that not all application-level caching can be eliminated - with the hierarchical DB approach, we don't store full entry DNs in the DB so they still need to be generated in main memory, and they probably should be cached. But that's a detail to be addressed later; it may well be that the cost of always constructing them on the fly (no caching) is acceptable. This backend should perform much better in all aspects (memory, CPU, and I/O usage) than the current BerkeleyDB code. It eliminates two levels of caching, entries pulled from the DB require zero decoding, readers require no locks, writes require no write-ahead-logging overhead. There are only two configurable parameters (the pathname to the DB file, and the size) so this will be far simpler for admins. Potential downside - on a 32 bit machine with only 2GB of addressable memory the maximum usable DB size is around 1.6GB. On a 64 bit machine, I doubt the limits will pose any problem. ("64 bits should be enough for anyone...") re: configuring the size of the DB file - this is most likely not a value that can be changed on an existing DB. I.e., if you configure a DB and find that you need to grow it later, you will probably need to slapcat/slapadd it again. At DB creation time the file is mmap'd with address NULL so that the OS picks the address, and the address is recorded in the DB. On subsequent opens the file is mmap'd at the recorded address. If the size is changed, and the process' address space is already full of other mappings, it may not be possible to simply grow the mapping at its current address. Since the DB records contain actual memory pointers based on the region address, any change in the mapping address would render the DB unusable. If this restriction turns out to be too impractical, we may have to resort to just storing array offsets, but that will then imply a decoding phase and the re-introduction of entry caching, which I really really want to avoid. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

4 6

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