connection_read
by paulo bruck
Hello guys
using openldap as master :
debian squeeze
ldap version 2.4.23-7.3
around 85 openldap as slaves based on red hat.
since last week we have been seeing a lot of connection_read in ldap master
reading docs about it:
http://www.openldap.org/lists/openldap-software/200208/msg00118.html
inserting at master slapd.conf:
connections 20000
threads 64
and after some time some of our branches stay w/ base different from master.
Is there any other parameter than we could change to mantain all branches
w/ the same base as Master???
best regards
May 9 15:34:02 ldap slapd[27856]: conn=5570 fd=272 closed (connection lost)
May 9 15:34:02 ldap slapd[27856]: conn=5569 fd=279 closed (connection lost)
May 9 15:34:02 ldap slapd[27856]: conn=5574 fd=279 closed (connection lost)
May 9 15:34:02 ldap slapd[27856]: conn=5573 fd=277 closed (connection lost)
May 9 15:34:03 ldap slapd[27856]: connection_read(274): no connection!
May 9 15:34:03 ldap slapd[27856]: connection_read(274): no connection!
May 9 15:34:03 ldap slapd[27856]: connection_read(274): no connection!
May 9 15:34:03 ldap slapd[27856]: connection_read(274): no connection!
May 9 15:34:04 ldap slapd[27856]: connection_read(274): no connection!
May 9 15:34:04 ldap slapd[27856]: connection_read(274): no connection!
May 9 15:34:04 ldap slapd[27856]: conn=5549 fd=263 closed (connection lost)
May 9 15:34:04 ldap slapd[27856]: conn=5558 fd=278 closed (connection lost)
May 9 15:34:04 ldap slapd[27856]: conn=5551 fd=270 closed (connection lost)
May 9 15:34:04 ldap slapd[27856]: connection_read(274): no connection!
May 9 15:34:04 ldap slapd[27856]: connection_read(274): no connection!
May 9 15:34:04 ldap slapd[27856]: conn=5550 fd=268 closed (connection lost)
May 9 15:34:04 ldap slapd[27856]: conn=5547 fd=221 closed (connection lost)
May 9 15:34:05 ldap slapd[27856]: connection_read(263): no connection!
May 9 15:34:05 ldap slapd[27856]: connection_read(263): no connection!
May 9 15:34:08 ldap slapd[27856]: conn=5577 fd=277 closed (connection lost)
May 9 15:34:09 ldap slapd[27856]: conn=5588 fd=263 closed (connection lost)
May 9 15:34:10 ldap slapd[27856]: conn=5575 fd=273 closed (connection lost)
May 9 15:34:10 ldap slapd[27856]: conn=5572 fd=276 closed (connection lost)
May 9 15:34:14 ldap slapd[27856]: conn=3461 fd=248 closed (connection lost)
9 years, 9 months
SSH Gateway
by Stuart Watson
Hi
I am looking at creating a SSH gateway using OpenLDAP. The idea is to
store our devs public keys in OpenLdap, which would give us the ability to
control who has SSH access to our servers.
Currently everyone shares the same key which means it is impossible to
control access.
Do I just need to...
Install OpenLDAP
Import the public keys into OpenLDAP
Install OpenSSH Server on the OpenLDAP server and configure it to use LDAP.
Configutre the remote servers to use the OpenLDAP servers to authenticate
The the devs can ssh from their computers through the OpenLDAP server to
the remote servers.
Can anyone help?
Thanks
9 years, 9 months
Re: dynamic group perfs
by Jephte Clain
2013/5/7 Quanah Gibson-Mount <quanah(a)zimbra.com>:
> --On Tuesday, May 07, 2013 9:36 AM +0400 Jephte Clain
> <jephte.clain(a)univ-reunion.fr> wrote:
>
>> It needs more than 30 seconds to build the dynamic group! and this is the
>> case every time I do the search
>>
>> For the sake of it, I made a static group with 45000 member, and it takes
>> 0.037 seconds for the search
>>
>> So my question is: is it normal for the dynamic group to be so slow to be
>> built? is there something I can do?
>
>
hello. thanks for your answer
> What about the second time you run a query on a subtree?
it's the same every time, so it's not a cache problem
> For back-hdb, the
> first time it has load a bunch of data into the idl cache IIRC. Also, you
> do not show in your config if you have actually indexed the attributes to be
> used by the dynamic group. This of course would be a requirement. For
> example:
>
> <ldap:///ou=users,ou=cas,dc=univ-reunion,dc=fr??one?(uid=*)>
>
> pres index on uid
>
> <ldap:///ou=webaccounts,dc=univ-reunion,dc=fr??one?(&(uid=*)(runUnivCategorie=inconnu)(!(runUnivAuthorization=webaccounts:disabled)))>
>
> runUnivCategorie -> eq index
> runUnivAuthorizaion -> eq index
well, all these attributes have an eq index, and I assumed an eq index
would imply the pres index. maybe that's the problem. I will try it on
friday, it's not possible right now.
you may have noticed in the examples I gave in the first mail: the
individual searches by themselves are quite fast.
$ time ldapsearch (...) -b ou=users,ou=cas,dc=univ-reunion,dc=fr
"(uid=*)" dn >/dev/null
real 0m1.025s
$ time ldapsearch (...) -b ou=webaccounts,dc=univ-reunion,dc=fr
"(&(uid=*)(runUnivCategorie=inconnu)(!(runUnivAuthorization=webaccounts:disabled)))"
dn >/dev/null
real 0m0.043s
$ time ldapsearch (...) -b ou=groups,ou=eduspot,dc=univ-reunion,dc=fr
"(cn=users)" member >/dev/null
real 0m34.334s
what I don't understand is how 1.025 + 0.043 = 34.33
or perhaps 1.025 is very slow by openldap standards, and the reason is
that there is only an eq index on uid?
but I didn't set a pres index on uid because in the branches above,
nearly 100% of the objets beneath have the uid attribute, and the
openldap admin guide says:
----------------------------- 8< -----------------------------
21.2.3. Presence indexing
If your client application uses presence filters and if the target
attribute exists on the majority of entries in your target scope, then
all of those entries are going to be read anyway, because they are
valid members of the result set. In a subtree where 100% of the
entries are going to contain the same attributes, the presence index
does absolutely NOTHING to benefit the search, because 100% of the
entries match that presence filter.
So the resource cost of generating the index is a complete waste of
CPU time, disk, and memory. Don't do it unless you know that it will
be used, and that the attribute in question occurs very infrequently
in the target data.
Almost no applications use presence filters in their search queries.
Presence indexing is pointless when the target attribute exists on the
majority of entries in the database. In most LDAP deployments,
presence indexing should not be done, it's just wasted overhead.
----------------------------- 8< -----------------------------
Is dynamic group a special case where a presence index is required?
thanks in advance for any insights
>
> --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
--
cordialement,
Jephté Clain
Direction des Systèmes d'Information
et des Usages Numériques - 2IG
Tél. 0262 93 86 31
Fax. 0262 93 81 06
9 years, 9 months
dynamic group perfs
by Jephte Clain
hello all,
I have a weird perf problem with a dynamic group. I wonder if it is
normal, and if I can improve the situation. jump to the line marked
"-------------> for the impatients, JUMP HERE :-)" if you want to skip
the details
This is openldap 2.4.35 on debian 6 (built from source with debian
defaults and patches)
here the relevant configuration:
------------ 8< ------------
dn: cn=module{0},cn=config
...
olcModuleLoad: {4}dynlist.la
dn: olcDatabase={2}hdb,cn=config
...
olcDbCacheSize: 4096
olcDbCheckpoint: 1024 10
olcDbConfig: {0}set_cachesize 2 0 0
olcDbConfig: {1}set_lk_max_objects 32768
olcDbConfig: {2}set_lk_max_locks 32768
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbConfig: {4}set_lg_dir /var/lib/ldap/logs/dc=univ-reunion,dc=fr
olcDbConfig: {5}set_lg_regionmax 262144
olcDbConfig: {6}set_lg_bsize 524288
olcDbIDLcacheSize: 12288
dn: olcOverlay={2}dynlist,olcDatabase={2}hdb,cn=config
...
olcDlAttrSet: {0}groupOfURLs memberURL member
------------ 8< ------------
and the definition of the dynamic group:
------------ 8< ------------
dn: cn=users,ou=groups,ou=eduspot,dc=univ-reunion,dc=fr
objectClass: groupOfURLs
memberURL: ldap:///ou=users,ou=cas,dc=univ-reunion,dc=fr??one?(uid=*)
memberURL:
ldap:///ou=webaccounts,dc=univ-reunion,dc=fr??one?(&(uid=*)(runUnivCategorie=inconnu)(!(runUnivAuthorization=webaccounts:disabled)))
------------ 8< ------------
this result in a dynamic group with 45000 members
I dont know how the final application will use the dynamic group, but I
did some tests on my own.
now for the perf tests:
$ time ldapsearch -LLL -H "ldap://localhost" -x -D
cn=admin,dc=univ-reunion,dc=fr -wadmin -b
ou=users,ou=cas,dc=univ-reunion,dc=fr "(uid=*)" dn >/dev/null
real 0m1.025s
user 0m0.096s
sys 0m0.196s
$ time ldapsearch -LLL -H "ldap://localhost" -x -D
cn=admin,dc=univ-reunion,dc=fr -wadmin -b
ou=webaccounts,dc=univ-reunion,dc=fr
"(&(uid=*)(runUnivCategorie=inconnu)(!(runUnivAuthorization=webaccounts:disabled)))"
dn >/dev/null
real 0m0.043s
user 0m0.004s
sys 0m0.004s
$ time ldapsearch -LLL -H "ldap://localhost" -x -D
cn=admin,dc=univ-reunion,dc=fr -wadmin -b
ou=groups,ou=eduspot,dc=univ-reunion,dc=fr "(cn=users)" member >/dev/null
real 0m34.334s
user 0m0.024s
sys 0m0.000s
-------------> for the impatients, JUMP HERE :-)
It needs more than 30 seconds to build the dynamic group! and this is
the case every time I do the search
For the sake of it, I made a static group with 45000 member, and it
takes 0.037 seconds for the search
So my question is: is it normal for the dynamic group to be so slow to
be built? is there something I can do?
thanks in advance for your answers! best regards,
--
cordialement,
Jephté Clain
Direction des Systèmes d'Information
et des Usages Numériques - 2IG
Tél. 0262 93 86 31
Fax. 0262 93 81 06
9 years, 9 months
Looking for schema work around
by jckidder＠aep.com
I have an application vendor that attempts schema validation incorrectly
and fails. This failure prevents us from being able to configure the
application to connect to our OpenLDAP implementation. I have identified
the issue and have a case open with the software vendor to get it fixed.
The failing application is part of a suite that must deploy to production
very soon in order to meet regulatory requirements and avoid very costly
fines. The application vendor is not obligated in any way to meet our
deadlines and has indicated that they will not be able to provide a code
fix in time. We have a work around that allows us to manage user accounts
locally within the application suite itself. If we are forced to take
this approach when this application is implemented we will not be able to
cost effectively switch back to LDAP once the vendor fixes the code. I'm
in a very tough spot where I'm trying to avoid this. To get past the
broken schema validation I need cn=Subschema to appear as cn=schema. I've
tried everything I can think of (short of tweaking the source) and every
approach I've tried has one little technical detail that prevents it from
working. Anyone have any ideas I could use? At this point I'm even
considering a replica that uses modified source but I have no experience
with the OpenLDAP source and would need hints as to how much effort this
is and where to make the code changes.
Any ideas or assistance would be greatly appreciated.
-Jon C. Kidder
American Electric Power
Middleware Services
614-716-4970
9 years, 9 months
Using LDAP how to restrict users to certain applications only
by Geo P.C.
Hi
We are using many applications like zabbix, phabricator, AC etc. We need to
integrate LDAP in all these applications. These application support LDAP
but not group based authentication.
Please let us know is there any option to restrict selected users to login.
We created all users under ou ‘users’ .
[image: Inline image 1]
On these application we need to login certain users only. How we can
restrict it as we can’t able to restrict on application side
In these application they provide only “Base DN” and “Search Attribute” so
we can’t able to give dn: ou=users,ou=system as it gives access to all
users.
So is it possible to give Base DN as “cn=Zabbix,ou=groups,ou=system” and
this group contains only user1 and user2. SO it will restrict users.
Please let us know how we can implement this scenario. Thanks in advance
please help us to solve this issue.
Thanks
Geo
9 years, 9 months
Unable to login applications using LDAP alias
by Geo P.C.
We have several applications and we are able to integrate LDAP
successfully.
In application we have given base dn as ou=People,dc=geo,dc=com and
the user dn: uid=geo_pc,ou=People,dc=geo,dc=com can able to login to
the application successfully.
Now we created an alias as follows:
dn: uid=geo_pc,ou=Applications,ou=Groups,dc=geo,dc=com
aliasedobjectname: uid=geo_pc,ou=People,dc=geo,dc=com
objectclass: alias
objectclass: extensibleObject
objectclass: top
uid: geo_pc
Now in application we have given base dn as
ou=Applications,ou=Groups,dc=geo,dc=com but with this user
ou=Applications,ou=Groups,dc=geo,dc=com we are unable to login to the
application.
Please let us know is there any additional configuration we need to
done. Can anyone please help us on it.
Thanks
Geo
9 years, 9 months
password policy and pwdMustChange behavior
by Felix Schmitt
Hi,
I'm installing an OpenLDAP directory server at a customer and we're also implementing password policies. We do have set the pwdMustChange attribute to true in our policy.
During the tests I was a bit surprised that a user for which I've set the password did not require to change his password but was allowed access with the new password.
Reading the documentation and the (expired) draft standard clearly suggests a different behavior.
pwdMustChange (true or false)
This attribute specifies with a value of "TRUE" that users must change their passwords when they first bind to the directory after a password is set or reset by a password administrator. If this attribute is not present, or if the value is "FALSE", users are not required to change their password upon binding after the password administrator sets or resets the password. This attribute is not set due to any actions specified by this document, it is typically set by a password administrator after resetting a user's password.
Then I did some research on the web and found this thread http://www.openldap.org/lists/openldap-technical/201106/msg00178.html It seems an administrator needs to additionally set the pwdReset attribute to force the user to change the password.
The question is: Why does an administrator need to set this attribute? Why isn't this done by the directory server on its own? The directory server does change a few other password policy related attributes as can be seen from the audit log (see below). Thus it should be possible to do the same for the pwdReset attribute.
This behavior of OpenLDAP is different from what I'm used from the Sun (now Oracle) Directory Server where the pwdReset attribute is changed automatically.
Best regards
Felix
# modify 1367849424 dc=telefonica,dc=com cn=Manager,dc=example,dc=com IP=192.168.186.141:52267 conn=1561
dn: uid=fbtwo,ou=people,dc=de,dc=telefonica,dc=com
changetype: modify
replace: userPassword
userPassword:: e1NTSEF9VzNpZmtPRkROQTk0MCtmR3pIanZOcTdxbk9QUDArNTM=
-
replace: pwdChangedTime
pwdChangedTime: 20130506141024Z
-
delete: pwdGraceUseTime
-
add: pwdHistory
pwdHistory: 20130506141024Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}AU4VVldD3ct
JnHil4AZPHnIC4G1aobhg
-
replace: entryCSN
entryCSN: 20130506141024.395155Z#000000#001#000000
-
replace: modifiersName
modifiersName: cn=Manager,dc=example,dc=com
-
replace: modifyTimestamp
modifyTimestamp: 20130506141024Z
-
# end modify 1367849424
----
Felix Schmitt
Blumenweg 24 phone: +49 8092 20796
D-85567 Grafing mobile: +49 172 842 99 12
Germany mailto:Felix-Schmitt@t-online.de
9 years, 9 months
Unable to use TLS in a 2-WayMaster/MirrorMode Setup
by Thomas Macaigne
Hi,
It's been a few days I'm trying to replicate my actual LDAP server on a new one.
@(#) $OpenLDAP: slapd 2.4.21 (Dec 19 2011 15:18:58) $
buildd@roseapple:/build/buildd/openldap-2.4.21/debian/build/servers/slapd
and
@(#) $OpenLDAP: slapd (Oct 17 2012 19:48:41) $
buildd@komainu:/build/buildd/openldap-2.4.28/debian/build/servers/slapd
for the replica.
The replication part works great, but whenever I try to use TLS it fails.
Here is how I proceed:
- Genereate the certs (tried with CA.sh, CA.pl, certtools)
-> I use the servers fqdn as CN (hostname --fqdn gives the right output)
- Copy files to /etc/ldap/ssl
- chmod 660 them and chown openldap:openldap
An ouput of slapcat can be found here: http://paste.ubuntu.com/5638646/
When I try to check if TLS is working by using -ZZ of ldapsearch:
ie: ldapsearch -xLLL -b dc=beware,dc=fr -D cn=admin,dc=beware,dc=fr -w motdepasse -H ldap://master.beware.fr/ -ZZ
I get no error.
The errors I get are:
May 6 16:14:20 master slapd[1057]: slapd starting
May 6 16:14:23 master slapd[1057]: slap_client_connect: URI=ldap://slave.beware.fr/ DN="cn=admin,cn=config" ldap_sasl_bind_s failed (-1)
May 6 16:14:23 master slapd[1057]: do_syncrepl: rid=002 rc -1 retrying (4 retries left)
May 6 16:14:23 master slapd[1057]: slap_client_connect: URI=ldap://slave.beware.fr Warning, ldap_start_tls failed (-1)
May 6 16:14:26 master slapd[1057]: slap_client_connect: URI=ldap://slave.beware.fr DN="cn=admin,dc=beware,dc=fr" ldap_sasl_bind_s failed (-1)
May 6 16:14:26 master slapd[1057]: do
(on the slave)
e.fr Error, ldap_start_tls failed (-1)
May 6 16:14:55 slave slapd[1278]: do_syncrepl: rid=003 rc -1 retrying (4 retries left)
May 6 16:15:00 slave slapd[1278]: slap_client_connect: URI=ldap://master.beware.fr/ DN="cn=admin,cn=config" ldap_sasl_bind_s failed (-1)
May 6 16:15:00 slave slapd[1278]: do_syncrepl: rid=001 rc -1 retrying (3 retries left)
May 6 16:15:00 slave slapd[1278]: slap_client_connect: URI=ldap://master.beware.fr Error, ldap_start_tls failed (-1)
May 6 16:15:00 slave slapd[1278]: do_syncrepl: rid=003 rc -1 retrying (3 retries left)
output of slapd -d 16383
5187bb09 slap_client_connect: URI=ldap://master.beware.fr Error, ldap_start_tls failed (-1)
5187bb09 daemon: activity on 1 descriptor
5187bb09 daemon: activity on:5187bb09
5187bb09 daemon: epoll: listen=7 active_threads=0 tvp=zero
5187bb09 daemon: epoll: listen=8 active_threads=0 tvp=zero
5187bb09 do_syncrepl: rid=003 rc -1 retrying (3 retries left)
Regards,
9 years, 9 months
