I have an ldap server acting as proxy, through back-ldap, to another
ldap server which holds the data.
These servers are in distinct networks and connections are all routed
through a firewall.
Both proxy and backend servers are running openldap version 2.4.17 (from
Everything is working fine except that from time to time the proxy
server has trouble responding requests. These anomalies happen not very
often and for very short periods of time, usually from a couple of
seconds to ten seconds. Although things keep working, it's rather
annoying for the end user to have its interaction with a system delayed
or denied, even if for such short periods.
Both system loads, from the proxy and the backend server, appear to be
fine and i have no reason to believe that it's a matter of system
I can observe though a rather large number of connections (usually from
1k to 2k), from the proxy server to the backend server, in CLOSE_WAIT
state. Both servers have set an idletimeout value of 30 seconds and i
was to expect that the unused connections would seize to exist after
that period of time.
Basically i want to know if this number of connections is normal, taking
in consideration that most queries and performed anonymously and i'm
quite positive that there aren't more than a couple hundred of
authenticated binds simultaneously.
What steps can i take to reduce this behavior?
Thank you all in advance,
fct.unl.pt:~# cat .signature
Email : hugo.monteiro(a)fct.unl.pt
Telefone : +351 212948300 Ext.15307
Web : http://hmonteiro.net
Divisão de Informática
Faculdade de Ciências e Tecnologia da
Universidade Nova de Lisboa
Quinta da Torre 2829-516 Caparica Portugal
Telefone: +351 212948596 Fax: +351 212948548
I have a setup with 2 masters (nway multimaster) and 4 slaves each having
syncrepl set up to connect to the 2 masters. The question I have, with the
following configuration (on the slaves) should they always be connected to
the masters? Netstat is showing that the connections are intermittent:
type=refreshAndPersist retry="60 +"
Netstat on the masters shows that the connections from the slaves will vary
sometimes 0, sometimes 4 seems to be somewhat random. We are trying to
determine if there is something wrong in our network. Thanks for the help.
I agree about userPassword
Something like that can restrict access to it
access to attrs=userPassword
by anonymous auth
by * none
Information Technology Services
University of Saskatchewan
phone: (306) 966-2762
I've set up an openLDAP directory with the password policy overlay and the
ppolicy_hash_cleartext option to ensure cleartext passwords get hashed (as
my client request).
But the slapo-ppolicy man page clearly states:
"It is recommended that when this option is used that compare, search, and
read access be denied to all directory users."
Its this warning about the userPassword attribute only? That is, more or
less, the standard configuration, not even the user can read his password,
only write. Or this warning applies to all the directory (bit too much?)
Any reason for this warning in particular here? I mean, not letting anybody
but the rootdn see the userPassword attribute is a good idea anyway, any
particular reason why enabling ppolicy_hash_cleartext makes its extra-good?
Jesús Couto F.
> Am 10.04.10 00:03 schrieb "masarati(a)aero.polimi.it" unter
>>> I am trying to use the
>>> module with slapd 2.4.11 (from debian).
>>> access to dn.children="dc=dg-i,dc=net"
>>> by dynacl/now=>=auditTimestamp none
>>> by dynacl/now=<=auditTimestamp none
>>> by group.exact="cn=Readers,...." read
>> Yes. I think you did not understand the logic behind the ACI access
>> granting mechanism. When you write
>> by dynacl/now=>=auditTimestamp none
>> the "none" indicates how much privilege you allow this rule to give.
>> Then, if the rule matches, the privilege is given, otherwise it is not.
>> This was designed because ACIs were much more granular that the "now"
>> dynacl. Think of this dynacl as something that gives a boolean
>> (match/nomatch). If true, the access level will be granted, otherwise
>> denied. So, if you have an attribute "validityStarts" and another
>> "validityEnds", and you want to allow "read" access to entries that are
>> between the validity interval, you'd need to do
>> access to <what>
>> by dynacl/now=">=validityStarts" <level> break
>> access to <what>
>> by dynacl/now="<=validityEnds" <level>
> What I am trying to do is I want to deny access to for Users who either
> noty yet valid or are expired.
> access to <what>
> by dynacl/now="<=validityStarts" none
> by dynacl/now=">=validityEnds" none
> Would this deny Users that are not valid or expired ?
If it were fine, it would work as expected. Do you see any resemblance
between this and what I wrote above? Personally, I don't. By setting
<level> to "none" you're telling dynacl to ignore those rules (line 1772
of slapd/acl.c). That's why now_dynacl_mask() is not even invoked.
I am trying to use the
module with slapd 2.4.11 (from debian).
The module seams to initialize correctly but the "now_dynacl_mask" function
is never called. my testing ACL looks like:
access to dn.children="dc=dg-i,dc=net"
by dynacl/now=>=auditTimestamp none
by dynacl/now=<=auditTimestamp none
by group.exact="cn=Readers,...." read
This should allways fail but it does not. it read access is grants to the
object for members of the group.
Is the module intended for use with 2.4 ?
Dembach Goo Informatik GmbH & Co KG
Tel: +49 221 801483 0
Mobil: +49 177 8091974
Fax: +49 221 801483 20
Emergency: +49 180 555 4992
Amtsgericht Köln HRA 22794, UST ID: DE242 159 527
Geschäftsführer: Manon Goo, Andreas Dembach
Haftende Gesellschafterin: Dembach Goo Verwaltungs GmbH
Just for fun I was testing the perl backend for openldap.
I starting setting up an LDAP using the SampleLdap.pm perl library in the
My goal is to setup a consumer LDAP in synch with other LDAP (bdb backend)
for keeping the mod add del etc. using the syncrepl mechanism.
I want to wrap every modification in the Master LDAP and triggering some
I'm very new to this approach and the first problem I'm facing is how to
keep the last db state after a slapd crash or shutdown.
Using SamplLdap.pm init it's just a subroutine returning 0, so after the
first sync if I shutdown the slapd next time I will need a full resync.
Do you know some other clever examples? I mean keeping the state of the LDAP
and triggering, for example recording on files, the modifications on LDAP.
I tried to add in the subroutine some operation on FILES (using standard
open FILE....;print FILE "operation"; close (FILE)) it seems do not work.
Many thanks to all!
I have a local OpenLDAP server with a couple of users. I'm using it for
development purposes, here's the ldif:
#Top level - the organization
dn: dc=site, dc=com
description: OneLogin LLC
o: OneLogin LLC
#Top level - manager
dn: cn=Manager, dc=site, dc=com
#Second level - organizational units
dn: ou=people, dc=site, dc=com
description: All people in the organization
dn: ou=groups, dc=site, dc=com
description: All groups in the organization
#Third level - people
dn: uid=celoserpa, ou=people, dc=site, dc=com
cn: Marcelo de Moraes Serpa
sn: de Moraes Serpa
So far, so good. I can bind with "cn=Manager,dc=site,dc=com" and the
12345678 password (the local server password, setup on slapd.conf).
However, I would like to bind with any user in under the people OU. In this
case, I'd like to bind with:
dn: uid=celoserpa, ou=people, dc=site, dc=com
But I'm getting a (49) - Invalid Credentials error everytime. I have tried
through CLI tools (such as ldapadd, ldapwhoami, etc) and also ruby/ldap. The
bind with these credentials fails with a invalid credentials error.
I was suspecting that maybe OpenLDAP doesn't compare against userPassword?
Or maybe some ACL configuration I am missing that is somehow affecting the
read access to userPassword for the specific DN.
I'm really lost here, any suggestion appreciated!
I have two replicas of my DIT, which unfortunately got out of sync
somehow. So I can spot a particular object where one attribute has a
different value on one replica than it has on the other one.
What would I do to find out how that could have happened?
What would I do to fix this? (Other than manually deciding which data is
the right one and overwrite the other; I guess this may not even fix it
for the next update.)