openldap-technical November 2013

openldap-technical@openldap.org

73 participants
72 discussions

Q: monitoring attributes
by Ulrich Windl 28 Nov '13

28 Nov '13

Hi! I found out why I never was successful with cn=monitor: By default '*' attributes show almost nothing; you'll have to use '+' attributes (in my version at least). I'm not very happy with the decision, because you'll get the truely operational attributes also. If the whole subtree cn=Monitor is invisible in naming contexts, I see little reason to hide the "normal" attributes as operational in the whole subtree. Seeing those operational atributes, I noticed that "creatorsName" and "modifiersName" are both present but have an empty value. That doesn't look very nice, especially as createTimestamp and modifyTimestamp do have proper values. Using monitoredObject for all monitored values gives a unique interface, but having all possible results in monitoredInfo is not very usable, especially if there's no description. For example (some attributes removed for brevity): --- dn: cn=Uptime,cn=Time,cn=Monitor structuralObjectClass: monitoredObject monitoredInfo: 153543 hasSubordinates: FALSE --- It's not clear (denying the obvious) what the units of uptime are: seconds, minutes, etc. It seems to me that "monitoredType" or "monitoredInfoType" and "monitoredUnit" (for measurable infos) are missing. Shouldn't "monitorCounter" be named "monitoredCounter" to use the same pattern as "monitoredInfo"? I could not find the schema for the monitoring objects in any file. Can I retrieve a readable schema from openLDAP? The other thing is that I'm not too happy with are spaces in RDNs, like " cn=Connection 2111,cn=Connections,cn=Monitor", or "cn=Database 2,cn=Databases,cn=Monitor". I'd prefer are more common pattern for IDs like "Connection-2111" or "Connection_2111". Also: is "cn=Connection 0,cn=Connections,cn=Monitor" a bug? I see it twice: --- dn: cn=Connection 0,cn=Connections,cn=Monitor structuralObjectClass: monitorConnection (...) monitorConnectionNumber: 0 monitorConnectionProtocol: 0 monitorConnectionOpsReceived: 0 monitorConnectionOpsExecuting: 0 monitorConnectionOpsPending: 0 monitorConnectionOpsCompleted: 0 monitorConnectionGet: 0 monitorConnectionRead: 0 monitorConnectionWrite: 0 monitorConnectionMask: L monitorConnectionListener: monitorConnectionPeerDomain: unknown monitorConnectionPeerAddress: unknown monitorConnectionLocalAddress: monitorConnectionStartTime: 19700101000000Z monitorConnectionActivityTime: 19700101000000Z (...) --- Regards, Ulrich

4 10

Problem with self in acl in combination with rwm
by Arthur de Jong 27 Nov '13

27 Nov '13

I have a configuration somewhat similar to the one below and the ACLs seem to be applied using the non-rewritten DN which causes the self specifier to never match. We are in the process of configuring a more secure LDAP server with stricter ACLs and extra security checks without affecting existing applications. For this purpose we are putting a rewriting proxy in front of several legacy LDAP servers. Ideally, the ACLs would be put in place on the original servers but this is not easily possible in this environment. Is this a bug or am I doing something wrong? Configuration snippet (simplified and anonymised): access to attrs=userPassword by self =xw by anonymous auth by * none access to * by self read by * search database ldap suffix "ou=department1,dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" subordinate uri "ldap://192.168.1.1" overlay rwm rwm-suffixmassage "ou=department1,dc=example,dc=com" "dc=department1,dc=local" database ldap suffix "ou=department2,dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" subordinate uri "ldap://192.168.1.2" overlay rwm rwm-suffixmassage "ou=department2,dc=example,dc=com" "dc=department2,dc=local" database bdb suffix "dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" rootpw {SSHA}5OWnUtaKRBk7x0UBQKO/HOgMZQoCczY5 directory /var/openldap-data cachesize 1000 index objectClass eq index cn,mail pres,eq,sub index uid,uidNumber pres,eq Part of the slapd output with -d 896 (again, anonymised): 5295fbb1 conn=1000 fd=27 ACCEPT from IP=127.0.0.1:48903 (IP=0.0.0.0:3389) 5295fbb1 conn=1000 op=0 BIND dn="uid=ldaptest,ou=People,ou=department2,dc=example,dc=com" method=128 5295fbb1 conn=1000 op=0 BIND dn="uid=ldaptest,ou=People,dc=department2,dc=local" mech=SIMPLE ssf=0 5295fbb1 conn=1000 op=0 RESULT tag=97 err=0 text= 5295fbb1 conn=1000 op=1 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" 5295fbb1 => access_allowed: search access to "dc=example,dc=com" "entry" requested 5295fbb1 => dn: [1] 5295fbb1 => acl_get: [3] attr entry 5295fbb1 => acl_mask: access to entry "dc=example,dc=com", attr "entry" requested 5295fbb1 => acl_mask: to all values by "uid=ldaptest,ou=people,dc=department2,dc=local", (=0) 5295fbb1 <= check a_dn_pat: self 5295fbb1 <= check a_dn_pat: * 5295fbb1 <= acl_mask: [2] applying search(=scxd) (stop) 5295fbb1 <= acl_mask: [2] mask: search(=scxd) 5295fbb1 => slap_access_allowed: search access granted by search(=scxd) 5295fbb1 => access_allowed: search access granted by search(=scxd) [...] 5295fbb2 => access_allowed: read access to "uid=ldaptest,ou=People,ou=department2,dc=example,dc=com" "entry" requested 5295fbb2 => dn: [1] 5295fbb2 => acl_get: [3] attr entry 5295fbb2 => acl_mask: access to entry "uid=ldaptest,ou=People,ou=department2,dc=example,dc=com", attr "entry" requested 5295fbb2 => acl_mask: to all values by "uid=ldaptest,ou=people,dc=department2,dc=local", (=0) 5295fbb2 <= check a_dn_pat: self 5295fbb2 <= check a_dn_pat: * 5295fbb2 <= acl_mask: [2] applying search(=scxd) (stop) 5295fbb2 <= acl_mask: [2] mask: search(=scxd) 5295fbb2 => slap_access_allowed: read access denied by search(=scxd) 5295fbb2 => access_allowed: no more rules 5295fbb2 send_search_entry: conn 1000 access to entry (uid=ldaptest,ou=People,ou=department2,dc=example,dc=com) not allowed The DN that is used seems to be uid=ldaptest,ou=people, dc=department2,dc=local which is how we were bound to the second LDAP server. Thanks ps, I would also be very interested in a solution for http://www.openldap.org/lists/openldap-technical/201302/msg00152.html -- -- arthur - arthur(a)arthurdejong.org - http://arthurdejong.org/ --

1 0

syncrepl
by Tony Chilton 27 Nov '13

27 Nov '13

I have set up a slave ldap server for syncrepl and seem to be unable to get it to repicate. There is nothing logged on the slave at all. ACL logging on the master shows the slave connecting and seeming to get access - see below. On the MAIN SERVER I HAVE access to attrs=userPassword,shadowLastChange by self =xw by anonymous auth by dn="cn=sync,dc=my company,dc=com" read by * none access to * by self write by dn="cn=sync,dc=my company,dc=com" read by users read by * read # Replication stuff overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 200 ON THE SLAVE I HAVE access to * by self write by dn="cn=sync,dc=my company,dc=com" write by users read by anonymous auth loglevel sync config acl logfile /tmp/ldaptmp syncrepl rid=123 provider=ldaps://envy.my company.com type=refreshOnly interval=01:00:00:00 searchbase="dc=my company,dc=com" filter="(objectClass=*)" scope=sub attrs="*,+" schemachecking=off retry="60 10 300 3" logbase="cn=accesslog" syncdata=accesslog bindmethod=simple binddn="cn=sync,dc=my company,dc=com" credentials="password" AUTH OUTPUT FROM THE MASTER Nov 26 10:48:04 envy slapd[19774]: => acl_mask: to value by "", (=0) Nov 26 10:48:04 envy slapd[19774]: <= check a_dn_pat: self Nov 26 10:48:04 envy slapd[19774]: <= check a_dn_pat: cn=sync,dc=imagreendriver,dc=com Nov 26 10:48:04 envy slapd[19774]: <= check a_dn_pat: users Nov 26 10:48:04 envy slapd[19774]: <= check a_dn_pat: * Nov 26 10:48:04 envy slapd[19774]: <= acl_mask: [4] applying read(=rscxd) (stop) Nov 26 10:48:04 envy slapd[19774]: <= acl_mask: [4] mask: read(=rscxd) Nov 26 10:48:04 envy slapd[19774]: => slap_access_allowed: read access granted by read(=rscxd) AN LDAP SEARCH QUERY produces zip on slave ldapsearch -H ldaps:/// -x -b 'dc=my company,dc=com' '(objectclass=*)' -s sub # extended LDIF # # LDAPv3 # base <dc=my company,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 32 No such object # numResponses: 1

4 3

Re: OpenLDAP 2.4.38 available
by Clément OUDOT 27 Nov '13

27 Nov '13

2013/11/18 OpenLDAP Project <project(a)openldap.org>: > OpenLDAP 2.4.38 is now available for download as detailed on our download page: > > http://www.openldap.org/software/download/ > Hi, I am happy to inform you that LDAP Tool Box packages are now available for OpenLDAP 2.4.38 (see announce: http://tools.ltb-project.org/news/44) The great news is that we now provide Debian packages! We also now have a YUM repository and a APT repository. Special mention to David Coutadeur who works hard on the Debian packages. Clément.

1 0

Re : Antw: dynlist performance
by "POISSON Frédéric" 27 Nov '13

27 Nov '13

Hello, Le 27/11/13, Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> a écrit : > >>> "POISSON Frédéric"<frederic.poisson(a)admin.gmessaging.net> schrieb am > 27.11.2013 > um 10:46 in Nachricht <3fd84a3867972521.5295cd90(a)admin.gmessaging.net>: > > Hello, > > > > I'm testing the dynlist overlay on OpenLDAP 2.4.38 because i have a static > > group of around 10K uniqueMember. I want to have now a equivalent group with > > > dynlist. > > > > I have configured my overlay dynlist like this : > > dn: olcOverlay={2}dynlist,olcDatabase={1}bdb,cn=config > > objectClass: olcOverlayConfig > > objectClass: olcDynamicList > > olcOverlay: {2}dynlist > > olcDlAttrSet: {0}groupOfURLs memberURL uniqueMember > > > > And my group is quite like OpenLDAP example in documentation : > > > > dn: cn=GeneralisationDyn,ou=Groups,dc=example,dc=com > > objectClass: top > > objectClass: groupOfURLs > > cn: GeneralisationDyn > > memberURL: ldap:///ou=People,dc=example,dc=com??one?(objectClass=person) > > uniqueMember: uid=user1,ou=People,dc=example,dc=com > > uniqueMember: uid=user2,ou=People,dc=example,dc=com > > [...] > > > > My backend is Berkeley DB and i have tune it in order to have quite fast > > responses on searches, and locally on my server (virtualized with a single > > proc), it take that time to return the entries found by memberURL : > > > > real 0m0.272s > > user 0m0.040s > > sys 0m0.023s > > Actually, if you sum sys and user, you get 0.07s. Times 10000 gives 700s. So > the bulk transfer is quite efficient compared to the single transfer. > Also not that the direction of search is different: Once you start from > uniqueMember, and the other time you start from DN (I guess). > > Sorry i don't understand the way you explain that, it is not clear in my mind. Do the dyngroup plugin run the same ldapsearch as presented inside the memberURL ? If yes : why showing the uniqueMember from dyngroup overlay takes more time than running the equivalent ldapsearch ? If not : How the dyngroup overlay works ? Sorry if my questions are boring... > > > > > > If i run an ldapsearch to see all uniqueMember of my dynamic group it take > > around 8 to 10 seconds to have the output ! > > > > Why a so big difference of response time in a search of entries and a search > > > of uniqueMember inside a dynamic group ? > > Is there some tuning for dynlist plugin ? > > > > Notice also that when i search uniqueMember inside my static group with > > quite same number of uniqueMember) i have less than 0.1 seconds of real > time. > > > > > > Thanks, > > Regards, > > -- > > > > Frederic Poisson > > > Regards, -- Frederic Poisson

1 0

Re : Re: dynlist performance
by "POISSON Frédéric" 27 Nov '13

27 Nov '13

Hello, Thanks Clement for your response and blog for valsort usage (http://coudot.blogs.linagora.com/index.php/post/2013/01/07/Astuce-OpenLDAP-…!). Dieter i didn't mention my search filter because i take the same base/scope/filter that i configure inside memberURL, and also my idea wasn't to compare my server configuration with others and yours, but just to understand why it take more time to search uniqueMember whitout valsort overlay than searching the entries locally. Now, yes using valsort overlay decrease the time of ldapsearch display for my 10K entries : real 0m0.436s user 0m0.010s sys 0m0.009s Where is it mention inside OpenLDAP documentation/faq that performance are better with valsort and what is the threshold for using it (eg how many uniqueMember? ) ? Thanks, Le 27/11/13, Dieter Klünter <dieter(a)dkluenter.de> a écrit : > Am Wed, 27 Nov 2013 10:46:40 +0100 > schrieb "POISSON Frédéric" <frederic.poisson(a)admin.gmessaging.net>: > > > Hello, > > > > I'm testing the dynlist overlay on OpenLDAP 2.4.38 because i have a > > static group of around 10K uniqueMember. I want to have now a > > equivalent group with dynlist. > > > > I have configured my overlay dynlist like this : > > dn: olcOverlay={2}dynlist,olcDatabase={1}bdb,cn=config > > objectClass: olcOverlayConfig > > objectClass: olcDynamicList > > olcOverlay: {2}dynlist > > olcDlAttrSet: {0}groupOfURLs memberURL uniqueMember > > > > And my group is quite like OpenLDAP example in documentation : > > > > dn: cn=GeneralisationDyn,ou=Groups,dc=example,dc=com > > objectClass: top > > objectClass: groupOfURLs > > cn: GeneralisationDyn > > memberURL: > > ldap:///ou=People,dc=example,dc=com??one?(objectClass=person) > > uniqueMember: uid=user1,ou=People,dc=example,dc=com uniqueMember: > > uid=user2,ou=People,dc=example,dc=com [...] > > > > My backend is Berkeley DB and i have tune it in order to have quite > > fast responses on searches, and locally on my server (virtualized > > with a single proc), it take that time to return the entries found by > > memberURL : > > > > real 0m0.272s > > user 0m0.040s > > sys 0m0.023s > > > > If i run an ldapsearch to see all uniqueMember of my dynamic group it > > take around 8 to 10 seconds to have the output ! > > > > Why a so big difference of response time in a search of entries and a > > search of uniqueMember inside a dynamic group ? Is there some tuning > > for dynlist plugin ? > > > > Notice also that when i search uniqueMember inside my static group > > with quite same number of uniqueMember) i have less than 0.1 seconds > > of real time. > > You didn't mention the search string and filter, but here my results of > 5,000 entries > > time ldapsearch -Y DIGEST-MD5 -U replicator -wxxxx -l0 -z0 -H > ldap://localhost -b cn=dynamicGroup,o=avci,c=de -s base "*" > [5000 lines] > > # search result > search: 3 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > real 0m0.606s > user 0m0.014s > sys 0m0.027s > > -Dieter > > -- > Dieter Klünter | Systemberatung > http://dkluenter.de > GPG Key ID:DA147B05 > 53°37'09,95"N > 10°08'02,42"E > > > -- Frederic Poisson

2 1

dynlist performance
by "POISSON Frédéric" 27 Nov '13

27 Nov '13

Hello, I'm testing the dynlist overlay on OpenLDAP 2.4.38 because i have a static group of around 10K uniqueMember. I want to have now a equivalent group with dynlist. I have configured my overlay dynlist like this : dn: olcOverlay={2}dynlist,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: {2}dynlist olcDlAttrSet: {0}groupOfURLs memberURL uniqueMember And my group is quite like OpenLDAP example in documentation : dn: cn=GeneralisationDyn,ou=Groups,dc=example,dc=com objectClass: top objectClass: groupOfURLs cn: GeneralisationDyn memberURL: ldap:///ou=People,dc=example,dc=com??one?(objectClass=person) uniqueMember: uid=user1,ou=People,dc=example,dc=com uniqueMember: uid=user2,ou=People,dc=example,dc=com [...] My backend is Berkeley DB and i have tune it in order to have quite fast responses on searches, and locally on my server (virtualized with a single proc), it take that time to return the entries found by memberURL : real 0m0.272s user 0m0.040s sys 0m0.023s If i run an ldapsearch to see all uniqueMember of my dynamic group it take around 8 to 10 seconds to have the output ! Why a so big difference of response time in a search of entries and a search of uniqueMember inside a dynamic group ? Is there some tuning for dynlist plugin ? Notice also that when i search uniqueMember inside my static group with quite same number of uniqueMember) i have less than 0.1 seconds of real time. Thanks, Regards, -- Frederic Poisson

4 3

ldap_search_ext_s timeout
by Mahadev, Vasavi (CW) 27 Nov '13

27 Nov '13

Hi All, The LDAP directory services in our product uses ldap_search_ext_s for synchronous search. Now,my intension is to specify a timeout in this API,so that in case if the server does not respond within the timelimit,the operation should be terminated. I tried specifying time out for the asyncronous search usign the API ldap_search_ext and it did not work.Adding timeout to ldap_result did timed out the operation! So, I was wondering how I can make the synchronous search to timeout . Requesting your help on this. Regards, Vasavi

1 0

Different approaches to setup ldap client
by slacker lnx 26 Nov '13

26 Nov '13

Hello, I have a few ldap clients which were set up by my previous sys-admin. 1. In some of the servers I see that the configuration is done in /etc/pam_ldap.conf, /etc/nslcd.conf and there is a nslcd process running on the clients. 2. On other servers I find that there is only an /etc/ldap.conf and there are no nslcd process running. The configuration values in both the approaches are the same. Are there two different ways to setup an ldap client. I would like to understand both these approaches. In the second approach is there some other process which does the ldap lookup? Can someone share links to docs related to both the installation steps. Thanks

3 2

Recommended ACL for nagios monitoring
by ML mail 26 Nov '13

26 Nov '13

Hello, I would like to monitor connectivity to my OpenLDAP using nagios with its check_ldap script and was wondering which minimal ACL would you recommend for that purpose? For that purpose I will be using a dedicated user such as cn=nagios,ou=users,dc=domain,dc=tld and would like it just to be able to bind to dc=domain,dc=tld and nothing else. Any recommendations? Thanks ML

6 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical November 2013