openldap-technical April 2010

openldap-technical@openldap.org

66 participants
76 discussions

Virtual list view problem
by Venish Khant 31 May '16

31 May '16

Hi all I am using cpan Net::LDAP module to access LDAP entries. I want to search LDAP entries using Net::LDAP search method. When I do search, I want some limited number of entries from search result, for this(searching) process I am using Net::LDAP::Control::VLV module. But I get error on VLV response control. Please, any one have idea about this error. * Error:* Died at vlv.pl line 50, This is my example. I changed the font style of line 50 #!/usr/bin/perl -w use Net::LDAP; use Net::LDAP::Control::VLV; use Net::LDAP::Constant qw( LDAP_CONTROL_VLVRESPONSE ); use Net::LDAP::Control::Sort; sub procentry { my ( $mesg, $entry) = @_; # Return if there is no entry to process if ( !defined($entry) ) { return; } print "dn: " . $entry->dn() . "\n"; @attrs = $entry->attributes(); foreach $attr (@attrs) { #printf("\t%s: %s\n", $attr, $entry->get_value($attr)); $attrvalue = $entry->get_value($attr,asref=>1); #print $attr.":". $entry->get_value($attr)."\n"; foreach $value(@$attrvalue) { print "$attr: $value\n"; } } $mesg->pop_entry; print "\n"; } $ldap = Net::LDAP->new( "localhost" ); # Get the first 20 entries $vlv = Net::LDAP::Control::VLV->new( before => 0, # No entries from before target entry after => 19, # 19 entries after target entry content => 0, # List size unknown offset => 1, # Target entry is the first ); my $sort = Net::LDAP::Control::Sort->new( order => 'cn' ); @args = ( base => "dc=example,dc=co,dc=in", scope => "subtree", filter => "(objectClass=inetOrgPerson)", callback => \&procentry, # Call this sub for each entry control => [ $sort, $vlv ], ); $mesg = $ldap->search( @args ); # Get VLV response control *($resp) = $mesg->control( LDAP_CONTROL_VLVRESPONSE ) or die;* $vlv->response( $resp ); # Set the control to get the last 20 entries $vlv->end; $mesg = $ldap->search( @args ); # Get VLV response control ($resp) = $mesg->control( LDAP_CONTROL_VLVRESPONSE ) or die; $vlv->response( $resp ); # Now get the previous page $vlv->scroll_page( -1 ); $mesg = $ldap->search( @args ); # Get VLV response control ($resp) = $mes # Now page with first entry starting with "B" in the middle $vlv->before(9); # Change page to show 9 before $vlv->after(10); # Change page to show 10 after $vlv->assert("B"); # assert "B" $mesg = $ldap->search( @args );g->control( LDAP_CONTROL_VLVRESPONSE ) or die; $vlv->response( $resp ); -- Venish Khant www.deeproot.co.in

4 11

Certificate authentication and back-ldap proxy
by Ubay Dorta Guerra 27 Dec '10

27 Dec '10

Hi, We have some problems with certificate authentication when the master server is behind a back-ldap proxy. We have openldap 2.4.21 on Suse Linux Enterprise Server 10 SP3 and these are the details of our scenario: The master server: server1.example.com has the following slapd.conf file: access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to attrs=userPassword,userPKCS12 by self write by dn.exact="CN=admin_w_cert,O=Internet Widgits Pty Ltd,ST=Some-State,C=AU" read by * auth access to attrs=shadowLastChange by self write by * read access to * by * read # # Security SSL # TLSCipherSuite HIGH:MEDIUM:+SSLv3 TLSCertificateFile /etc/ssl/certs/server1.example.com.pem TLSCertificateKeyFile /etc/ssl/private/server1.example.com.key TLSCACertificatePath /etc/ssl/cacerts/ TLSVerifyClient demand # #Log level # loglevel 256 # Require authentication require authc ####################################################################### # HDB database definitions ####################################################################### database hdb suffix "dc=example,dc=com" checkpoint 1024 5 cachesize 10000 rootdn "cn=Manager,dc=example,dc=com" rootpw secret # Indices to maintain index objectClass eq # Overlay ppolicy overlay ppolicy ---------------------- Authentication is required, and we give access to the user passwords for the dn of a certificate. When we search for passwords using the certificate we get the following: root# ldapsearch -LLL -b 'uid=user_w_pass,ou=people,dc=example,dc=com' -H ldaps://server1.example.com userPassword SASL/EXTERNAL authentication started SASL username: CN=admin_w_cert,O=Internet Widgits Pty Ltd,ST=Some-State,C=AU SASL SSF: 0 dn: uid=user_w_pass,ou=people,dc=example,dc=com userPassword:: e2NyeXB0fTcyMXpQbU4waWdKaU0= ----------------------- The root user (ldap client) has a ~/.ldaprc file with: TLS_CACERTDIR /etc/ssl/cacerts/ TLS_CERT /etc/ssl/certs/admin_w_cert.pem TLS_KEY /etc/ssl/private/admin_w_cert.key TLS_REQCERT demand SASL_MECH EXTERNAL In /var/log/messages we get: ldap-master[22358]: conn=1000 fd=11 ACCEPT from IP=server1.example.com:40899 (IP=server1.example.com:636) ldap-master[22358]: conn=1000 fd=11 TLS established tls_ssf=256 ssf=256 ldap-master[22358]: conn=1000 op=0 BIND dn="" method=163 ldap-master[22358]: conn=1000 op=0 BIND authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" authzid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" ldap-master[22358]: conn=1000 op=0 BIND dn="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" mech=EXTERNAL sasl_ssf=0 ssf=256 ldap-master[22358]: conn=1000 op=0 RESULT tag=97 err=0 text= ldap-master[22358]: conn=1000 op=1 SRCH base="uid=user_w_pass,ou=people,dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" ldap-master[22358]: conn=1000 op=1 SRCH attr=userPassword ldap-master[22358]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= ldap-master[22358]: conn=1000 op=2 UNBIND ldap-master[22358]: conn=1000 fd=11 closed This is the correct behavior for us. The problem appears when we introduce a back-ldap proxy between the client and the master. The proxy server (proxy-server1.example.com) is listening in port 1636 and its slapd.conf file is: # # Security SSL # TLSCipherSuite HIGH:MEDIUM:+SSLv3 TLSCACertificatePath /etc/ssl/cacerts/ TLSCertificateFile /etc/ssl/certs/proxy-server1.example.com.pem TLSCertificateKeyFile /etc/ssl/private/proxy-server1.example.com.key TLSVerifyClient demand # Log level loglevel 256 ####################################################################### # Database definitions ####################################################################### database ldap rebind-as-user true suffix "dc=example,dc=com" uri "ldaps://server1.example.com" tls ldaps tls_cert=/etc/ssl/certs/proxy-server1.example.com.pem tls_key=/etc/ssl/private/proxy-server1.example.com.key tls_cacertdir=/etc/ssl/cacerts/ ---------------------- If we search for passwords through the proxy we get: root # ldapsearch -LLL -b 'uid=user_w_pass,ou=people,dc=example,dc=com' -H ldaps://proxy-server1.example.com:1636 userPassword SASL/EXTERNAL authentication started SASL username: CN=admin_w_cert,O=Internet Widgits Pty Ltd,ST=Some-State,C=AU SASL SSF: 0 Server is unwilling to perform (53) Additional information: authentication required In the /var/log/messages the following messages appear: ldap-proxy[22802]: conn=1001 fd=8 ACCEPT from IP=proxy-server1.example.com:60712 (IP=proxy-server1.example.com:1636) ldap-proxy[22802]: conn=1001 fd=8 TLS established tls_ssf=256 ssf=256 ldap-proxy[22802]: conn=1001 op=0 BIND dn="" method=163 ldap-proxy[22802]: conn=1001 op=0 BIND authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" authzid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" ldap-proxy[22802]: conn=1001 op=0 BIND dn="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" mech=EXTERNAL sasl_ssf=0 ssf=256 ldap-proxy[22802]: conn=1001 op=0 RESULT tag=97 err=0 text= ldap-proxy[22802]: conn=1001 op=1 SRCH base="uid=user_w_pass,ou=people,dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" ldap-proxy[22802]: conn=1001 op=1 SRCH attr=userPassword ldap-master[22358]: conn=1008 op=2 SRCH base="uid=user_w_pass,ou=people,dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" ldap-master[22358]: conn=1008 op=2 SRCH attr=userPassword ldap-master[22358]: conn=1008 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=authentication required ldap-proxy[22802]: conn=1001 op=1 SEARCH RESULT tag=101 err=53 nentries=0 text=authentication required ldap-proxy[22802]: conn=1001 op=2 UNBIND ldap-proxy[22802]: conn=1001 fd=8 closed The /root/.ldaprc file is the same than the previous one. When we increase the logging level we discover this: .... ldap-proxy[23008]: conn=1000 op=0 do_bind ldap-proxy[23008]: >>> dnPrettyNormal: <> ldap-proxy[23008]: <<< dnPrettyNormal: <>, <> ldap-proxy[23008]: conn=1000 op=0 BIND dn="" method=163 ldap-proxy[23008]: do_bind: dn () SASL mech EXTERNAL ldap-proxy[23008]: ==> sasl_bind: dn="" mech=EXTERNAL datalen=0 ldap-proxy[23008]: SASL Canonicalize [conn=1000]: authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" ldap-proxy[23008]: slap_sasl_getdn: conn 1000 id=cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au [len=61] ldap-proxy[23008]: ==>slap_sasl2dn: converting SASL name cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au to a DN ldap-proxy[23008]: <==slap_sasl2dn: Converted SASL name to <nothing> ldap-proxy[23008]: SASL Canonicalize [conn=1000]: slapAuthcDN="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" ldap-proxy[23008]: SASL proxy authorize [conn=1000]: authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" authzid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" ldap-proxy[23008]: conn=1000 op=0 BIND authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" authzid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" ldap-proxy[23008]: SASL Authorize [conn=1000]: proxy authorization allowed authzDN="" ldap-proxy[23008]: send_ldap_sasl: err=0 len=-1 ldap-proxy[23008]: conn=1000 op=0 BIND dn="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" mech=EXTERNAL sasl_ssf=0 ssf=256 ldap-proxy[23008]: do_bind: SASL/EXTERNAL bind: dn="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" sasl_ssf=0 ldap-proxy[23008]: send_ldap_response: msgid=1 tag=97 err=0 ldap-proxy[23008]: conn=1000 op=0 RESULT tag=97 err=0 text= ldap-proxy[23008]: <== slap_sasl_bind: rc=0 .... ldap-proxy[23008]: conn=1000 op=1 SRCH base="uid=user_w_pass,ou=people,dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" ldap-proxy[23008]: conn=1000 op=1 SRCH attr=userPassword ldap-proxy[23008]: ==> limits_get: conn=1000 op=1 self="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au" this="uid=user_w_pass,ou=people,dc=example,dc=com" ldap-master[22983]: daemon: activity on 1 descriptor ldap-master[22983]: daemon: activity on: ldap-master[22983]: ldap-master[22983]: slap_listener_activate(7): ldap-master[22983]: daemon: epoll: listen=7 busy ldap-master[22983]: >>> slap_listener(ldaps://server1.example.com) ..... ldap-master[22983]: conn=1000 op=0 do_bind ldap-master[22983]: >>> dnPrettyNormal: <> ldap-master[22983]: <<< dnPrettyNormal: <>, <> ldap-master[22983]: conn=1000 op=0 BIND dn="" method=128 ldap-master[22983]: do_bind: version=3 dn="" method=128 ldap-master[22983]: send_ldap_result: conn=1000 op=0 p=3 ldap-master[22983]: send_ldap_result: err=0 matched="" text="" ldap-master[22983]: send_ldap_response: msgid=1 tag=97 err=0 ldap-master[22983]: conn=1000 op=0 RESULT tag=97 err=0 text= ldap-master[22983]: do_bind: v3 anonymous bind ---------------- Therefore the proxy is binding anonymously in the master, instead of using the dn of the certificate. Is there any problem with the SASL EXTERNAL method? If we use SIMPLE authentication through the proxy, there is no problem: root # ldapsearch -LLL -x -b 'uid=user_w_pass,ou=people,dc=example,dc=com' -H ldaps://proxy-server1.example.com:1636 -D 'uid=user_w_pass,ou=people,dc=example,dc=com' -W userPassword Enter LDAP Password: dn: uid=user_w_pass,ou=people,dc=example,dc=com userPassword:: e2NyeXB0fTcyMXpQbU4waWdKaU0= Thanks in advance. --------------------------------------------------------------------------------------------- ADVERTENCIA: Sobre la privacidad y cumplimiento de la Ley de Protección de Datos, acceda a http://www.iac.es/disclaimer.php WARNING: For more information on privacy and fulfilment of the Law concerning the Protection of Data, consult http://www.iac.es/disclaimer.php?lang=en

3 4

Multi master replication
by Aravind Divakaran 21 Jun '10

21 Jun '10

Hi All, I have configured two servers with multi master replication. Below is my configuration for synrepl on both servers. Server One ------------ serverID 001 overlay syncprov syncprov-checkpoint 100 10 syncrepl rid=000 provider=ldap://192.168.10.100 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=example,dc=com" attrs="*,+" bindmethod=simple binddn="cn=syncuser,dc=example,dc=com" credentials=password mirrormode TRUE Server Two -------------- serverID 002 overlay syncprov syncprov-checkpoint 100 10 syncrepl rid=000 provider=ldap://192.168.10.25 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=example,dc=com" attrs="*,+" bindmethod=simple binddn="cn=syncuser,dc=example,dc=com" credentials=password mirrormode TRUE Today one of user said that he was not able to login. So i checked in the servers in one server i was able to login but on another server i was not able to login with the same password. I have checked the contextCSN on both server they are equal. In the log it is showing this syncrepl_entry: rid=000 entry unchanged, ignored (uid=user,ou=People,dc=example,dc=com) Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 uid=user,ou=People,dc=example,dc=com Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 be_add uid=user,ou=People,dc=example,dc=com (68) Apr 28 12:14:17 mails slapd[16595]: dn_callback : entries have identical CSN uid=user,ou=People,dc=example,dc=com 20100422132507.789242Z#000000#002#000000 Can anyone help me why above message is showing in the log files and why the user is not able to login. Rgds, Aravind M D

7 14

ppolicy master/slave issue
by Chris Jacobs 25 May '10

25 May '10

Hello again, I'm having an odd issue with ppolicy and my master/slave config. First, my goals General use: Slave handles all reads locally. Writes get forwarded to the master by the slave. Password policy: When password failures happen on clients using slave ldap servers, the failures, etc, get passed to the master to get replicated to the slaves. I understand this would be done using the ppolicy option: ppolicy_forward_updates Authentication: Actually authenticate (more later). To the problem: --------------- When I leave the section in the chain bit of SLAVE slapd.conf below marked by lines intact (which bind as root): * ppolicy_forward_updates seems to work great - the master shows matching "pwdFailureTime" attributes. * Regardless of password entered, you get a shell. User/bad password = get a shell! This being a problem should be obvious. I suspect that's due to the chain overlay section... If I comment out the lines in the SLAVE slapd.conf: * authentication actually requires authentication (bad password = no authentication) * ppolicy_forward_updates don't work (no updates to master) It's possible that from my description some may already know my issue - however, just to be sure, I've pasted below 'bare' versions of the: * a master slapd.conf (sans schema includes) * a slave slapd.conf (sans schema includes) * /etc/ldap.conf (using slave) * /etc/openldap/ldap.conf (same on all ldap servers) (thanks Howard - they are NOT the same) * /etc/pam.d/system-auth-ac (CentOS 5.4; ssh refers to system-auth-ac for all types). Thanks for any help (and, likely, pointing out any 'stupids' below), - chris PS: Feel free to critique - you won't hurt my feelings. MASTER slapd.conf: (one of a pair, mirrored, active/passive fail over) ---------------------------------------------------------------------- serverID 1 loglevel 0 pidfile /usr/local/var/openldap-data/run/slapd.pid argsfile /usr/local/var/openldap-data/run/slapd.args TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCACertificateFile /etc/openldap/cacerts/cacert.pem TLSCertificateFile /etc/openldap/cacerts/servercrt.pem TLSCertificateKeyFile /etc/openldap/cacerts/serverkey.pem TLSVerifyClient never password-hash {MD5} sizelimit size.soft=500 size.hard=unlimited timelimit time.soft=3600 time.soft=unlimited database bdb suffix "dc=unix,dc=aptimus,dc=net" rootdn "uid=root,ou=people,dc=unix,dc=aptimus,dc=net" rootpw "secret" directory "/usr/local/var/openldap-data/aptimus" include /etc/openldap/slapd.access.conf index uid,cn,gidNumber,uidNumber,memberUid eq index objectClass pres,eq index operatingSystem pres,eq index host pres,eq index rack eq index entryUUID eq index uniqueMember eq index entryCSN eq index site eq overlay ppolicy ppolicy_hash_cleartext ppolicy_use_lockout overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 10 syncrepl rid=2 provider=ldaps://ldapmaster2.corp.aptimus.net type=refreshAndPersist interval=00:00:10:00 searchbase="dc=unix,dc=aptimus,dc=net" bindmethod=simple binddn="uid=root,ou=people,dc=unix,dc=aptimus,dc=net" credentials="secret" retry="15 20 60 +" mirrormode on database monitor SLAVE slapd.conf: ----------------- serverID 13 loglevel 0 pidfile /usr/local/var/openldap-data/run/slapd.pid argsfile /usr/local/var/openldap-data/run/slapd.args TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCACertificateFile /etc/openldap/cacerts/cacert.pem TLSCertificateFile /etc/openldap/cacerts/servercrt.pem TLSCertificateKeyFile /etc/openldap/cacerts/serverkey.pem TLSVerifyClient never password-hash {MD5} sizelimit size.soft=500 size.hard=unlimited timelimit time.soft=3600 time.soft=unlimited overlay chain chain-uri ldaps://ldap-vip.corp.aptimus.net/ chain-rebind-as-user TRUE vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv chain-idassert-bind bindmethod="simple" binddn="uid=root,ou=people,dc=unix,dc=aptimus,dc=net" credentials="Ten%20two" mode="self" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ chain-tls ldaps chain-return-error TRUE database bdb suffix "dc=unix,dc=aptimus,dc=net" rootdn "uid=root,ou=people,dc=unix,dc=aptimus,dc=net" rootpw "secret" directory "/usr/local/var/openldap-data/aptimus" include /etc/openldap/slapd.access.conf index uid,cn,gidNumber,uidNumber,memberUid eq index objectClass pres,eq index operatingSystem pres,eq index host pres,eq index rack eq index entryUUID eq index uniqueMember eq index entryCSN eq index site eq overlay ppolicy ppolicy_hash_cleartext ppolicy_use_lockout ppolicy_forward_updates syncrepl rid=1 provider=ldaps://ldap-vip.corp.aptimus.net type=refreshAndPersist interval=00:00:10:00 searchbase="dc=unix,dc=aptimus,dc=net" bindmethod=simple binddn="uid=root,ou=people,dc=unix,dc=aptimus,dc=net" credentials="secret" retry="15 20 60 +" updateref "ldaps://ldap-vip.corp.aptimus.net" database monitor /etc/openldap/ldap.conf: (same on all LDAP servers) --------------------------------------------------- uri ldaps://localhost base dc=unix,dc=aptimus,dc=net network_timeout 0 sizelimit 0 timelimit 0 tls_cacert /etc/openldap/cacerts/cacert.pem tls_reqcert demand /etc/ldap.conf: (on client using slave) --------------------------------------- uri ldaps://ldap-vip.dc1.aptimus.net timelimit 10 bind_timelimit 10 bind_policy soft base dc=unix,dc=aptimus,dc=net scope sub ssl on tls_checkpeer no tls_cacertfile /etc/openldap/cacert.pem (contents same as /etc/openldap/cacerts/cacert.pem) pam_login_attribute uid pam_lookup_policy yes pam_password exop /etc/pam.d/system-auth-ac: -------------------------- 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_localuser.so 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 password sufficient pam_unix.so sha256 shadow nullok try_first_pass use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_ldap.so This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

2 5

RE: RPM spec file
by Joe Friedeggs 04 May '10

04 May '10

> On 15/04/2010 16:38, Joe Friedeggs wrote: >> >> I need to build a Red Hat rpm for the latest OpenLDAP release. I am looking for spec file, howto page, or anything else that might speed up this project. Any advice/suggestions would be greatly appreciated. > > The folks at LTB-project maintain RPMs for recent OpenLDAP releases. You > could either use their pre-built RPMs or grab their spec file from the > repository: > > http://ltb-project.org/wiki/documentation/openldap-rpm > > Jonathan I googled the HECK out of that rpm.......how did I miss the LBT :-( Thanks, Jonathan, that is just what I was looking for. And thanks to all others that provided input. Joe _________________________________________________________________ Hotmail: Trusted email with Microsoft’s powerful SPAM protection. http://clk.atdmt.com/GBL/go/196390706/direct/01/

3 3

openldap library and LDAP_OPT_X_KEEPALIVE_IDLE
by Fred MAISON 30 Apr '10

30 Apr '10

Hello, Could someone tell which openldap library version first included keepalive paches giving acces to following options : LDAP_OPT_X_KEEPALIVE_IDLE LDAP_OPT_X_KEEPALIVE_PROBES LDAP_OPT_X_KEEPALIVE_INTERVAL I have submitted a patch on freeradius for the rlm_ldap module for using those options to solve firewall/load-balancers LDAP session timeout by generation regular tcp keepalive packets ont LDAP sockets, and I see my current linux distros does not seems to have fresh-enough openldap library version to support this. debian squeeze libldap2-dev 2.4.17 CentOS 5.4 openldap-devel-2.3.43-3.el5 2.3.43 Best regards Fred MAISON

2 1

_ldap.so: undefined symbol: gnutls_alert_send
by Jean-Sébastien Mansart 29 Apr '10

29 Apr '10

Hi. I've got this error with a Zope/Plone site : Traceback (most recent call last): File "/zope/z_sgec/Zope-2.10.11-final-py2.4/lib/python/Zope2/Startup/run.py", line 56, in ? run() File "/zope/z_sgec/Zope-2.10.11-final-py2.4/lib/python/Zope2/Startup/run.py", line 21, in run starter.prepare() File "/home/zope/z_sgec/Zope-2.10.11-final-py2.4/lib/python/Zope2/Startup/__init__.py", line 102, in prepare self.startZope() File "/home/zope/z_sgec/Zope-2.10.11-final-py2.4/lib/python/Zope2/Startup/__init__.py", line 278, in startZope Zope2.startup() File "/home/zope/z_sgec/Zope-2.10.11-final-py2.4/lib/python/Zope2/__init__.py", line 47, in startup _startup() File "/home/zope/z_sgec/Zope-2.10.11-final-py2.4/lib/python/Zope2/App/startup.py", line 45, in startup OFS.Application.import_products() File "/home/zope/z_sgec/Zope-2.10.11-final-py2.4/lib/python/OFS/Application.py", line 686, in import_products import_product(product_dir, product_name, raise_exc=debug_mode) File "/home/zope/z_sgec/Zope-2.10.11-final-py2.4/lib/python/OFS/Application.py", line 709, in import_product product=__import__(pname, global_dict, global_dict, silly) File "/home/zope/z_sgec/buildout-cache/eggs/Products.LDAPMultiPlugins-1.9-py2.4.egg/Products/LDAPMultiPlugins/__init__.py", line 22, in ? from Products.LDAPMultiPlugins.LDAPMultiPlugin import addLDAPMultiPluginForm File "/home/zope/z_sgec/buildout-cache/eggs/Products.LDAPMultiPlugins-1.9-py2.4.egg/Products/LDAPMultiPlugins/LDAPMultiPlugin.py", line 29, in ? from Products.LDAPUserFolder import manage_addLDAPUserFolder File "/home/zope/z_sgec/buildout-cache/eggs/Products.LDAPUserFolder-2.16-py2.4.egg/Products/LDAPUserFolder/__init__.py", line 20, in ? from Products.LDAPUserFolder.LDAPUserFolder import LDAPUserFolder File "/home/zope/z_sgec/buildout-cache/eggs/Products.LDAPUserFolder-2.16-py2.4.egg/Products/LDAPUserFolder/LDAPUserFolder.py", line 47, in ? from Products.LDAPUserFolder.LDAPDelegate import filter_format File "/home/zope/z_sgec/buildout-cache/eggs/Products.LDAPUserFolder-2.16-py2.4.egg/Products/LDAPUserFolder/LDAPDelegate.py", line 19, in ? import ldap File "/home/zope/z_sgec/buildout-cache/eggs/python_ldap-2.3.11-py2.4-linux-i686.egg/ldap/__init__.py", line 22, in ? from _ldap import * ImportError: /home/zope/z_sgec/buildout-cache/eggs/python_ldap-2.3.11-py2.4-linux-i686.egg/_ldap.so: undefined symbol: gnutls_alert_send I have install gnutls1.3, recompiled openldap, python-ldap, and so on, but nothing works. Anyone could help me ? Thanks. -- *Jean-Sébastien Mansart *- Développeur Web Email : jean-sebastien.mansart(a)bayard-service.com <mailto:jean-sebastien.mansart@bayard-service.com> Tel : 04 79 26 28 29 *Bayard Service Edition * Savoie Technolac - House Boat BP308 - 73377 Le Bourget du Lac Cedex www.bayardserviceweb.com <http://www.bayardserviceweb.com>

3 2

Slow problem after some time
by Marco Pizzoli 28 Apr '10

28 Apr '10

Hi list, I have a problem with my openldap 2.4.22 deployment. Today I upgraded my architecture from 2-way openldap2.4.20 to 3-way openldap.2.4.22, but I continue to have the same problem of slowlyness after some time my systems came up. One of them in particular but I'm aware of our balancing system heavily prefer this one. The symptom is that every search, even the same simple search executed repeteadly, cause a cpu-burst and will be served in a enormous time, sometimes 1m30s even after a cold start the same query is served in less than a second. My user database is accessed for linux, AIX, DB2 and Oracle authentication. I have repeatedly the same searches fired against my openldap instancies. I suspect to have a problem in the way I configured the memory to be allocated My data on the user_db are quite static, but I have an accesslog writing very much. Retaining 3 days of history, my db dir grow to about 11/12GB. I'm using 4 different disk (and scsi controller) for userdb, logdb, transactionlog and OS. Following information about my environment. I can send others if necessary. My user database is quite little: 1.5MB slapcat ldif database hdb suffix "dc=lancse,dc=csebo.it" rootdn "cn=Manager,dc=lancse,dc=csebo.it" rootpw {SSHA}mySecret directory /srv/ldap/db_utenti index cn eq index ou eq index objectClass eq index uid eq index gidNumber eq index uidNumber eq #index member pres,eq index memberUid eq index entryCSN eq index entryUUID eq index userPassword pres index uniqueMember eq limits dn="cn=Manager,dc=lancse,dc=csebo.it" size=unlimited # cachesize: numero di entry del db da tenere in cache. # Ad oggi (2010-04-20) nel database degli utenti ne abbiamo cachesize 2000000 # dncachesize: indica il numero di dn da tenere in memoria. # Il valore di 0 indica nessun limite #dncachesize 2000000 dncachesize 0 # idlcachesize: index-data-lookup cache. Indica il numero di slot dell'indice tenuti in memoria idlcachesize 2000000 # cachefree: indica quante entry alla volta liberare quando viene saturata cachefree 10 # checkpoint ogni 1MB di scritte eseguite e/o 30 minuti di tempo checkpoint 1024 30 [root@ldap01 db_utenti]# ls -lhtr *.bdb -rw------- 1 ldap ldap 44K Apr 26 18:09 uid.bdb -rw------- 1 ldap ldap 40K Apr 26 18:09 gidNumber.bdb -rw------- 1 ldap ldap 8.0K Apr 27 09:07 uniqueMember.bdb -rw------- 1 ldap ldap 28K Apr 27 12:32 uidNumber.bdb -rw------- 1 ldap ldap 40K Apr 27 12:32 ou.bdb -rw------- 1 ldap ldap 32K Apr 28 11:04 memberUid.bdb -rw------- 1 ldap ldap 36K Apr 28 16:14 userPassword.bdb -rw------- 1 ldap ldap 164K Apr 28 16:14 objectClass.bdb -rw------- 1 ldap ldap 72K Apr 28 16:14 entryUUID.bdb -rw------- 1 ldap ldap 260K Apr 28 16:14 dn2id.bdb -rw------- 1 ldap ldap 32K Apr 28 16:14 cn.bdb -rw------- 1 ldap ldap 64K Apr 28 17:34 entryCSN.bdb -rw------- 1 ldap ldap 2.0M Apr 28 17:39 id2entry.bdb The DB_CONFIG is this: # Uso 256MB di cache splittato in 2 file set_cachesize 0 268435456 2 # Transaction Log settings set_lg_regionmax 262144 set_lg_bsize 2097152 # IMPOSTO LA DIR DEI TLOGS IN UN FileSystem DEDICATO set_lg_dir logs # PARAMETRI DI TUNING DEI LOCK set_lk_max_objects 3000 set_lk_max_locks 3000 set_lk_max_lockers 3000 # IMPOSTO LA RIMOZIONE AUTOMATICA DEI LOG set_flags DB_LOG_AUTOREMOVE ------------------------------------------------------------------------------------- This is the accesslog db dir database hdb suffix "cn=log01,dc=csebo.it" rootdn "cn=Manager,cn=log01,dc=csebo.it" rootpw mySecret directory /srv/ldap/db_log index entryUUID eq index reqStart eq index reqEnd eq index objectClass eq index reqType eq index reqDN eq index reqAuthzID eq index reqEntries eq index reqAttr eq index reqResult eq index reqFilter pres,eq #index reqEntries eq #index reqSession eq #index reqResult eq #index reqScope eq #index reqDerefAliases eq #index reqAttrsOnly eq #index reqFilter eq,approx #index reqTimeLimit eq,approx #index reqSizeLimit eq,approx limits dn="cn=Manager,cn=log01,dc=csebo.it" size=unlimited # cachesize: numero di entry del db da tenere in cache. cachesize 150000 # dncachesize: indica il numero di dn da tenere in memoria. # Il valore di 0 indica nessun limite dncachesize 300000 # idlcachesize: index-data-lookup cache. Indica il numero di slot dell'indice tenuti in memoria # Per i backend bdb e' suggerito essere uguale a "cachesize" # Per i backend hdb e' suggerito essere uguale ad almeno 3 volte "cachesize" idlcachesize 450000 # cachefree: indica quante entry alla volta liberare quando viene saturata cachefree 10 # checkpoint ogni 4MB di scritte eseguite e/o 30 minuti di tempo checkpoint 4096 30 [root@ldap01 db_log]# ls -lhtr total 7.8G drwx------ 2 ldap ldap 16K Feb 26 11:54 lost+found lrwxrwxrwx 1 ldap ldap 26 Feb 26 12:11 logs -> ../transactionlogs/db_logs -rw-r--r-- 1 ldap ldap 1.3K Apr 28 17:40 DB_CONFIG -rw------- 1 ldap ldap 2.3M Apr 28 17:40 __db.004 -rw------- 1 ldap ldap 321M Apr 28 17:40 __db.003 -rw------- 1 ldap ldap 16M Apr 28 17:40 __db.002 -rw------- 1 ldap ldap 24K Apr 28 17:40 __db.001 -rw-r--r-- 1 ldap ldap 2.0K Apr 28 17:40 alock -rw------- 1 ldap ldap 32K Apr 28 17:40 __db.006 -rw------- 1 ldap ldap 2.5M Apr 28 17:40 __db.005 -rw------- 1 ldap ldap 1.3M Apr 28 18:27 reqEntries.bdb -rw------- 1 ldap ldap 21M Apr 28 18:27 reqFilter.bdb -rw------- 1 ldap ldap 12M Apr 28 18:27 reqAttr.bdb -rw------- 1 ldap ldap 1.7M Apr 28 18:27 reqType.bdb -rw------- 1 ldap ldap 106M Apr 28 18:27 reqStart.bdb -rw------- 1 ldap ldap 1.2M Apr 28 18:27 reqResult.bdb -rw------- 1 ldap ldap 105M Apr 28 18:27 reqEnd.bdb -rw------- 1 ldap ldap 6.3M Apr 28 18:27 reqDN.bdb -rw------- 1 ldap ldap 5.7M Apr 28 18:27 reqAuthzID.bdb -rw------- 1 ldap ldap 4.6M Apr 28 18:27 objectClass.bdb -rw------- 1 ldap ldap 6.0G Apr 28 18:27 id2entry.bdb -rw------- 1 ldap ldap 163M Apr 28 18:27 entryUUID.bdb -rw------- 1 ldap ldap 1.1G Apr 28 18:27 dn2id.bdb This is the DB_CONFIG file # one 0.25 GB cache set_cachesize 0 268435456 1 # Transaction Log settings set_lg_regionmax 262144 set_lg_bsize 2097152 # IMPOSTO LA DIR DEI TLOGS IN UN FileSystem DEDICATO set_lg_dir logs # Dimensione dei log --> 60MB set_lg_max 62914560 #set_lg_max 41943040 # PARAMETRI DI TUNING DEI LOCK set_lk_max_objects 3000 set_lk_max_locks 3000 set_lk_max_lockers 3000 My system has 15 GB of RAM. This is an example of my RAM situation when the problem arises [root@ldap01 db_log]# free -m total used free shared buffers cached Mem: 14799 8009 6790 0 924 3160 -/+ buffers/cache: 3924 10875 Swap: 6143 8 6135 top -H PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP DATA COMMAND 9008 ldap 25 0 4806m 3.8g 346m S 0.0 26.5 0:10.69 880m 4.0g slapd2.4 9151 ldap 15 0 4806m 3.8g 346m S 0.0 26.5 0:11.23 880m 4.0g slapd2.4 9152 ldap 15 0 4806m 3.8g 346m S 0.0 26.5 2:37.42 880m 4.0g slapd2.4 9153 ldap 15 0 4806m 3.8g 346m S 0.0 26.5 3:20.29 880m 4.0g slapd2.4 9154 ldap 15 0 4806m 3.8g 346m S 0.3 26.5 3:02.49 880m 4.0g slapd2.4 9155 ldap 16 0 4806m 3.8g 346m S 0.0 26.5 2:23.49 880m 4.0g slapd2.4 9156 ldap 15 0 4806m 3.8g 346m S 0.0 26.5 2:14.86 880m 4.0g slapd2.4 9157 ldap 15 0 4806m 3.8g 346m S 0.0 26.5 2:44.86 880m 4.0g slapd2.4 9158 ldap 16 0 4806m 3.8g 346m S 0.0 26.5 2:03.71 880m 4.0g slapd2.4 9163 ldap 16 0 4806m 3.8g 346m S 0.0 26.5 2:06.05 880m 4.0g slapd2.4 9164 ldap 15 0 4806m 3.8g 346m S 0.0 26.5 2:46.38 880m 4.0g slapd2.4 9165 ldap 15 0 4806m 3.8g 346m S 0.0 26.5 2:25.31 880m 4.0g slapd2.4 9170 ldap 15 0 4806m 3.8g 346m S 0.0 26.5 2:12.04 880m 4.0g slapd2.4 9171 ldap 15 0 4806m 3.8g 346m S 0.0 26.5 2:17.15 880m 4.0g slapd2.4 9172 ldap 18 0 4806m 3.8g 346m R 98.1 26.5 2:06.54 880m 4.0g slapd2.4 9173 ldap 15 0 4806m 3.8g 346m S 0.0 26.5 2:39.32 880m 4.0g slapd2.4 9174 ldap 15 0 4806m 3.8g 346m S 0.0 26.5 2:25.64 880m 4.0g slapd2.4 9175 ldap 15 0 4806m 3.8g 346m S 0.0 26.5 2:33.29 880m 4.0g slapd2.4 With dstat I can see that I *don't* have disk reading, only writings due to the accesslog ---procs--- ------memory-usage----- ---paging-- -dsk/total- ---system-- ----total-cpu-usage---- ------memory-usage----- run blk new| used buff cach free| in out | read writ| int csw |usr sys idl wai hiq siq| used buff cach free 2 0 2|3932M 926M 3178M 6764M| 0 0 | 0 559k| 246 445 | 24 0 75 0 0 0|3932M 926M 3178M 6764M 1 0 0|3932M 926M 3178M 6764M| 0 0 | 0 464k| 200 333 | 24 0 76 0 0 0|3932M 926M 3178M 6764M 1 0 2|3933M 926M 3178M 6764M| 0 0 | 0 408k| 213 309 | 24 1 75 0 0 0|3933M 926M 3178M 6764M 3 0 0|3932M 926M 3178M 6764M| 0 0 | 0 420k| 205 280 | 23 0 75 1 0 0|3932M 926M 3178M 6764M 3 0 0|3932M 926M 3178M 6764M| 0 0 | 0 376k| 210 349 | 23 0 77 0 0 0|3932M 926M 3178M 6764M 1 0 0|3932M 926M 3178M 6764M| 0 0 | 0 900k| 233 373 | 24 0 75 0 0 0|3932M 926M 3178M 6764M 1 0 0|3932M 926M 3178M 6764M| 0 0 | 0 356k| 208 446 | 22 1 77 0 0 0|3932M 926M 3178M 6764M 1 0 0|3932M 926M 3178M 6764M| 0 0 | 0 440k| 213 389 | 22 0 76 1 0 0|3932M 926M 3178M 6764M 1 0 0|3932M 926M 3178M 6764M| 0 0 | 0 403k| 200 306 | 23 1 75 1 0 0|3932M 926M 3178M 6764M 3 0 4|3932M 926M 3178M 6764M| 0 0 | 0 648k| 196 365 | 24 1 74 1 0 0|3932M 926M 3178M 6764M 2 0 0|3932M 926M 3178M 6764M| 0 0 | 0 572k| 246 287 | 22 2 75 0 0 0|3932M 926M 3178M 6764M 1 0 2|3932M 926M 3179M 6763M| 0 0 | 0 552k| 197 256 | 25 1 73 1 0 0|3932M 926M 3179M 6763M 2 0 0|3932M 926M 3179M 6763M| 0 0 | 0 368k| 210 259 | 23 1 75 0 0 0|3932M 926M 3179M 6763M 2 0 0|3932M 926M 3179M 6763M| 0 0 | 0 4228k| 203 272 | 24 1 73 2 0 0|3932M 926M 3179M 6763M 2 0 0|3932M 926M 3179M 6763M| 0 0 | 0 440k| 218 346 | 23 1 76 0 0 0|3932M 926M 3179M 6763M 4 0 0|3932M 926M 3179M 6763M| 0 0 | 0 499k| 215 359 | 24 0 75 1 0 0|3932M 926M 3179M 6763M 2 0 0|3932M 926M 3179M 6763M| 0 0 | 0 348k| 215 313 | 25 0 74 1 0 0|3932M 926M 3179M 6763M 1 0 0|3932M 926M 3179M 6763M| 0 0 | 0 360k| 166 245 | 24 0 75 1 0 0|3932M 926M 3179M 6763M 2 0 7|3933M 926M 3179M 6762M| 0 0 | 0 432k| 225 393 | 25 3 71 0 0 0|3933M 926M 3179M 6762M 2 0 0|3933M 926M 3179M 6762M| 0 0 | 0 508k| 206 353 | 24 1 75 0 0 0|3933M 926M 3179M 6762M 1 0 2|3933M 926M 3179M 6762M| 0 0 | 0 716k| 254 342 | 25 1 75 0 0 0|3933M 926M 3179M 6762M 2 0 0|3933M 926M 3179M 6762M| 0 0 | 0 436k| 252 361 | 24 0 75 0 0 0|3933M 926M 3179M 6762M 1 0 0|3933M 926M 3179M 6762M| 0 0 | 0 456k| 226 359 | 24 0 75 1 0 0|3933M 926M 3179M 6762M I have also password_policy with forwarding of operational attributes and auditlog overlay. Thanks in advance Marco -- _________________________________________ Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison

1 0

How to correctly escape search filters
by Jeremiah Martell 27 Apr '10

27 Apr '10

I've been trying to research how to correctly escape search filters, and I can't find any single reliable source that makes sense. I look at RFC 2253 (http://www.ietf.org/rfc/rfc2253.txt) section 2.4, and this IBM webpage ( http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/rzah… ), and they both seem to suggest that you need to escape (for example) the '+' sign. But when I escape a search filter like this: (&(objectclass=person)(facsimileTelephoneNumber=+1234)) to this: (&(objectclass=person)(facsimileTelephoneNumber=\+1234)) it results in a bad filter. My hunch is that perhaps DNs, attribute names, and attribute values are all escaped different. Is there a simple explanation online on how to escape search filters? Thanks, - Jeremiah

2 1

Re: openldap 2.4.21 - back-ldap + pcache ... backend binding
by repudi8or repu 27 Apr '10

27 Apr '10

On Tue, Apr 27, 2010 at 3:43 PM, repudi8or repu <repudi8or(a)gmail.com> wrote: > Thanks for the response Masarati, > > I have setup with mode=self, but still the same error. > > Maybe im having a conceptual issue here. What i am trying to do is ensure > the backend functions prior to looking at the configuring the frontend > correctly. I am configuring the solaris openldap slapd with back-ldap and > pcache and am expecting to be able to simulate a fronted authentication > process using ldapsearch to the solaris openldap proxy. The backend ldap > service is AD @ backendldap.core.dir.mycompany.com. the proxy box i will > refer to as openldapproxy (openldapproxy.core.dir.mycompany.com)" > > my database ldap section now looks like this :- > backendldap.core.dir.mycompany.com" > > database ldap > uri "ldap://backendldap.core.dir.mycompany.com" > suffix "ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com" > rootdn "dc=core,dc=dir,dc=mycompany,dc=com" > idassert-bind > bindmethod=simple binddn="cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com" credentials="password" > mode=self > > i am testing by running ldapsearch on the openldapproxy host itself in the > following manner :- > # /usr/local/bin/ldapsearch -x -h localhost -b > ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com employeeID=12345678 > > the proxied bind goes out to the backend AD as i have shown in the below > discussion. The response returned is :- > # filter: employeeID=12345678 > # requesting: ALL > # > # search result > search: 2 > result: 48 Inappropriate authentication > # numResponses: 1 > > Running slapd in diag mode i see the following in the debug output :- > do_bind: v3 anonymous bind > connection_get(11) > connection_get(11): got connid=1014 > connection_read(11): checking for input on id=1014 > ber_get_next > ber_get_next: tag 0x30 len 105 contents: > op tag 0x63, time 1272346583 > ber_get_next > conn=1014 op=1 do_search > ber_scanf fmt ({miiiib) ber: > >>> dnPrettyNormal: > <ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com> > => ldap_bv2dn(ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com,0) > <= ldap_bv2dn(ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com)=0 > => ldap_dn2bv(272) > <= ldap_dn2bv(ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com)=0 > => ldap_dn2bv(272) > <= ldap_dn2bv(ou=people,ou=eprofile,dc=core,dc=dir,dc=mycompany,dc=com)=0 > <<< dnPrettyNormal: > <ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com>, > <ou=people,ou=eprofile,dc=core,dc=dir,dc=mycompany,dc=com> > SRCH "ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com" 2 0 0 0 > 0 > ber_scanf fmt ({mm}) ber: > filter: (?=undefined) > ber_scanf fmt ({M}}) ber: > attrs: > ==> limits_get: conn=1014 op=1 self="[anonymous]" > this="ou=people,ou=eprofile,dc=core,dc=dir,dc=telstra,dc=com" > send_ldap_result: conn=1014 op=1 p=3 > send_ldap_result: err=48 matched="" text="" > send_ldap_response: msgid=2 tag=101 err=48 > Note the anonymous bind, I need this to be a simply authenticated bind > using the idassert binddn and credentials > Note the "self="[anonymous]"............... I was expecting that it should > have been self=[USERID_THAT_RAN_THE_LDAPSEARCH] > > Regards Rep > On Tue, Apr 27, 2010 at 1:55 PM, <masarati(a)aero.polimi.it> wrote: > >> > Hi Folks, >> > >> > I am having troubles configuring openladp to my requirements. >> > >> > I am setting up an openldap server running on solaris 10 x86 to use as >> > a ldap proxy authentication server. >> > >> > My issue is that i cant get it to send authenticated simple binds to the >> > backend ldap system. I am running wireshark and when i ldapsearch direct >> > to >> > the backend ldap i see a bind which looks like this :- >> > Lightweight-Directory-Access-Protocol >> > LDAPMessage bindRequest(1) >> > "cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com" simple >> > messageID: 1 >> > protocolOp: bindRequest (0) >> > bindRequest >> > version: 3 >> > name: >> > cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com >> > authentication: simple (0) >> > simple: 384174656C73747261316732 >> > >> > However when i initiate an ldapsearch to my local solaris slapd and >> > capture >> > the proxied backldap bind to the backend ldap system it looks like this >> :- >> > Lightweight-Directory-Access-Protocol >> > LDAPMessage bindRequest(1) "<ROOT>" simple >> > messageID: 1 >> > protocolOp: bindRequest (0) >> > bindRequest >> > version: 3 >> > name: >> > authentication: simple (0) >> > simple: <MISSING> >> > >> > I am having trouble working out from the documentation if it should be >> > acl-bind or idassert-bind or some other option which influences the >> > backend >> > bind. I have tried both those to no avail. >> > Here is the "database ldap" section from my slapd.conf >> > >> > ####################################################################### >> > # ldap database definitions >> > ####################################################################### >> > database ldap >> > uri "ldap://backendldap.core.dir.mycompany.com" >> > suffix "ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com" >> > rootdn "dc=core,dc=dir,dc=mycompany,dc=com" >> > acl-bind bindmethod=simple >> > binddn="cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com" >> > credentials="password" >> > idassert-bind bindmethod=simple >> > binddn="cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com" >> > credentials="password" >> >> The relevant directive is "idassert-bind", since you appear to be looking >> for an identity assertion. I hope what you posted was screwed up by the >> mailer: continuation lines must start with whitespace. What is missing >> above is the "mode=self" parameter to "idassert-bind". Try something like >> >> idassert-bind bindmethod=simple >> binddn="cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com" >> credentials="password" >> mode=self >> >> p. >> >> > overlay pcache >> > proxycache bdb 400 1 50 1200 >> > directory /var/openldap-data >> > cachesize 10000 >> > index cn,sn,uid pres,eq,sub >> > index objectclass eq >> > >> > proxycachequeries 400 >> > proxyattrset 0 uid mail cn sn givenName >> > proxytemplate (uid=) 0 600 >> > proxytemplate (mail=) 0 600 >> > proxytemplate (&(uid=)(mail=)) 0 600 >> > >> > Any help would be greatly appreciated >> > >> > Regards Rep >> > >> >> >> >

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical April 2010