openldap-technical

openldap-technical@openldap.org

9 participants
9876 discussions

Asynchronicity
by William Ahern 11 Nov '10

11 Nov '10

Excepting DNS, is the latest release of OpenLDAP fully asynchronous-capable, even with TLS? Perusing the source code I can't find any obvious places other than DNS where things might block, but it's harder to prove the negative. I remember many years ago this wasn't the case, and I had to thread the connect phase, but the ChangeLog suggests that things have changed considerably.

3 5

number of contextcsn entries per database
by PJunod＠mediageneral.com 11 Nov '10

11 Nov '10

I have setup two ldap servers for authentication and access control in a multi-master configuration. I am concerned about the number of contextcsn entries that are supposed to be present in each database. Right now there are two servers participating in the multi-master configuration. From my understanding, there should be one contextCSN entry per database per host. My cn=config database has two contextCSN entries as I would expect. One for each syncrepl rid configured. My bdb database only has one contextCSN entry though, with an rid of just "000". (my rid's are 001, 002, 101, and 102) Replication seems to work fine on both databases. I can write to either one and the changes are replicated over immediately. I am just curious about this discrepancy in the number of contextCSN entries. Could someone confirm the number of contextCSN entries per database and if it should match the number of hosts participating in the multi-master replication? Here are some relevant settings for the replication: dn: cn=config olcServerID: 1 ldap://<server1> olcServerID: 2 ldap://<server2> ####################### # module{0}, config dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap2.4 olcModuleLoad: {0}syncprov.la ####################### # {0}config, config dn: olcDatabase={0}config,cn=config olcSyncrepl: {0}rid=001 provider=ldap://<server1> binddn="cn=Ma nager,cn=config" bindmethod=simple credentials=<password> searchbase="cn=config " type=refreshAndPersist retry="5 500 5 +" timeout=1 starttls=yes olcSyncrepl: {1}rid=002 provider=ldap://<server2> binddn="cn=Ma nager,cn=config" bindmethod=simple credentials=<password> searchbase="cn=config " type=refreshAndPersist retry="5 500 5 +" timeout=1 starttls=yes olcMirrorMode: TRUE ####################### # {0}syncprov, {0}config, config dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov ####################### # {1}bdb, config dn: olcDatabase={1}bdb,cn=config olcSyncrepl: {0}rid=101 provider=ldap://<server1> binddn="cn=Ma nager,dc=mgcorp,dc=net" bindmethod=simple credentials=<password> searchbase="dc =mgcorp,dc=net" type=refreshAndPersist interval=00:00:00:10 retry="5 500 5 +" timeout=1 starttls=yes olcSyncrepl: {1}rid=102 provider=ldap://<server2> binddn="cn=Ma nager,dc=mgcorp,dc=net" bindmethod=simple credentials=<password> searchbase="dc =mgcorp,dc=net" type=refreshAndPersist interval=00:00:00:10 retry="5 500 5 +" timeout=1 starttls=yes olcMirrorMode: TRUE ############################## Here are the results of searches for contextCSN in cn=config and dc=mgcorp,dc=net: ldapsearch -x -W -s base -D "cn=Manager,cn=config" -h "<server2>" -b "cn=config" contextCSN contextCSN: 20101110214932.998233Z#000000#000#000000 contextCSN: 20101028121213.444193Z#000000#001#000000 ldapsearch -x -W -s base -D "cn=Manager,dc=mgcorp,dc=net" -h "<server2>" -b "dc=mgcorp,dc=net" contextCSN contextCSN: 20101110213409.736943Z#000000#000#000000

2 1

Attributes for filtering OS logins
by Anton Chu 11 Nov '10

11 Nov '10

I have a scenario where I want to setup two LDAP groups where one group can access a file on the server while the other one cannot after they login. Can some PAM tweaks make this happen if not on the ldap side?

3 3

Re: ldapsearch performance degradation
by Tim Dyce 11 Nov '10

11 Nov '10

Hi Dieter, Thanks for the tips on tuning, sadly the problem is still haunting us :( Andrey Kiryanov at CERN has been doing a lot of work on this performance degradation problem as well. He has tried BDB 4.8.30 and OpenLDAP 2.4.23 but the problem is still apparent. The basic test we are running (sent earlier) creates 100 ou entries in the root, each with 250 child ou entries, then deletes 20-35% of these and re-adds them. For each deletion cycle the ldapsearch performance degrades, taking longer to complete the search each time. The performance is consistent, across restarts of slapd, and tied to the current state of the database. I have tried rsyncing out the database, and returning it later, and the performance is consistent with the number of deletion cycles the database has undergone. The only clue I have is that when dumping the databases which db_dump it's clear that the ordering of the database becomes increasingly less aligned with the order of the output data when doing a full tree search as we are. Which suggests that the database is writing frequently accessed entires too often instead of holding them in cache? I have run cachegrind against the server at 2, 20 and 1000 deletion iterations and the results are very different - http://www.ph.unimelb.edu.au/~tjdyce/callgrind.tar.gz The number of fetches grows massively over time. Anything you guys can suggest would be much appreciated, it's started to affect quite a number of our grid sites. Cheers, Tim > On 04/11/10 02:56, Dieter Kluenter wrote: >>> Hi Dieter, >>> >>> I've done some more testing with openldap 2.3 and 2.4, on Redhat and >>> Ubuntu. >>> I even went as far as placing the BDB database directory in a ramdisk. >>> But the performance still seems to degrade over time as data is added >>> then deleted repeatedly from the ldap server. >>> >>> It looks like the BDB database starts to fragment or lose structure >>> over time? >>> I've tried a few DB options that seem to have some impact. >>> >>> Any ideas on what I can do from here? >> Quite frankly, I have no clue, all i can do is guessing. First let's >> define the problem: you have measured the presentation of search >> Results the client side, and you observered an increase of time >> required to present the results. >> Mostlikely it is either a caching problem, a disk problem or a network >> problem. >> As far as openldap related, there are four caches to watch: >> 1. the bdb/hdb database (DB_CONFIG, cachesize) >> 2. the DN cache (dncachesize) >> 2. the cache of searched and indexed attribute types (idlcachesize) >> 3. the frontside cache of search results (cachesize) >> >> please check slapd.conf whether appropriate sizes are configured, see >> man slapd-bdb(5) and slapd.conf(5) for more information. >> >> But I must admit, a misconfiguration of any of this caches would not >> lead to such a degrading in presenting search results. >> >> An other approach would be to check the caching behaviour of clients, >> to check the network cache and the disk cache. >> >> -Dieter >> > -- ---------- Tim Dyce Research Computing EPP Group The School of Physics The University of Melbourne +61 3 8344 5462 +61 431 485 166

2 7

LDAPCon 2011?
by xsun 10 Nov '10

10 Nov '10

Hi there, There is something planned to 2011 about an LDAP Conference? I couldn't attend at 2009 and I think is too late for the conference on this year. Thanks, Matheus Morais

2 2

pamL-dap configuration guide
by Tim Dunphy 10 Nov '10

10 Nov '10

Hey List, I was just wondering if anyone happened to know of a good guide to use for configuring centos clients to authenticate pam modules (such as su, sudoers, ssh, system authentication and the like) against openLDAP? I am running a FreeBSD openLDAP server, but I believe that shouldn't affect the clients ability to log in via pam/ldap. At the moment I am googling this to not much avail! Thanks! -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!

3 3

tls
by Christian Bösch 10 Nov '10

10 Nov '10

Hi Can someone tell me if it's possible to require strong encryption like TLS except from one IP address? /chris

3 5

uniqueMember attribute is not suffixmassaged if attribute is not mapped and changed
by Arvo Jari-Pekka 09 Nov '10

09 Nov '10

Hi. My configuration is like this: --------- database meta suffix "ou=a,dc=c,dc=b" uri "ldap://host:port/ou=a,dc=c,dc=b" suffixmassage "ou=a,dc=c,dc=b" "dc=a,dc=b" ... --------- This works fine in everything else but the uniqueMembers of groupOfUniqueNames gets not rewritten (they are still in dc=a,dc=b domain). If I however add a mapping --------- map objectClass groupOfNames groupOfUniqueNames map attribute member uniqueMember --------- then the "member" attributes are correctly rewritten. The problem of course is that I do not want to change the objectclass. Mapping the attribute to itself does not help either. So --------- map objectClass groupOfUniqueNames * map attribute uniqueMember * --------- does not have any effect. I must have missed something crucial on the documentation. Can someone please tell me what it is and how can I get uniqueMembers rewritten without changing the objectclass. OpenLDAP version is 2.4.11 for both the real and the meta server. BR, Jari-Pekka Arvo

3 2

Is ldap_bind() mandatory before each ldap_search() call?
by Shankar Anand R 09 Nov '10

09 Nov '10

Hi all, I see that most LDAP utilities (openldap included) do a ldap_bind() before every ldap_search(). Is this mandatory? If LDAP descriptor (ld) is valid and can be used for multiple ldap_search() calls, when does it become invalid? Is it time based, say ld becomes invalid after 10 minutes? I have an application which needs to search the LDAP server for some specific attributes of users. The user name is taken as input from the command line. Is it necessary to do a ldap_bind() before each ldap_search() call? Doesn't this make it costly? Can I do ldap_bind() once and call ldap_search() many times? When does my "bind" become invalid? Can my application do this: #1 - bind to a LDAP server during initialization #2- then do an ldap_search() whenever required #3- then invalidate the ld after 10 minutes #4- do a ldap_bind() again and repeat from #2? Can someone kindly clarify? Thanks, Shankar

3 7

pam services under LDAP
by bluethundr 09 Nov '10

09 Nov '10

Hello List I am attempting to setup various pam modules to consult our new LDAP services in order to do what it needs to do. My LDAP server is FreeBSD but the clients are CentOS... I have setup my /etc/pam.d sudo file on the client (for example) this way in the attempt to accomplish this via LDAP: [root@VIRCENT03:~]#cat /etc/pam.d/sudo #%PAM-1.0 auth include system-auth auth required pam_ldap.so account include system-auth account required pam_ldap.so password include system-auth password required pam_ldap.so session optional pam_keyinit.so revoke session required pam_limits.so session required pam_ldap.so but even tho the user is part of the %wheel group under LDAP it is unable to sudo to any other account (including root). If I try to sudo this is what happens: [bluethundr@VIRCENT03:~]#sudo bash [sudo] password for bluethundr: bluethundr is not in the sudoers file. This incident will be reported. It would appear that sudo support for ldap is compiled in: [root@VIRCENT03:~]#ldd $(which sudo)| grep -i ldap libldap-2.3.so.0 => /usr/lib/libldap-2.3.so.0 (0x00552000) This is how I setup my ldap.conf file [root@VIRCENT03:~]#cat /etc/openldap/ldap.conf # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example, dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never URI ldap://ldap.acadaca.net/ BASE dc=acadaca,dc=net TLS_CACERTDIR /etc/openldap/cacerts sudoers_base ou=sudoers,ou=Services,dc=acadaca,dc=net In my openldap logs on the LDAP server there appears to be no activity when I sudo. however in the secure logs on the client I do.. Nov 8 16:05:34 VIRCENT03 su: pam_unix(su-l:session): session opened for user root by bluethundr(uid=500) Nov 8 16:05:37 VIRCENT03 su: pam_unix(su-l:session): session opened for user bluethundr by bluethundr(uid=0) Nov 8 16:05:44 VIRCENT03 sudo: bluethundr : user NOT in sudoers ; TTY=pts/5 ; PWD=/home/bluethundr ; USER=root ; COMMAND=/bin/bash Conversely when I sudo via LDAP on my FreeBSD ldap server this is what I see... Nov 8 19:44:25 LBSD2 sudo: bluethundr : TTY=pts/11 ; PWD=/usr/home/bluethundr ; USER=root ; COMMAND=/bin/bash Nov 8 19:44:51 LBSD2 sudo: bluethundr : TTY=pts/10 ; PWD=/usr/home/bluethundr ; USER=root ; COMMAND=/bin/bash Works there! I do see other events in secure.log that appear to be pam successes however. am i interpreting this correctly that at least part of the system is communicating with pam on the ldap server? thanks -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!

6 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical