openldap-technical August 2017

openldap-technical@openldap.org

32 participants
54 discussions

delta syncrepl errors
by Gerard Ranke 22 Aug '17

22 Aug '17

Hello all, I'm trying to set up delta-syncrepl on a test setup, consisting of a producer plus consumer running openldap 2.4.45. ( I'll put relevant parts of both producer and consumer config at the end of this post. ) I'm following the instructions from the openldap manual ( chapter 18.3.2 ) as much as possible. Both slapd's start up but replication isn't happening. I get the following messages in the logs: producer: 2017-08-18T14:54:39.153754+02:00 pro slapd[10098]: send_search_entry: conn 1278 ber write failed. 2017-08-18T14:54:44.157627+02:00 pro slapd[10098]: send_search_entry: conn 1279 ber write failed. 2017-08-18T14:54:49.368758+02:00 pro slapd[10098]: send_search_entry: conn 1281 ber write failed. 2017-08-18T14:55:09.390341+02:00 pro slapd[10098]: send_search_entry: conn 1283 ber write failed. 2017-08-18T14:55:19.395091+02:00 pro slapd[10098]: send_search_entry: conn 1284 ber write failed. consumer: 2017-08-18T14:54:39.153660+02:00 del slapd[25530]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20170815125023.000001Z,cn=accesslog) 2017-08-18T14:54:39.154089+02:00 del slapd[25530]: do_syncrepl: rid=001 rc -1 retrying (1 retries left) 2017-08-18T14:54:44.157539+02:00 del slapd[25530]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20170815125023.000001Z,cn=accesslog) 2017-08-18T14:54:44.158156+02:00 del slapd[25530]: do_syncrepl: rid=001 rc -1 retrying 2017-08-18T14:54:49.368843+02:00 del slapd[25530]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20170815125023.000001Z,cn=accesslog) 2017-08-18T14:54:49.369446+02:00 del slapd[25530]: do_syncrepl: rid=001 rc -1 retrying 2017-08-18T14:54:59.383750+02:00 del slapd[25530]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20170815125023.000001Z,cn=accesslog) 2017-08-18T14:54:59.384369+02:00 del slapd[25530]: do_syncrepl: rid=001 rc -1 retrying 2017-08-18T14:55:09.390382+02:00 del slapd[25530]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20170815125023.000001Z,cn=accesslog) 2017-08-18T14:55:09.390971+02:00 del slapd[25530]: do_syncrepl: rid=001 rc -1 retrying 2017-08-18T14:55:19.395206+02:00 del slapd[25530]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20170815125023.000001Z,cn=accesslog) When I do a search on the producer from the consumer I get results that look like I would expect to see: ldapsearch -x -h pro.hku.nl -b "cn=accesslog" -D cn=dsyncuser,dc=hku,dc=nl -w ****** "(&(objectClass=auditWriteObject)(reqResult=0))" (...) # 20170817170609.000001Z, accesslog dn: reqStart=20170817170609.000001Z,cn=accesslog objectClass: auditAdd reqStart: 20170817170609.000001Z reqEnd: 20170817170610.000000Z reqType: add reqSession: 1 reqAuthzID: cn=root,dc=hku,dc=nl reqDN: nlHkuID=77454,ou=People,dc=hku,dc=nl reqResult: 0 reqMod: objectClass:+ top reqMod: objectClass:+ posixAccount reqMod: objectClass:+ shadowAccount reqMod: objectClass:+ inetOrgPerson reqMod: objectClass:+ nlHkuPerson reqMod: objectClass:+ eduPerson reqMod: objectClass:+ apple-user reqMod: objectClass:+ sambaSamAccount reqMod: ou:+ People reqMod: authAuthority:+ ;basic; reqMod: nlHkuID:+ 77454 reqMod: loginShell:+ /bin/false reqMod: gidNumber:+ 300 (...) reqMod: structuralObjectClass:+ nlHkuPerson reqMod: entryUUID:+ 1b7405d0-17ba-1037-98e3-99bbae3c2a53 reqMod: creatorsName:+ cn=root,dc=hku,dc=nl reqMod: createTimestamp:+ 20170817170608Z reqMod: entryCSN:+ 20170817170608.603041Z#000000#000#000000 reqMod: modifiersName:+ cn=root,dc=hku,dc=nl reqMod: modifyTimestamp:+ 20170817170608Z reqEntryUUID: 1b7405d0-17ba-1037-98e3-99bbae3c2a53 (...) The producer config has: (...) dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap olcModuleLoad: {0}back_mdb.so olcModuleLoad: {1}dynlist.so olcModuleLoad: {2}accesslog.so olcModuleLoad: {3}syncprov.so olcModuleLoad: {4}smbk5pwd.so structuralObjectClass: olcModuleList (...) dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=hku,dc=nl olcAccess: {0}to * by dn.base="cn=dsyncuser,dc=hku,dc=nl" read by * break (...) olcAccess: {15}to * by * read olcAddContentAcl: FALSE olcLastMod: TRUE olcLimits: {0}dn.exact="cn=root,dc=hku,dc=nl" size=unlimited time=unlimited olcLimits: {1}dn.exact="cn=dsyncuser,dc=hku,dc=nl" size=unlimited time=unlim ited olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=root,dc=hku,dc=nl olcRootPW:: *** olcSyncUseSubentry: FALSE olcMonitoring: TRUE (...) dn: olcOverlay={1}accesslog,olcDatabase={1}mdb,cn=config objectClass: olcAccessLogConfig objectClass: olcOverlayConfig olcOverlay: {1}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 07+00:00 01+00:00 olcAccessLogSuccess: TRUE (...) dn: olcOverlay={2}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcSyncProvConfig objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: {2}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100 olcSpNoPresent: TRUE olcSpReloadHint: TRUE structuralObjectClass: olcSyncProvConfig (...) dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /var/lib/ldap-accesslog olcSuffix: cn=accesslog olcAccess: {0}to * by dn.base="cn=dsyncuser,dc=hku,dc=nl" read olcLimits: {0}dn.exact="cn=dsyncuser,dc=hku,dc=nl" size=unlimited time=unlim ited olcRootDN: cn=accesslog olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart olcDbMaxSize: 1047483648 structuralObjectClass: olcMdbConfig (...) Parts from the consumer config: (...) dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap olcModuleLoad: {0}back_mdb.so olcModuleLoad: {1}dynlist.so structuralObjectClass: olcModuleList (...) dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=hku,dc=nl olcAccess: {0}to * by dn.base="cn=dsyncuser,dc=hku,dc=nl" read by * break (...) olcAccess: {15}to * by * read olcAddContentAcl: FALSE olcLastMod: TRUE olcLimits: {0}dn.exact="cn=root,dc=hku,dc=nl" size=unlimited time=unlimited olcLimits: {1}dn.exact="cn=dsyncuser,dc=hku,dc=nl" size=unlimited time=unlim ited olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=replroot,dc=hku,dc=nl olcRootPW:: ***** olcSyncUseSubentry: FALSE olcSyncrepl: {0}rid=001 provider=ldap://pro.hku.nl bindmethod=simple binddn= "cn=dsyncuser,dc=hku,dc=nl" credentials="****" tls_cert="/etc/ssl/certs /del_cert.pem" tls_key="/etc/ssl/private/del_key.pem" tls_cacertdir="/etc/s sl/certs" tls_reqcert=demand tls_crlcheck=none logbase="cn=accesslog" logfi lter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog se archbase="dc=hku,dc=nl" schemachecking=on type=refreshAndPersist retry="5 5 10 +" olcMonitoring: TRUE olcDbIndex: default pres,eq olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbIndex: cn eq,sub (...) olcDbMaxReaders: 0 olcDbMaxSize: 12147483648 olcDbMode: 0600 olcDbSearchStack: 16 structuralObjectClass: olcMdbConfig Thank you for taking the time to read all this, any remarks on how to get this going will be very much appreciated! Best regards, gerard

1 0

How to enable memberOf overlay with posixGroup?
by MegaBrutal 16 Aug '17

16 Aug '17

Hi all, I've spent days trying to figure out how could I enable the memberOf overlay, and it doesn't seem to be easy for an LDAP-noob. I've read like 50+ tutorials which didn't help me get it working. Use case: I want to have 2 main groups which control access to different services on my network. A "unixusers" which is a minimum to log in to Linux servers (having a hostObject entry for the user is another requirement, which is irrelevant to this question, as I already solved that problem); and a "cloudusers" group which enables log in to my ownCloud instance. The groups should enforce the following rules: – Only users in "cloudusers" should be allowed to log in to ownCloud. – Users in "unixusers" are allowed to log in to a set of Linux servers controlled by "host" (hostObject) entries. – Users not in the "unixusers" group may not log in to any Linux systems, even if they have "host" entries. Problems: – ownCloud complains that the memberOf overlay is not enabled, hence it doesn't let me restrict access to the "cloudusers" group. It would allow any users regardless of any group memberships, which is not acceptable. – I have a similar problem on Linux with PAM: I can't really get it to consider "unixusers" membership for user logins, although I got the "host" entries working correctly, so at least I can already restrict access with that. My guess is that it all boils down to the lack of memberOf overlay. I also figured that memberOf would need groupOfNames groups, while I need posixGroup type groups. I evaluated the possibility to use groupOfNames, but it lacks the necessary gidNumber attribute which is a requirement for Unix groups. But anyway, I can't enable memberOf even for groupOfNames. I can't enable memberOf by any means. My OpenLDAP uses the new configuration method and it completely ignores slapd.conf, so the config must be injected with ldapadd to cn=config. Could you please help me with this? Regards, MegaBrutal

5 6

Re: syncprov
by Quanah Gibson-Mount 15 Aug '17

15 Aug '17

--On Tuesday, August 15, 2017 3:39 PM +0100 Philip Colmer <philip.colmer(a)linaro.org> wrote: > If I am correct and there only needs to be one, what is the best way > to remove the extraneous ones? You'll have to stop the server, slapcat the cn=config DB, delete the extra overlays, and then slapadd the cn=config DB back in. I would suggest adding logic to your process that checks for the existence of the syncprov overlay prior to attempting to add it to the stack. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

syncprov
by Philip Colmer 15 Aug '17

15 Aug '17

I'm adding a third server to an existing multi-server configuration and I think the LDIF files I'm using to configure the replication have some errors in them. dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov The above is a snippet from the LDIF file and I'm concerned that it keeps on adding a new syncprov overlay when there only needs to be one. On the current three-server configuration, there are four instances of syncprov! If I am correct and there only needs to be one, what is the best way to remove the extraneous ones? Thanks. Philip

1 0

Search against multiple databases under
by JOSE L MARTINEZ-AVIAL 10 Aug '17

10 Aug '17

Hello, I'm trying to combine my test openldap (MDB database) with my production AD installation, so I can have the production users access my test systems. In order to do that I've created two databases in my slapd.conf, as follows: ####################################################################### # database definitions ####################################################################### include /usr/local/etc/openldap/slapd-meta-ad-prd.conf include /usr/local/etc/openldap/slapd-mdb.conf The configuration file for the AD connection is as follows: database meta suffix "dc=bsi,dc=test,dc=com" uri "ldap://miadc01.mia.usa.sinvest/dc=bsi,dc=test,dc=com" suffixmassage "dc=bsi,dc=test,dc=com" "dc=mia,dc=usa,dc=sinvest" idassert-bind bindmethod=simple binddn="cn=Test User,cn=users,dc=mia,dc=usa,dc=sinvest" credentials=xxxxx The configurtion file for the MDB is: database mdb maxsize 1073741824 suffix "dc=test,dc=com" rootdn "cn=Manager,dc=test,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. # Added by pplu to support root authentication rootpw xxxxxxx # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/local/var/openldap-data/mdb # Indices to maintain index objectClass eq overlay memberof memberof-group-oc groupOfUniqueNames memberof-member-ad uniquemember So the first database uses the sufix "dc=bsi,dc=test,dc=com", and the second one uses "dc=test,dc=com". The idea is that the AD would appear as a branch of the development database. I've found that I can search the AD by using the search DN "dc=bsi,dc=test,dc=com", but if I try to look with DN "dc=test,dc=com", only the test database is searched. The search does not combine both databases. How can I do it? thanks JL

2 1

Re: problem with syncrepl and STARTTLS
by Ryan Tandy 09 Aug '17

09 Aug '17

On Wed, Aug 09, 2017 at 07:47:06PM +0200, r0m5 wrote: >Yes so far "TLS_REQCERT allow" on the PHP applications' OS because the >OpenLDAP consumers certs are still self-signed. > >Indeed I saw #8385 linked in ITS#8427. From my understanding #8385 deals >with certificate validation using libldap. php5-ldap depends on libldap >and the versions of libldap install on our php frontends are old >(jessie...). I'm actually about to propose an update for stretch including that fix along with some others (and will update jessie-backports once it's released for stretch). I hadn't intended to backport it as far as jessie, but I have some other changes pending for jessie as well so I may as well include it. >So I will also make sure that the PHP frontends trust the CA that will >sign the new LDAP consumer's certificates. I guess that should solve the >STARTTLS problems from application to consumer the same way it (looks >like it) solved the STARTTLS problems from consumers to providers. Yes, it should.

1 0

Re: problem with syncrepl and STARTTLS
by Quanah Gibson-Mount 09 Aug '17

09 Aug '17

--On Friday, June 02, 2017 11:01 AM +0200 r0m5 <r0m5(a)r0m5.eu> wrote: > > Hello, > > I am facing an issue with syncrepl and STARTTLS on 389 port. The kind of > problem happening only sometimes, and disappearing "by itself". I use > Debian Jessie, OpenLDAP 2.4.40+dfsg-1+deb8u2. 2.4.40 is 2.5 years old, 5 point releases behind, and had significant known replication issues. I believe there is a build of 2.4.44 in backports for Jessie. I would advise using that instead. As far as debug logging, you would need to use "-d -1" to slapd, rather than attempting to set the loglevel to -1, as some debug logging is only possible via the slapd daemon. But your first step is to move to a current release. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 6

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical August 2017