openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

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

invalid value for attributeType olcSuffix while restoring cn=config (slapd-2.4.33)
by Igor Zinovik 06 May '13

06 May '13

Hello, openldap-technical@ readers. I backed up cn=config from openldap-2.4.33 and now i try to restore it, but with no success. I made backup copy this way: ldap1# sudo slapcat -b cn=config -F /etc/openldap/slapd.d -l config.ldif After this i created new clean VM with opensuse 12.3 and slapd 2.4.33 opensuse# slapadd -u -F /etc/openldap/slapd.d -b cn=config -l config.ldif 5187acde str2entry: invalid value for attributeType olcSuffix #0 (syntax 1.3.6.1.4.1.1466.115.121.1.12) slapadd: could not parse entry (line=3206) _################### 98.19% eta none elapsed none spd 19.9 M/s opensuse# fgrep -n olcSuffix config.ldif 522:olcAttributeTypes: ( OLcfgDbAt:0.10 NAME 'olcSuffix' EQUALITY distinguishedNam 1049: n $ olcSuffix $ olcSubordinate $ olcAccess $ olcAddContentAcl $ olcLastMod $ 3205:olcSuffix: dc=example,dc=ru 3411:olcSuffix: cn=example-log LDIF content around line 3206 is following: 3201: dn: olcDatabase={1}mdb,cn=config 3202: objectClass: olcDatabaseConfig 3203: objectClass: olcMdbConfig 3204: olcDatabase: {1}mdb 3205: olcSuffix: dc=example,dc=ru 3206: olcAddContentAcl: FALSE Here is trace: 5187b22a <<< dnPrettyNormal: <olcDatabase={1}mdb,cn=config>, <olcDatabase={1}mdb,cn=config> 5187b22a >>> dnPretty: <dc=example,dc=ru> 5187b22a str2entry: invalid value for attributeType olcSuffix #0 (syntax 1.3.6.1.4.1.1466.115.121.1. 12) slapadd: could not parse entry (line=3201)

1 0

Use LDAP netgroup to control NFS exports?
by jupiter 06 May '13

06 May '13

Hi, I am running LDAP server and NFS server on CentOS 6, is it true that LDAP can be used to control NFS exports authentication, uid and gid setting without needing to specifie client IP addresses , anonuid and anongid on NFS exports file? I saw some sample such as to define "/tmp/nfs2 @mynetgrp(rw,no_root_squash)" to exports file, it seems to me, you can add new user with IP address to LDAP entry anytine without updating exports file in NFS server? If it is correct, has the netgroup schema already been defined in /etc/openldap/schema? Could anyone kindly point me a link for document or howto for the setting in both LDAP and NFS exports? Thank you. Kind regards. Jupiter

2 1

About ppolicy
by Jacques Foucry 06 May '13

06 May '13

Hello Folks, On my openldap server I was using shadowAccount to enforce password change for my users. It works, but it's not really secure. Users can reuse old passwors, etc. So I had a look to ppolicy and appli this tutorial: http://theslashroot.blogspot.fr/2011/12/openldap-with-ppolicy.html Some things are not clear for me. Did I have to disable shadowAccount on my schema? If not is shadowLastChange will be updated? I hope I need to include ppolicy schema on all my replica. Thanks in advance for your help, Jacques Foucry -- Jacques Foucry *NOVΛSPARKS * IT Manager Tel : +33 (0)1 42 68 12 61 jacques.foucry(a)novasparks.com

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical