openldap-technical August 2013

openldap-technical@openldap.org

70 participants
88 discussions

Issue with mdb_cursor_del in MDB_DUPSORT databases
by Mark Zealey 29 Aug '13

29 Aug '13

Hi Howard, I've now switched the database to use MDB_DUPSORT and found what seems to be another issue to do with invalid data being returned after mdb_cursor_del. The following code shows the behaviour against a database that I can provide you with if you need: rc = mdb_cursor_open(txn, dbi, &cursor); char seek[] = "ku.oc.repmulp\t"; key.mv_size = sizeof(seek); key.mv_data = &seek; mdb_cursor_get(cursor, &key, &data, MDB_SET_RANGE); for( i = 0; i < 15; i++ ) { mdb_cursor_del( cursor, MDB_NODUPDATA ); data.mv_size = 0; key.mv_size = 0; mdb_cursor_get( cursor, &key, &data, //MDB_NEXT MDB_GET_CURRENT ); if( key.mv_size == 0 ) printf("WARNING 0 SIZE KEY\n"); else printf("KEY OK: %d: %.*s\n", key.mv_size, key.mv_size, key.mv_data); if( data.mv_size == 0 ) printf("WARNING 0 SIZE DATA\n"); else printf("DATA OK: %d: %.*s\n", data.mv_size, data.mv_size, data.mv_data); } mdb_txn_abort(txn); If you run as-is it seems that if the cursor points at a record with multiple entries, the data is not updated. If however the mdb_cursor_del line is commented and mdb_cursor_get changed to use MDB_NEXT the output is as expected with multiple entries. Here is sample output with get-only: KEY OK: 16: ku.oc.repmulp MX DATA OK: 40: 4160598 300 0 primary.mail.plumper.co.uk KEY OK: 16: ku.oc.repmulp MX DATA OK: 37: 4160598 300 10 cerebellum.david14.com KEY OK: 16: ku.oc.repmulp MX DATA OK: 46: 4160598 300 20 secondary-mail.mailhoster.co.uk KEY OK: 16: ku.oc.repmulp NS DATA OK: 30: 4160598 300 ns1.xcalibre.co.uk KEY OK: 16: ku.oc.repmulp NS DATA OK: 30: 4160598 300 ns2.xcalibre.co.uk KEY OK: 21: ku.oc.repmulp.05pot A DATA OK: 29: 4160598 86400 212.159.180.202 KEY OK: 22: ku.oc.repmulp.05pot MX DATA OK: 40: 4160598 300 0 primary.mail.plumper.co.uk KEY OK: 22: ku.oc.repmulp.05pot MX DATA OK: 37: 4160598 300 10 cerebellum.david14.com KEY OK: 22: ku.oc.repmulp.05pot MX DATA OK: 46: 4160598 300 20 secondary-mail.mailhoster.co.uk And here with mdb_cursor_del: KEY OK: 16: ku.oc.repmulp MX WARNING 0 SIZE DATA KEY OK: 16: ku.oc.repmulp NS WARNING 0 SIZE DATA KEY OK: 21: ku.oc.repmulp.05pot A DATA OK: 29: 4160598 86400 212.159.180.202 KEY OK: 22: ku.oc.repmulp.05pot MX WARNING 0 SIZE DATA KEY OK: 25: ku.oc.repmulp.05pot.www A DATA OK: 29: 4160598 86400 212.159.180.202 KEY OK: 20: ku.oc.repmulp.3pop A DATA OK: 29: 4160598 86400 212.159.180.202 Behaviour seems to be the same regardless of whether I use MDB_NODUPDATA or 0 as the mdb_cursor_del flag (ie 0 length data returned and all duplicate entries deleted) Thanks, Mark

2 2

RE: ldapadd "ldap_bind: Invalid credentials (49)"
by Juergen.Sprenger＠swisscom.com 29 Aug '13

29 Aug '13

--On Thursday, August 29, 2013 12:35 AM +0000 Clint Petty <cpetty(a)luthresearch.com> wrote: > > > After upgrading from OpenLDAP 2.4.23 to 2.4.36, I can no longer add a > user: > > > ># ldapadd -x -D "cn=Manager,dc=luthresearch,dc=net" -w secret -f # >/etc/openldap/adduser.ldif Check Your config for RootPW and whether the hash algorithm used is still supported by Your build of OpenLDAP. Had a similar problem on an old server because --enable-crypt was not set when building OpenLDAP 2.4.36. You can check that by using slappasswd to create a String like the one used in Your config: # /usr/local/sbin/slappasswd -s secret -h '{crypt}' Password generation failed for scheme {crypt}: scheme not recognized --Jürgen Sprenger

3 2

ldapadd "ldap_bind: Invalid credentials (49)"
by Clint Petty 29 Aug '13

29 Aug '13

After upgrading from OpenLDAP 2.4.23 to 2.4.36, I can no longer add a user: # ldapadd -x -D "cn=Manager,dc=luthresearch,dc=net" -w secret -f /etc/openldap/adduser.ldif ldap_bind: Invalid credentials (49)

2 3

Unstable slapd-meta connection with MS AD LDAP
by Nick Anzalone 29 Aug '13

29 Aug '13

Hello, I'm trying to use slapd-meta (openldap version 2.4.28) as a proxy between a web application LDAP authentication request and a MS AD server. The idea being that if we have multiple LDAP authentication clients we can add another target with suffix massage to redirect requests to the appropriate LDAP server. We were forced to use a dedicated proxy because we were told the MS server's firewall requires an actual IP, not a FQDN, and we don't have a stable ip (we're using a load balancer service which only provides a FQDN). In general, it looked like this solution would work well. My problem is that the connection between the slapd-meta proxy and the MS server does not seem very robust. I would be extremely grateful if someone could help me understand where I might start looking to diagnose what is wrong. #################### Problem Summary ##################### The problem I'm seeing was reported as an "Operations Error" from the command line. Initially, I did not have idle-timeout set at all, and this error would occur reliably after 15 minutes of inactivity, and was not recoverable (I needed to restart the slapd server to correct the problem). I suspected that the cause was that the connection was remaining idle too long and getting invalidated by the MS LDAP server (which I don't have access to). To address this problem, I set idle-timeout to 10m (MS AD apparently has a default timeout of 15m). I have set up a cron job to "ping" the MS server every minute in an attempt to keep the connection open (although I'm not sure if it actually uses the same connection, so this may not be doing much). I also set the value of the nretries configuration directive to 20. These adjustments seemed to help significantly. With constant activity (authentication through the web application), everything appears to work great. However I still occasionally get the "operations error," which causes my web application to reject the initial authentication even with correct credentials. At this point it is most reliably reproduced by inducing more than 15 minutes of inactivity on the slapd-meta proxy, and then attempting a login. After an initial failed login attempt, the problem seems to correct for itself (i.e. a second login attempt through the web application with the same credentials will succeed). I am at all times able to connect directly to the LDAP server with no trouble. It is only connections through the slapd-meta proxy I have set up that (sometimes) fail. It may also be worth noting that I don't see any of these problems with an openldap test server that I set up. Thanks so much in advance for any help or suggestions. ################################## Problem Details ##################################### Below is an excerpt from my syslog from a failed authentication request initiated by my web application: -------------------- log output from syslog ------------------------------------------ Aug 28 20:33:26 my-proxy-server slapd[10330]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Aug 28 20:33:26 my-proxy-server slapd[10330]: daemon: epoll: listen=9 active_threads=0 tvp=NULL Aug 28 20:33:26 my-proxy-server slapd[10330]: daemon: epoll: listen=10 active_threads=0 tvp=NULL Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 do_search Aug 28 20:33:26 my-proxy-server slapd[10330]: >>> dnPrettyNormal: <dc=AAA,dc=YYY,dc=ZZZ> Aug 28 20:33:26 my-proxy-server slapd[10330]: <<< dnPrettyNormal: <dc=AAA,dc=YYY,dc=ZZZ>, <dc=AAA,dc=YYY,dc=ZZZ> Aug 28 20:33:26 my-proxy-server slapd[10330]: SRCH "dc=AAA,dc=YYY,dc=ZZZ" 2 3 Aug 28 20:33:26 my-proxy-server slapd[10330]: 0 0 0 Aug 28 20:33:26 my-proxy-server slapd[10330]: begin get_filter Aug 28 20:33:26 my-proxy-server slapd[10330]: EQUALITY Aug 28 20:33:26 my-proxy-server slapd[10330]: end get_filter 0 Aug 28 20:33:26 my-proxy-server slapd[10330]: filter: (?SAMACCOUNTNAME=xxx) Aug 28 20:33:26 my-proxy-server slapd[10330]: => get_ctrls Aug 28 20:33:26 my-proxy-server slapd[10330]: => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) Aug 28 20:33:26 my-proxy-server slapd[10330]: <= get_ctrls: n=1 rc=0 err="" Aug 28 20:33:26 my-proxy-server slapd[10330]: attrs: Aug 28 20:33:26 my-proxy-server slapd[10330]: Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 SRCH base="dc=AAA,dc=YYY,dc=ZZZ" scope=2 deref=3 filter="(?SAMACCOUNTNAME=xxx)" Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 meta_back_getconn: mc=0x7fafbc004500 conn=ROOTDN expired (tainted). Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1: meta_back_getconn[1] Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 meta_back_getconn: candidates=1 conn=ROOTDN fetched Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 >>> meta_back_search_start[1] Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 >>> meta_search_dobind_init[1] Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 <<< meta_search_dobind_init[1]=1 Aug 28 20:33:26 my-proxy-server slapd[10330]: ==> rewrite_context_apply [depth=1] string='dc=AAA,dc=YYY,dc=ZZZ' Aug 28 20:33:26 my-proxy-server slapd[10330]: ==> rewrite_rule_apply rule='((.+),)?dc=AAA,[ ]?dc=YYY,[ ]?dc=ZZZ$' string='dc=AAA,dc=YYY,dc=ZZZ' [1 pass(es)] Aug 28 20:33:26 my-proxy-server slapd[10330]: ==> rewrite_context_apply [depth=1] res={0,'ou=Org Unit,dc=AAA,dc=BBB,dc=CCC,dc=DDD'} Aug 28 20:33:26 my-proxy-server slapd[10330]: [rw] searchBase: "dc=AAA,dc=YYY,dc=ZZZ" -> "ou=Org Unit,dc=AAA,dc=BBB,dc=CCC,dc=DDD" Aug 28 20:33:26 my-proxy-server slapd[10330]: ==> rewrite_context_apply [depth=1] string='(SAMACCOUNTNAME=xxx)' Aug 28 20:33:26 my-proxy-server slapd[10330]: ==> rewrite_context_apply [depth=1] res={0,'NULL'} Aug 28 20:33:26 my-proxy-server slapd[10330]: [rw] searchFilter: "(SAMACCOUNTNAME=xxx)" -> "(SAMACCOUNTNAME=xxx)" Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 meta_back_retry[1]: retrying URI="ldap://ms-ldap-server.AAA.BBB.CCC.DDD" DN="cn=bind-manager,ou=Org Unit,dc=AAA,dc=BBB,dc=CCC,dc=DDD". Aug 28 20:33:26 my-proxy-server slapd[10330]: >>> conn=1094 op=1 meta_back_bind_op_result[1] Aug 28 20:33:26 my-proxy-server slapd[10330]: <<< conn=1094 op=1 meta_back_bind_op_result[1] err=0 Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 meta_back_retry[1]: meta_back_single_dobind=0 Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 <<< meta_back_search_start[1]=1 Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 meta_back_search: ncandidates=1 cnd=" *" Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 meta_back_search[1] match="" err=1 (Operations error). Aug 28 20:33:26 my-proxy-server slapd[10330]: send_ldap_result: conn=1094 op=1 p=3 Aug 28 20:33:26 my-proxy-server slapd[10330]: send_ldap_result: err=1 matched="" text="" Aug 28 20:33:26 my-proxy-server slapd[10330]: send_ldap_response: msgid=2 tag=101 err=1 Aug 28 20:33:26 my-proxy-server slapd[10330]: conn=1094 op=1 SEARCH RESULT tag=101 err=1 nentries=0 text= ######################### slapd.conf ######################## # This is the main slapd configuration file. See slapd.conf(5) for more # info on the configuration options. ####################################################################### # Global Directives: # Features to permit #allow bind_v2 # Schema and objectClass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/slapd/slapd.pid # List of arguments that were passed to the server argsfile /var/run/slapd/slapd.args # Read slapd.conf(5) for possible values # should reduce this once we're live loglevel any # Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_meta.la moduleload back_ldap.la # The maximum number of entries that is returned for a search operation sizelimit 500 # The tool-threads parameter sets the actual amount of cpu's that is used # for indexing. tool-threads 1 # experiment trying to figure out error below: # ber_get_next on fd 12 failed errno=34 (Numerical result out of range) #sockbuf_max_incoming_auth 5000000000 # Specific Backend Directives for 'other': # Backend specific directives apply to this backend until another # 'backend' directive occurs backend meta # this is broken - causes slapd to terminate #TLSCipherSuite ALL:!NULL #TLSCipherSuite ECDHE-RSA-AES256-SHA #TLSCipherSuite SECURE256 # TLS Security settings TLSCACertificateFile /etc/ldap/cert/private/ca.my-proxy-server.YYY.ZZZ.pem TLSCertificateFile /etc/ldap/cert/private/ca.my-proxy-server.YYY.ZZZ.pem TLSCertificateKeyFile /etc/ldap/cert/private/private.my-proxy-server.YYY.ZZZ.pem #TLSVerifyClient try # require TLS (secure) connection #security tls=1 ######################################################### # CUSTOM META SLAPD ################################################# database meta suffix "dc=YYY,dc=ZZZ" rootdn "cn=XXX,dc=YYY,dc=ZZZ" rootpw ***** # The following parameters were added to trouble-shoot the unstable connection w/ MS LDAP server idle-timeout 10m nretries 20 ####################################################################### # Test LDAP server on staging # Each LDAP server will get its own entry like this # Please document each server ####################################################### # The LDAP server URL. Note the dc=test in the suffix, which allows us to uniquely identify the request as # one that should be passed to our test server. We might use one like dc=AAA for an entry that would pass # requests to the AAA LDAP server uri "ldap://test.YYY.ZZZ/dc=test,dc=YYY,dc=ZZZ" # Tells the client to use a secure connection with the server. tls start # More connection specifics: specifies the filename/location of the client certificate if the server requires one # we also specify the DN used to bind, and credentials (password) for the binding DN. idassert-bind tls_cacert=/etc/ldap/cert/test.YYY.ZZZ.crt binddn="cn=admin,dc=YYY,dc=ZZZ" credentials="*****" # NB: There is a parameter that needs to "allow" the server to require a client certificate (tls_reqcert=allow), however it doesn't seem to # work. So we were forced to set this in the ldap.conf (client-side) config file. slapd uses this file to set default values for many # parameters, including this one. # This removes the "dc=test" specifier before delegating the LDAP request to the test server. suffixmassage "dc=test,dc=YYY,dc=ZZZ" "dc=YYY,dc=ZZZ" ########################################################################## # AAA LDAP Server Entry # Here is the AAA-provided "user context": # OU=Org Unit, DC=AAA, DC=BBB, DC=CCC, DC=DDD # ########################################################## uri "ldap://ms-ldap-server.AAA.BBB.CCC.DDD/dc=AAA,dc=YYY,dc=ZZZ" tls start idassert-bind tls_cacert=/etc/ldap/cert/AAA.BBB.CCC.DDD.crt binddn="cn=bind-manager,ou=Org Unit,dc=AAA,dc=BBB,dc=CCC,dc=DDD" credentials="******" suffixmassage "dc=AAA,dc=YYY,dc=ZZZ" "ou=Org Unit,dc=AAA,dc=BBB,dc=CCC,dc=DDD" default-target

2 1

Re : Re: OpenLDAP 2.4.36 slapd crash with "assertion failed" message
by "POISSON Frédéric" 29 Aug '13

29 Aug '13

Re Hello, Sorry that was for me the first time i use gdb and i haven't understand that it require to install rpm with debuginfo, now here is a new gdb trace with more informations : # gdb /usr/local/openldap/libexec/slapd 4700 GNU gdb (GDB) Red Hat Enterprise Linux (7.2-50.el6) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/local/openldap/libexec/slapd...Reading symbols from /usr/lib/debug/usr/local/openldap/libexec/slapd.debug...done. done. Attaching to program: /usr/local/openldap/libexec/slapd, process 4700 Reading symbols from /usr/local/berkeleydb/lib64/libdb-4.6.so...Reading symbols from /usr/lib/debug/usr/local/berkeleydb/lib64/libdb-4.6.so.debug... warning: "/usr/lib/debug/usr/local/berkeleydb/lib64/libdb-4.6.so.debug": separate debug info file has no debug info (no debugging symbols found)...done. (no debugging symbols found)...done. Loaded symbols for /usr/local/berkeleydb/lib64/libdb-4.6.so Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled] [New Thread 0x7f0f51882700 (LWP 4814)] Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /usr/lib64/libsasl2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libsasl2.so.2 Reading symbols from /usr/lib64/libssl.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libssl.so.10 Reading symbols from /usr/lib64/libcrypto.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libcrypto.so.10 Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libcrypt.so.1 Reading symbols from /lib64/libresolv.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libresolv.so.2 Reading symbols from /usr/lib64/libltdl.so.7...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libltdl.so.7 Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/libgssapi_krb5.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libgssapi_krb5.so.2 Reading symbols from /lib64/libkrb5.so.3...(no debugging symbols found)...done. Loaded symbols for /lib64/libkrb5.so.3 Reading symbols from /lib64/libcom_err.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libcom_err.so.2 Reading symbols from /lib64/libk5crypto.so.3...(no debugging symbols found)...done. Loaded symbols for /lib64/libk5crypto.so.3 Reading symbols from /lib64/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libz.so.1 Reading symbols from /lib64/libfreebl3.so...(no debugging symbols found)...done. Loaded symbols for /lib64/libfreebl3.so Reading symbols from /lib64/libkrb5support.so.0...(no debugging symbols found)...done. Loaded symbols for /lib64/libkrb5support.so.0 Reading symbols from /lib64/libkeyutils.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libkeyutils.so.1 Reading symbols from /lib64/libselinux.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libselinux.so.1 Reading symbols from /lib64/libnss_files.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libnss_files.so.2 Reading symbols from /usr/lib64/sasl2/libsasldb.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libsasldb.so Reading symbols from /lib64/libdb-4.7.so...(no debugging symbols found)...done. Loaded symbols for /lib64/libdb-4.7.so Reading symbols from /usr/lib64/sasl2/libanonymous.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libanonymous.so 0x0000003a00c0804d in pthread_join () from /lib64/libpthread.so.0 Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.23-13.el6.x86_64 db4-4.7.25-16.el6.x86_64 glibc-2.12-1.47.el6_2.12.x86_64 keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6_2.1.x86_64 libcom_err-1.41.12-11.el6.x86_64 libselinux-2.0.94-5.2.el6.x86_64 libtool-ltdl-2.2.6-15.5.el6.x86_64 nss-softokn-freebl-3.12.9-11.el6.x86_64 openssl-1.0.0-20.el6_2.4.x86_64 zlib-1.2.3-27.el6.x86_64 (gdb) backtrace full #0 0x0000003a00c0804d in pthread_join () from /lib64/libpthread.so.0 No symbol table info available. #1 0x000000000043a0e9 in slapd_daemon () at daemon.c:2929 i = <value optimized out> rc = <value optimized out> #2 0x0000000000426435 in main (argc=11, argv=<value optimized out>) at main.c:1012 i = <value optimized out> no_detach = 0 rc = -12 urls = 0x23f5010 "ldap://*:25389 ldaps://*:25636" username = 0x23f5080 "root" groupname = 0x23f50a0 "\026\065U" sandbox = 0x0 syslogUser = 160 pid = <value optimized out> waitfds = {9, 10} g_argc = 11 g_argv = <value optimized out> configfile = 0x0 configdir = 0x23f5040 "/usr/local/openldap/etc/openldap/slapd.d" serverName = <value optimized out> scp = <value optimized out> scp_entry = <value optimized out> debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = <value optimized out> slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = <value optimized out> __PRETTY_FUNCTION__ = "main" (gdb) continue Continuing. [New Thread 0x7f0f51081700 (LWP 5623)] Program received signal SIGABRT, Aborted. [Switching to Thread 0x7f0f51081700 (LWP 5623)] 0x0000003a00432885 in raise () from /lib64/libc.so.6 (gdb) backtrace full #0 0x0000003a00432885 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x0000003a00434065 in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x0000003a0042b9fe in __assert_fail_base () from /lib64/libc.so.6 No symbol table info available. #3 0x0000003a0042bac0 in __assert_fail () from /lib64/libc.so.6 No symbol table info available. #4 0x0000000000450bed in slap_send_ldap_result (op=0x7f0f44002670, rs=0x7f0f51080950) at result.c:813 tmp = 0x0 otext = 0x7f0f5107f394 "" oref = 0x0 __PRETTY_FUNCTION__ = "slap_send_ldap_result" #5 0x000000000042d567 in config_back_modify (op=<value optimized out>, rs=<value optimized out>) at bconfig.c:5926 cfb = <value optimized out> ce = <value optimized out> last = 0xd00000000 ml = <value optimized out> ca = {argc = 2, argv = 0x7f0f44103f90, argv_size = 513, line = 0x7f0f44102cc0 "/dev/random", tline = 0x7f0f44103f70 "", fname = 0x5d1f79 "slapd", lineno = 0, log = "olcTLSRandFile: value #0", '\000' <repeats 4099 times>, reply = {err = 0, msg = '\000' <repeats 255 times>}, depth = 0, valx = -1, values = {v_int = 1141915104, v_uint = 1141915104, v_long = 139703543152096, v_ulong = 139703543152096, v_ber_t = 139703543152096, v_string = 0x7f0f44103de0 "0?\020D\017\177", v_bv = {bv_len = 139703543152096, bv_val = 0x0}, v_dn = {vdn_dn = { bv_len = 139703543152096, bv_val = 0x0}, vdn_ndn = {bv_len = 0, bv_val = 0x0}}, v_ad = 0x7f0f44103de0}, rvalue_vals = 0x0, rvalue_nvals = 0x0, op = 0, type = 4, ca_op = 0x7f0f44002670, be = 0x88e960, bi = 0x0, ca_entry = 0x24780d8, ca_private = 0x2477970, cleanup = 0x427a70 <config_tls_cleanup>, table = Cft_Global} rdn = {bv_len = 2, bv_val = 0x2477e30 "cn=config"} ptr = <value optimized out> rad = 0x2422450 do_pause = <value optimized out> #6 0x000000000045745b in fe_op_modify (op=0x7f0f44002670, rs=0x7f0f51080950) at modify.c:303 update = <value optimized out> repl_user = <value optimized out> op_be = <value optimized out> bd = 0x88e960 textbuf = "x,\000D\017\177", '\000' <repeats 18 times>, "\003\000\000\000\000\000\000\000\020/Z\000\000\000\000\000Â7Z\000\000\000\000\000`ó@\002\000\000\000\000ð\035\000D\017\177\000\000\200ªG\000\000\000\000\000\066¢E\000\000\000\000\000\016\000\000\000\000\000\000\000K,\020D\017\177", '\000' <repeats 18 times>, "\v\000\000\000\000\000\000\000À,\020D\017\177\000\000à+\000D\017\177\000\000à,\020D\017\177\000\000\000\000\000\000\000\000\000\000\200\236C\002", '\000' <repeats 28 times>, "\237nE\000\000\000\000\000\000\b\bQ\017\177\000\000p\t\bQ\017\177\000\000\000\001\000\000\000\000\000\000p&\000D\017\177\000\000\230&\000D\017\177\000\000¨&"... #7 0x0000000000457d86 in do_modify (op=0x7f0f44002670, rs=0x7f0f51080950) at modify.c:177 dn = {bv_len = 9, bv_val = 0x7f0f44102c37 "cn=config"} textbuf = "')\000D\017\177", '\000' <repeats 42 times>, "Ð\b\bQ\000\000\000\000°\n\bQ\017\177", '\000' <repeats 18 times>, "P\t\bQ\017\177\000\000ùäÀ\000:", '\000' <repeats 11 times>, "\211\022\\\000\000\000\000\000Ð\b\bQ\017\177\000\000p&\000D\017\177\000\000ÿÿÿÿ\017\177\000\000½ÄE\000\000\000\000\000P\t\bQ\017\177\000\000@\224x\000:", '\000' <repeats 11 times>, "\020&\000D\017\177\000\000à+\000D\017\177\000\000\000\000\020\000\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000°\n\bQ\017\177\000\000ð0I", '\000' <repeats 13 times>, "\005\000\000\000\061\000\000\000p&\000D\017"... tmp = <value optimized out> #8 0x000000000043fb79 in connection_operation (ctx=0x7f0f51080ab0, arg_v=0x7f0f44002670) at connection.c:1155 rc = 80 cancel = <value optimized out> op = 0x7f0f44002670 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = -12, sr_matched = 0x0, sr_text = 0x7f0f5107f394 "", sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 102 opidx = SLAP_OP_MODIFY conn = 0x2502d20 memctx = 0x7f0f44002be0 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #9 0x0000000000440365 in connection_read_thread (ctx=0x7f0f51080ab0, argv=<value optimized out>) at connection.c:1291 ---Type <return> to continue, or q <return> to quit--- rc = <value optimized out> cri = {op = 0x7f0f44002670, func = 0, arg = 0x0, ctx = 0x7f0f51080ab0, nullop = <value optimized out>} s = <value optimized out> #10 0x0000000000595b80 in ldap_int_thread_pool_wrapper (xpool=0x2425680) at tpool.c:688 pool = 0x2425680 task = 0x7f0f4c0008c0 work_list = <value optimized out> ctx = {ltu_id = 139703760721664, ltu_key = {{ltk_key = 0x43e990, ltk_data = 0x7f0f44002ad0, ltk_free = 0x43ea60 <conn_counter_destroy>}, {ltk_key = 0x492f40, ltk_data = 0x7f0f44002be0, ltk_free = 0x492f60 <slap_sl_mem_destroy>}, {ltk_key = 0x452d70, ltk_data = 0x0, ltk_free = 0x452b40 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 26 times>, { ltk_key = 0x0, ltk_data = 0x3a00c07e8a, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = <value optimized out> keyslot = 990 hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #11 0x0000003a00c077f1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #12 0x0000003a004e5ccd in clone () from /lib64/libc.so.6 No symbol table info available. (gdb) continue Continuing. [Thread 0x7f0f51081700 (LWP 5623) exited] [Thread 0x7f0f51882700 (LWP 4814) exited] Program terminated with signal SIGABRT, Aborted. The program no longer exists. (gdb) quit Regards Le 29/08/13, "POISSON Frédéric" <frederic.poisson(a)admin.gmessaging.net> a écrit : > Hello, > > Ok thanks for the information, i try the gdb with full backtrace and i have : > > # gdb /usr/local/openldap/libexec/slapd 9522 > GNU gdb (GDB) Red Hat Enterprise Linux (7.2-50.el6) > Copyright (C) 2010 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-redhat-linux-gnu". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>... > Reading symbols from /usr/local/openldap/libexec/slapd...(no debugging symbols found)...done. > Attaching to program: /usr/local/openldap/libexec/slapd, process 9522 > Reading symbols from /usr/local/berkeleydb/lib64/libdb-4.6.so...(no debugging symbols found)...done. > Loaded symbols for /usr/local/berkeleydb/lib64/libdb-4.6.so > Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done. > [Thread debugging using libthread_db enabled] > [New Thread 0x7f036993a700 (LWP 9523)] > Loaded symbols for /lib64/libpthread.so.0 > Reading symbols from /usr/lib64/libsasl2.so.2...(no debugging symbols found)...done. > Loaded symbols for /usr/lib64/libsasl2.so.2 > Reading symbols from /usr/lib64/libssl.so.10...(no debugging symbols found)...done. > Loaded symbols for /usr/lib64/libssl.so.10 > Reading symbols from /usr/lib64/libcrypto.so.10...(no debugging symbols found)...done. > Loaded symbols for /usr/lib64/libcrypto.so.10 > Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols found)...done. > Loaded symbols for /lib64/libcrypt.so.1 > Reading symbols from /lib64/libresolv.so.2...(no debugging symbols found)...done. > Loaded symbols for /lib64/libresolv.so.2 > Reading symbols from /usr/lib64/libltdl.so.7...(no debugging symbols found)...done. > Loaded symbols for /usr/lib64/libltdl.so.7 > Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done. > Loaded symbols for /lib64/libc.so.6 > Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. > Loaded symbols for /lib64/ld-linux-x86-64.so.2 > Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done. > Loaded symbols for /lib64/libdl.so.2 > Reading symbols from /lib64/libgssapi_krb5.so.2...(no debugging symbols found)...done. > Loaded symbols for /lib64/libgssapi_krb5.so.2 > Reading symbols from /lib64/libkrb5.so.3...(no debugging symbols found)...done. > Loaded symbols for /lib64/libkrb5.so.3 > Reading symbols from /lib64/libcom_err.so.2...(no debugging symbols found)...done. > Loaded symbols for /lib64/libcom_err.so.2 > Reading symbols from /lib64/libk5crypto.so.3...(no debugging symbols found)...done. > Loaded symbols for /lib64/libk5crypto.so.3 > Reading symbols from /lib64/libz.so.1...(no debugging symbols found)...done. > Loaded symbols for /lib64/libz.so.1 > Reading symbols from /lib64/libfreebl3.so...(no debugging symbols found)...done. > Loaded symbols for /lib64/libfreebl3.so > Reading symbols from /lib64/libkrb5support.so.0...(no debugging symbols found)...done. > Loaded symbols for /lib64/libkrb5support.so.0 > Reading symbols from /lib64/libkeyutils.so.1...(no debugging symbols found)...done. > Loaded symbols for /lib64/libkeyutils.so.1 > Reading symbols from /lib64/libselinux.so.1...(no debugging symbols found)...done. > Loaded symbols for /lib64/libselinux.so.1 > Reading symbols from /lib64/libnss_files.so.2...(no debugging symbols found)...done. > Loaded symbols for /lib64/libnss_files.so.2 > Reading symbols from /usr/lib64/sasl2/libsasldb.so...(no debugging symbols found)...done. > Loaded symbols for /usr/lib64/sasl2/libsasldb.so > Reading symbols from /lib64/libdb-4.7.so...(no debugging symbols found)...done. > Loaded symbols for /lib64/libdb-4.7.so > Reading symbols from /usr/lib64/sasl2/libanonymous.so...(no debugging symbols found)...done. > Loaded symbols for /usr/lib64/sasl2/libanonymous.so > 0x0000003a00c0804d in pthread_join () from /lib64/libpthread.so.0 > Missing separate debuginfos, use: debuginfo-install openldap-ltb-2.4.36-1.el6.x86_64 > (gdb) backtrace full > #0 0x0000003a00c0804d in pthread_join () from /lib64/libpthread.so.0 > No symbol table info available. > #1 0x000000000043a0e9 in slapd_daemon () > No symbol table info available. > #2 0x0000000000426435 in main () > No symbol table info available. > (gdb) continue > Continuing. > [New Thread 0x7f0369139700 (LWP 11349)] > > Program received signal SIGABRT, Aborted. > [Switching to Thread 0x7f0369139700 (LWP 11349)] > 0x0000003a00432885 in raise () from /lib64/libc.so.6 > (gdb) backtrace full > #0 0x0000003a00432885 in raise () from /lib64/libc.so.6 > No symbol table info available. > #1 0x0000003a00434065 in abort () from /lib64/libc.so.6 > No symbol table info available. > #2 0x0000003a0042b9fe in __assert_fail_base () from /lib64/libc.so.6 > No symbol table info available. > #3 0x0000003a0042bac0 in __assert_fail () from /lib64/libc.so.6 > No symbol table info available. > #4 0x0000000000450bed in slap_send_ldap_result () > No symbol table info available. > #5 0x000000000042d567 in ?? () > No symbol table info available. > #6 0x000000000045745b in fe_op_modify () > No symbol table info available. > #7 0x0000000000457d86 in do_modify () > No symbol table info available. > #8 0x000000000043fb79 in ?? () > No symbol table info available. > #9 0x0000000000440365 in ?? () > No symbol table info available. > #10 0x0000000000595b80 in ?? () > No symbol table info available. > #11 0x0000003a00c077f1 in start_thread () from /lib64/libpthread.so.0 > No symbol table info available. > #12 0x0000003a004e5ccd in clone () from /lib64/libc.so.6 > No symbol table info available. > (gdb) continue > Continuing. > [Thread 0x7f0369139700 (LWP 11349) exited] > [Thread 0x7f036993a700 (LWP 9523) exited] > > Program terminated with signal SIGABRT, Aborted. > The program no longer exists. > (gdb) quit > > Tell me if it help, or if you need more. > > Regards, > > Le 29/08/13, Nick Milas <nick(a)eurobjects.com> a écrit : > > On 29/8/2013 12:42 μμ, "POISSON Frédéric" wrote: > > > > >The server shutdown when i add this entry and with slapd option "-d 255" i have : > > >slapd: result.c:813: slap_send_ldap_result: Assertion `!((rs->sr_err)<0)' failed. > > >/etc/init.d/slapd: line 285: 5461 Aborted $SLAPD_BIN -h "$SLAPD_SERVICES" $SLAPD_PARAMS > > > > > >Notice that i test this ldif modification on release 2.4.35 without problem. > > > > Can you try taking a full backtrace? > > > > See for example: http://www.openldap.org/lists/openldap-technical/201111/msg00243.html > > > > I am not a developer, but I have been through the same situation, so I know that a full backtrace is needed for troubleshooting. > > > > Best regards, > > Nick > > > > > > > -- > > Frederic Poisson > > > > > > -- Frederic Poisson

2 2

The RootDN
by Joseph D Carroll Jr 29 Aug '13

29 Aug '13

It's been 3 days since I first started reading and playing with openLDAP. Prior to this, I have had no ldap experience of any kind, so please bear with me. (Hopefully this doesn't reach a new low... ) I am working on setting up my first ldap server for a demo environment, and I can't seem to wrap my head around what a rootdn is. I have read several articles, even much of the Zytrax book, and I still cannot figure out what this rootdn is. I get that it is a user, so maybe better stated, I don't understand where the user exists. Is it an OS user with filesystem privileges? Is it a user that exists in every DIT? If so, when/where is it used, can you have multiple, is it only usuable/accesible when you "include" the core.schema, .. ? If I had to guess, I would say: - A rootdn exists in the DIT as a completely arbitrary user (absolutely no relation to the OS) - There can only be one rootdn per DIT - (Consquently) If a parent defines a rootdn, any referral cannot - The rootdn is used for some kind of system action (who knows what) I know this is the "technical" forum, but I am more so interested in the "why to's" and "reasons behind" than the "how to's". Any clarity would be greatly appreciated. Thanks, JD

3 2

Re : Re: OpenLDAP 2.4.36 slapd crash with "assertion failed" message
by "POISSON Frédéric" 29 Aug '13

29 Aug '13

Hello, Ok thanks for the information, i try the gdb with full backtrace and i have : # gdb /usr/local/openldap/libexec/slapd 9522 GNU gdb (GDB) Red Hat Enterprise Linux (7.2-50.el6) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/local/openldap/libexec/slapd...(no debugging symbols found)...done. Attaching to program: /usr/local/openldap/libexec/slapd, process 9522 Reading symbols from /usr/local/berkeleydb/lib64/libdb-4.6.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/berkeleydb/lib64/libdb-4.6.so Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled] [New Thread 0x7f036993a700 (LWP 9523)] Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /usr/lib64/libsasl2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libsasl2.so.2 Reading symbols from /usr/lib64/libssl.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libssl.so.10 Reading symbols from /usr/lib64/libcrypto.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libcrypto.so.10 Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libcrypt.so.1 Reading symbols from /lib64/libresolv.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libresolv.so.2 Reading symbols from /usr/lib64/libltdl.so.7...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libltdl.so.7 Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/libgssapi_krb5.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libgssapi_krb5.so.2 Reading symbols from /lib64/libkrb5.so.3...(no debugging symbols found)...done. Loaded symbols for /lib64/libkrb5.so.3 Reading symbols from /lib64/libcom_err.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libcom_err.so.2 Reading symbols from /lib64/libk5crypto.so.3...(no debugging symbols found)...done. Loaded symbols for /lib64/libk5crypto.so.3 Reading symbols from /lib64/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libz.so.1 Reading symbols from /lib64/libfreebl3.so...(no debugging symbols found)...done. Loaded symbols for /lib64/libfreebl3.so Reading symbols from /lib64/libkrb5support.so.0...(no debugging symbols found)...done. Loaded symbols for /lib64/libkrb5support.so.0 Reading symbols from /lib64/libkeyutils.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libkeyutils.so.1 Reading symbols from /lib64/libselinux.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libselinux.so.1 Reading symbols from /lib64/libnss_files.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libnss_files.so.2 Reading symbols from /usr/lib64/sasl2/libsasldb.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libsasldb.so Reading symbols from /lib64/libdb-4.7.so...(no debugging symbols found)...done. Loaded symbols for /lib64/libdb-4.7.so Reading symbols from /usr/lib64/sasl2/libanonymous.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libanonymous.so 0x0000003a00c0804d in pthread_join () from /lib64/libpthread.so.0 Missing separate debuginfos, use: debuginfo-install openldap-ltb-2.4.36-1.el6.x86_64 (gdb) backtrace full #0 0x0000003a00c0804d in pthread_join () from /lib64/libpthread.so.0 No symbol table info available. #1 0x000000000043a0e9 in slapd_daemon () No symbol table info available. #2 0x0000000000426435 in main () No symbol table info available. (gdb) continue Continuing. [New Thread 0x7f0369139700 (LWP 11349)] Program received signal SIGABRT, Aborted. [Switching to Thread 0x7f0369139700 (LWP 11349)] 0x0000003a00432885 in raise () from /lib64/libc.so.6 (gdb) backtrace full #0 0x0000003a00432885 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x0000003a00434065 in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x0000003a0042b9fe in __assert_fail_base () from /lib64/libc.so.6 No symbol table info available. #3 0x0000003a0042bac0 in __assert_fail () from /lib64/libc.so.6 No symbol table info available. #4 0x0000000000450bed in slap_send_ldap_result () No symbol table info available. #5 0x000000000042d567 in ?? () No symbol table info available. #6 0x000000000045745b in fe_op_modify () No symbol table info available. #7 0x0000000000457d86 in do_modify () No symbol table info available. #8 0x000000000043fb79 in ?? () No symbol table info available. #9 0x0000000000440365 in ?? () No symbol table info available. #10 0x0000000000595b80 in ?? () No symbol table info available. #11 0x0000003a00c077f1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #12 0x0000003a004e5ccd in clone () from /lib64/libc.so.6 No symbol table info available. (gdb) continue Continuing. [Thread 0x7f0369139700 (LWP 11349) exited] [Thread 0x7f036993a700 (LWP 9523) exited] Program terminated with signal SIGABRT, Aborted. The program no longer exists. (gdb) quit Tell me if it help, or if you need more. Regards, Le 29/08/13, Nick Milas <nick(a)eurobjects.com> a écrit : > On 29/8/2013 12:42 μμ, "POISSON Frédéric" wrote: > > >The server shutdown when i add this entry and with slapd option "-d 255" i have : > >slapd: result.c:813: slap_send_ldap_result: Assertion `!((rs->sr_err)<0)' failed. > >/etc/init.d/slapd: line 285: 5461 Aborted $SLAPD_BIN -h "$SLAPD_SERVICES" $SLAPD_PARAMS > > > >Notice that i test this ldif modification on release 2.4.35 without problem. > > Can you try taking a full backtrace? > > See for example: http://www.openldap.org/lists/openldap-technical/201111/msg00243.html > > I am not a developer, but I have been through the same situation, so I know that a full backtrace is needed for troubleshooting. > > Best regards, > Nick > > > -- Frederic Poisson

2 1

OpenLDAP 2.4.36 slapd crash with "assertion failed" message
by "POISSON Frédéric" 29 Aug '13

29 Aug '13

Hello, I'm testing the latest release of OpenLDAP 2.4.36 and my slapd stop while i'm doing a change on cn=config. My tests are with my own compilation of OpenLDAP on a RHEL6 server but i see the same problem with "LTB project RPMs" http://ltb-project.org/wiki/download#openldap with RHEL6 package. My aim is to modify cn=config like this in order to implement TLS, here is my ldif : dn: cn=config changetype: modify add: olcTLSRandFile olcTLSRandFile: /dev/random The server shutdown when i add this entry and with slapd option "-d 255" i have : slapd: result.c:813: slap_send_ldap_result: Assertion `!((rs->sr_err)<0)' failed. /etc/init.d/slapd: line 285: 5461 Aborted $SLAPD_BIN -h "$SLAPD_SERVICES" $SLAPD_PARAMS Notice that i test this ldif modification on release 2.4.35 without problem. Is there any changes inside cn=config behavior with release 2.4.36 that i don't see ? Thanks in advance, Regards, PS: This is my second submission to mailling list, sorry for the convenience. -- Frederic Poisson

2 1

OpenLDAP Samba4
by Pascal den Bekker 29 Aug '13

29 Aug '13

Hello, I want to use openldap as a backend for Samba4. I set up the openldap with a different port, because samba4 has an own "ldap" server running on port 389. I set up the standard config for samba4 like this: passdb backend = ldapsam:ldap://ldap.example.com:3389 ldap suffix = dc=ldap,dc=example,dc=com ldap user suffix = ou=users ldap group suffix = ou=groups ldap machine suffix = ou=computers ldap idmap suffix = ou=Idmap ldap delete dn = no ldap admin dn = cn=admin,dc=ldap,dc=example,dc=com ldap ssl = no ldap passwd sync = yes idmap_ldb:use rfc2307 = Yes invalid users = root Created also the ou's in openldap, added a couple of users in openldap. Also set the smbpasswd, but everytime when I try to ask the openldap through samba. Im getting: smbldap_search_domain_info: Adding domain info for OPENCHANGE failed with NT_STATUS_UNSUCCESSFUL Do I still need to load the samba.schema in openldap ? And when yes.. How do I do that?? openldap: 2.4.31 samba: 4.0.1 OS: Debian Wheezy Cheers, -- Pascal den Bekker Linux System Administrator Affinitas GmbH | Kohlfurter Straße 41/43 | 10999 Berlin | Germany email: pascal_den.bekker(a)affinitas.de | tel: +49 30 868 000 140 www.edarling.de | www.shopaman.de Geschäftsführer: Lukas Brosseder, David Khalil, Michael Schrezenmaier Eingetragen beim Amtsgericht Berlin-Charlottenburg, HRB 115958

3 3

Object not found
by espeake＠oreillyauto.com 28 Aug '13

28 Aug '13

I have a user name readonly that we use in our applications to get uid's. THis has worked in the past with our old LDAP solution. We have moved to 2.4.31 on Ubuntu 12.04 with a n-way Multi master setup. The slap cat for this database looks like this. dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=oreillyauto,dc=com olcAccess: {0}to attrs=userPassword by anonymous auth by * none olcAccess: {1}to dn.subtree="dc=oreillyauto,dc=com" by group/groupOfUniqueName s/uniqueMember="cn=System Administrators,ou=Groups,dc=oreillyauto,dc=com" wri te by group/groupOfUniqueNames/uniqueMember="cn=LDAP Admin,ou=Groups,dc=oreil lyauto,dc=com" write by * none break olcAccess: {2}to attrs=userPassword by group/groupOfUniqueNames/uniqueMember=" cn=Authenticate,ou=Groups,dc=oreillyauto,dc=com" write by anonymous auth by s elf write olcAccess: {3}to attrs=uid by anonymous read by users read olcAccess: {4}to attrs=ou,employeeNumber by users read olcAccess: {5}to dn.subtree="ou=System,dc=oreillyauto,dc=com" by dn.subtree="o u=Users,dc=oreillyauto,dc=com" none by users read olcAccess: {6}to dn.children="ou=Groups,dc=oreillyauto,dc=com" by dnattr=owner write by dnattr=uniqueMember read by * none olcAccess: {7}to dn.children="ou=Users,dc=oreillyauto,dc=com" by self read by group/groupOfUniqueNames/uniqueMember="cn=Authenticate,ou=Groups,dc=oreillya uto,dc=com" read by * none olcAccess: {8}to * by self read by users read olcAddContentAcl: FALSE olcLastMod: TRUE olcLimits: {0}dn.exact="uid=syncrepl,ou=System,dc=oreillyauto,dc=com" time.sof t=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited olcLimits: {1}dn.exact="uid=ldapAdmin,ou=System,dc=oreillyauto,dc=com" time.so ft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited olcLimits: {2}dn.exact="uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com" time .soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: uid=admin,dc=oreillyauto,dc=com olcRootPW:: c2VjcmV0 olcSyncUseSubentry: FALSE olcDbCacheSize: 50000 olcDbCheckpoint: 512 30 olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 150000 olcDbIndex: objectClass eq olcDbIndex: cn eq olcDbIndex: uid eq olcDbIndex: oreillyGroup eq olcDbIndex: locationEntry eq olcDbIndex: counterNumber eq olcDbIndex: businessCategory eq olcDbIndex: locationNumber eq olcDbIndex: position eq olcDbIndex: title eq,subany olcDbIndex: givenName eq,subany olcDbIndex: functionListing eq olcDbIndex: manager eq olcDbIndex: sn eq,subany olcDbIndex: nickName eq,subany olcDbIndex: employeeNumber eq olcDbIndex: ou eq olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq olcDbIndex: supervisor eq olcDbIndex: status eq olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 structuralObjectClass: olcHdbConfig entryUUID: 91ce693e-9e13-1032-84c2-0151b658a842 createTimestamp: 20130820183919Z creatorsName: cn=config olcMirrorMode: TRUE olcSyncrepl: {0}rid=004 provider=ldap://tntest-ldap-3.oreillyauto.com b inddn="uid=admin,dc=oreillyauto,dc=com" bindmethod=simple credentials=<password> searchbase="dc=oreillyauto,dc=com" type=refreshAndPersist retry="5 5 5 +" tim eout=1 olcSyncrepl: {1}rid=005 provider=ldap://tntest-ldap-1.oreillyauto.com binddn=" uid=admin,dc=oreillyauto,dc=com" bindmethod=simple credentials=<password> searchb ase="dc=oreillyauto,dc=com" type=refreshAndPersist retry="5 5 5 +" timeout=1 olcSyncrepl: {2}rid=006 provider=ldap://tntest-ldap-2.oreillyauto.com binddn=" uid=admin,dc=oreillyauto,dc=com" bindmethod=simple credentials=<password> searchb ase="dc=oreillyauto,dc=com" type=refreshAndPersist retry="5 5 5 +" timeout=1 entryCSN: 20130821193620.549061Z#000000#002#000000 modifiersName: uid=admin,dc=oreillyauto,dc=com modifyTimestamp: 20130821193620Z And the ldap logs show this: Aug 28 07:56:48 tntest-ldap-1 slapd[3067]: conn=27464 op=0 BIND dn="uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com" method=128 Aug 28 07:56:48 tntest-ldap-1 slapd[3067]: conn=27464 op=0 BIND dn="uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com" mech=SIMPLE ssf=0 Aug 28 07:56:48 tntest-ldap-1 slapd[3067]: conn=27464 op=0 RESULT tag=97 err=0 text= Aug 28 07:56:48 tntest-ldap-1 slapd[3067]: conn=27464 op=1 SRCH base="uid=espeake,ou=Users,dc=oreillyauto,dc=com" scope=0 deref=3 filter="(objectClass=*)" Aug 28 07:56:48 tntest-ldap-1 slapd[3067]: conn=27464 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text= Aug 28 07:56:48 tntest-ldap-1 slapd[3067]: conn=27464 op=2 UNBIND Aug 28 07:56:48 tntest-ldap-1 slapd[3067]: conn=27464 fd=40 closed We had one issue with this server not running a rebuild last night due to a certificate error of the cacert not being found and we are addressing the through the following article: http://www.mikepilat.com/blog/2011/05/adding-a-certificate-authority-to-the… Searching as the ldapadmin user I find the user. So I am thinking that I need to adjust the ACL here but I'm not seeing what is wrong. Thanks, Eric Speake Web Systems Administrator O'Reilly Auto Parts This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.

2 2

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical August 2013