openldap-technical July 2011

openldap-technical@openldap.org

80 participants
92 discussions

Installing
by Dalen, van William 28 Jul '11

28 Jul '11

Hi, When i want to install OpenLDAP i began with install the deamon and utils with the command sudo apt-get install slapd ldap-utils I got an error. This is the output: Preconfiguring packages ... Unquoted string "pm" may clash with future reserved word at /usr/share/perl5/Deb conf/Element/Noninteractive/Boolean.pm line 5, <GEN1> line 1. Can't locate object method "new" via package "Debconf::Element::Noninteractive:: Boolean" (perhaps you forgot to load "Debconf::Element::Noninteractive::Boolean" ?) at /usr/share/perl5/Debconf/FrontEnd.pm line 68, <GEN1> line 1. (Reading database ... 52208 files and directories currently installed.) Unpacking slapd (from .../slapd_2.4.23-6ubuntu6_amd64.deb) ... Unquoted string "pm" may clash with future reserved word at /usr/share/perl5/Deb conf/Element/Noninteractive/Boolean.pm line 5, <GEN1> line 2. Can't locate object method "new" via package "Debconf::Element::Noninteractive:: Boolean" (perhaps you forgot to load "Debconf::Element::Noninteractive::Boolean" ?) at /usr/share/perl5/Debconf/FrontEnd.pm line 68, <GEN1> line 2. dpkg: error processing /var/cache/apt/archives/slapd_2.4.23-6ubuntu6_amd64.deb ( --unpack): subprocess new pre-installation script returned error exit status 9 Errors were encountered while processing: /var/cache/apt/archives/slapd_2.4.23-6ubuntu6_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) I am a newbie to Linux and OpenLAP. I don't know what this output means, so i can't solve the problem (for now). Please can anyone help me? With regards, William

3 2

cn=config configuration method
by Giles Coochey 28 Jul '11

28 Jul '11

I'm trying to get my head round configuring OpenLDAP 2.4 until Centos 6. So much documentation refers to slapd.conf Under Centos 6, it appears that cn=config is in use. So is reconfiguring OpenLDAP simply a case of editing the .ldif files in /etc/openldap/slapd.d Or should I be modifying the directory to reconfigure - presumably by some combination of slapadd etc... Thanks Giles

3 3

after restart slapd server I cannot search single record in ldap servers
by Marcin Więcek 28 Jul '11

28 Jul '11

Hello, I set up an slapd with slapd-meta backend. I have two Active Directory servers which don't share any portion of naming context. I would like to get one virtual domain. I configure it and it works fine until I restart slapd server. When I restart slapd server then I am unable to search in my ldap servers single record. When I search one single record (samAccountName=testdom1) then I have got 0 result. root@slapd:~# ldapsearch -b 'dc=dom,dc=com' -h 172.30.14.190 -p 389 -D 'cn=Manager,dc=dom,dc=com' -w secret '(samAccountName=testdom1)' # extended LDIF # # LDAPv3 # base <dc=dom,dc=com> with scope subtree # filter: (samAccountName=testdom1) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 root@slapd:~# In the log (full debug) I have: Jul 27 16:12:17 dom slapd[12096]: daemon: read active on 9 Jul 27 16:12:17 dom slapd[12096]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Jul 27 16:12:17 dom slapd[12096]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Jul 27 16:12:17 dom slapd[12096]: connection_get(9) Jul 27 16:12:17 dom slapd[12096]: connection_get(9): got connid=1000 Jul 27 16:12:17 dom slapd[12096]: connection_read(9): checking for input on id=1000 Jul 27 16:12:17 dom slapd[12096]: op tag 0x42, time 1311775937 Jul 27 16:12:17 dom slapd[12096]: ber_get_next on fd 9 failed errno=0 (Success) Jul 27 16:12:17 dom slapd[12096]: connection_read(9): input error=-2 id=1000, closing. Jul 27 16:12:17 dom slapd[12096]: connection_closing: readying conn=1000 sd=9 for close Jul 27 16:12:17 dom slapd[12096]: connection_close: deferring conn=1000 sd=9 Jul 27 16:12:17 dom slapd[12096]: conn=1000 op=2 do_unbind Jul 27 16:12:17 dom slapd[12096]: conn=1000 op=2 UNBIND Jul 27 16:12:17 dom slapd[12096]: connection_resched: attempting closing conn=1000 sd=9 Jul 27 16:12:17 dom slapd[12096]: connection_close: deferring conn=1000 sd=9 Jul 27 16:12:17 dom slapd[12096]: daemon: activity on 1 descriptor Jul 27 16:12:17 dom slapd[12096]: daemon: activity on: Jul 27 16:12:17 dom slapd[12096]: Jul 27 16:12:17 dom slapd[12096]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Jul 27 16:12:17 dom slapd[12096]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Jul 27 16:12:17 dom slapd[12096]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= Jul 27 16:12:17 dom slapd[12096]: connection_resched: attempting closing conn=1000 sd=9 Jul 27 16:12:17 dom slapd[12096]: connection_close: conn=1000 sd=9 Jul 27 16:12:17 dom slapd[12096]: =>meta_back_conn_destroy: fetching conn=1000 DN="cn=manager,dc=dom,dc=com" Jul 27 16:12:17 dom slapd[12096]: daemon: removing 9 Jul 27 16:12:17 dom slapd[12096]: conn=1000 fd=9 closed Then when I search full list of record (samAccountName=*) I have got full list of records from two ldap servers. root@slapd:~# ldapsearch -b 'dc=dom,dc=com' -h 172.30.14.190 -p 389 -D 'cn=Manager,dc=dom,dc=com' -w secret '(samAccountName=*)' # search result search: 2 result: 0 Success # numResponses: 39 # numEntries: 38 root@slapd:~# And this is the trick. From now... When I again search one single record I got correct result - until I restart slapd server again. I don't know what can be wrong. Any ideas? root@slapd:~# ldapsearch -b 'dc=dom,dc=com' -h 172.30.14.190 -p 389 -D 'cn=Manager,dc=dom,dc=com' -w secret '(samAccountName=testdom1)' # extended LDIF # # LDAPv3 # base <dc=dom,dc=com> with scope subtree # filter: (samAccountName=testdom1) # requesting: ALL # # testdom1, dom.com dn: cn=testdom1,dc=dom,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: USER cn: testdom1 givenName: testdom1 distinguishedName: cn=testdom1,dc=dom,dc=com INSTANCETYPE: 4 WHENCREATED: 20110726100434.0Z WHENCHANGED: 20110726160313.0Z DISPLAYNAME: testdom1 USNCREATED: 24630 USNCHANGED: 24756 name: testdom1 OBJECTGUID:: +ERwSjOp5Uex1n86v5CurA== USERACCOUNTCONTROL: 66048 BADPWDCOUNT: 0 CODEPAGE: 0 COUNTRYCODE: 0 BADPASSWORDTIME: 129561692315625000 LASTLOGOFF: 0 LASTLOGON: 129561692402968750 PWDLASTSET: 129561697935781250 PRIMARYGROUPID: 513 OBJECTSID:: AQUAAAAAAAUVAAAAMkafw9OC5FYbZ2/5UwQAAA== ACCOUNTEXPIRES: 9223372036854775807 LOGONCOUNT: 0 SAMACCOUNTNAME: testdom1 SAMACCOUNTTYPE: 805306368 USERPRINCIPALNAME: testdom1(a)dom1.com OBJECTCATEGORY: CN=Person,CN=Schema,CN=Configuration,DC=dom1,DC=com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 root@slapd:~# The log: Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to "cn=testdom1,dc=dom,dc=com" "BADPWDCOUNT" requested Jul 27 16:19:22 dom slapd[12096]: <= root access granted Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access granted by manage(=mwrscxd) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in cache (CODEPAGE) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to "cn=testdom1,dc=dom,dc=com" "CODEPAGE" requested Jul 27 16:19:22 dom slapd[12096]: <= root access granted Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access granted by manage(=mwrscxd) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in cache (COUNTRYCODE) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to "cn=testdom1,dc=dom,dc=com" "COUNTRYCODE" requested Jul 27 16:19:22 dom slapd[12096]: <= root access granted Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access granted by manage(=mwrscxd) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in cache (BADPASSWORDTIME) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to "cn=testdom1,dc=dom,dc=com" "BADPASSWORDTIME" requested Jul 27 16:19:22 dom slapd[12096]: <= root access granted Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access granted by manage(=mwrscxd) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in cache (LASTLOGOFF) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to "cn=testdom1,dc=dom,dc=com" "LASTLOGOFF" requested Jul 27 16:19:22 dom slapd[12096]: <= root access granted Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access granted by manage(=mwrscxd) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in cache (LASTLOGON) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to "cn=testdom1,dc=dom,dc=com" "LASTLOGON" requested Jul 27 16:19:22 dom slapd[12096]: <= root access granted Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access granted by manage(=mwrscxd) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in cache (PWDLASTSET) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to "cn=testdom1,dc=dom,dc=com" "PWDLASTSET" requested Jul 27 16:19:22 dom slapd[12096]: <= root access granted Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access granted by manage(=mwrscxd) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in cache (PRIMARYGROUPID) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to "cn=testdom1,dc=dom,dc=com" "PRIMARYGROUPID" requested Jul 27 16:19:22 dom slapd[12096]: <= root access granted Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access granted by manage(=mwrscxd) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in cache (OBJECTSID) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to "cn=testdom1,dc=dom,dc=com" "OBJECTSID" requested Jul 27 16:19:22 dom slapd[12096]: <= root access granted Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access granted by manage(=mwrscxd) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in cache (ACCOUNTEXPIRES) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to "cn=testdom1,dc=dom,dc=com" "ACCOUNTEXPIRES" requested Jul 27 16:19:22 dom slapd[12096]: <= root access granted Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access granted by manage(=mwrscxd) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in cache (LOGONCOUNT) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to "cn=testdom1,dc=dom,dc=com" "LOGONCOUNT" requested Jul 27 16:19:22 dom slapd[12096]: <= root access granted Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access granted by manage(=mwrscxd) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in cache (SAMACCOUNTNAME) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to "cn=testdom1,dc=dom,dc=com" "SAMACCOUNTNAME" requested Jul 27 16:19:22 dom slapd[12096]: <= root access granted Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access granted by manage(=mwrscxd) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in cache (SAMACCOUNTTYPE) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to "cn=testdom1,dc=dom,dc=com" "SAMACCOUNTTYPE" requested Jul 27 16:19:22 dom slapd[12096]: <= root access granted Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access granted by manage(=mwrscxd) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in cache (USERPRINCIPALNAME) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to "cn=testdom1,dc=dom,dc=com" "USERPRINCIPALNAME" requested Jul 27 16:19:22 dom slapd[12096]: <= root access granted Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access granted by manage(=mwrscxd) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in cache (OBJECTCATEGORY) Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to "cn=testdom1,dc=dom,dc=com" "OBJECTCATEGORY" requested Jul 27 16:19:22 dom slapd[12096]: <= root access granted Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access granted by manage(=mwrscxd) Jul 27 16:19:22 dom slapd[12096]: conn=1003 op=1 ENTRY dn="cn=testdom1,dc=dom,dc=com" Jul 27 16:19:22 dom slapd[12096]: <= send_search_entry: conn 1003 exit. Jul 27 16:19:22 dom slapd[12096]: send_ldap_result: conn=1003 op=1 p=3 Jul 27 16:19:22 dom slapd[12096]: send_ldap_result: err=0 matched="" text="" Jul 27 16:19:22 dom slapd[12096]: send_ldap_response: msgid=2 tag=101 err=0 Jul 27 16:19:22 dom slapd[12096]: conn=1003 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Jul 27 16:19:22 dom slapd[12096]: daemon: activity on 1 descriptor Jul 27 16:19:22 dom slapd[12096]: daemon: activity on: Jul 27 16:19:22 dom slapd[12096]: 9r Jul 27 16:19:22 dom slapd[12096]: Jul 27 16:19:22 dom slapd[12096]: daemon: read active on 9 Jul 27 16:19:22 dom slapd[12096]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Jul 27 16:19:22 dom slapd[12096]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Jul 27 16:19:22 dom slapd[12096]: connection_get(9) Jul 27 16:19:22 dom slapd[12096]: connection_get(9): got connid=1003 Jul 27 16:19:22 dom slapd[12096]: connection_read(9): checking for input on id=1003 Jul 27 16:19:22 dom slapd[12096]: op tag 0x42, time 1311776362 Jul 27 16:19:22 dom slapd[12096]: ber_get_next on fd 9 failed errno=0 (Success) Jul 27 16:19:22 dom slapd[12096]: connection_read(9): input error=-2 id=1003, closing. Jul 27 16:19:22 dom slapd[12096]: connection_closing: readying conn=1003 sd=9 for close Jul 27 16:19:22 dom slapd[12096]: connection_close: deferring conn=1003 sd=9 Jul 27 16:19:22 dom slapd[12096]: conn=1003 op=2 do_unbind Jul 27 16:19:22 dom slapd[12096]: conn=1003 op=2 UNBIND Jul 27 16:19:22 dom slapd[12096]: connection_resched: attempting closing conn=1003 sd=9 Jul 27 16:19:22 dom slapd[12096]: connection_close: deferring conn=1003 sd=9 Jul 27 16:19:22 dom slapd[12096]: daemon: activity on 1 descriptor Jul 27 16:19:22 dom slapd[12096]: daemon: activity on: Jul 27 16:19:22 dom slapd[12096]: Jul 27 16:19:22 dom slapd[12096]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Jul 27 16:19:22 dom slapd[12096]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Jul 27 16:19:22 dom slapd[12096]: connection_resched: attempting closing conn=1003 sd=9 Jul 27 16:19:22 dom slapd[12096]: connection_close: conn=1003 sd=9 Jul 27 16:19:22 dom slapd[12096]: =>meta_back_conn_destroy: fetching conn=1003 DN="cn=manager,dc=dom,dc=com" Jul 27 16:19:22 dom slapd[12096]: daemon: removing 9 Jul 27 16:19:22 dom slapd[12096]: conn=1003 fd=9 closed My OpenLDAP version: root@slapd:~# slapd -V @(#) $OpenLDAP: slapd 2.4.23 (Jul 26 2011 14:53:23) $ root@slapd:/root/openldap-2.4.23/servers/slapd My slapd.conf: root@slapd:~# cat /usr/local/etc/openldap/slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args # Load dynamic backend modules: # modulepath /usr/local/libexec/openldap # moduleload back_bdb.la # moduleload back_hdb.la # moduleload back_ldap.la loglevel 0xFFFF access to * by * read ####################################################################### # database definitions ####################################################################### database meta suffix "dc=dom,dc=com" rootdn "cn=Manager,dc=dom,dc=com" rootpw secret chase-referrals no #nretries forever nretries 3 # 1 sec timeout for binds bind-timeout 1000000 #norefs true dncache-ttl DISABLED conn-ttl 90 idle-timeout 1m30s onerr CONTINUE # ldap1 uri "ldap://dc1.dom1.com:389/dc=dom,dc=com" suffixmassage "dc=dom,dc=com" "cn=Users,dc=dom1,dc=com" idassert-bind bindmethod=simple binddn="cn=LDAPconnector,cn=Users,dc=dom1,dc=com" credentials="pass" mode=none flags=non-prescriptive # ldap2 uri "ldap://dc2.dom2.com:389/dc=dom,dc=com" suffixmassage "dc=dom,dc=com" "cn=Users,dc=dom2,dc=com" idassert-bind bindmethod=simple binddn="cn=LDAPconnector2,cn=Users,dc=dom2,dc=com" credentials="pass" mode=none flags=non-prescriptive root@slapd:~# King regards, Marcin

2 1

Excessive logging at stats loglevel: any useful alternative to none?
by Nick Urbanik 28 Jul '11

28 Jul '11

Dear Folks, We are running openldap-servers-2.3.43-12.el5_6.7 on CentOS 5 on four HP blades. We have only stats loglevel: grep level /etc/openldap/slapd.conf loglevel stats ...but these servers are rather busy, and the logfiles are massive: # ls -lSr | tail -n4 -rw------- 1 root root 7160148590 Jul 28 10:48 ldap -rw------- 1 root root 24102619198 Jul 26 04:02 ldap.3 -rw------- 1 root root 25034865261 Jul 27 04:02 ldap.2 -rw------- 1 root root 25504838803 Jul 28 04:02 ldap.1 and are threatening to fill the disk. We want *some* logging, but we don't want too much. Can anyone suggest a useful log level here? It would be great to have some control over the verbosity of logging of each subsystem; for example, we cannot log any information about syncrepl, as that would totally fill our disks. -- Nick Urbanik http://nicku.org 808-71011 nick.urbanik(a)optusnet.com.au GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24 I disclaim, therefore I am.

1 1

Translucent overlay
by Conger,Keith 25 Jul '11

25 Jul '11

Hi List Members I'm using OpenLDAP in a translucent overlay configuration to store the attributes for our custom schema. All other attributes come from the backend LDAP server(ActiveDirectory). When I try to modify an attribute that is stored on the backend LDAP Server(ActiveDirectory), the change is stored in the translucent overlays database and not written to the backend LDAP server(ActiveDirectory). Is it possible for a client connected to OpenLDAP to modify an attribute in the backend LDAP server(ActiveDirectory)? The attribute I'm mainly concerned with is "unicodePwd" which Active Directory uses for password storage. If this isn't possible, does anyone have a different approach I'm missing? Background: Were creating a password reset web app that I'd like to only communicate to OpenLDAP. OpenLDAP will store of password question/answer along with some other identity verification data, but the password needs to be set within Active Directory since there are Desktops authenticating users. Thanks for any help -- Keith Conger Enterprise Systems Administrator Onondaga Community College 4585 West Seneca Turnpike Syracuse, N.Y. 13215-4585 Phone: 315.498.2767 Email/JID: congerk(a)sunyocc.edu Web: http://myhome.sunyocc.edu/~congerk/

1 0

client LDAP configuration issue
by Christophe Thibault 25 Jul '11

25 Jul '11

Hello, I'm currently encountering a weird issue I don't understand. I'm working on this problem since 3 days now, withount any clue. My problem: I built a sample client that connect to a LDAP server, to test authentication. It works fine for LDAP, but fails for LDAPS, as long as I don't provide the right certs. The issue is that I tried setting the TLS_CACERT in different locations without success (I tried in the system /etc/ldap/ldap.conf, custom location by setting the LDAPCONF env variable, setting environment variable LDAPTLS_CACERT, etc.) What is weird (for me) is that using the same ldap.conf (global or user), or environment variable works for the ldapsearch client that comes witth the openldap distribution. More strange, is that setting the TLS_REQCERT parameter (either in ldap.conf or in an environment variable) works for my custom client. In my client, displaying I probably missed something, do I need to explicitely call some function to initialize these parameters? Is there any way to trace calls to these internal functions that should read the ldap.conf or environment variables? Any idead is welcome! thanks, chris

2 1

SASL Pass-through password reset
by Conger,Keith 25 Jul '11

25 Jul '11

Hi, Does anyone know if its possible to reset a password when using OpenLDAP with SASL pass-through to an 2008 Active Directory either through GSSAPI or LDAPS. I've read that you you can change a password, but we need to be able to reset with an administrative level account when a user forgets their password. Thanks in Advance, Keith -- Keith Conger

1 0

SlapD is using more CPU
by arun.sasi1＠wipro.com 25 Jul '11

25 Jul '11

Hello Team, Whenever the number of search increase to the master server... slapd is utilizing more about more than 100%... What could be the reason and also is there any bench mark defined... Whenver it goes 100% slapd server is getting stopped... Thanks & Regards, Arun Sasi V Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

3 2

Active Directory OpenLDAP Proxy
by Marc Schöchlin 25 Jul '11

25 Jul '11

Hello OpenLDAP Users, i setup da openldap-instance as described at https://help.ubuntu.com/10.04/serverguide/C/openldap-server.html. It seems that the Objectclass "olcOverlayConfig" is missed - where can i find that objectclass? Is there a complete manual available which describes how to setup a active directory proxy server? Is it possible to modify the configuration using a ldap browser like active directory studio? To use that server to be a proxy to a active directory server i am trying to add the following configuration: proxy2.ldif --- dn: olcDatabase={2}ldap objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcSuffix: dc=proxy,dc=foobar,dc=de olcRootDN: dc=foobar,dc=local olcDbURI: "ldap://10.45.2.11:389" dn: olcOverlay={0}pcache objectClass: olcOverlayConfig objectClass: olcPcacheConfig olcOverlay: {0}pcache olcPcache: bdb 100000 1 1000 100 olcPcacheAttrset: 0 mail postalAddress telephoneNumber olcPcacheTemplate: "(sn=)" 0 3600 0 0 0 olcPcacheTemplate: "(&(sn=)(givenName=))" 0 3600 0 0 0 olcPcacheTemplate: "(&(departmentNumber=)(secretary=))" 0 3600 dn: olcDatabase={0}hdb objectClass: olcHdbConfig objectClass: olcPcacheDatabase olcDatabase: {0}hdb olcDbDirectory: ./proxy-db.2.a olcDbCacheSize: 20 olcDbIndex: objectClass eq olcDbIndex: cn,sn,uid,mail pres,eq,sub --- LDAP-ADD Complains: # ldapadd -vvv -Y EXTERNAL -H ldapi:/// -f /etc/ldap/proxy.ldif ldap_initialize( ldapi:///??base ) SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 add objectClass: olcDatabaseConfig olcLDAPConfig add olcDatabase: {2}ldap add olcSuffix: dc=proxy,dc=foobar,dc=de add olcRootDN: dc=foobar,dc=local add olcDbURI: "ldap://10.41.2.12:389" adding new entry "olcDatabase={2}ldap" ldap_add: Invalid syntax (21) additional info: objectClass: value #1 invalid per syntax I

2 2

retry: counter not reaching zero, continuing on
by ml+openldap＠esmtp.org 23 Jul '11

23 Jul '11

While trying to determine how syncrepl behaves in various error conditions, I encountered an unexpected behaviour in which the retry specification doesn't seem to work. A MASTER is set up to use push replication to a REPLICA as follows: database ldap hidden on suffix "" rootdn "cn=slapd-ldap" uri ldap://REPLICA/ lastmod on restrict all sync_use_subentry true acl-bind bindmethod=simple binddn="cn=Monitor" credentials=password syncrepl rid=001 provider=ldapi://%2Fvar%2Frun%2Fldapi binddn="cn=Manager" bindmethod=simple credentials=passwd searchbase="" type=refreshAndPersist retry="5 5 60 +" When I stop the REPLICA and add an entry on the MASTER, then the MASTER is retrying every 5s and claims that 4 (sometimes 3) retries are left: Jul 22 13:12:52 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:12:57 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (3 retries left) Jul 22 13:13:02 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:07 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (3 retries left) Jul 22 13:13:12 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:17 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:22 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:28 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:33 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:38 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:43 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:48 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:53 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:58 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) When I start REPLICA again, syncrepl succeeds. Do I have to set some other option such that the retry specification is actually used? That is, try every 5s for 5 times, then try every 60s. Or is the retry logic dependent on the error syncrepl encounters? The full log for one failed retry is: conn=1004 op=0 BIND dn="cn=manager" method=128 conn=1004 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0 conn=1004 op=0 RESULT tag=97 err=0 text= conn=1004 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" conn=1004 op=1 SRCH attr=* + srs csn 20110722201233.471069Z#000000#001#000000 log csn 20110722201233.471069Z#000000#001#000000 cmp 0, too old log csn 20110722201252.820971Z#000000#001#000000 Entry uid=user68,ou=People,dc=example,dc=com CSN 20110722201233.471069Z#000000#001#000000 older or equal to ctx 20110722201233.471069Z#000000#001#000000 syncprov_search_response: cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=001 inserted UUID 95b838a2-4b55-4bcc-8b00-be329b138db0 conn=1004 fd=15 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) syncrepl_entry: rid=001 be_search (52) syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com null_callback : error code 0x34 syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52) syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed (52) do_syncrepl: rid=001 rc 52 retrying (4 retries left) conn=1004 op=2 UNBIND conn=1004 fd=15 closed connection_read(15): no connection! connection_read(15): no connection!

2 1

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical July 2011