openldap-technical

openldap-technical@openldap.org

7 participants
9901 discussions

Re: Kerberos issue running OpenLDAP on Mac OS X Mavericks
by Dan White 27 Mar '14

27 Mar '14

Putting the email list back into the CC. On 03/20/14 10:16 -0500, Denis Ahearn wrote: >Thanks for responding Dan. We have spent the past several days taking the >information you provided and trying to get smarter about how OpenLDAP and >Kerberos work on Mac OS X Mavericks. Unfortunately we haven't made much >progress. I think it may be because the way we are trying to use OpenLDAP >is not the standard way that Apple intends it to be used from a server or >client standpoint, so there doesn't seem to be any documentation available >that speaks directly to our use case. Responses to your questions are >listed below. > >>> If you are authenticating against Active Directory, how does slapd fit >>> into the picture? > >Our Rails app authenticates using Active Directory only in staging and >production. We're using OpenLDAP (slapd) in our local development >environments to simulate this (i.e. to provide a local LDAP server that >serves the purpose that Active Directory does in production). To test >locally, we define an organization, groups and users in ldif files that get >loaded into OpenLDAP using ldapadd. > >>> Do you have an authz-regex rule mapping the authentication identity to >>> this? Can you reproduce this problem with ldapsearch/ldapwhoami, using >>> the same parameters as your ruby code? > >Are you referring to setting an authz-regex rule in slapd.conf? If so, we >do not have any authz-regex rules in our slapd.conf. I attached the >slapd.conf and ldap.conf files that are being used with OpenLDAP if that >helps. > >>> It appears your client has a kerberos ticket, and is attempting GSSAPI >>> authentication. You can verify that with klist or your OS's kerberos >>> utilities. > >I ran the klist command on the Mac that is having this issue. Output is >below: > >$ klist > >Credentials cache: API:77A8E90B-01BF-4F18-A94E-035C3AB25A59 > > Principal: dahearn(a)BWD.INT > > Issued Expires Principal > > >>> The client side Ruby code may allow you to configure a sasl mechanism. >>> If not, see ldap.conf(5) and set an appropriate LDAPSASL_MECH >>> environment variable or set SASL_MECH within your home .ldaprc file >>> (to, for instance, DIGEST-MD5). > >We tried the suggestions you listed above, none of which seemed to have any >effect on OpenLDAP's behavior (output in slapd.log is exactly the same). I'm still not clear if ruby is attempting SASL GSSAPI authentication or not. Your syslog (auth facility) may tell you that. Since you have a ticket, it's certainly possible. You can disable GSSAPI in a couple of additional ways: 1) Remove the SASL GSSAPI shared library, assuming your cyrus sasl install was compiled using shared libraries. pluginviewer (or saslpluginview) should list the mechanisms which are installed. 2) Configure a slapd.conf SASL configuration, on the server, which explicitly lists which mechanisms you wish to offer. The FAQ at: http://www.cyrussasl.org/mediawiki/index.php/FAQ details how to *enable* GSSAPI for slapd. Find out where cyrus sasl is looking for config files (e.g. /usr/lib/sasl2 or /etc/sasl2) and create a slapd.conf file with this line: mech_list: PLAIN LOGIN DIGEST-MD5 Are you performing pass-through authentication? In that case, try running saslauthd in debug mode for testing. >We are only using OpenLDAP in our development environment as a way to store >groups and users for testing purposes, and to provide an LDAP server that >our application can talk to in the same way it talks to Active Directory in >our production environment. We rely upon logic in the application (the >Ruby Devise and CanCan gems) to provide the necessary authentication and >authorization services. What I think we need to do is make OpenLDAP not >use Kerberos or other authentication mechanisms, but I haven't been able to >figure out if this is possible and if so, how to do that. Does this sound >like the way to go? If so, can you provide any assistance in setting this >up? Is there anything else I can send you to help you understand our setup? Replace the ruby authentication step with a ldapsearch/ldapwhoami call (with a -d -1 option for debugging on the client side). Or see if you can specify a debug option within Ruby (assuming it is using libldap). If you can figure out how your ruby code is connecting to the server in this way, your problem will likely stand out pretty quickly. A wireshark trace of the ruby ldap connection may help with that as well. -- Dan White

2 3

Changing cert paths may cause openldap to stop
by Nick Milas 27 Mar '14

27 Mar '14

Hi, On 2.4.39 (CentOS 5.10 x86_64), I found that if I attempt to change certificate values but there is an error in a path, openldap stops. I would expect this should be avoided. Openldap should reject the modification and not stop. Running the modification below, it hungs; we press Ctrl-C (and we print a full backtrace), then we find slapd is stopped. Please check the output below. Best regards, Nick Example: ------------------------------------------------------------------------------- Modification file: /root/work/certmod2: ------------------------------------------------------------------------------- dn: cn=config changetype: modify replace: olcTLSCACertificateFile olcTLSCACertificateFile: /usr/local/openldap/etc/openldap/certs/chain-2241.pem - replace: olcTLSCertificateFile olcTLSCertificateFile: /usr/local/openldap/etc/openldap/certs/cert-2241.pem - replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /usr/local/openldap/etc/openldap/certs/priv-2241.pem ------------------------------------------------------------------------------- In this case priv-2241.pem does not exist (the correct value would be: key-2241.pem). ------------------------------------------------------------------------------- Modification attempt: ------------------------------------------------------------------------------- # /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D "cn=admin,cn=config" -f /root/work/certmod2 ldap_initialize( ldap://localhost ) Enter LDAP Password: replace olcTLSCACertificateFile: /usr/local/openldap/etc/openldap/certs/chain-2241.pem replace olcTLSCertificateFile: /usr/local/openldap/etc/openldap/certs/cert-2241.pem replace olcTLSCertificateKeyFile: /usr/local/openldap/etc/openldap/certs/priv-2241.pem modifying entry "cn=config" <it hungs and we press Ctrl-C> ldap_result: Can't contact LDAP server (-1) ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- (gdb) backtrace full #0 0x00000033bf830265 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x00000033bf831d10 in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x00000033bf829706 in __assert_fail () from /lib64/libc.so.6 No symbol table info available. #3 0x000000000044f66d in slap_send_ldap_result (op=0xcd75580, rs=0x2ba278651c20) at result.c:813 tmp = <value optimized out> otext = 0x2ba278650664 "" oref = 0x0 __PRETTY_FUNCTION__ = "slap_send_ldap_result" #4 0x000000000042ca7f in config_back_modify (op=0xcd75580, rs=0x2ba278651c20) at bconfig.c:5926 cfb = 0x8787a0 ce = 0xffffffff last = 0x600000000 ml = 0x6 ca = {argc = 2, argv = 0xce77200, argv_size = 513, line = 0xce75c00 "/usr/local/openldap/etc/openldap/certs/priv-2241.pem", tline = 0xc81a880 "\220d\224\f", fname = 0x5c7c99 "slapd", lineno = 0, log = "olcTLSCertificateKeyFile: value #0", '\000' <repeats 4089 times>, reply = {err = 0, msg = '\000' <repeats 255 times>}, depth = 0, valx = -1, values = {v_int = 209823808, v_uint = 209823808, v_long = 209823808, v_ulong = 209823808, v_ber_t = 209823808, v_string = 0xc81a840 "/usr/local/openldap/etc/openldap/certs/priv-2241.pem", v_bv = {bv_len = 209823808, bv_val = 0x0}, v_dn = {vdn_dn = {bv_len = 209823808, bv_val = 0x0}, vdn_ndn = {bv_len = 0, bv_val = 0x0}}, v_ad = 0xc81a840}, rvalue_vals = 0x0, rvalue_nvals = 0x0, op = 0, type = 8, ca_op = 0xcd75580, be = 0x87a520, bi = 0x0, ca_entry = 0xc81ab48, ca_private = 0xc81a280, cleanup = 0x427850 <config_tls_cleanup>, table = Cft_Global} rdn = {bv_len = 2, bv_val = 0xc81a7e0 "cn=config"} rad = 0xc7c4e90 do_pause = 1 #5 0x0000000000455ff7 in fe_op_modify (op=0xcd75580, rs=0x2ba278651c20) at modify.c:303 repl_user = <value optimized out> bd = 0x87a520 textbuf = "\005\000\000\000\000\000\000\000xZ\327\f\000\000\000\000h[\327\f\000\000\000\000\003\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000\270Z\327\f\000\000\000\000P\271}\f\000\000\000\000\000\\\347\f\000\000\000\000\320[\347\f\000\000\000\000:\213E", '\000' <repeats 21 times>, "4\000\000\000\000\000\000\000\000\\\347\f\000\000\000\000\270U\327\f", '\000' <repeats 12 times>, "@\\\347\f", '\000' <repeats 12 times>"\340, \272}\f\000\000\000\000\020", '\000' <repeats 15 times>"\304, XE\000\000\000\000\000\340:\306\f\000\000\000\000\000\001\000\000\000\000\000\000\320\032ex\242+\000\000@\034ex\242+\000\000\200U\327\f\000\000\000\000\001\000\000\000\000\000\000\000\270U\327\f\000\000\000\000\250U\327\f\000\000\000\000\340:\306\f\000\000\000\000\251\063"... #6 0x0000000000456762 in do_modify (op=0xcd75580, rs=0x2ba278651c20) at modify.c:177 dn = {bv_len = 9, bv_val = 0xcd75459 "cn=config"} textbuf = "\000\b\000\000\000\000\000\000\000\001\000\000\000\000\000\000 \000\000\000\000\000\000\000\004", '\000' <repeats 15 times>"\377, \017\000\000\000\000\000\000\260\005\002", '\000' <repeats 14 times>"\360, \377\377\377\377\377\377\000\000\000\000~", '\000' <repeats 27 times>"\271, \312\065\062\"", '\000' <repeats 11 times>"\340, I\265\277\063\000\000\000\000\000\020\000\000\000\000\000\000\000\020\000\000\000\000\000\001\000\000\000\000\000\000\000\340:\306\f\000\000\000\000\000\000\020\000\000\000\000\000\236@\207\277\063", '\000' <repeats 13 times>, "\020\000\000\000\000\000p\035ex\242+\000\000Mc[\000\000\000\000\000\000\000\020\000\000\000\000\000\373\210E\000\000\000\000\000\001\000\000\000\000\000\000\000\330\002I\000\000\000\000\000\200U\327\f\000\000\000\000]\226F\---Type <return> to continue, or q <return> to quit--- 000\000\000\000" tmp = 0x0 #7 0x000000000043f0d5 in connection_operation (ctx=0x2ba278651d70, arg_v=<value optimized out>) at connection.c:1155 rc = <value optimized out> cancel = <value optimized out> op = 0xcd75580 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = -1, sr_matched = 0x0, sr_text = 0x2ba278650664 "", 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 = 0xc9c2d20 memctx = 0xcc63ae0 memctx_null = 0x0 __PRETTY_FUNCTION__ = "connection_operation" #8 0x000000000043f6af in connection_read_thread (ctx=0x2ba278651d70, argv=<value optimized out>) at connection.c:1291 s = 12 #9 0x000000000058d92c in ldap_int_thread_pool_wrapper (xpool=0xc7c8430) at tpool.c:688 task = 0xcd752f0 work_list = <value optimized out> ctx = {ltu_id = 47976804591936, ltu_key = {{ltk_key = 0x43e040, ltk_data = 0xcd75950, ltk_free = 0x43e110 <conn_counter_destroy>}, { ltk_key = 0x48ff50, ltk_data = 0xcc63ae0, ltk_free = 0x48ff70 <slap_sl_mem_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 30 times>}} kctx = <value optimized out> keyslot = 435 hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #10 0x00002ba23235583d in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #11 0x00000033bf8d526d in clone () from /lib64/libc.so.6 No symbol table info available. -------------------------------------------------------------------------------

1 0

Failure in 2.4.32: similar experiences?
by Nick Urbanik 26 Mar '14

26 Mar '14

Dear Folks, We have some moderately busy OpenLDAP servers, OpenLDAP 2.4.32 running on CentOS 5.8 on HP BL495cG6 blades, with 24GB RAM, in a cluster of four, using LVS to balance the load. They peak at just over 3000 LDAP connections per second. They stopped serving requests, or at least, began serving them so slowly that they caused an outage. After my colleague restarted slapd, they resumed serving the requests. slapd didn't die, or dump core. Sadly, since the most minimal logging produces 25GB per day, so we have that turned off, and after the event, I now am graphing some of the statistics from the monitor database, though that provides less detail than I would wish. My questions: ============= Has anyone had a similar experience of failure with this version of OpenLDAP specifically, or with any other version? Has anyone any suggestions on what might have happened? I am upgrading LDAP to 2.4.39, but would like to know if there is a known problem that I will resolve by this upgrade. Here is a "sanitised" view of our configuration: # slapd.conf generated by /usr/bin/conform include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/local.schema include /etc/openldap/schema/prefs.schema loglevel stats allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args tool-threads 8 password-hash {CRYPT} password-crypt-salt-format "$1$%.8s" TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt TLSCertificateFile /etc/openldap/ldap.syd.crt TLSCertificateKeyFile /etc/openldap/ldap.syd.key ############################################################ # GLOBAL database definition ############################################################ access to dn.base="" by peername.ip=133.3.193.2 read by peername.ip=19.21.201.10 read by * read access to dn.base="cn=Subschema" by * read ############################################################ # ou=tree1,ou=name database definition ############################################################ database bdb suffix "ou=tree1,ou=name" rootdn cn=manager,ou=tree1,ou=name rootpw root-password directory /var/lib/ldap/ou=tree1,ou=name index domain eq,pres index entryCSN eq index entryUUID eq index mail eq,pres index objectClass eq index uid eq,pres shm_key 331 cachesize 100000 idlcachesize 100000 checkpoint 32768 30 idletimeout 3600 writetimeout 90000 access to dn.base="ou=tree1,ou=name" by peername.ip=96.76.69.162 read by * none break access to dn.subtree="ou=tree1,ou=name" by dn.base="cn=Reader,ou=tree1,ou=name" read by peername.ip=205.191.75.42 read by peername.ip=198.132.212.127 read by peername.ip=101.169.45.146 read by peername.ip=212.38.134.82 read by peername.ip=127.0.0.1 read by peername.ip=49.15.162.36 read by peername.ip=142.226.69.215 read by peername.ip=236.107.103.158 read by peername.ip=57.167.92.229 read by peername.ip=138.57.161.36 read by peername.ip=99.33.110.154 read by peername.ip=196.119.159.149 read by peername.ip=44.116.9.128 read by peername.ip=122.234.222.27 read by self peername.ip=154.238.170.210 read by self peername.ip=31.62.15.241 read by self peername.ip=163.226.124.118 read by self peername.ip=92.190.127.61 read by self peername.ip=125.225.28.232 read by self peername.ip=122.148.131.239 read by self peername.ip=118.160.216.124 read by self peername.ip=74.226.71.41 read by self peername.ip=179.149.175.90 read by self peername.ip=235.160.10.186 read by self peername.ip=125.80.123.119 read by self peername.ip=185.5.66.203 read by self peername.ip=158.224.9.61 read by self peername.ip=46.146.95.97 read by self peername.ip=6.182.235.60 read by self peername.ip=7.137.32.196 read by self peername.ip=204.184.227.24 read by self peername.ip=56.10.14.169 read by self peername.ip=165.49.58.78 read by self peername.ip=165.211.155.235 read by self peername.ip=119.216.126.40 read by self peername.ip=94.212.46.227 read by self peername.ip=210.225.203.227 read by self peername.ip=171.235.159.67 read by self peername.ip=28.94.19.93 read by self peername.ip=206.12.128.149 read by self peername.ip=18.223.36.165 read by self peername.ip=35.164.112.79 read by self peername.ip=145.100.109.232 read by self peername.ip=10.230.19.137 read by self peername.ip=86.124.99.133 read by self peername.ip=56.223.60.177 read by self peername.ip=140.114.55.210 read by self peername.ip=216.13.135.39 read by self peername.ip=5.93.220.80 read by self peername.ip=87.215.35.140 read by self peername.ip=162.101.170.221 read by self peername.ip=100.59.12.102 read by self peername.ip=58.223.90.131 read by self peername.ip=124.165.37.123 read by self peername.ip=11.178.120.42 read by self peername.ip=99.205.107.56 read by self peername.ip=31.26.172.88 read by self peername.ip=211.133.184.38 read by self peername.ip=84.215.59.209 read by self peername.ip=13.70.104.6 read by self peername.ip=111.100.110.74 read by self peername.ip=190.199.36.1 read by self peername.ip=236.212.185.240 read by self peername.ip=180.4.69.152 read by self peername.ip=38.63.162.124 read by self peername.ip=68.34.84.216 read by self peername.ip=43.41.142.100 read by self peername.ip=118.225.164.10 read by self peername.ip=40.26.24.236 read by self peername.ip=197.161.148.167 read by self peername.ip=148.163.210.9 read by self peername.ip=161.141.31.120 read by self peername.ip=85.59.211.7 read by self peername.ip=237.59.225.239 read by self peername.ip=29.114.216.84 read by anonymous auth by * none break syncrepl rid=001 provider=ldap://master:389 type=refreshAndPersist bindmethod=simple binddn=cn=syncrepl,ou=tree1,ou=name credentials=syncrepl-password searchbase="ou=tree1,ou=name" retry="5 10 60 +" ############################################################ # ou=tree2,ou=name database definition ############################################################ database bdb suffix "ou=tree2,ou=name" rootdn cn=manager,ou=tree2,ou=name rootpw root-password directory /var/lib/ldap/ou=tree2,ou=name index avcid eq index entryCSN eq index entryUUID eq index gsid eq index objectClass eq shm_key 320 cachesize 100000 idlcachesize 100000 checkpoint 32768 30 idletimeout 3600 writetimeout 90000 access to dn.base="ou=tree2,ou=name" by peername.ip=1.224.5.235 read by * none break access to dn.subtree="ou=tree2,ou=name" by dn.base="cn=Reader,ou=tree2,ou=name" read by peername.ip=124.182.243.237 read by peername.ip=73.200.132.164 read by peername.ip=5.106.199.123 read by peername.ip=243.60.43.234 read by peername.ip=127.0.0.1 read by anonymous auth by * none break syncrepl rid=010 provider=ldap://master:389 type=refreshAndPersist bindmethod=simple binddn=cn=syncrepl,ou=tree2,ou=name credentials=syncrepl-password searchbase="ou=tree2,ou=name" retry="5 10 60 +" ############################################################ # ou=tree3,ou=name database definition ############################################################ database bdb suffix "ou=tree3,ou=name" rootdn cn=manager,ou=tree3,ou=name rootpw root-password directory /var/lib/ldap/ou=tree3,ou=name index entryCSN eq index entryUUID eq index fnn eq index lineid eq index objectClass eq index serviceid eq index ullsid eq shm_key 74 cachesize 100000 idlcachesize 100000 checkpoint 32768 30 idletimeout 3600 writetimeout 90000 access to dn.base="ou=tree3,ou=name" by peername.ip=100.131.166.211 read by * none break access to dn.subtree="ou=tree3,ou=name" by dn.base="cn=Reader,ou=tree3,ou=name" read by peername.ip=39.236.93.167 read by peername.ip=48.145.97.90 read by peername.ip=143.186.10.231 read by peername.ip=35.68.19.116 read by peername.ip=127.0.0.1 read by anonymous auth by * none break syncrepl rid=008 provider=ldap://master:389 type=refreshAndPersist bindmethod=simple binddn=cn=syncrepl,ou=tree3,ou=name credentials=syncrepl-password searchbase="ou=tree3,ou=name" retry="5 10 60 +" ############################################################ # ou=tree4,ou=name database definition ############################################################ database bdb suffix "ou=tree4,ou=name" rootdn cn=manager,ou=tree4,ou=name rootpw root-password directory /var/lib/ldap/ou=tree4,ou=name index cn eq index entryCSN eq index entryUUID eq index objectClass eq shm_key 195 cachesize 100000 idlcachesize 100000 checkpoint 32768 30 idletimeout 3600 writetimeout 90000 access to dn.base="ou=tree4,ou=name" by peername.ip=26.233.142.132 read by * none break access to dn.subtree="ou=tree4,ou=name" by dn.base="cn=Reader,ou=tree4,ou=name" read by peername.ip=127.0.0.1 read by anonymous auth by * none break access to dn.subtree="" by peername.ip=101.156.205.102 read by peername.ip=136.25.130.235 read by peername.ip=136.206.49.17 read by peername.ip=37.21.18.99 read by * none break syncrepl rid=002 provider=ldap://master:389 type=refreshAndPersist bindmethod=simple binddn=cn=syncrepl,ou=tree4,ou=name credentials=syncrepl-password searchbase="ou=tree4,ou=name" retry="5 10 60 +" ############################################################ # ou=tree5,ou=name database definition ############################################################ database bdb suffix "ou=tree5,ou=name" rootdn cn=manager,ou=tree5,ou=name rootpw root-password directory /var/lib/ldap/ou=tree5,ou=name index entryCSN eq index entryUUID eq index gsid eq index objectClass eq index uid eq shm_key 626 cachesize 100000 idlcachesize 100000 checkpoint 32768 30 idletimeout 3600 writetimeout 90000 access to dn.base="ou=tree5,ou=name" by peername.ip=225.143.210.78 read by * none break access to dn.subtree="ou=tree5,ou=name" by dn.base="cn=Reader,ou=tree5,ou=name" read by peername.ip=106.154.145.84 read by peername.ip=197.28.75.183 read by peername.ip=179.151.185.161 read by peername.ip=4.60.182.12 read by peername.ip=127.0.0.1 read by anonymous auth by * none break syncrepl rid=011 provider=ldap://master:389 type=refreshAndPersist bindmethod=simple binddn=cn=syncrepl,ou=tree5,ou=name credentials=syncrepl-password searchbase="ou=tree5,ou=name" retry="5 10 60 +" ############################################################ # ou=tree6,ou=name database definition ############################################################ database bdb suffix "ou=tree6,ou=name" rootdn cn=manager,ou=tree6,ou=name rootpw root-password directory /var/lib/ldap/ou=tree6,ou=name index entryCSN eq index entryUUID eq index objectClass eq index uid eq index username eq shm_key 290 cachesize 100000 idlcachesize 100000 checkpoint 32768 30 idletimeout 3600 writetimeout 90000 access to dn.base="ou=tree6,ou=name" by peername.ip=195.44.90.201 read by * none break access to dn.subtree="ou=tree6,ou=name" by dn.base="cn=Reader,ou=tree6,ou=name" read by peername.ip=131.55.25.176 read by peername.ip=52.151.227.147 read by peername.ip=144.91.87.53 read by peername.ip=51.236.131.115 read by peername.ip=127.0.0.1 read by anonymous auth by * none break syncrepl rid=009 provider=ldap://master:389 type=refreshAndPersist bindmethod=simple binddn=cn=syncrepl,ou=tree6,ou=name credentials=syncrepl-password searchbase="ou=tree6,ou=name" retry="5 10 60 +" ############################################################ # ou=tree7,ou=name database definition ############################################################ database bdb suffix "ou=tree7,ou=name" rootdn cn=manager,ou=tree7,ou=name rootpw root-password directory /var/lib/ldap/ou=tree7,ou=name index entryCSN eq index entryUUID eq index objectClass eq index uid eq index username eq shm_key 105 cachesize 100000 idlcachesize 100000 checkpoint 32768 30 idletimeout 3600 writetimeout 90000 access to dn.base="ou=tree7,ou=name" by peername.ip=82.36.151.29 read by peername.ip=69.183.15.150 read by * none break access to dn.subtree="ou=tree7,ou=name" by peername.ip=81.44.61.5 read by peername.ip=75.34.88.223 read by peername.ip=40.106.122.233 read by dn.base="cn=Reader,ou=tree7,ou=name" read by peername.ip=127.0.0.1 read by anonymous auth by * none break syncrepl rid=003 provider=ldap://master:389 type=refreshAndPersist bindmethod=simple binddn=cn=syncrepl,ou=tree7,ou=name credentials=syncrepl-password searchbase="ou=tree7,ou=name" retry="5 10 60 +" ############################################################ # ou=tree8,ou=name database definition ############################################################ database bdb suffix "ou=tree8,ou=name" rootdn cn=manager,ou=tree8,ou=name rootpw root-password directory /var/lib/ldap/ou=tree8,ou=name index entryCSN eq index entryUUID eq index objectClass eq index uid eq index username eq shm_key 280 cachesize 100000 idlcachesize 100000 checkpoint 32768 30 idletimeout 3600 writetimeout 90000 access to dn.base="ou=tree8,ou=name" by peername.ip=221.195.40.138 read by * none break access to dn.subtree="ou=tree8,ou=name" by dn.base="cn=Reader,ou=tree8,ou=name" read by peername.ip=211.28.110.6 read by peername.ip=4.134.128.66 read by peername.ip=194.183.122.54 read by peername.ip=89.223.206.194 read by peername.ip=28.88.175.182 read by peername.ip=209.169.46.101 read by peername.ip=230.21.178.118 read by peername.ip=41.55.202.55 read by peername.ip=127.0.0.1 read by anonymous auth by * none break syncrepl rid=004 provider=ldap://master:389 type=refreshAndPersist bindmethod=simple binddn=cn=syncrepl,ou=tree8,ou=name credentials=syncrepl-password searchbase="ou=tree8,ou=name" retry="5 10 60 +" ############################################################ # ou=tree9,ou=name database definition ############################################################ database bdb suffix "ou=tree9,ou=name" rootdn cn=manager,ou=tree9,ou=name rootpw root-password directory /var/lib/ldap/ou=tree9,ou=name index entryCSN eq index entryUUID eq index objectClass eq index uid eq index username eq shm_key 122 cachesize 100000 idlcachesize 100000 checkpoint 32768 30 idletimeout 3600 writetimeout 90000 access to dn.base="ou=tree9,ou=name" by peername.ip=153.54.1.23 read by * none break access to dn.subtree="ou=tree9,ou=name" by dn.base="cn=Reader,ou=tree9,ou=name" read by peername.ip=164.215.79.230 read by peername.ip=52.205.194.57 read by peername.ip=69.215.8.144 read by peername.ip=240.46.54.48 read by peername.ip=127.0.0.1 read by anonymous auth by * none break syncrepl rid=006 provider=ldap://master:389 type=refreshAndPersist bindmethod=simple binddn=cn=syncrepl,ou=tree9,ou=name credentials=syncrepl-password searchbase="ou=tree9,ou=name" retry="5 10 60 +" ############################################################ # ou=tree10,ou=name database definition ############################################################ database bdb suffix "ou=tree10,ou=name" rootdn cn=manager,ou=tree10,ou=name rootpw root-password directory /var/lib/ldap/ou=tree10,ou=name index entryCSN eq index entryUUID eq index mtaMacAddress eq index mtaSubcriberKey eq index objectClass eq shm_key 548 cachesize 100000 idlcachesize 100000 checkpoint 32768 30 idletimeout 3600 writetimeout 90000 access to dn.base="ou=tree10,ou=name" by peername.ip=111.64.19.131 read by * none break access to dn.subtree="ou=tree10,ou=name" by dn.base="cn=Reader,ou=tree10,ou=name" read by peername.ip=49.225.102.91 read by peername.ip=169.2.225.154 read by peername.ip=177.202.224.166 read by peername.ip=56.152.182.238 read by peername.ip=157.83.196.154 read by peername.ip=66.220.12.152 read by peername.ip=132.204.57.43 read by peername.ip=222.142.242.198 read by peername.ip=153.130.78.144 read by peername.ip=166.31.243.77 read by peername.ip=226.40.169.1 read by peername.ip=224.110.119.208 read by peername.ip=15.227.192.210 read by peername.ip=45.56.216.152 read by peername.ip=127.0.0.1 read by anonymous auth by * none break syncrepl rid=000 provider=ldap://master:389 type=refreshAndPersist bindmethod=simple binddn=cn=syncrepl,ou=tree10,ou=name credentials=syncrepl-password searchbase="ou=tree10,ou=name" retry="5 10 60 +" ############################################################ # ou=tree11,ou=name database definition ############################################################ database bdb suffix "ou=tree11,ou=name" rootdn cn=manager,ou=tree11,ou=name rootpw root-password directory /var/lib/ldap/ou=tree11,ou=name index entryCSN eq index entryUUID eq index objectClass eq index uid eq index username eq shm_key 215 cachesize 100000 idlcachesize 100000 checkpoint 32768 30 idletimeout 3600 writetimeout 90000 access to dn.base="ou=tree11,ou=name" by peername.ip=51.114.241.35 read by * none break access to dn.subtree="ou=tree11,ou=name" by dn.base="cn=Reader,ou=tree11,ou=name" read by peername.ip=17.32.79.33 read by peername.ip=140.205.127.168 read by peername.ip=190.147.122.157 read by peername.ip=170.66.104.2 read by peername.ip=45.154.226.85 read by peername.ip=116.172.183.88 read by peername.ip=96.51.58.70 read by peername.ip=85.240.27.171 read by peername.ip=127.0.0.1 read by anonymous auth by * none break syncrepl rid=005 provider=ldap://master:389 type=refreshAndPersist bindmethod=simple binddn=cn=syncrepl,ou=tree11,ou=name credentials=syncrepl-password searchbase="ou=tree11,ou=name" retry="5 10 60 +" ############################################################ # ou=tree12,ou=name database definition ############################################################ database monitor rootdn cn=manager,ou=tree12,ou=name rootpw root-password access to dn.subtree="ou=tree12,ou=name" by peername.ip=127.0.0.1 read by * none -- 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 0

MDB_MAP_FULL: Environment mapsize limit reached
by Aleksander Dzierżanowski 26 Mar '14

26 Mar '14

Hello OpenLDAP guru & fans. Recently I was trying to migrate from 'bdb' to 'mdb' backend by adding temporary additional instance of OpenLDAP. Unfortunately I'm unable to import database both using 'slapadd' or regular replication mechanism. What I got is exact same error: slapadd -b o=mysuffix < /tmp/mysuffix.ldif 5332ec95 => mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize limit reached (-30792) 5332ec95 => mdb_tool_entry_put: index_entry_add failed: err=80 5332ec95 => mdb_tool_entry_put: txn_aborted! Internal error (80) slapadd: could not add entry dn="uid=myuser,ou=People,ou=developers,o=suffix" (line=2080): txn_aborted! Internal error (80) _# 9.26% eta none elapsed none spd 2.3 M/s Closing DB... My bdb 'maxsize' argument is set to 1GB. Database is really small, it contain just few hundred of small entries. My OpenLDAP version is 2.4.38 from OpenLTB project (I'm unable to use 2.4.39 because I need to use CentOS 6.4 version, latest one is for 6.5). Changing only backend to 'bdb' in configuration make import succesfull. Any advices? regards, -- Aleksander

1 1

Not adding attributes
by espeake＠oreillyauto.com 26 Mar '14

26 Mar '14

I have just started getting this error in the past 10 days. There has not been any configuration changes that we can find. In googleing this error I am not finding anything that matches it. If I create an ldif file to add these for the user, that works fine. Mar 25 16:42:21 tn-ldap-1 slapd[14976]: conn=33594 op=17: memberof_value_modify DN="uid=dsmith174,ou=users,dc=oreillyauto,dc=com" add locationEntry="ou=Store4351,ou=Locations,dc=oreillyauto,dc=com" failed err=32 Mar 25 16:42:22 tn-ldap-1 slapd[14976]: conn=33594 op=19: memberof_value_modify DN="uid=dsmith174,ou=users,dc=oreillyauto,dc=com" add oreillyGroup="cn=Store Non-Management,ou=Groups,dc=oreillyauto,dc=com" failed err=32 Mar 25 16:42:22 tn-ldap-1 slapd[14976]: conn=33594 op=21: memberof_value_modify DN="uid=dsmith174,ou=users,dc=oreillyauto,dc=com" add oreillyGroup="cn=Store,ou=Groups,dc=oreillyauto,dc=com" failed err=32 What I do wonder about though in my olcDatabase={1}hdb folder I have two memberOf overlays. This is the first one. # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 a078db21 dn: olcOverlay={0}memberof objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {0}memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfUniqueNames olcMemberOfMemberAD: uniqueMember olcMemberOfMemberOfAD: oreillyGroup structuralObjectClass: olcMemberOf creatorsName: cn=config entryUUID: 91cea156-9e13-1032-84c3-0151b658a842 createTimestamp: 20130820183919Z entryCSN: 20130820183919.833799Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130820183919Z This is the second one. # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 fe8a4925 dn: olcOverlay={1}memberof objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {1}memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: oreillyOrgUnit olcMemberOfMemberAD: uniqueMember olcMemberOfMemberOfAD: locationEntry structuralObjectClass: olcMemberOf creatorsName: cn=config entryUUID: 91ceb650-9e13-1032-84c4-0151b658a842 createTimestamp: 20130820183919Z entryCSN: 20130820183919.834337Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130820183919Z I have am looking through the application to see if something could have changed in the way it is presenting the data. I haven't found anything yet. Am I correct in that an error 32 means that it couldn't find the uid to add the group to? Thanks, Eric Speake Web Systems Administrator O'Reilly Auto Parts (417) 862-2674 Ext. 1975 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

question about openldap restore with command sldapadd
by xiaoming zhao 25 Mar '14

25 Mar '14

All, I got one question, when doing openldap restore, in our script, we tried to remove the openldap/data directory, then restore the backup openldap files. but since we have other data added in openldap database after backup. then if we doing backup, it will remove the data newly added after backup. I tried to sldapadd with "-c" option, but the sldapadd command retrun value is 1. so we can't know if this is a error because of existing entry or some other error. Do you have any idea how to handle this case? ignore the existing entry when doing sldapadd. Thanks, Eric.

2 6

unsubscribe
by Alex Samad - Yieldbroker 25 Mar '14

25 Mar '14

1 0

Denying access to syncrepl consumere during initial DIT content load
by Christian Kratzer 24 Mar '14

24 Mar '14

Hi, I remember a discussion some time ago about the possibility of delaying access to a syncrepl. consumer during the intial DIT load. I have setup my servers to authenticate replication via sasl method external and the servers respective certificates which is nice. I have also setup limits and acl to the DIT as using a groupOfNames: olcLimits: group/groupOfNames/member="cn=replicators,ou=serviceaccounts,dc=cksoft,dc=net" size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=unlimited olcAccess: to * by group/groupOfNames/member="cn=replicators,ou=serviceaccounts,dc=cksoft,dc=net" read This is all nice and shiny and I like having my ldap consumers configured without cleartext credentials (apart from the cert private key of course) ;) The fun starts when I delete the DIT from multiple consumers and allow them to resync from masters. If they also resync from each other they could possibly authenticate using sasl external but they would not be allowed access to all of the DIT, all of the attributes or be unlimited using olcLimits as the group might not yet have been replicated. I also had major fun just reseeding a single server out of a set of 4 causing data loss on the servers that connected to the not yet full synced up server. This is another situation in which it would be nice to be able to disallow any ldap connections to a consumere while it is in the initial sync phase. I seem to recall there was discussion in possibly addiing such a feature but my google foo is lacking and I cannot find the discussion. In case there is not yet such a feauture I am considering firewalling access to slapd during the initial sync phase. Is there any ldap way of reliably detecting that initial sync has completed apart from tailing syslog and looking for csn commit messages ... Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/

7 21

RE: Slave not able to update master pwdFailureTime via chain.
by Brad dameron 24 Mar '14

24 Mar '14

>From what I read I need to setup authzTo. But having problems understanding what I need to set in the slaps.conf and on the allowed user. -------- Original message -------- From: Esteban Pereira <esteban.pereira(a)gepsit.fr> Date:03/20/2014 10:55 AM (GMT-08:00) To: Brad dameron <serpent6877(a)hotmail.com>,openldap-technical(a)openldap.org Subject: Re: Slave not able to update master pwdFailureTime via chain. I've never configured this kind of architecture, but as far as I know the ppolicy, I think my first thought configuring this would have been to not rebind as user because the attribute modified is an operational one which need the manage right (not sure about that) So I should have configured this with the replication user with manage right and without rebinding as a user when chaining to the master. Hope this help On Thu, Mar 20, 2014 at 6:14 PM, Brad dameron <serpent6877(a)hotmail.com>wrote: > I understand what you are saying. But this is what the > ppolicy_forward_updates says: > > ppolicy_forward_updates > Specify that policy state changes that result from Bind operations (such as recording > failures, lockout, etc.) on a consumer should be forwarded to a master instead of > being written directly into the consumer’s local database. This setting is only use‐ > ful on a replication consumer, and also requires the updateref setting and chain > overlay to be appropriately configured. > > So when a password failure occurs "pwdFailureTime" it relays it to the master as the user doing a MOD > from what I have seen in my logs. And thus the user doesn't have access to modify this attribute. > > Brad > > > > ------------------------------ > Date: Thu, 20 Mar 2014 12:13:02 +0100 > Subject: Re: Slave not able to update master pwdFailureTime via chain. > From: esteban.pereira(a)gepsit.fr > To: serpent6877(a)hotmail.com > CC: openldap-technical(a)openldap.org > > > Hi Brad, > > pwdFailureTime is an operational attribute, I don't think any user can > modify it on any instance. May be you should try to modify it on the master > to see if it comes from this assumption. > > Esteban > > > On Thu, Mar 20, 2014 at 11:33 AM, Brad dameron <serpent6877(a)hotmail.com>wrote: > > OpenLDAP 2.4.23-26 on CentOS 5. I am trying to get the pwdFailureTime > updated on the master when the slave recieves a password failure. Here is > my config. It's pretty simple and basic. No TLS. > > Master: > > access to attrs=userPassword > by group.exact="cn=ldapadmins,ou=Groups,dc=test,dc=net" write > by dn.exact="cn=replication,dc=test,dc=net" read > by self write > by anonymous auth > by * none > access to * > by group.exact="cn=ldapadmins,ou=Groups,dc=test,dc=net" write > by dn.exact="cn=replication,dc=test,dc=net" write > by self write > by users read > by anonymous read > by * none > > > > Slave: > > overlay chain > chain-uri ldap://172.16.0.84:389 > chain-rebind-as-user TRUE > chain-idassert-bind bindmethod=simple > binddn="cn=replication,dc=test,dc=net" > credentials="MyPasswd" > mode="self" > chain-return-error TRUE > > # Password Policy > overlay ppolicy > ppolicy_default "cn=default,ou=Policies,dc=test,dc=net > ppolicy_use_lockout > ppolicy_forward_updates > > > # Slave Replication > syncrepl rid=101 > provider=ldap://172.16.0.84:389 > type=refreshAndPersist > interval=00:00:01:00 > retry="60 10 300 +" > searchbase="dc=test,dc=net" > schemachecking=off > bindmethod=simple > binddn="cn=replication,dc=test,dc=net" > credentials="MyPasswd" > updateref "ldap://172.16.0.84:389" > > > > I see the connection on the master but it gives a permission error: > > > Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 MOD > dn="cn=testuser,ou=People,dc=test,dc=net" > Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 MOD > attr=pwdFailureTime > Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 RESULT tag=103 > err=50 text= > > > I read that you maybe need authzTo added to the binddn for the chain? Or > is this only for TLS? > > I tried adding this ldif: > > dn: cn=replication,dc=test,dc=net > changetype: modify > add: authzTo > authzTo: * > > And even set the: > > chain-idassert-authzFrom "*" > > in the chain. But it always gives me the error code 50 not enough > permissions. I believe it is supposed to give access to the user to MOD the > pwdFailureTime tribute knowing it is coming from a relay. But I can't find > very specific docs on this or see what is wrong. Any help apreciated. > > Thanks, > Brad > > >

1 0

Build mdb tools
by "POISSON Frédéric" 21 Mar '14

21 Mar '14

Hello, I'm trying to build mdb tools (mdb_stat and mdb_copy inside libraries/liblmdb directory) on a Solaris 10 SPARC operating system with OpenLDAP 2.4.39. Is there some requirements for building the tools on this OS because i have a error during build ? Here is my result (while i do not set any specific gcc flags) : # make ... gcc -pthreads -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast mdb_stat.o liblmdb.a -o mdb_stat Undefined first referenced symbol in file fdatasync liblmdb.a(mdb.o) ld: fatal: Symbol referencing errors. No output written to mdb_stat collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `mdb_stat' # Notice that i use a gcc 3.4.3 and gcc option "-pthread" do not exist for this gcc release, i had to replace it by "-pthreads". I try to read mdb.c for any specific options but i don't find anything... Notice also that i succeed to build OpenLDAP 2.4.39 with my Solaris 10 environment. Thanks, -- Frederic Poisson

5 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical