Joseph Dickson wrote:
> A quick preface -- I appreciate the work that everyone puts forth on the
> OpenLDAP project, including the documentation. OpenLDAP does a great
> job of allowing me to spend my time on things that are interesting and
> important to my particular situation, rather than fighting with a server.
> However, I do tend to speak up when I hear folks talk about the
> documentation that exists as being adequate... I think the best evidence
> that this is not the case is that, on this list, I consistently see the
> same 4 or 5 people answering the questions which pertain to the OpenLDAP
> server itself.
I don't think that proves your point; the vast majority of people using
OpenLDAP already figured out how to do everything they want with it and never
come here in the first place. All you're seeing is that a small segment of the
population actually takes the pains to answer questions.
> I would suggest that at least keeping a recent version of the
> documentation on the project website would help a great deal. I don't
> agree that the best place for the documentation to live is with the
> code, at least not for the user.
With 2.4 we've put procedures in place to update the online docs whenever a
new release is uploaded. As for docs living with the code - if you're using a
prebuilt distro, the docs obviously live wherever the distro packager put
them. If you built it yourself, the docs get installed when you install the
binaries. I don't see your point.
>> When you're looking for a software feature, the manpages and Admin
>> Guide should be your first resort. Pretty much every feature is
>> documented. Some features exist that are undocumented; most of them
>> are intentionally so, so don't give them a second thought. A web
>> search should be your last resort.
> Could you give me an example of a feature that remains undocumented
> This seems like a bad philosophy on the face of it, so I
> must be missing something..
Ok, for example, there are various options in different sections of code that
can only be enabled by explicitly defining certain macros at compile time.
They're not documented anywhere; if you look in the source code they're
obvious though. These tend to be extra debug functions that developers can use
while working on related code. Most people will never need them; developers
who need them can use them easily enough.
> In general, I just wanted to remind everyone that OpenLDAP's
> documentation isn't great, and saying that it is doesn't really help.
> Compare to the documentation of other projects (for example, Postgres),
> I think we can agree that there's quite a bit of room for improvement.
> I know it would be better for me to step up and begin writing rather
> than rubbing salt in the wound, as it were, but sadly my free time is
> already devoted to other things so the best I can do at this point is
> try to remind people that there is work to be done on the documentation.
Your reminder is less than worthless, because it just gives people an excuse
to continue to not rely on the existing docs, instead of using them and
helping to fix their shortcomings. It also fails to acknowledge the tremendous
amount of work that continues to be done on actually improving the docs.
(E.g., the 2.4 Admin Guide which is over 100 pages longer than the 2.3 Guide.)
And it belabors the obvious - everybody actually contributing to the OpenLDAP
codebase is already keenly aware of the need for improvement. If they thought
the status quo was fine, they wouldn't be writing contributions in the first
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
We need to configure recursive access control for groups in OpenLDAP server.
I will describe in details.
Currently we allow members of "System Administrator" group to modify
specific attributes by defining an ACL:
access to attrs=employeeType,employeeNumber
by self write
by * read
The problem is that we need to handle also nested memberships. If some group
is specified as a uniqueMember of "System Administrator" group, then access
should be granted to all sub-group members and so on recursively. In the
following example both users (user1 and user2) must be able to modify
dn: cn=System Administrator,ou=groups,dc=domain,dc=com
uniqueMember: cn=Sub Group,ou=groups,dc=domain,dc=com
dn: cn=Sub Group,ou=groups,dc=domain,dc=com
It should be possible to create new group, add it as uniqueMember to "System
Administrator" group and then all new group members automatically must be
granted access to attributes.
I have found the following solution, which uses Sets syntax:
access to attrs=employeeType,employeeNumber
by self write
* by set="[cn=System
Administrator,ou=groups,dc=domain,dc=com]/uniqueMember* & user" write*
by * read
At first glance it worked as expected, but then problems started to
appear... We have two OpenLDAP instances and now there are two different
*First instance* (2.3.38) - After including some group in "System
Administrator" and performing some operations, then after some time OpenLDAP
*Second instance* (2.3.27) - OpenLDAP doesn't crash, but operations (e.g.
search) are very slow (un-acceptable)!
I can provide more details if necessary.
So, my questions are:
1) Is ACL with subject:
*by set="[cn=System Administrator,ou=groups,dc=domain,dc=com]/uniqueMember*
& user" write*
valid for our situation?
2) Maybe there is another way to achieve our goal (that would be easier to
apply rather than investigating current problems)?
3) Could please somebody assist in problems with new configuration (crash on
1st instance and poor performance on 2nd) ?
By the way, we are using quite advanced configuration, with ppolicy, refint,
unique, accesslog overlays enabled.
So probably there are dependencies or incompatibilities between them...
That is very urgent and critical for our project, we really need to
solve this problem as soon as possible!
Thanks a lot in advance,
<quote who="Tony Earnshaw">
> Gavin Henry skrev, on 06-12-2007 23:13:
>>> My site is implementing ppolicy on a 4-server OpenLDAP/RHEL5 setup. I
>>> have a problem with chaining referrals from the 3 slaves to the master.
>>> I followed the slapo-chain man page and chaining works:
>>> moduleload back_ldap.la
>>> overlay chain
>>> chain-uri "ldaps://mercurius.intern"
>>> chain-idassert-bind bindmethod="simple"
>>> chain-return-error true
>>> cn=proxy,dc=barlaeus,dc=nl is the rootdn on all servers, thus also on
>>> the master.
>>> The rootdn is not able to update passwords. I have no idea why the
>>> rootdn shouldn't be able to update passwords (PASSMOD). However, it
>>> seems to me that the chaining from the slave should be carried out as
>>> the actual user and not rootdn. I can find nothing in slapo-chain or
>>> slapd-ldap that lists this possibility.
>>> Can anyone here help with this?
>> What are you logs/-d saying?
> It's been a while since and up to now I've only had logs going back 5
> days (I've increased this to 21 days now, but that doesn't help here).
> Basically, the rootdn bound, issued a PASSMOD instruction for
> userPassword and got a reply tag=103 error=0; it then did a MOD
> instruction for shadowLastChange and got the same. userPassword wasn't
> changed, but shadowLastChange was.
> By having the slave server connect directly to the provider instead of
> using the consumer's chain function, all happens as expected, so that's
> the workaround at the present- but it's far from optimal.
The slave connect directly to the provider? What does that mean? Surely
the slave issues a referral and the client follows it?
> Tony Earnshaw
> Email: tonni at hetnet dot nl
Is it possible to control the size limit based on the ip address?
*limits* <*who*> <*limit*> *[*<*limit*> *[...]]
*The argument *who* can be any of
anonymous | users | [dn[.<style>]=]<pattern> |
Which doesn't look like the 'who' can be an ip address,
but I just want to confirm that is the case (since the 'who' in
slapd.access support peername.ip and I'm hoping that
that the underlying code for both 'who's is the same :)
Basically we have software running on a host that is
unable to authenticate (due to 3rd party software)
and we need to increase the size limits for queries coming from it,
without increasing that limit for all anonymous binds.
Are there alternative ways of doing this?
Possibly setting up a server with back-ldap running, only allowing
access from the specific
ip address and letting the back-ldap server bind to real servers as an
Or is there a way to map ip address to an identity that can be used in
the limits control.
We're running 2.3.24.
<quote who="Alina Dubrovska">
> Thank you for reply and suggestion about support services!
> However, I'm looking forward that somebody from the list is familiar with
> sets syntax for defining an ACL and would be able to determine if ACL like
> this is correct:
> *access to attrs=employeeType,employeeNumber
> by self write
> by set="[cn=System
> Administrator,ou=groups,dc=domain,dc=com]/uniqueMember* & user" write
> by * read*
Switch on ACL debugging and run slapd by hand to check.
> So, we have a parent group (groupOfUniqueNames, "System Administrator")
> all members should be granted access permission to modify specific
> attributes. Then we need to have ability to add new child groups in
> so that all child group members would be automatically granted the same
> of permissions as parent group. Without modifying slapd.conf and
> server of course.
> Probably there is some important nuance with sets syntax or maybe there is
> any another alternative solution?
> Because as I mentioned, with stated ACL we have performance issues on one
> OpenLDAP instance and fatal crash on another...
Sets are somewhat experimental.
Well crashes shouldn't happen, so that should be a bug report via
Please read http://www.openldap.org/doc/admin24/troubleshooting.html for
submitting proper bug reports.
Thanks. And now your logs?
More info, more info....
<quote who="A Molchanov">
> -----Original Message-----
> From: Gavin Henry <ghenry(a)suretecsystems.com>
> To: A Molchanov <vip43(a)mail.ru>
> Date: Thu, 06 Dec 2007 20:31:25 +0000
> Subject: Re: slave-to-master replica
> A Molchanov wrote:
>> Hellow, its about for ldap-2.3 replication with syncrepl
>> I need slave-to-master replica, have making slapd.conf like
>> http://www.openldap.org/faq/data/cache/1434.html... but it's not
> Can we see your config?
>> Its even imposable to make changes on the slave directly,..
> A slave is readonly
>> I hope anybody have a working sample, ..please show me
> More info needed.
> yes, thanks, my ldap version 2.3-27
> my slapd.conf is:
> authz-policy to
> authz-regexp cn=admin
> #authz-regexp cn=slave1.firm.ru
> access to attrs=authzTo
> by * read stop
> overlay syncprov
> syncprov-checkpoint 100 10
> syncprov-sessionlog 100
> and slave:
> overlay chain
> chain-uri ldaps://master.firm.ru
> chain-idassert-bind bindmethod=simple
> chain-idassert-authzFrom "*"
> chain-return-error TRUE
> syncrepl rid=5
> retry="50 +"
> updateref ldap://192.168.0.1
> .that is the subject of the help ))
My site is implementing ppolicy on a 4-server OpenLDAP/RHEL5 setup. I
have a problem with chaining referrals from the 3 slaves to the master.
I followed the slapo-chain man page and chaining works:
cn=proxy,dc=barlaeus,dc=nl is the rootdn on all servers, thus also on
The rootdn is not able to update passwords. I have no idea why the
rootdn shouldn't be able to update passwords (PASSMOD). However, it
seems to me that the chaining from the slave should be carried out as
the actual user and not rootdn. I can find nothing in slapo-chain or
slapd-ldap that lists this possibility.
Can anyone here help with this?
Email: tonni at hetnet dot nl
--On December 5, 2007 1:41:49 PM -0500 Nathan Nobbe
> i have not read any material on ideal directory layout. can you refer me
> to good
> resource? the design i have created is based only on intuition. that,
> and the schema
> reference available in phpLdapAdmin. truth be told, ive found the
> documentation in
> the openldap administration guide only marginally helpful. at least i
> havent seen much
> in there about ldap itself; the guide seems to presume preexisting
> knowledge of ldap;
> of which mine is scant :)
Well, there's not hard rule. The general principal is, as flat as
possible, as deep as necessary. The problem of course is compounded that
bad design decisions at the beginning can haunt you for years. ;)
> if i were to have a tree for organizationalUnit objects and another for
> objects, what would the ideal root objectClass of those trees?
The root objectClass of a tree really does not have to pertain to the
objects contained in that tree. I tend to make my branch roots fairly
> In answer to your question, however, you may find that using sets helps
> with some of what you want to do.
> what are sets in the context of ldap?
That's an excellent question. Some day they'll be documented, hopefully.
:) But here are some examples:
access to dn.children="cn=people,dc=myorg,dc=com"
by set.exact="this/uid & user/uid" read
If THIS ENTRY and the BINDING USER have the same value for UID, allow READ
access to dn.children="cn=nis,dc=myorg,dc=com"
by set.exact="this/host & user" read
if THIS ENTRY's host attribute matches the USER, allow READ
Principal Software Engineer
Zimbra :: the leader in open source messaging and collaboration
Hellow, its about for ldap-2.3 replication with syncrepl
I need slave-to-master replica, have making slapd.conf like http://www.openldap.org/faq/data/cache/1434.html... but it's not working.
Its even imposable to make changes on the slave directly,..
I hope anybody have a working sample, ..please show me