openldap-technical

openldap-technical@openldap.org

1 participants
9868 discussions

Open ldap GPG Keyserver
by Michée Lengronne 10 May '13

10 May '13

Hello, I would like to know if it is possible to do a GPG Keyserver with Openldap. I found tutorials but very outdated. I use Debian Squeeze and I saw that ldaputils is an optionnal dependency for the gnupg package, so I think it is possible. Do you have tutorials somewhere, some examples to do that ? Is there some restrictions ? Thanks. -- Michée Lengronne's email footer Michée Lengronne Tel: +33(0)672504808 -- E-mail: michee(a)lengronne.ch My online CV <http://www.doyoubuzz.com/michee-lengronne>

1 0

index on attribute in acl filter
by Al 10 May '13

10 May '13

Hi, I am looking for a way to allow certain support individuals to unlock ldap accounts that have been locked by too many failed auth attempts (ppolicy), however I do not want them to be able to unlock accounts that have been locked for administrative reasons. I was assuming I could use an ACL like the one below, since we lock an account for administrative reasons with the same pwdAccountLockedTime value - {6}to dn.subtree="cn=users,dc=company,dc=com" filter=(!(pwdAccountLockedTime=000001010000Z)) by group/groupOfUniqueNames/uniqueMember.exact="cn=user_admins,cn=groups,dc=company,dc=com" write by users read {7}to dn.subtree="cn=users,dc=company,dc=com" filter=(pwdAccountLockedTime=000001010000Z) by group/groupOfUniqueNames/uniqueMember.exact="cn=super_user_admins,cn=groups,dc=company,dc=com" by users read I know for a search with that filter, an index on pwdAccountLockedTime would be beneficial, but would it help for an acl filter? Does this seem like a reasonable approach? Thanks in advance, Al

2 1

cleaning HDB after an unclean shutdown
by Benin Technologies 10 May '13

10 May '13

Hi, I'm doing some tests on a perl backend, which causes sometimes my OpenLDAP to hang. I then kill the process, but when I try to restart openldap it won't, because of my HDB backend. I get the following message : db_db_open: database "dc=mycompany": database already in use. After rebooting the server, everything works fine. Any way to "clean" the HDB backend manually, without having to reboot the server ? Ben

4 6

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical