Re: logging
by Howard Chu
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
> intentionally?
NO.
(just kidding)
> 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
place.
--
-- 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/
15 years, 11 months
Recursive access control for groups
by Alina Dubrovska
Hello,
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 group/groupOfUniqueNames/uniqueMember="cn=System
Administrator,ou=groups,dc=domain,dc=com" 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
attributes:
dn: cn=System Administrator,ou=groups,dc=domain,dc=com
uniqueMember: cn=user1,ou=users,dc=domain,dc=com
uniqueMember: cn=Sub Group,ou=groups,dc=domain,dc=com
dn: cn=Sub Group,ou=groups,dc=domain,dc=com
uniqueMember: cn=user2,ou=users,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
problems.
*First instance* (2.3.38) - After including some group in "System
Administrator" and performing some operations, then after some time OpenLDAP
crashes!
*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!
Please help!!!
Thanks a lot in advance,
Alina.
15 years, 11 months
Re: chain and ppolicy question
by Gavin Henry
<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"
>>> binddn="cn=proxy,dc=barlaeus,dc=nl"
>>> credentials="secret"
>>> 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?
>
> Best,
>
> --Tonni
>
> --
> Tony Earnshaw
> Email: tonni at hetnet dot nl
>
15 years, 12 months
size limit by ip?
by Patrick Radtke
Is it possible to control the size limit based on the ip address?
man slapd.conf
*limits* <*who*> <*limit*> *[*<*limit*> *[...]]
*The argument *who* can be any of
anonymous | users | [dn[.<style>]=]<pattern> |
group[/oc[/at]]=<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
authorized account?
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.
thanks,
Patrick
15 years, 12 months
Re: Recursive access control for groups
by Gavin Henry
<quote who="Alina Dubrovska">
> Gavin,
>
> 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")
> and
> all members should be granted access permission to modify specific
> attributes. Then we need to have ability to add new child groups in
> runtime,
> so that all child group members would be automatically granted the same
> set
> of permissions as parent group. Without modifying slapd.conf and
> restarting
> 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
http://www.openldap.org/its.
Please read http://www.openldap.org/doc/admin24/troubleshooting.html for
submitting proper bug reports.
15 years, 12 months
Re: Re[2]: slave-to-master replica
by Gavin Henry
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
>> working.
>
> Hi,
>
> 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:
>
> ---master:
> -------
> authz-policy to
>
> authz-regexp cn=admin
> cn=admin,dc=firm,dc=ru
>
> #authz-regexp cn=slave1.firm.ru
> cn=slave1.firm.ru,ou=IT,dc=firm,dc=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
> binddn="cn=admin,dc=firm,dc=ru"
> mode=self
> chain-idassert-authzFrom "*"
> chain-return-error TRUE
>
> syncrepl rid=5
> provider=ldap://192.168.0.1
> bindmethod=simple
> binddn="cn=admin,dc=firm,dc=ru"
> credentials=ghbrjkmysqcthdth
> searchbase="dc=firm,dc=ru"
> scope=sub
> schemachecking=on
> type=refreshAndPersist
> retry="50 +"
> updateref ldap://192.168.0.1
> ---------
> .that is the subject of the help ))
>
15 years, 12 months
chain and ppolicy question
by Tony Earnshaw
OpenLDAP 2.3.38.
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"
binddn="cn=proxy,dc=barlaeus,dc=nl"
credentials="secret"
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?
Best,
--Tonni
--
Tony Earnshaw
Email: tonni at hetnet dot nl
15 years, 12 months
Re: access control
by Quanah Gibson-Mount
--On December 5, 2007 1:41:49 PM -0500 Nathan Nobbe
<quickshiftin(a)gmail.com> wrote:
> 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
> organizationalPerson
> 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
benign, like:
dn: cn=people,dc=myorg,dc=com
objectclass: organizationalRole
description: people
cn: people
> 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
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 12 months
syncrepl - ldap_start_tls failed (-11)
by Cristian Laufer
Hello All,
Im trying to setup syncrepl with TLS. But so far it won´t work.
Actually Im a bit confused because Provider.log says "TLS established"
and consumer.log "ldap_start_tls failed (-11)".
My settings are as follows:
provider slapd.conf:
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
consumer slapd.conf:
index entryCSN,entryUUID eq
syncrepl rid=123
starttls=yes
provider=ldap://ldapmaster:389
type=refreshAndPersist
interval=00:00:00:01
searchbase="dc=test,dc=de"
filter="(objectclass=*)"
scope=sub
attrs="*"
schemachecking=off
updatedn="cn=syncuser,ou=system,dc=test,dc=de"
credentials="xxx"
bindmethod=simple
binddn="cn=admin,dc=uni-koblenz-landau,dc=de"
credentials="xxx"
provider.log:
Dec 5 15:40:57 testldap slapd[8997]: conn=2 op=3 UNBIND
Dec 5 15:40:57 testldap slapd[8997]: conn=2 fd=15 closed
Dec 5 15:41:01 testldap slapd[8997]: conn=3 fd=15 ACCEPT from
IP=192.168.1.2:50400 (IP=0.0.0.0:389)
Dec 5 15:41:01 testldap slapd[8997]: conn=3 op=0 STARTTLS
Dec 5 15:41:01 testldap slapd[8997]: conn=3 op=0 RESULT oid= err=0 text=
Dec 5 15:41:01 testldap slapd[8997]: conn=3 fd=15 TLS established
tls_ssf=256 ssf=256
Dec 5 15:41:01 testldap slapd[8997]: conn=3 op=1 BIND
dn="cn=admin,dc=test,dc=de" method=128
Dec 5 15:41:01 testldap slapd[8997]: conn=3 op=1 BIND
dn="cn=admin,dc=test,dc=de" mech=SIMPLE ssf=0
Dec 5 15:41:01 testldap slapd[8997]: conn=3 op=1 RESULT tag=97 err=0 text=
Dec 5 15:41:01 testldap slapd[8997]: conn=3 op=2 SRCH
base="dc=test,dc=de" scope=2 deref=0 filter="(objectClass=*)"
Dec 5 15:41:01 testldap slapd[8997]: conn=3 op=2 SRCH attr=*
structuralObjectClass entryCSN
consumer.log:
Dec 5 14:49:50 TESTNETZ-BDC slapd[6513]: slapd starting
Dec 5 14:49:51 TESTNETZ-BDC slapd[6513]: Warning: rid 123 ldap_start_tls
failed (-11)
Dec 5 14:49:51 TESTNETZ-BDC slapd[6513]: conn=0 fd=25 ACCEPT from
IP=127.0.0.1:54163 (IP=0.0.0.0:389)
Dec 5 14:49:51 TESTNETZ-BDC slapd[6513]: conn=0 op=0 BIND dn="" method=128
Dec 5 14:49:51 TESTNETZ-BDC slapd[6513]: conn=0 op=0 RESULT tag=97 err=0
text=
Dec 5 14:49:51 TESTNETZ-BDC slapd[6513]: conn=0 op=1 SRCH base=""
scope=0 deref=0 filter="(objectClass=*)"
Dec 5 14:49:51 TESTNETZ-BDC slapd[6513]: conn=0 op=1 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Dec 5 14:49:51 TESTNETZ-BDC slapd[6513]: conn=0 op=2 UNBIND
Dec 5 14:49:51 TESTNETZ-BDC slapd[6513]: conn=0 fd=25 closed
Does someone know what part of the setup could be wrong? Are there more
config files needed?
I would appreciate any help or hint!
Thank you!
Cristian
15 years, 12 months
