openldap-software

openldap-software@openldap.org

2719 discussions

slap_sl_malloc failed, using ch_malloc
by Marcel Chastain 31 Dec '07

31 Dec '07

Hello all, I have a set of 11 servers setup with syncrepl, all running openldap 2.4.6: 1 syncrepl provider, and 10 consumers. The provider is having a hard time staying up for more than 18-24 hours at a time - it will either stop responding, or just die. I'm working on getting the debug log output right before it dies, but for now, about 60% of my provider's log is filled with messages such as this: Dec 28 15:04:15 ldapm01 slapd[10335]: slap_sl_malloc of 32 bytes failed, using ch_malloc Dec 28 15:04:15 ldapm01 slapd[10335]: slap_sl_malloc of 56 bytes failed, using ch_malloc Dec 28 15:04:15 ldapm01 slapd[10335]: slap_sl_malloc of 56 bytes failed, using ch_malloc The logs are quite copious, but I haven't seen anything else indicative of an error. I've been researching for over a week, and attempting to tweak my settings, but I can't find any data on this. Does this have anything to do with the 'searchstack' setting? I looked in the source code, and noticed that it didn't seem like a terrible error, but this is the only output I have for the time being. Any help would be greatly appreciated, as these are production machines. If the information I provided doesn't help, please tell me what you would need to understand the problem better. ########Provider: database bdb suffix "dc=testbox,dc=net" directory "/var/lib/ldap/master/" mode 0600 cachesize 20000 idlcachesize 60000 index objectClass eq index ou eq index entryCSN,entryUUID eq index uid,uidNumber,gidNumber eq idletimeout 30 overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 1000 syncprov-reloadhint TRUE lastmod on ############Consumer: database bdb suffix "dc=testbox,dc=net" directory "/var/lib/ldap/slave/" mode 0600 cachesize 10000 idlcachesize 30000 #### Consumer checkpoint 512 5 index uid,uidNumber,gidNumber,member pres,eq index ou,objectClass,entryCSN,entryUUID,homeDirectory,dc,contextCSN,associatedDomain,cn eq idletimeout 30 lastmod on syncrepl rid=233 provider=ldaps://ldapm01.testbox.net type=refreshOnly retry="10 100 30 +" interval="00:00:05:00" searchbase="dc=eigbox,dc=net" filter="(!(entryDN:dnSubtreeMatch:=ou=unwanted,ou=pub,dc=testbox,dc=net))" scope=sub attrs="*,+" schemachecking=off bindmethod=simple binddn="cn=sync-user,dc=testbox,dc=net" credentials=secret ############# Thanks in advance! ------------------------------------------ Marcel Chastain Senior Systems Administrator Endurance International Group Email: Marcel.Chastain(a)Gmail.com ------------------------------------------

4 5

Segmentation fault
by sf.techguy＠gmail.com 29 Dec '07

29 Dec '07

[ I posted this to the OpenLDAP tech list, and they suggested re-posting here. It was suggested to upgrade to a newer version of OpenLDAP, but for various reasons, upgrading to is problematic, and I'm willing to endure an unreasonable amount of pain to try to get it working with my ancient version. :) ] Running OpenLDAP 2.2.19 on Darwin kernel v. 8.11.1, and when I issue: /usr/sbin/slapcat -d 5 -v -l /Users/localadmin/Desktop/bkup.ldif I get the following output: <snip>... # id=00000070 entry_decode: "cn=raidgroup,cn=groups,dc=fileserver,dc=mydomain,dc=private" <= entry_decode(cn=raidgroup,cn=groups,dc=fileserver,dc=mydomain,dc=private) # id=00000071 slapcat shutdown: initiated Segmentation fault ...</snip> Anyone know how I can track down what's causing this segmentation fault?

2 1

Chaining ppolicy state attributes
by Ben Spencer 28 Dec '07

28 Dec '07

Looking at http://www.openldap.org/lists/openldap-software/200701/msg00149.html and http://www.openldap.org/lists/openldap-software/200704/msg00050.html it would seem as if it might be impossible/tricky to chain state related ppolicy attribute (ex: pwdAccountLockedTime) updates of a consumer to the master and then back down to the other consumers in OpenLDAP 2.3 Has anyone successfully done this with OpenLDAP 2.3 (2.3.39)? Are these attributes exchanged in 2.4 in a multimaster configuration? Looking at the debug, the update of these state attributes are updated locally via bdb_modify_internal. I am guessing that these are not exposed to the slapo-chain overlay as a result of that internal update. Thanks benji --- Benji Spencer System Administrator Ph: 312-329-2288

3 3

OpenLDAP 2.4.7 Bug?
by Allan E. Johannesen 28 Dec '07

28 Dec '07

I'm not runing a 2.3 server for comparison, but is this a bug or is it expected behavior to have this sort of error? In a program, which had constructed the ** due to a missing first name, it also was found to break the connection to the server... CCC5:~> ldapsearch '(cn=** VERNON-GERSTENFELD*)' SASL/GSSAPI authentication started SASL username: aej(a)WPI.EDU SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <dc=WPI, dc=EDU> (default) with scope subtree # filter: (cn=** VERNON-GERSTENFELD*) # requesting: ALL # # extended result response extended: 1.3.6.1.4.1.1466.20036 result: 2 Protocol error text: unexpected data in PDU # numResponses: 1 # numExtended: 1 CCC5:~> ldapsearch -VV ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.7 (Dec 17 2007 09:23:50) $ aej@CCC1.WPI.EDU:/tools/src/openldap/RHEL4-i686/openldap-2.4.7/clients/tools (LDAP library: OpenLDAP 20407)

5 9

How to generate an LDIF file?
by canaparo 27 Dec '07

27 Dec '07

Hi everyone, I have to write a program in C++ that generates a valid LDIF file (both related to the LDIF syntax and LDAP schema). It is possibile to do without having a running LDAP server? Any suggestion for libraries that helps for this task? (e.g. something similar to Xerces-C++ for XML). Thanks, Marco

4 4

rebind-as-user for reconnecting broken backend connection
by Andrew Bidwell 24 Dec '07

24 Dec '07

Hi, I'm using openldap 2.4.7 as a proxy to backend ldap servers. I've enabled "rebind-as-user" ("rebind-as-user yes" on "database ldap" definition) to allow for connections to reconnect when the backend is restarted or connection is lost. Which works fine in certain situations, but not in others. It seems that when a search operation (I haven't tested any other operations, but I can replicate a search operation) is performed when the backend is down, and then performed again when the backend is back up (both over an already bound connection), a rebind operation is not sent from openldap to the backend. But if no searches were performed against openldap while the backend was down and came up again and a search was performed against openldap, the rebind is successful. To explain I'll detail the scenarios: This works fine - 1) client binds 2) ldap search 3) backend is restarted 4) ldap search (bind operation is made from openldap to backend to re-establish authenticated connection) This fails - 1) client binds 2) ldap search 3) backend is down 4) ldap search (fails as expected) 5) backend is up 6) ldap search (no bind operation is made, search is performed on unauthenticated connection) Given that the rebind-as-user is specified, and that the client connection to openldap is still valid, I would have expected openldap to rebind at step 6 of the failing scenario as it does in step 4 of the working scenario. Is this behaviour expected, or is there a configuration option that will allow a rebind to take place in my failing case? I apologise if this question has been asked before - I searched through the archives, but couldn't find any related threads. Please let me know if you require further details. Thanks for your help! Andrew

1 0

Re: Issue using ldapadd
by Gavin Henry 21 Dec '07

21 Dec '07

<quote who="Jonathan Wage"> > Uncommented and restarted ldap with the following command: > > sudo ./slapd -d 256 -f /private/etc/openldap/slapd.conf Can you start up with -d -1 and just paste the first say 50 lines. and CC your reply to openldap-software(a)openldap.org > > Then when I run this command: > > sudo ldapadd -x -D "cn=Manager,dc=example,dc=com" -W -f example.ldif > > I get this in the screen with slapd running: > > conn=0 fd=12 ACCEPT from IP=127.0.0.1:64609 (IP=0.0.0.0:389) > conn=0 op=0 BIND dn="cn=Manager,dc=example,dc=com" method=128 > conn=0 op=0 RESULT tag=97 err=49 text= > conn=0 fd=12 closed (connection lost) > > The error code translates to incorrect DN or password. > > - Jon > > On Dec 21, 2007 1:52 PM, Gavin Henry <ghenry(a)suretecsystems.com> wrote: > >> Uncommment: >> >> # modulepath /usr/libexec/openldap >> # moduleload back_bdb.la >> >> -- >> Kind Regards, >> >> Gavin Henry. >> Managing Director. >> >> T +44 (0) 1224 279484 >> M +44 (0) 7930 323266 >> F +44 (0) 1224 824887 >> E ghenry(a)suretecsystems.com >> >> Open Source. Open Solutions(tm). >> >> http://www.suretecsystems.com/ >> >> <quote who="Jonathan Wage"> >> > When I start slapd like you said above I am able to see the logs. I >> then >> > run >> > the same command where I get the invalid credentials and I get the >> > following: >> > >> > ------------------ >> > >> > daemon: activity on 1 descriptor >> > daemon: listen=7, new connection on 13 >> > daemon: added 13r >> > conn=1 fd=13 ACCEPT from IP=127.0.0.1:63502 (IP=0.0.0.0:389) >> > daemon: select: listen=6 active_threads=0 tvp=NULL >> > daemon: select: listen=7 active_threads=0 tvp=NULL >> > daemon: activity on 1 descriptor >> > daemon: activity on: 13r >> > daemon: read activity on 13 >> > connection_get(13) >> > connection_get(13): got connid=1 >> > connection_read(13): checking for input on id=1 >> > ber_get_next >> > ldap_read: want=8, got=8 >> > 0000: 30 2e 02 01 01 60 29 02 >> > 0....`). >> > ldap_read: want=40, got=40 >> > 0000: 01 03 04 1c 63 6e 3d 4d 61 6e 61 67 65 72 2c 64 >> > ....cn=Manager,d >> > 0010: 63 3d 65 78 61 6d 70 6c 65 2c 64 63 3d 63 6f 6d >> > c=example,dc=com >> > 0020: 80 06 73 65 63 72 65 74 >> > ..secret >> > ber_get_next: tag 0x30 len 46 contents: >> > ber_dump: buf=0x003451d0 ptr=0x003451d0 end=0x003451fe len=46 >> > 0000: 02 01 01 60 29 02 01 03 04 1c 63 6e 3d 4d 61 6e >> > ...`).....cn=Man >> > 0010: 61 67 65 72 2c 64 63 3d 65 78 61 6d 70 6c 65 2c >> > ager,dc=example, >> > 0020: 64 63 3d 63 6f 6d 80 06 73 65 63 72 65 74 >> > dc=com..secret >> > ber_get_next >> > ldap_read: want=8 error=Resource temporarily unavailable >> > ber_get_next on fd 13 failed errno=35 (Resource temporarily >> unavailable) >> > daemon: select: listen=6 active_threads=0 tvp=NULL >> > daemon: select: listen=7 active_threads=0 tvp=NULL >> > do_bind >> > ber_scanf fmt ({imt) ber: >> > ber_dump: buf=0x003451d0 ptr=0x003451d3 end=0x003451fe len=43 >> > 0000: 60 29 02 01 03 04 1c 63 6e 3d 4d 61 6e 61 67 65 >> > `).....cn=Manage >> > 0010: 72 2c 64 63 3d 65 78 61 6d 70 6c 65 2c 64 63 3d >> > r,dc=example,dc= >> > 0020: 63 6f 6d 80 06 73 65 63 72 65 74 >> > com..secret >> > ber_scanf fmt (m}) ber: >> > ber_dump: buf=0x003451d0 ptr=0x003451f6 end=0x003451fe len=8 >> > 0000: 00 06 73 65 63 72 65 74 >> > ..secret >> >>>> dnPrettyNormal: <cn=Manager,dc=example,dc=com> >> > => ldap_bv2dn(cn=Manager,dc=example,dc=com,0) >> > <= ldap_bv2dn(cn=Manager,dc=example,dc=com)=0 >> > => ldap_dn2bv(272) >> > <= ldap_dn2bv(cn=Manager,dc=example,dc=com)=0 >> > => ldap_dn2bv(272) >> > <= ldap_dn2bv(cn=manager,dc=example,dc=com)=0 >> > <<< dnPrettyNormal: <cn=Manager,dc=example,dc=com>, >> > <cn=manager,dc=example,dc=com> >> > do_bind: version=3 dn="cn=Manager,dc=example,dc=com" method=128 >> > conn=1 op=0 BIND dn="cn=Manager,dc=example,dc=com" method=128 >> > ==> bdb_bind: dn: cn=Manager,dc=example,dc=com >> > bdb_dn2entry("cn=manager,dc=example,dc=com") >> > => bdb_dn2id("dc=example,dc=com") >> > <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found >> > (-30990) >> > send_ldap_result: conn=1 op=0 p=3 >> > send_ldap_result: err=49 matched="" text="" >> > send_ldap_response: msgid=1 tag=97 err=49 >> > ber_flush: 14 bytes to sd 13 >> > 0000: 30 0c 02 01 01 61 07 0a 01 31 04 00 04 00 >> > 0....a...1.... >> > ldap_write: want=14, written=14 >> > 0000: 30 0c 02 01 01 61 07 0a 01 31 04 00 04 00 >> > 0....a...1.... >> > conn=1 op=0 RESULT tag=97 err=49 text= >> > daemon: activity on 1 descriptor >> > daemon: activity on: 13r >> > daemon: read activity on 13 >> > connection_get(13) >> > connection_get(13): got connid=1 >> > connection_read(13): checking for input on id=1 >> > ber_get_next >> > ldap_read: want=8, got=0 >> > >> > ber_get_next on fd 13 failed errno=0 (Undefined error: 0) >> > connection_read(13): input error=-2 id=1, closing. >> > connection_closing: readying conn=1 sd=13 for close >> > connection_close: deferring conn=1 sd=13 >> > daemon: select: listen=6 active_threads=0 tvp=NULL >> > daemon: select: listen=7 active_threads=0 tvp=NULL >> > daemon: activity on 1 descriptor >> > daemon: waked >> > daemon: select: listen=6 active_threads=0 tvp=NULL >> > daemon: select: listen=7 active_threads=0 tvp=NULL >> > connection_resched: attempting closing conn=1 sd=13 >> > connection_close: conn=1 sd=13 >> > daemon: removing 13 >> > conn=1 fd=13 closed (connection lost) >> > >> > - Jon >> > >> > On Dec 21, 2007 10:54 AM, Gavin Henry <ghenry(a)suretecsystems.com> >> wrote: >> > >> >> <quote who="Jonathan Wage"> >> >> > Here is my slapd.conf >> >> > >> >> > # >> >> > # See slapd.conf(5) for details on configuration options. >> >> > # This file should NOT be world readable. >> >> > # >> >> > include /private/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 /private/var/db/openldap/run/slapd.pid >> >> > argsfile /private/var/db/openldap/run/slapd.args >> >> > >> >> > # Load dynamic backend modules: >> >> > # modulepath /usr/libexec/openldap >> >> > # moduleload back_bdb.la >> >> > # moduleload back_ldap.la >> >> > # moduleload back_ldbm.la >> >> > # moduleload back_passwd.la >> >> > # moduleload back_shell.la >> >> > >> >> > # Sample security restrictions >> >> > # Require integrity protection (prevent hijacking) >> >> > # Require 112-bit (3DES or better) encryption for updates >> >> > # Require 63-bit encryption for simple bind >> >> > # security ssf=1 update_ssf=112 simple_bind=64 >> >> > >> >> > # Sample access control policy: >> >> > # Root DSE: allow anyone to read it >> >> > # Subschema (sub)entry DSE: allow anyone to read it >> >> > # Other DSEs: >> >> > # Allow self write access >> >> > # Allow authenticated users read access >> >> > # Allow anonymous users to authenticate >> >> > # Directives needed to implement policy: >> >> > # access to dn.base="" by * read >> >> > # access to dn.base="cn=Subschema" by * read >> >> > # access to * >> >> > # by self write >> >> > # by users read >> >> > # by anonymous auth >> >> > # >> >> > # if no access controls are present, the default policy >> >> > # allows anyone and everyone to read anything but restricts >> >> > # updates to rootdn. (e.g., "access to * by * read") >> >> > # >> >> > # rootdn can always read and write EVERYTHING! >> >> > >> >> > >> ####################################################################### >> >> > # BDB database definitions >> >> > >> ####################################################################### >> >> > >> >> > database bdb >> >> > suffix "dc=example,dc=com" >> >> > rootdn "cn=Manager,dc=example,dc=com" >> >> > # Cleartext passwords, especially for the rootdn, should >> >> > # be avoid. See slappasswd(8) and slapd.conf(5) for details. >> >> > # Use of strong authentication encouraged. >> >> > rootpw secret >> >> > # The database directory MUST exist prior to running slapd AND >> >> > # should only be accessible by the slapd and slap tools. >> >> > # Mode 700 recommended. >> >> > directory /private/var/db/openldap/openldap-data >> >> > # Indices to maintain >> >> > index objectClass eq >> >> > >> >> > >> >> > Which logs are you referring to? The openldap log? >> >> >> >> Start slapd by hand with -d -1 >> >> >> >> and then bind via ldapsearch. >> >> >> >> >> >> >> > >> > >> > -- >> > Jonathan Wage >> > http://www.jwage.com >> > http://www.centresource.com >> > >> >> > > > -- > Jonathan Wage > http://www.jwage.com > http://www.centresource.com >

2 3

Re: Issue using ldapadd
by Gavin Henry 21 Dec '07

21 Dec '07

Uncommment: # modulepath /usr/libexec/openldap # moduleload back_bdb.la -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ <quote who="Jonathan Wage"> > When I start slapd like you said above I am able to see the logs. I then > run > the same command where I get the invalid credentials and I get the > following: > > ------------------ > > daemon: activity on 1 descriptor > daemon: listen=7, new connection on 13 > daemon: added 13r > conn=1 fd=13 ACCEPT from IP=127.0.0.1:63502 (IP=0.0.0.0:389) > daemon: select: listen=6 active_threads=0 tvp=NULL > daemon: select: listen=7 active_threads=0 tvp=NULL > daemon: activity on 1 descriptor > daemon: activity on: 13r > daemon: read activity on 13 > connection_get(13) > connection_get(13): got connid=1 > connection_read(13): checking for input on id=1 > ber_get_next > ldap_read: want=8, got=8 > 0000: 30 2e 02 01 01 60 29 02 > 0....`). > ldap_read: want=40, got=40 > 0000: 01 03 04 1c 63 6e 3d 4d 61 6e 61 67 65 72 2c 64 > ....cn=Manager,d > 0010: 63 3d 65 78 61 6d 70 6c 65 2c 64 63 3d 63 6f 6d > c=example,dc=com > 0020: 80 06 73 65 63 72 65 74 > ..secret > ber_get_next: tag 0x30 len 46 contents: > ber_dump: buf=0x003451d0 ptr=0x003451d0 end=0x003451fe len=46 > 0000: 02 01 01 60 29 02 01 03 04 1c 63 6e 3d 4d 61 6e > ...`).....cn=Man > 0010: 61 67 65 72 2c 64 63 3d 65 78 61 6d 70 6c 65 2c > ager,dc=example, > 0020: 64 63 3d 63 6f 6d 80 06 73 65 63 72 65 74 > dc=com..secret > ber_get_next > ldap_read: want=8 error=Resource temporarily unavailable > ber_get_next on fd 13 failed errno=35 (Resource temporarily unavailable) > daemon: select: listen=6 active_threads=0 tvp=NULL > daemon: select: listen=7 active_threads=0 tvp=NULL > do_bind > ber_scanf fmt ({imt) ber: > ber_dump: buf=0x003451d0 ptr=0x003451d3 end=0x003451fe len=43 > 0000: 60 29 02 01 03 04 1c 63 6e 3d 4d 61 6e 61 67 65 > `).....cn=Manage > 0010: 72 2c 64 63 3d 65 78 61 6d 70 6c 65 2c 64 63 3d > r,dc=example,dc= > 0020: 63 6f 6d 80 06 73 65 63 72 65 74 > com..secret > ber_scanf fmt (m}) ber: > ber_dump: buf=0x003451d0 ptr=0x003451f6 end=0x003451fe len=8 > 0000: 00 06 73 65 63 72 65 74 > ..secret >>>> dnPrettyNormal: <cn=Manager,dc=example,dc=com> > => ldap_bv2dn(cn=Manager,dc=example,dc=com,0) > <= ldap_bv2dn(cn=Manager,dc=example,dc=com)=0 > => ldap_dn2bv(272) > <= ldap_dn2bv(cn=Manager,dc=example,dc=com)=0 > => ldap_dn2bv(272) > <= ldap_dn2bv(cn=manager,dc=example,dc=com)=0 > <<< dnPrettyNormal: <cn=Manager,dc=example,dc=com>, > <cn=manager,dc=example,dc=com> > do_bind: version=3 dn="cn=Manager,dc=example,dc=com" method=128 > conn=1 op=0 BIND dn="cn=Manager,dc=example,dc=com" method=128 > ==> bdb_bind: dn: cn=Manager,dc=example,dc=com > bdb_dn2entry("cn=manager,dc=example,dc=com") > => bdb_dn2id("dc=example,dc=com") > <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found > (-30990) > send_ldap_result: conn=1 op=0 p=3 > send_ldap_result: err=49 matched="" text="" > send_ldap_response: msgid=1 tag=97 err=49 > ber_flush: 14 bytes to sd 13 > 0000: 30 0c 02 01 01 61 07 0a 01 31 04 00 04 00 > 0....a...1.... > ldap_write: want=14, written=14 > 0000: 30 0c 02 01 01 61 07 0a 01 31 04 00 04 00 > 0....a...1.... > conn=1 op=0 RESULT tag=97 err=49 text= > daemon: activity on 1 descriptor > daemon: activity on: 13r > daemon: read activity on 13 > connection_get(13) > connection_get(13): got connid=1 > connection_read(13): checking for input on id=1 > ber_get_next > ldap_read: want=8, got=0 > > ber_get_next on fd 13 failed errno=0 (Undefined error: 0) > connection_read(13): input error=-2 id=1, closing. > connection_closing: readying conn=1 sd=13 for close > connection_close: deferring conn=1 sd=13 > daemon: select: listen=6 active_threads=0 tvp=NULL > daemon: select: listen=7 active_threads=0 tvp=NULL > daemon: activity on 1 descriptor > daemon: waked > daemon: select: listen=6 active_threads=0 tvp=NULL > daemon: select: listen=7 active_threads=0 tvp=NULL > connection_resched: attempting closing conn=1 sd=13 > connection_close: conn=1 sd=13 > daemon: removing 13 > conn=1 fd=13 closed (connection lost) > > - Jon > > On Dec 21, 2007 10:54 AM, Gavin Henry <ghenry(a)suretecsystems.com> wrote: > >> <quote who="Jonathan Wage"> >> > Here is my slapd.conf >> > >> > # >> > # See slapd.conf(5) for details on configuration options. >> > # This file should NOT be world readable. >> > # >> > include /private/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 /private/var/db/openldap/run/slapd.pid >> > argsfile /private/var/db/openldap/run/slapd.args >> > >> > # Load dynamic backend modules: >> > # modulepath /usr/libexec/openldap >> > # moduleload back_bdb.la >> > # moduleload back_ldap.la >> > # moduleload back_ldbm.la >> > # moduleload back_passwd.la >> > # moduleload back_shell.la >> > >> > # Sample security restrictions >> > # Require integrity protection (prevent hijacking) >> > # Require 112-bit (3DES or better) encryption for updates >> > # Require 63-bit encryption for simple bind >> > # security ssf=1 update_ssf=112 simple_bind=64 >> > >> > # Sample access control policy: >> > # Root DSE: allow anyone to read it >> > # Subschema (sub)entry DSE: allow anyone to read it >> > # Other DSEs: >> > # Allow self write access >> > # Allow authenticated users read access >> > # Allow anonymous users to authenticate >> > # Directives needed to implement policy: >> > # access to dn.base="" by * read >> > # access to dn.base="cn=Subschema" by * read >> > # access to * >> > # by self write >> > # by users read >> > # by anonymous auth >> > # >> > # if no access controls are present, the default policy >> > # allows anyone and everyone to read anything but restricts >> > # updates to rootdn. (e.g., "access to * by * read") >> > # >> > # rootdn can always read and write EVERYTHING! >> > >> > ####################################################################### >> > # BDB database definitions >> > ####################################################################### >> > >> > database bdb >> > suffix "dc=example,dc=com" >> > rootdn "cn=Manager,dc=example,dc=com" >> > # Cleartext passwords, especially for the rootdn, should >> > # be avoid. See slappasswd(8) and slapd.conf(5) for details. >> > # Use of strong authentication encouraged. >> > rootpw secret >> > # The database directory MUST exist prior to running slapd AND >> > # should only be accessible by the slapd and slap tools. >> > # Mode 700 recommended. >> > directory /private/var/db/openldap/openldap-data >> > # Indices to maintain >> > index objectClass eq >> > >> > >> > Which logs are you referring to? The openldap log? >> >> Start slapd by hand with -d -1 >> >> and then bind via ldapsearch. >> >> >> > > > -- > Jonathan Wage > http://www.jwage.com > http://www.centresource.com >

1 0

Issue using ldapadd
by Jonathan Wage 21 Dec '07

21 Dec '07

Using the following command: ldapadd -x -D "cn=Manager,dc=example,dc=com" -f example.ldif -w secret No matter what I do, it says: ldap_bind: Invalid credentials (49) Here is my slapd.conf database bdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret Here is example.ldif: dn: dc=example,dc=com objectclass: dcObject objectclass: organization o: Example Company dc: example dn: cn=Manager,dc=example,dc=com objectclass: organizationalRole cn: Manager I saw another person with the same issue but it was because the slapd.confinformation did not match the information being passed to ldapadd, I already correct that as you can see and it still does not work. What else am I missing? Thanks, Jon -- Jonathan Wage http://www.jwage.com http://www.centresource.com

4 3

Sync Replication via TLS/SSL - get bind err
by Chris G. Sellers 21 Dec '07

21 Dec '07

I have setup sync replication on two OpenLDAP servers. I have it successfully working via ldap://:389 I then setup TLS for SSL connections. I used a self signed cert (using the OpenLDAP how-to) as well as a CAsigned cert from cacert.org. I've setup the ca.crt in the ldap.conf file on both the master and slave. I've also setup the ca.cert in the TLS for the master server that the sync repl host connects to. I've tested the cert with a connection via ldap -Z and -d debug option and seen that the cert appears to be validated. So, when I turn on ldaps:// for the syncrepl section of the slave server, and use port 389 I get a bind error Dec 20 11:01:43 IdP slapd[11717]: do_syncrep1: rid 123 ldap_sasl_bind_s failed (-1) Dec 20 11:01:43 IdP slapd[11717]: do_syncrepl: rid 123 quitting which suggests that the connection could not be made on port 389 via TLS. I can't figure out how to tell the repl connection to send a certificate. Do I have to setup a user in LDAP with a cert? Do I put a client cert into the syncrepl section of the slapd.conf file on the slave? Please advise. Thanks Sellers |----------------------------------------------------------------------| Chris G. Sellers, MLS Lead Internet Engineer National Institute for Technology & Liberal Education 535 West William Street, Ann Arbor, Michigan 48103 chris.sellers(a)nitle.org 734.661.2318

7 17

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software