openldap-technical

openldap-technical@openldap.org

9 participants
9866 discussions

Re: SASL EXTERNAL binds and sasl-secprops minssf > 0
by Quanah Gibson-Mount 08 Aug '17

08 Aug '17

--On Saturday, August 05, 2017 3:05 PM -0400 David Hawes <dhawes(a)gmail.com> wrote: > 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 Please file an ITS for this, thanks. I would think the expected behavior for SASL/EXTERNAL is the SASL SSF matches the TLS SSF, given it's a TLS encrypted connection. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

ppolicy issues
by r0m5 08 Aug '17

08 Aug '17

Hello ! I have two issues regarding ppolicy. I use debian jessie backports (slapd 2.4.44). 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). But I need exceptions for that. Indeed for some reason I have to use EAP-MD5 and EAP-MD5 makes it mandatory to store cleartext passwords in LDAP. So I would like to find a way to use "olcPPolicyHashCleartext: TRUE" on some OUs, but not on others. Any way to do that ? Maybe setting up a second mdb database with a different ppolicy overlay configuration ("olcPPolicyHashCleartext: FALSE") and the same olcSuffix than the existing database ? A search on the base DN would then need to cover the two databases. 2) syncrepl of (for example) pwdChangedTime. This attribute is not synced to my consumers, even though the schema is imported on the consumer, the module is configured and the overlay is also configured. Syncrepl for attributes non related to ppolicy works fine. Somehow ppolicy is working on the consumers though, since after a failed bindind on the consumer I can see pwdFailureTime on this consumer. Any idea ? (I tried slapd -d -1 but didn't find something relevant, I can paste the resuslts here if needed) Regards, ********* provider # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 fb6dde8c dn: olcOverlay={1}ppolicy objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: ppolicy olcPPolicyDefault: cn=default,ou=ppolicies,dc=acme,dc=fr olcPPolicyHashCleartext: TRUE structuralObjectClass: olcPPolicyConfig entryUUID: 3528350a-0f9a-1037-89da-e5a4ba1189f6 creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20170807085738Z entryCSN: 20170807085738.529346Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20170807085738Z ********* provider # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 295fad94 dn: cn=module{2} objectClass: olcModuleList cn: module{2} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}ppolicy.la structuralObjectClass: olcModuleList entryUUID: 6e4da4de-0a3e-1037-9174-b1e488f02d8a creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20170731131804Z entryCSN: 20170731131804.891811Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20170731131804Z ********* consumer # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 4758a296 dn: olcOverlay={0}ppolicy objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: ppolicy olcPPolicyDefault: cn=default,ou=ppolicies,dc=acme,dc=fr olcPPolicyHashCleartext: TRUE structuralObjectClass: olcPPolicyConfig entryUUID: e5a3785a-0d8c-1037-908e-d903a2095e18 creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20170804181719Z entryCSN: 20170804181719.336420Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20170804181719Z ********* consumer # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 d0060305 dn: cn=module{1} objectClass: olcModuleList cn: module{1} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}ppolicy.la structuralObjectClass: olcModuleList entryUUID: e560e800-0d8c-1037-908d-d903a2095e18 creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20170804181718Z entryCSN: 20170804181718.900179Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20170804181718Z ********* consumer olcSyncrepl: {0}rid=2 provider=ldap://ldap-provider-dev.acme starttls=critical tls_reqcert=demand bindmethod=simple binddn="cn=replication,ou=Applications ,dc=acme,dc=fr" credentials=xxx searchbase="dc=acme,dc=fr" schemache cking=off type=refreshAndPersist filter="(objectClass=*)" attrs="*" scope=s ub retry="60 +"

3 2

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

08 Aug '17

On 7 August 2017 at 11:37, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Saturday, August 05, 2017 3:05 PM -0400 David Hawes <dhawes(a)gmail.com> > wrote: > >> 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 > > > Please file an ITS for this, thanks. I would think the expected behavior > for SASL/EXTERNAL is the SASL SSF matches the TLS SSF, given it's a TLS > encrypted connection. > ITS filed: http://www.openldap.org/its/index.cgi/Incoming?id=8708;selectid=8708

1 0

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 07 Aug '17

07 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 06 Aug '17

06 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 05 Aug '17

05 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical