openldap-technical August 2017

openldap-technical@openldap.org

32 participants
54 discussions

Re: ppolicy issues
by Quanah Gibson-Mount 08 Aug '17

08 Aug '17

--On Tuesday, August 08, 2017 8:46 PM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > r0m5 wrote: >> 1) I use "olcPPolicyHashCleartext: TRUE" so the clients send cleartext >> passwords and slapd hashes it before writing in database for security >> reasons (and slapd can perform password quality checks). > > There's a nasty issue with this configuration option when using > slapo-accesslog: > > If the client sends the clear-text 'userPassword' value but the password > quality check fails and therefore the modify request fails with > constraintViolation the clear-text 'userPassword' value will be written > to accesslog DB. In case of successful modification only the hashed > 'userPassword' value is written to accesslog DB. :-/ Is there an ITS on this? If not, there should be. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Openldap Configuration issues
by Andrew Findlay 08 Aug '17

08 Aug '17

Please keep the discussion on-list so that others can find it if they have similar problems. On Tue, Aug 08, 2017 at 12:44:25PM +0200, R H wrote: > Subject: Re: Openldap Configuration issues > > No point in changing stuff without knowing what is going on. > > Add this to your config and restart slapd: > > loglevel stats,stats2 > after setting loglevel to stats, stats2 > > Aug 8 05:40:18 docker slapd[2990]: daemon: read active on 14 > Aug 8 05:40:18 docker slapd[2990]: daemon: epoll: listen=9 active_threads=0 > tvp=zero > Aug 8 05:40:18 docker slapd[2990]: daemon: epoll: listen=10 active_threads=0 > tvp=zero No - something has set a different log level. You are seeing a lot of connection-management and debug stuff rather than the query and response summaries that you need. You might do better to stop the server and run it manually. Something like this: /usr/sbin/slapd -d stats,stats2 -h ldap:/// -g openldap -u openldap What I am expecting to see looks more like this (from a Cyrus mailbox server using LDAP via saslauthd): Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=103 BIND anonymous mech=implicit ssf=0 Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=103 BIND dn="cn=saslauthd,dc=ldap,dc=example,dc=com" method=128 Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=103 BIND dn="cn=saslauthd,dc=ldap,dc=example,dc=com" mech=SIMPLE ssf=0 Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=103 RESULT tag=97 err=0 text= That shows saslauthd connecting to LDAP and authenticating correctly. Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=104 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(uid=myusername)" Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=104 SRCH attr=dn That is the search to find the user account. Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=104 ENTRY dn="uniqueIdentifier=1405431085.7365.0,associatedDomain=example.co.uk,ou=domains,dc=example,dc=com" Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=104 SEARCH RESULT tag=101 err=0 nentries=1 text= That shows the search result: the user entry is "uniqueIdentifier=1405431085.7365.0,associatedDomain=example.co.uk,ou=domains,dc=example,dc=com" Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=105 BIND anonymous mech=implicit ssf=0 Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=105 BIND dn="uniqueIdentifier=1405431085.7365.0,associatedDomain=example.co.uk,ou=domains,dc=example,dc=com" method=128 Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=105 BIND dn="uniqueIdentifier=1405431085.7365.0,associatedDomain=example.co.uk,ou=domains,dc=example,dc=com" mech=SIMPLE ssf=0 Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=105 RESULT tag=97 err=0 text= Finally the password is checked by binding to LDAP using the account DN and password as credentials. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Openldap Configuration issues
by R H 07 Aug '17

07 Aug '17

Dear All, For the last few days I've been desperately reading official/user made guides in order to properly configure my openldap to allow users to login to a project management webapp (namely Redmine). With that said, please let me share the basic setup of the environment i'm dealing with. Webapplication(s): Redmine, Phpldapadmin LDAP: Openldap After the installation, i took the following steps to re-configure my ldap to reflect better the ldap being used in production (since this whole redmine + ldap isn't in production yet) 1. Stopped slapd service and removed the *cn=config.ldif* from */etc/ldap/slapd.d* 2. Modified */usr/share/slapd/slapd.conf* to this: include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel none modulepath /usr/lib/ldap moduleload back_mdb sizelimit 500 tool-threads 1 backend mdb database mdb suffix "o=testcompany.com" rootdn "cn=admin,o=testcompany.com" directory "/var/lib/tc-ldap" rootpw "password" index objectClass eq index uid eq index ou eq index default eq,sub lastmod on checkpoint 512 30 access to attrs=userPassword,shadowLastChange by dn="cn=admin,o=testcompany.com" write by anonymous auth by self write by * none access to dn.base="" by * read access to * by dn="cn=admin,o=testcompany.com" write by * read 3. Afterwards, *slaptest -f /usr/share/slapd/slapd.conf -F /etc/ldap/slapd.d* which generated my new *cn=config.ldif* 4. Set the appropriate user/group to the new *cn=config.ldif* with *chown -R openldap:openldap /etc/ldap/slapd.d/* 5. Fired up slapd service and checked if the ldap was running or not. Since it was and i could access it with phpldapadmin, i added an *organizationalUnit (ou=sales)*, all the country codes and imported 3000 users (by using *ldapadd*) Now my DIT looks as follows - o=testcompany.com - ou=sales - AD + uid=123456,c=AD,ou=sales,o=testcompany.com + ... which is great, this is exactly the way it should look like, however I've noticed, that *cn=admin,o=testcompany.com <http://testcompany.com>* entry doesn't exists, while it did using the default config after i've installed openldap. 6. In Redmine, I've configured and tested the *ldap authentication*. It is working correctly (it can both connect to my ldap and If i wish to add a new user and choose the before configured ldap authentication for it, i can even choose from the entries that are in my ldap, which is also great) 7. However (this is where my problem is) when i try to log into Redmine with a user that i've just created (with ldap authentication) i always get *Invalid credentials* error (while it works like a charm when i login with any other account, created with *Simple Authentication*) These events led me to believe that the error is in the LDAP configuration. After a few more hours/days of fooling around with the *ACL*s and *dpkg-reconfigure slapd* (and even purging-reinstalling slapd and ldap-utils) i still can not get beyond this point. And one more bit of information, after *dpkg-reconfigure slapd* and creating a few users under the default *dc=example,dc=com*, i can get them to log into Redmine just fine (and even *cn=admin,o=testcompany.com <http://testcompany.com>* shows up...). Below i'll attach a few things that I've tried. I hope someone can aid me with a few tips as to where i got off the trail (somehow i feel that i'm missing the obvious here). What I have tried so far: 1. modify the default slapd.conf file, and repeat the process i've written above 2. create a completely new one 3. a lot of different ways to add/modify the ACL 4. read through a lot of mailing list, similar problems on redmine forums, and openldap mailing lists, still no success (i can paste a lot of links from my .txt if you need it)

3 2

Memory leak on single threaded Windows slapd
by Derrick McKee 06 Aug '17

06 Aug '17

Hi, I am trying to run slapd on windows as a single threaded application. I got it to compile, and run with the mdb backstore. However, it seems like slapd allocates 3 MB for every request, and doesn't free it after the request has been served. Anyone have any idea as to where to start to try to figure this out? Thanks. -- Derrick McKee Ph.D. Student at Purdue University

1 0

Re: mdb broken under OpenBSD
by Howard Chu 05 Aug '17

05 Aug '17

Paul B. Henson wrote: >> From: Howard Chu >> Sent: Friday, August 4, 2017 4:23 AM >> >> Nice work, thanks for the update. > > So 10 of the mdb tests ended up failing; a couple because slapd failed to start, a bunch because ldapadd failed, and one because the script that evidently was executable per the -x test moments before suddenly wasn't found? There doesn't seem to be any log info or other remnants of the tests left over once they are done running to determine why they failed? Unless I missed something; what does one do to check on a test to see why it failed? Thanks… By default, all test output is in the testrun directory. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

SASL EXTERNAL binds and sasl-secprops minssf > 0
by David Hawes 05 Aug '17

05 Aug '17

With ITS #8568 [1], I notice that the first SASL EXTERNAL (using TLS client auth) bind on a connection succeeds, but subsequent SASL EXTERNAL binds on the same connection fail with: slapd[31088]: conn=1009 op=3 RESULT tag=97 err=48 text=SASL(-15): mechanism too weak for this user: mech EXTERNAL is too weak when: sasl-secprops minssf=128 In previous OpenLDAP versions, both the initial and subsequent SASL EXTERNAL binds succeed due to the bug in #8568. This was a misconfiguration on my part (I should have kept the default of 0), but I wonder if the initial SASL bind should also fail. It seems to succeed because tls_ssf is used in connection.c: slap_sasl_external( c, c->c_tls_ssf, &authid ); [1] http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8568;selectid=8568

1 0

Re: mdb broken under OpenBSD
by Howard Chu 04 Aug '17

04 Aug '17

Paul B. Henson wrote: > On Thu, Aug 03, 2017 at 02:20:29PM -0700, Paul B. Henson wrote: > >> From my initial look, mdb_env_create() successfully sets mdb->mi_dbenv, >> it's still valid in mdb_db_open(), but by the time it reaches >> be->be_entry_put in slapadd() it's NULL :(. > > It turned out it was only sometimes NULL. The culprit was actually the local > OpenBSD patch that was added to mdb_db_open() to ensure MDB_WRITEMAP is always > set: > > if ( !(flags & MDB_WRITEMAP) ) { > Debug( LDAP_DEBUG_ANY, > LDAP_XSTRING(mdb_db_open) ": database \"%s\" does not have writemap. " > "This is required on systems without unified buffer cache.\n", > be->be_suffix[0].bv_val, rc, 0 ); > goto fail; > } > > There were two problems with it; first, it accesses the local flags variable > before it is initialized to mdb->mi_dbenv_flags shortly thereafter, so > the value is random and the if block nondeterministically triggers, and > second, it doesn't assign a failure value to rc before it jumps to fail:, > so the function returns successfully but with a closed be. > > mdb has been disabled for a while, so I'm guessing the first issue might > have occurred over time as backend.c changed and the patch was just > blindly updated without testing. The second issue I'm not sure about. So much for OpenBSD's vaunted attention to detail. > > I temporarily tweaked it to always enable MDB_WRITEMAP That would be the simplest approach. > so I could run the > mdb test suite (which doesn't have it enabled for everything) and so far > it seems to be working. > > I would hope that this simple issue isn't why they've had it disabled all > this time, but I guess I'll see what happens with the full test suite > as it progresses. > Nice work, thanks for the update. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: mdb_dbi_open and threads
by Howard Chu 03 Aug '17

03 Aug '17

Hallvard Breien Furuseth wrote: > On 22. mai 2017 14:00, Howard Chu wrote: >> Muhammed Muneer wrote: >>> Hallvard wrote >> >>> "With threads 1 and 2 coexisting? When thread 2 called mdb_dbi_open(), >>> thread 1's prospect of using mdb_dbi_open() at all was lost." >>> >>> Yeah with both coexisting. Thats what I thought. > > Sorry, I should have said with _transactions_ #1 and #2 coexisting, > _transaction_ #1's prospect of using mdb_dbi_open() at all was lost. > Transaction #3 in thread #1 can use it if it stared after txn#2 ended. > > Anyway, just forget about being clever with DBIs. LMDB does not support > DBI cleverness, that's one of its trade-offs for speed and simplicity. Exactly. >> If you want to use dbi_open in multiple threads then put it in your own >> wrapper function, protected by a mutex. > > Wait, what? mdb_dbi_open() isn't coded to handle concurrent txns > calling it, regardless of any mutexes the caller has. In particular, > it does not use nor update the environment's numdbs, so the two > transactions could end up creating the same DBI for different DBs. Yes. This is only safe if you also close the dbi in the same txn that opened it. Which you are probably doing, if you are opening and closing on the fly. > >> Naturally you will also have to wrap dbi_close the same way. > > If we did support this, txn_commit() of the txn which used dbi_open() > would also need the mutex. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 4

Re: mdb broken under OpenBSD
by Howard Chu 03 Aug '17

03 Aug '17

Paul B. Henson wrote: > I was interested in using openldap under OpenBSD; they currently have > mdb disabled as they say it is broken. That OS lacks a unified buffer > cache, so mdb can only be used with the MDB_WRITEMAP option enabled, but > supposedly theoretically it should work with that. I tried running the > mdb tests, and it immediately segfaults: > > Program terminated with signal 11, Segmentation fault. > > 2773 flags |= env->me_flags & MDB_WRITEMAP; > > It looks like mdb_txn_begin is being passed a NULL env? I haven't started > poking around yet to see why that might be, but I thought I'd just toss this > out there in case an expert had a thought before I spent a lot of time on > it :). Thanks... OpenBSD's lack of a unified buffer cache is a pretty glaring deficiency, yes. Have to say, since getting nowhere discussing that feature with them, I personally have written off supporting it. For the trace you're showing, you'll have to debug the slapadd invocation and find out why env is NULL. Also use current (2.4.45) source, at least. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 2

mdb broken under OpenBSD
by Paul B. Henson 03 Aug '17

03 Aug '17

I was interested in using openldap under OpenBSD; they currently have mdb disabled as they say it is broken. That OS lacks a unified buffer cache, so mdb can only be used with the MDB_WRITEMAP option enabled, but supposedly theoretically it should work with that. I tried running the mdb tests, and it immediately segfaults: Program terminated with signal 11, Segmentation fault. 2773 flags |= env->me_flags & MDB_WRITEMAP; It looks like mdb_txn_begin is being passed a NULL env? I haven't started poking around yet to see why that might be, but I thought I'd just toss this out there in case an expert had a thought before I spent a lot of time on it :). Thanks... #0 0x000016210db057c5 in mdb_txn_begin (env=0x0, parent=0x0, flags=0, ret=0x16210df6fec0) at /usr/obj/ports/openldap-2.4.44/openldap-2.4.44/servers/slapd/back-mdb/../../../libraries/libl mdb/mdb.c:2773 txn = (MDB_txn *) 0xf ntxn = (MDB_ntxn *) 0x0 rc = 0 size = 0 tsize = 32639 #1 0x000016210db224df in mdb_tool_entry_put (be=0x1623ccbdd200, e=0x16235a80c008, [47/9401] text=0x7f7ffffeeb90) at /usr/obj/ports/openldap-2.4.44/openldap-2.4.44/servers/slapd/back-mdb/tools.c:624 rc = 0 mdb = (struct mdb_info *) 0x1623c3580000 op = {o_hdr = 0x0, o_tag = 0, o_time = 0, o_tincr = 0, o_bd = 0x0, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = { rs_modlist = 0x0, rs_e = 0x0}, oq_bind = {rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x0}, oq_modify = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\0'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\0'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = { rs_scope = 0, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = { rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = { bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_dont_replicate = 0 '\0', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 31 times>, o_controls = 0x0, o_authz = {sai_method = 0, sai_mech = { bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}} ohdr = {oh_opid = 0, oh_connid = 0, oh_conn = 0x0, oh_msgid = 0, oh_protocol = 0, oh_tid = 0x0, oh_threadctx = 0x0, oh_tmpmemctx = 0x0, oh_tmpmfuncs = 0x0, oh_counters = 0x0, oh_log_prefix = '\0' <repeats 255 times>} __func__ = "mdb_tool_entry_put" #2 0x000016210dac8329 in slapadd (argc=8, argv=0x7f7ffffeee58) at /usr/obj/ports/openldap-2.4.44/openldap-2.4.44/servers/slapd/slapadd.c:456 textbuf = '\0' <repeats 255 times> textlen = 256 erec = {e = 0x16235a80c008, lineno = 1, nextline = 18} bvtext = {bv_len = 256, bv_val = 0x7f7ffffeebd0 ""} thr = 0x16210dd8cd78 id = 140187732470848 prev = (Entry *) 0x0 ldifrc = 1 rc = 0 stat_buf = {st_mode = 4294896512, st_dev = 32639, st_ino = 140187732470584, st_nlink = 990767968, st_uid = 5667, st_gid = 0, st_rdev = 0, st_atim = {tv_sec = 179931522, tv_nsec = 48}, st_mtim = {tv_sec = 24342436749856, tv_nsec = 24341375494144}, st_ctim = { tv_sec = 24343378665241, tv_nsec = 140187732470664}, st_size = 0, st_blocks = 140187732470664, st_blksize = 990767968, st_flags = 5667, st_gen = 0, __st_birthtim = {tv_sec = 179915312, tv_nsec = 48}} #3 0x000016210da02d7a in main (argc=8, argv=0x7f7ffffeee58) at /usr/obj/ports/openldap-2.4.44/openldap-2.4.44/servers/slapd/main.c:664 i = 0 no_detach = 0 rc = 1 urls = 0x0 username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 pid = 8 waitfds = {331804096, 5667} g_argc = 8 g_argv = (char **) 0x7f7ffffeee58 configfile = 0x0 configdir = 0x0 serverName = 0x7f7ffffef122 "slapd" serverMode = 1 scp = (struct sync_cookie *) 0x0 scp_entry = (struct sync_cookie *) 0x0 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x16210ddb6ec5 "" l = 1 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 1 __func__ = "main"

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical August 2017