openldap-technical

openldap-technical@openldap.org

1 participants
9989 discussions

Ghost/invisible subtree
by David Mohr 06 Feb '11

06 Feb '11

Hi, I'm having a strange issue. I'm running openldap 2.4.23 (on debian), and after playing around with some software using my ldap server I now have a ghost subtree. 'Ghost' meaning that I cannot see this subtree, but if I try to add an entry that used to exist, I get an 'Already exists (68)' error. With slapcat I can see all the invisible entries. I tried to run slapindex, but that did not help. Then I created a dump using slapcat, deleted the database, and used slapadd to fill it with data again. Yet my subtree is still invisible. Does anyone have suggestions on how to solve this issue? I can't seem to find any information beyond slapcat & slapadd. I don't see any obvious issues in the ldif dump either. Any help? Thanks, ~David

1 1

AccessLog behaviour
by Marco Pizzoli 05 Feb '11

05 Feb '11

Hi all, I would like to know the internal behaviour of slapo-accesslog. I would like to have accesslog with a data retention of 10 days. In my ldap usage scenario this retention produce an accesslog db of quite 10GB of data. Things are working quite fine, but when the log db contains data older than the retention I defined after restart slapd has a thread allocated at 100% of cpu of one processor. I logged at loglevel 992 = 512 + 256 + 128 + 64 + 32, blocked with iptables every external ldap access and saw these lines in the log: [cut] Feb 3 09:37:08 ldap03 slapd[16289]: => access_allowed: search access to "reqStart=20110202042854.000008Z,cn=log03,dc=mycorp.it" "reqStart" requested Feb 3 09:37:08 ldap03 slapd[16289]: <= root access granted Feb 3 09:37:08 ldap03 slapd[16289]: => access_allowed: search access granted by manage(=mwrscxd) Feb 3 09:37:08 ldap03 slapd[16289]: <= test_filter 6 Feb 3 09:37:08 ldap03 slapd[16289]: => test_filter Feb 3 09:37:08 ldap03 slapd[16289]: LE Feb 3 09:37:08 ldap03 slapd[16289]: => access_allowed: search access to "reqStart=20110202042854.000010Z,cn=log03,dc=mycorp.it" "reqStart" requested Feb 3 09:37:08 ldap03 slapd[16289]: <= root access granted Feb 3 09:37:08 ldap03 slapd[16289]: => access_allowed: search access granted by manage(=mwrscxd) Feb 3 09:37:08 ldap03 slapd[16289]: <= test_filter 6 Feb 3 09:37:08 ldap03 slapd[16289]: => test_filter Feb 3 09:37:08 ldap03 slapd[16289]: LE Feb 3 09:37:08 ldap03 slapd[16289]: => access_allowed: search access to "reqStart=20110202042854.000012Z,cn=log03,dc=mycorp.it" "reqStart" requested Feb 3 09:37:08 ldap03 slapd[16289]: <= root access granted Feb 3 09:37:08 ldap03 slapd[16289]: => access_allowed: search access granted by manage(=mwrscxd) Feb 3 09:37:08 ldap03 slapd[16289]: <= test_filter 6 Feb 3 09:37:08 ldap03 slapd[16289]: => test_filter Feb 3 09:37:08 ldap03 slapd[16289]: LE Feb 3 09:37:08 ldap03 slapd[16289]: => access_allowed: search access to "reqStart=20110202042854.000014Z,cn=log03,dc=mycorp.it" "reqStart" requested Feb 3 09:37:08 ldap03 slapd[16289]: <= root access granted Feb 3 09:37:08 ldap03 slapd[16289]: => access_allowed: search access granted by manage(=mwrscxd) Feb 3 09:37:08 ldap03 slapd[16289]: <= test_filter 6 Feb 3 09:37:08 ldap03 slapd[16289]: => test_filter Feb 3 09:37:08 ldap03 slapd[16289]: LE Feb 3 09:37:08 ldap03 slapd[16289]: => access_allowed: search access to "reqStart=20110202042855.000000Z,cn=log03,dc=mycorp.it" "reqStart" requested Feb 3 09:37:08 ldap03 slapd[16289]: <= root access granted Feb 3 09:37:08 ldap03 slapd[16289]: => access_allowed: search access granted by manage(=mwrscxd) Feb 3 09:37:08 ldap03 slapd[16289]: <= test_filter 6 Feb 3 09:37:09 ldap03 slapd[16289]: => test_filter Feb 3 09:37:09 ldap03 slapd[16289]: LE Feb 3 09:37:09 ldap03 slapd[16289]: => access_allowed: search access to "reqStart=20110202042855.000002Z,cn=log03,dc=mycorp.it" "reqStart" requested Feb 3 09:37:09 ldap03 slapd[16289]: <= root access granted Feb 3 09:37:09 ldap03 slapd[16289]: => access_allowed: search access granted by manage(=mwrscxd) Feb 3 09:37:09 ldap03 slapd[16289]: <= test_filter 6 Feb 3 09:37:09 ldap03 slapd[16289]: => test_filter Feb 3 09:37:09 ldap03 slapd[16289]: LE Feb 3 09:37:09 ldap03 slapd[16289]: => access_allowed: search access to "reqStart=20110202042855.000004Z,cn=log03,dc=mycorp.it" "reqStart" requested [cut] I could assume that slapo-accesslog is querying all entries older than the retention and passes to delete them. What if this step to end the job will take more time than the interval time of re-starting? Augmenting the frequency of this job could help in this meaning? Every best practice to follow to use accesllog effectively will be very appreciated! :-) Thanks Marco Pizzoli -- _________________________________________ Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison

2 3

How to I verify SSL is working correctly
by Rob Tanner 04 Feb '11

04 Feb '11

Hi, I’m adding SSL to an existing openLDAP server. My certificate is a 2048 bit from Comodo and I need to install both the certificate and and the intermediate chain, 5 certificates altogether. I bundled the chain into a single file in the order Comodo lists and in slapd.conf I added: TLSCACertificateFile /path/to/providerBundle.crt TLSCertificateFile /path/to/mycert.pem TLSCertificateKeyFile /path/to/mykey.pem Then I restarted openLDAP. I have several different browsers to test the SSL connection, and mostly they all worked just fine. However, lbe, a java based browser that I think was originally from Novel, asks me if I want to trust the CA root certificate, which is the first cert in the CA bundle. So, needless to say, I’m confused. Can anyone help unconfuse me? Thanks. Rob Tanner UNIX Services Manager Linfield College, McMinnville Oregon

2 1

TLS Directives in slapd.conf
by ldap＠mm.st 04 Feb '11

04 Feb '11

I have authentication working using TLS on my RH5 servers with openldap 2.3, but was looking for some clarification on the TLS directives in slapd.conf. Most of what I have seen and read states to generate the key and cert (can be done a number of ways) and update the following directives: # TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt # TLSCertificateFile /etc/pki/tls/certs/slapd.pem # TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem Which I have done using the "make ldap.pem" in the pki directory on the Redhat server. Both the key and the cert are in a singe file. The directives now read: TLSCACertificateFile /etc/pki/tls/certs/ldap.pem TLSCertificateFile /etc/pki/tls/certs/ldap.pem TLSCertificateKeyFile /etc/pki/tls/certs/ldap.pem I place the cert section in the client ldap.conf and all seems to work fine. My question is, what is the function of TLSCACertificateFile directive. I can comment out the directive and authentication still works fine and appears to not have a effect on operation. Both TLSCertificateFile and TLSCertificateKeyFile seem to be required if any one of the directives are used. The man page explanation says it "contains certificates for all of the Certificate Authorities that slapd will recognize." I'm not sure how TLSCACertificateFile should be used, if at all. Just trying to understand how the directive should be implemented.

1 0

LDAP writes/second limit?
by Diego Lima 04 Feb '11

04 Feb '11

Hello all, I'm running some load tests on an LDAP server using JMeter and as part of the tests I'm running a continuous loop of users trying to change their passwords. The problem is, there is a point where OpenLDAP stops responding requests and is unable to complete its current operations. This is what each "user" do: Bind -> Modify userPassword -> Unbind When I spawn a few users on a short time and try to do the modify operation the server stops responding. I was able to do that by spawning 5 threads simultaneously and trying to have them change the user password at once. It seems that something is not handling the write operations well and is hanging. Slapd doesnt stop responding completely, as I'm able to send a kill signal to it and it'll tell that it is waiting for some tasks to end. The complete log follows: Feb 4 13:47:44 Server01 slapd[8772]: @(#) $OpenLDAP: slapd 2.4.23 (Jan 28 2011 17:07:07) $#012#011root@Server01:/home/suporte/openldap-2.4.23/servers/slapd Feb 4 13:47:44 Server01 slapd[8772]: /ldap/etc/slapd.conf: line 108: rootdn is always granted unlimited privileges. Feb 4 13:47:44 Server01 slapd[8773]: bdb_db_open: database "dc=diretorio,dc=mycompany": unclean shutdown detected; attempting recovery. Feb 4 13:47:45 Server01 slapd[8773]: slapd starting Feb 4 13:47:51 Server01 slapd[8773]: conn=1000 fd=12 ACCEPT from IP=192.168.1.2:6098 (IP=0.0.0.0:389) Feb 4 13:47:51 Server01 slapd[8773]: conn=1002 fd=15 ACCEPT from IP=192.168.1.2:6101 (IP=0.0.0.0:389) Feb 4 13:47:51 Server01 slapd[8773]: conn=1003 fd=13 ACCEPT from IP=192.168.1.2:6102 (IP=0.0.0.0:389) Feb 4 13:47:51 Server01 slapd[8773]: conn=1001 fd=14 ACCEPT from IP=192.168.1.2:6099 (IP=0.0.0.0:389) Feb 4 13:47:51 Server01 slapd[8773]: conn=1004 fd=16 ACCEPT from IP=192.168.1.2:6103 (IP=0.0.0.0:389) Feb 4 13:47:51 Server01 slapd[8773]: conn=1001 op=0 BIND dn="cn=tcarga_usuario4,ou=usuarios,dc=diretorio,dc=mycompany" method=128 Feb 4 13:47:51 Server01 slapd[8773]: conn=1002 op=0 BIND dn="cn=tcarga_usuario1,ou=usuarios,dc=diretorio,dc=mycompany" method=128 Feb 4 13:47:51 Server01 slapd[8773]: conn=1003 op=0 BIND dn="cn=tcarga_usuario3,ou=usuarios,dc=diretorio,dc=mycompany" method=128 Feb 4 13:47:51 Server01 slapd[8773]: conn=1004 op=0 BIND dn="cn=tcarga_usuario5,ou=usuarios,dc=diretorio,dc=mycompany" method=128 Feb 4 13:47:51 Server01 slapd[8773]: conn=1002 op=0 BIND dn="cn=tcarga_usuario1,ou=usuarios,dc=diretorio,dc=mycompany" mech=SIMPLE ssf=0 Feb 4 13:47:51 Server01 slapd[8773]: conn=1000 op=0 BIND dn="cn=tcarga_usuario2,ou=usuarios,dc=diretorio,dc=mycompany" method=128 Feb 4 13:47:51 Server01 slapd[8773]: conn=1002 op=0 RESULT tag=97 err=0 text= Feb 4 13:47:51 Server01 slapd[8773]: conn=1000 op=0 BIND dn="cn=tcarga_usuario2,ou=usuarios,dc=diretorio,dc=mycompany" mech=SIMPLE ssf=0 Feb 4 13:47:51 Server01 slapd[8773]: conn=1003 op=0 BIND dn="cn=tcarga_usuario3,ou=usuarios,dc=diretorio,dc=mycompany" mech=SIMPLE ssf=0 Feb 4 13:47:51 Server01 slapd[8773]: conn=1001 op=0 BIND dn="cn=tcarga_usuario4,ou=usuarios,dc=diretorio,dc=mycompany" mech=SIMPLE ssf=0 Feb 4 13:47:51 Server01 slapd[8773]: conn=1000 op=0 RESULT tag=97 err=0 text= Feb 4 13:47:51 Server01 slapd[8773]: conn=1003 op=0 RESULT tag=97 err=0 text= Feb 4 13:47:51 Server01 slapd[8773]: conn=1004 op=0 BIND dn="cn=tcarga_usuario5,ou=usuarios,dc=diretorio,dc=mycompany" mech=SIMPLE ssf=0 Feb 4 13:47:51 Server01 slapd[8773]: conn=1001 op=0 RESULT tag=97 err=0 text= Feb 4 13:47:51 Server01 slapd[8773]: conn=1004 op=0 RESULT tag=97 err=0 text= Feb 4 13:47:51 Server01 slapd[8773]: conn=1004 op=1 MOD dn="cn=tcarga_usuario5,ou=usuarios,dc=diretorio,dc=mycompany" Feb 4 13:47:51 Server01 slapd[8773]: conn=1000 op=1 MOD dn="cn=tcarga_usuario2,ou=usuarios,dc=diretorio,dc=mycompany" Feb 4 13:47:51 Server01 slapd[8773]: conn=1001 op=1 MOD dn="cn=tcarga_usuario4,ou=usuarios,dc=diretorio,dc=mycompany" Feb 4 13:47:51 Server01 slapd[8773]: conn=1004 op=1 MOD attr=userPassword Feb 4 13:47:51 Server01 slapd[8773]: conn=1003 op=1 MOD dn="cn=tcarga_usuario3,ou=usuarios,dc=diretorio,dc=mycompany" Feb 4 13:47:51 Server01 slapd[8773]: conn=1003 op=1 MOD attr=userPassword Feb 4 13:47:51 Server01 slapd[8773]: conn=1000 op=1 MOD attr=userPassword Feb 4 13:47:51 Server01 slapd[8773]: slap_queue_csn: queing 0x40d36450 20110204154751.766634Z#000001#000#000000 Feb 4 13:47:51 Server01 slapd[8773]: slap_queue_csn: queing 0x426a5450 20110204154751.766634Z#000000#000#000000 Feb 4 13:47:51 Server01 slapd[8773]: slap_queue_csn: queing 0x436a7450 20110204154751.766652Z#000000#000#000000 Feb 4 13:47:51 Server01 slapd[8773]: conn=1002 op=1 MOD dn="cn=tcarga_usuario1,ou=usuarios,dc=diretorio,dc=mycompany" Feb 4 13:47:51 Server01 slapd[8773]: conn=1001 op=1 MOD attr=userPassword Feb 4 13:47:51 Server01 slapd[8773]: conn=1002 op=1 MOD attr=userPassword Feb 4 13:47:51 Server01 slapd[8773]: slap_queue_csn: queing 0x42ea6450 20110204154751.766981Z#000000#000#000000 Feb 4 13:47:51 Server01 slapd[8773]: slap_queue_csn: queing 0x41ea4450 20110204154751.767126Z#000000#000#000000 Feb 4 13:47:51 Server01 slapd[8773]: conn=1004 op=1 RESULT tag=103 err=0 text= Feb 4 13:47:51 Server01 slapd[8773]: slap_graduate_commit_csn: removing 0x7f9bc4203f10 20110204154751.766634Z#000000#000#000000 Feb 4 13:47:51 Server01 slapd[8773]: conn=1004 op=2 UNBIND Feb 4 13:47:51 Server01 slapd[8773]: conn=1004 fd=16 closed [ Here I sent sigterm to slapd ] Feb 4 13:52:14 Server01 slapd[8773]: daemon: shutdown requested and initiated. Feb 4 13:52:14 Server01 slapd[8773]: slapd shutdown: waiting for 4 operations/tasks to finish The server does not respond anymore and I have to kill the process by using kill -9. Anyone ever experienced the same or can provide hints as to what is happening? I'm using slapd 2.4.23 and berkeley db 4.6 on a Debian Lenny system. -- Diego Lima http://www.diegolima.org

2 2

'Inheriting' an attribute from a group.
by ian+openldap＠comtek.co.uk 04 Feb '11

04 Feb '11

Is there a recommended, 'production' way to inherit certain attributes from a group? Perhaps some kind of overlay? For example, if a user is in the 'users' group and the users group has the attribute userQuota=100 then the user will appear to have userQuota=100. If, on the other hand, userQuota=200 is set on the user then that would override the current value. Thanks for any suggestions. Ian

3 2

System user login fails if ldap goes down.
by Meghanand Acharekar 04 Feb '11

04 Feb '11

Hi, I have configured a mixed authentication systems (LDAP + System Users). On this system some users are configure to login via ldap rest as system users. I observed that if the ldap server goes down, system users also not able to login. Is there any way to prevent this, following my pam configuration. system-auth : auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 debug minclass=4 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=0 minlen=8 password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so nsswitch.conf --------------------- passwd: files ldap shadow: files ldap group: files ldap I get following errors in syslog, even after proving correct password. sshd[23564]: nss_ldap: failed to bind to LDAP server ldap://10.0.119.36/: Can't contact LDAP server sshd[23564]: nss_ldap: reconnecting to LDAP server (sleeping 32 seconds)... sshd[23568]: pam_ldap: ldap_simple_bind Can't contact LDAP server sshd[23568]: Failed password for testuser from 1.2.3.4 port 33324 ssh2 sshd[23571]: fatal: Access denied for user testuser by PAM account configuration Regards, Meghanand N. Acharekar

2 4

Which backend should I use?
by Olivier PAVILLA 04 Feb '11

04 Feb '11

Hi. I need your advice again :) I have LDAP server with ldbm database on a fedora core 5 which is running for more than 3 years without any update nor upgrade neither. So now I've to migate this old LDAP on a new server with new Linux distribution (Debian Lenny). I'm tune up both /etc/ldap/slapd.conf and /var/lib/ldap/DB_CONFIG. But right now I read on a website (http://linagora.org/contrib/annuaires/documentations/openldap_guide_install…) that backend bdb will disappear. Should I use backend hdb or it doesn't make something different? -- Olivier Pavilla << 仕事を探しています。求職中です。>> S.C.I.R.C. Orléans (Bourgogne) - I.U.F.M. Centre-Val de Loire 72 Rue du Faubourg Bourgogne -45044 ORLEANS Cedex 1 Tel : 02-38-49-26-20 , mailto:olivier.pavilla@univ-ørleans.fr http://blog.linux-squad.com - 僕の傑作です。

4 5

Re: Transparent proxy, (objectClass=user) not being relayed. Schema issue?
by masarati＠aero.polimi.it 03 Feb '11

03 Feb '11

> Well now the issue I run into is slapd crashing when I also configure > proxy > caching. It stops when trying to Initialize the BDB database: > > slap_sasl_init: initialized! > bdb_back_initialize: initialize BDB backend > bdb_back_initialize: Berkeley DB 4.8.30: (April 9, 2010) > hdb_back_initialize: initialize HDB backend > hdb_back_initialize: Berkeley DB 4.8.30: (April 9, 2010) >>>> dnPrettyNormal: <dc=ad,dc=mydomain,dc=edu> > <<< dnPrettyNormal: <dc=ad,dc=mydomain,dc=edu>, <dc=ad,dc=mydomain,dc=edu> >>>> dnPrettyNormal: <dc=ad,dc=mydomain,dc=edu> > <<< dnPrettyNormal: <dc=ad,dc=mydomain,dc=edu>, <dc=ad,dc=mydomain,dc=edu> > ldap_url_parse_ext(ldap://ldapadlb.mydomain.edu/dc=ad,dc=mydomain,dc=edu) >>>> dnPrettyNormal: <dc=ad,dc=mydomain,dc=edu> > <<< dnPrettyNormal: <dc=ad,dc=mydomain,dc=edu>, <dc=ad,dc=mydomain,dc=edu> > bdb_db_init: Initializing BDB database > slapd-ldap destroy: freeing system resources. > slapd stopped. > connections_destroy: nothing to destroy. > > overlay pcache > proxycache bdb 10000 1 50 100 > proxyattrset 0 uid > proxytemplate * 0 0 > directory /usr/local/var/openldap-data > cachesize 100 Please direct software usage questions to the list. I suspect a misconfiguration; try starting slapd -with d config. p.

2 4

ldap_bind: Invalid credentials (49)
by John Espiro 03 Feb '11

03 Feb '11

System: Ubuntu 10.10 server 64bit @(#) $OpenLDAP: slapd 2.4.23 (Nov 19 2010 17:41:28) $ buildd@allspice:/build/buildd/openldap-2.4.23/debian/build/servers/slapd Problem: I am following the guide here: http://blog.suretecsystems.com/archives/163-OpenLDAP-Quick-Tips-Change-logl… Entering: ldapmodify -x -D 'cn=config' -W -f log.ldif Gives me: Enter LDAP Password: ldap_bind: Invalid credentials (49) I enter the password (that is also stored in ldap.secret), but the error persists. I've got to be missing something obvious, but it's not clear what that is... John

5 6

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical