Re: ppolicy issues
by Quanah Gibson-Mount
--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>
6 years, 3 months
Re: Openldap Configuration issues
by Andrew Findlay
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 |
-----------------------------------------------------------------------
6 years, 3 months
Openldap Configuration issues
by R H
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)
6 years, 3 months
Memory leak on single threaded Windows slapd
by Derrick McKee
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
6 years, 3 months
Re: mdb broken under OpenBSD
by Howard Chu
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/
6 years, 3 months
SASL EXTERNAL binds and sasl-secprops minssf > 0
by David Hawes
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
6 years, 3 months
Re: mdb broken under OpenBSD
by Howard Chu
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/
6 years, 3 months
Re: mdb_dbi_open and threads
by Howard Chu
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/
6 years, 4 months
Re: mdb broken under OpenBSD
by Howard Chu
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/
6 years, 4 months
mdb broken under OpenBSD
by Paul B. Henson
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"
6 years, 4 months
