openldap-technical May 2013

openldap-technical@openldap.org

67 participants
76 discussions

connection_read
by paulo bruck 09 May '13

09 May '13

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)

2 1

SSH Gateway
by Stuart Watson 09 May '13

09 May '13

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

5 8

compile OpenLDAP with SSL support
by Ashwin Kumar 09 May '13

09 May '13

How to compile OpenLDAP libraries with SSL (OpenSSL) support? Please provide me with instructions to build on Linux and Windows. Thanks and regards. -- Ashwin kumar (http://ashwinkumar.me)

1 0

Re: dynamic group perfs
by Jephte Clain 08 May '13

08 May '13

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

2 1

dynamic group perfs
by Jephte Clain 08 May '13

08 May '13

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

3 3

Looking for schema work around
by jckidder＠aep.com 08 May '13

08 May '13

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

2 2

Using LDAP how to restrict users to certain applications only
by Geo P.C. 07 May '13

07 May '13

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

3 4

Unable to login applications using LDAP alias
by Geo P.C. 07 May '13

07 May '13

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

2 1

password policy and pwdMustChange behavior
by Felix Schmitt 06 May '13

06 May '13

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

1 0

Unable to use TLS in a 2-WayMaster/MirrorMode Setup
by Thomas Macaigne 06 May '13

06 May '13

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,

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical May 2013