openldap-technical

openldap-technical@openldap.org

9 participants
9866 discussions

Secure replication
by Real, Elizabeth (392K) 06 May '17

06 May '17

Hey guys, I’m running multi-master OpenLDAP (version 2.4.40) servers and need to secure replication. Can you point me to where I can find that information? What I found online is old and does not apply to the version I’m running. The olcSyncRepl directive on both systems needs to go from: olcSyncRepl: rid=001 provider=ldap to: olcSyncRepl: rid=001 provider=ldaps Thank you, Liz

3 2

Re: chain overlay does an anonymous bind and ignores the chain binddn (v2.4.44)
by Howard Chu 05 May '17

05 May '17

mailing lists wrote: > Hello, > > I am testing the chain overlay from a read-only slave (consumer) slapd server > to a read-write master (provider), but what I am seeing is an anonymous bind > from the consumer to the provider instead of the authorization identity > configurated in the chain directive. Have you successfully run test032 in the test suite? Have you compared your config to the config used in that test? > > afaik, the bind dn in the provider must be the chain binddn configured in the > consumer, but it gets an anonymous bind. > > > any suggestion about what can be my mistake?? > > > > -- -- 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

Unable to load the lastbind module with 2.4.44 (custom build)
by mailing lists 05 May '17

05 May '17

Hello all, What I'm trying to do is enable the lastbind module in a centos7 server, so I applied this patch to the rpmbuild process: # cat /root/rpmbuild/SOURCES/openldap-lastbind-overlay.patch --- a/servers/slapd/overlays/Makefile.in 2017-04-12 12:14:46.617978071 +0100 +++ b/servers/slapd/overlays/Makefile.in 2017-04-12 12:21:12.569292484 +0100 @@ -36,6 +36,7 @@ valsort.c \ smbk5pwd.c \ allop.c \ + lastbind.c \ sha2.c slapd-sha2.c OBJS = statover.o \ @SLAPD_STATIC_OVERLAYS@ \ @@ -56,7 +57,7 @@ UNIX_LINK_LIBS = $(@BUILD_LIBS_DYNAMIC@_LDAP_LIBS) LIBRARY = ../liboverlays.a -PROGRAMS = @SLAPD_DYNAMIC_OVERLAYS@ smbk5pwd.la allop.la pw-sha2.la +PROGRAMS = @SLAPD_DYNAMIC_OVERLAYS@ smbk5pwd.la allop.la pw-sha2.la lastbind.la XINCPATH = -I.. -I$(srcdir)/.. XDEFS = $(MODULES_CPPFLAGS) @@ -140,6 +141,12 @@ allop.la : allop.lo $(LTLINK_MOD) -module -o $@ allop.lo version.lo $(LINK_LIBS) $(shell pkg-config openssl --libs) +lastbind.lo : lastbind.c + $(LTCOMPILE_MOD) -DDO_SAMBA -UHAVE_MOZNSS -DHAVE_OPENSSL $(shell pkg-config openssl --cflags) $< + +lastbind.la : lastbind.lo + $(LTLINK_MOD) -module -o $@ lastbind.lo version.lo $(LINK_LIBS) $(shell pkg-config openssl --libs) + sha2.lo : sha2.c $(LTCOMPILE_MOD) $< the resulting package contains the module: # rpm -qpl /root/rpmbuild/RPMS/x86_64/openldap-servers-2.4.44-1.x86_64.rpm | grep lastbind /usr/lib64/openldap/lastbind-2.4.so.2 /usr/lib64/openldap/lastbind-2.4.so.2.10.7 /usr/lib64/openldap/lastbind.la /usr/share/man/man5/slapo-lastbind.5.gz but a configuration file as simple as the following one, fails to load: # cat test.conf modulepath /usr/lib64/openldap/ moduleload back_bdb.la moduleload back_hdb.la moduleload back_ldap.la moduleload unique.la moduleload ppolicy.la moduleload dynlist.la moduleload memberof.la moduleload syncprov.la moduleload accesslog.la moduleload lastbind.la moduleload auditlog.la # slaptest -d -1 -f ./test.conf 58ee0ebd slaptest init: initiated tool. 58ee0ebd slap_sasl_init: initialized! 58ee0ebd bdb_back_initialize: initialize BDB backend 58ee0ebd bdb_back_initialize: Berkeley DB 5.3.21: (May 11, 2012) 58ee0ebd hdb_back_initialize: initialize HDB backend 58ee0ebd hdb_back_initialize: Berkeley DB 5.3.21: (May 11, 2012) 58ee0ebd mdb_back_initialize: initialize MDB backend 58ee0ebd mdb_back_initialize: LMDB 0.9.18: (February 5, 2016) 58ee0ebd reading config file ./test.conf 58ee0ebd ./test.conf: line 1 (modulepath /usr/lib64/openldap/) 58ee0ebd ./test.conf: line 2 (moduleload back_bdb.la) 58ee0ebd module_load: (back_bdb.la) already present (static) 58ee0ebd ./test.conf: line 3 (moduleload back_hdb.la) 58ee0ebd module_load: (back_hdb.la) already present (static) 58ee0ebd ./test.conf: line 4 (moduleload back_ldap.la) 58ee0ebd loaded module back_ldap.la 58ee0ebd module back_ldap.la: null module registered 58ee0ebd ./test.conf: line 5 (moduleload unique.la) 58ee0ebd loaded module unique.la 58ee0ebd module unique.la: null module registered 58ee0ebd ./test.conf: line 6 (moduleload ppolicy.la) 58ee0ebd loaded module ppolicy.la 58ee0ebd module ppolicy.la: null module registered 58ee0ebd ./test.conf: line 7 (moduleload dynlist.la) 58ee0ebd loaded module dynlist.la 58ee0ebd module dynlist.la: null module registered 58ee0ebd ./test.conf: line 8 (moduleload memberof.la) 58ee0ebd loaded module memberof.la 58ee0ebd module memberof.la: null module registered 58ee0ebd ./test.conf: line 9 (moduleload syncprov.la) 58ee0ebd loaded module syncprov.la 58ee0ebd module syncprov.la: null module registered 58ee0ebd ./test.conf: line 10 (moduleload accesslog.la) 58ee0ebd loaded module accesslog.la 58ee0ebd module accesslog.la: null module registered 58ee0ebd ./test.conf: line 11 (moduleload lastbind.la) 58ee0ebd loaded module lastbind.la 58ee0ebd module lastbind.la: init_module() failed 58ee0ebd ./test.conf: line 11: <moduleload> handler exited with 1! slaptest: bad configuration file! any idea about where I make the mistake?

2 2

Re: Multi Master replication with many 'nonpresent_callback' lines
by Quanah Gibson-Mount 03 May '17

03 May '17

--On Tuesday, May 02, 2017 3:10 PM +0000 Jesper Grøndahl <grondahl(a)ruc.dk> wrote: > However, as you can see I still get the "nonpresent_callback" lines for > each user. I can see that if you set "olcSpNoPresent: TRUE" in the > syncprov overlay entry the lines disappear. > But I can understand that it should only be done if you have an acceslog. > > So is it really necessary to go through all the objects in the database > every time you modify a single record when you have a mmr setup? > It just seems like a lot of information written to the log and a lot of > work every time a single record is modified. Do you have a session log configured? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

RE: Issue importing CGP schema into LDAP (centos 7)
by Quanah Gibson-Mount 03 May '17

03 May '17

--On Wednesday, May 03, 2017 12:34 PM -0400 John Cooter <jcooter(a)atlantech.net> wrote: > Thanks! That worked. Much appreciated. Don't mean to seem obtuse. No worries, glad it's working. :) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: Issue importing CGP schema into LDAP (centos 7)
by Quanah Gibson-Mount 03 May '17

03 May '17

--On Wednesday, May 03, 2017 12:30 PM -0400 John Cooter <jcooter(a)atlantech.net> wrote: > I attempted that this morning as well, and will present reference here: > Contents of test.conf > > 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/misc.schema > include /etc/openldap/schema/ppolicy.schema > include /etc/openldap/schema/cgp.schema (the referenced schema > for conversion) > > testing directory created > > slaptest -f test.conf -F testing > > error message: > > 5909f790 /etc/openldap/schema/cgp.schema: line 8 attributetype: Duplicate > attributeType: "2.16.840.1.113730.3.1.241" slaptest: bad configuration > directory! Fix your cgp.schema to not include the definition for displayName, since that already comes from inetorgperson.schema. And remove any other attributes it is incorrectly defining that are provided from other schema as well. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

RE: Issue importing CGP schema into LDAP (centos 7)
by Quanah Gibson-Mount 03 May '17

03 May '17

--On Wednesday, May 03, 2017 12:17 PM -0400 John Cooter <jcooter(a)atlantech.net> wrote: > That was my understanding, that I only needed to include the schema I was > trying to convert. The "test.conf" file ONLY had the schema for > conversion included. And since "organization" does come from the base > schema, I'm wondering WHY I'm getting this error on conversion. I have > included the problematic object definition earlier in this thread, and I > really don't see why I'm failing. I can post the entire schema I'm trying > to convert if that would help. I'm really quite stumped. This should be a > simple conversion, but why I'm failing when attempting to attach to an > existing objectClass is beyond my understanding. The test.conf that you are converting has *zero* knowledge of what you have loaded into cn=config. Generally what one does is, define a test.conf that includes all the necessary schema to convert the additional schema you are converting, and then you do something like: mkdir -p /tmp/test-config slaptest -F /tmp/test-config -f test.conf Then you can use the converted schema that is written into /tmp/test-config. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

RE: Issue importing CGP schema into LDAP (centos 7)
by Quanah Gibson-Mount 03 May '17

03 May '17

--On Wednesday, May 03, 2017 9:28 AM -0400 John Cooter <jcooter(a)atlantech.net> wrote: > So, just to confirm what you're saying, that EVEN THOUGH the existing > schema has all the prerequisite objectClass and other object types, and > even though I'm attempting to use slaptest to convert a single extended > .schema, a holdover from an earlier version of openldap, to an .ldif in > the configuration cn, that my test.conf, must have lines that include all > the other base schema files as well? You should absolutely not be including elements from other schema into the file simply for the purpose of conversion, as you will end up with a file you won't be able to import to cn=config if it has those other schema included. And, if it had all the elements as you claim, then you certainly wouldn't be getting an error about the "organization" objectClass being missing, given that that comes from the "core" schema file. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 3

RE: Issue importing CGP schema into LDAP (centos 7)
by Quanah Gibson-Mount 03 May '17

03 May '17

--On Tuesday, May 02, 2017 5:02 PM -0400 John Cooter <jcooter(a)atlantech.net> wrote: > The existing configuration, was created as follows: > Install ldap and related services > ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/cosine.ldif > ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/nis.ldif > ldapadd -Y EXTERNAL -H ldapi:/// -f > /etc/openldap/schema/inetorgperson.ldif create test.conf which only > contains a single line: include /etc/openldap/schema/cgp.schema run > slaptest statement, as listed below. Get error. > This slaptest statement should normally allow me to create the ldif to > add to the schema, but it keeps failing. And I'm trying to figure out why > and what I'm doing wrong. Your test LDIF file for converting schema must include all other schema that it is dependent upon for it to be able to convert properly. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 2

Issue importing CGP schema into LDAP (centos 7)
by John Cooter 02 May '17

02 May '17

I have been tasked with virtualizing our existing, aging, LDAP and CommuniGate Pro instances. Doing so will require moving from RHEL 5.X to CentOS 7.X, which means that the existing LDAP implementation has changed. Upon attempting to perform a "slaptest -f test.conf -F testing" where test.conf contains only an include statement that points to /etc/openldap/schema/cgp.schema, and testing is an empty directory, I receive the following error message: 59033edc /etc/openldap/schema/cgp.schema: line 640 objectClass: ObjectClass not found: "organization" slaptest: bad configuration directory! I am able to verify that the various base includes in my LDAP server do include an objectClass "organization" and can verify same in phpLDAPadmin, and in other methods. I am new to the concepts presented here, and since we are using LDAP in what appears to me to be a non-standard use case, I am at a loss. I present the relevant "line 640" below, from the schema I am attempting to import: objectClass ( 2.5.1000.0 NAME 'CommuniGateDomain' SUP 'organization' STRUCTURAL MAY ( cn $ dc ) ) Can someone perhaps tell me where I am going wrong, or how to more effectively troubleshoot this import?

2 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical