May 2017 - openldap-technical

by Michael Ströder

Ulrich Windl wrote: >>>> Michael Ströder <michael(a)stroeder.com> schrieb am 08.05.2017 um 23:39 in >> When running different replicas which terminate TLS themselves you can issue a >> different server cert with distinct subject-DN for each of them and put FQDN(s) of >> the same HA address(es) (e.g. of your load-balancer(s)) into subjectAltName >> extension in all these different server certs. > > So you have one certificate for all servers, and the answer is that you cannot > have different certificates? If so, we had discussed that before. I thought you > were advising otherwise now, and I was surprised how that would work. Did you deliberately misread my answer? I cannot imagine how I can make more clear that I have different certs on all replicas. And probably you also misread my former postings about that topic. Ciao, Michael.

6 years, 6 months

1
0
0 / 0

Re: Secure replication

by Quanah Gibson-Mount

--On Saturday, May 06, 2017 1:56 AM +0000 "Real, Elizabeth (392K)" <Elizabeth.Real(a)jpl.nasa.gov> wrote: > The olcSyncRepl directive on both systems needs to go from: > > olcSyncRepl: rid=001 provider=ldap > > to: > > olcSyncRepl: rid=001 provider=ldaps The use of "ldap://" does not mean that you have insecure replication. The "ldaps" designation was developed to allow for SSL encrypted connections as a part of LDAPv2, which did not have a formal design spec for allowing SSL encryption. The LDAPv3 spec, which is what OpenLDAP 2.4 (and much earlier version) implement, specifically has startTLS as a part of that specification, which uses "ldap:///". I.e., ldaps is a bastardized hack for LDAPv2. The proper way to do TLS encryption with LDAPv3 capable servers such as OpenLDAP 2.[1-4+] is to use the startTLS extended operation over a "ldap:///" URI. In addition, there are other ways to have an encrypted connection between an LDAP client and server without involving TLS at all, such as SASL/GSSAPI. As Michael noted, you can, in addition to enabling TLS encryption between the client and servers, use client cert authentication (SASL/EXTERNAL) so as to remove the requirement for clear text credentials to be stored in the olcSyncRepl attribute (if using simple binds). And again, the usage of SASL/GSSAPI also precludes the neccessity of storing cleartext credentials in the olcSyncRepl attribute. As an aside, I would note that 2.4.40 is completely unsafe to use with multimaster replication. I would generally suggest forming a clear set of requirements for your replication environment, and then asking how to implement them. Your current question is too vague/general to really be answered well. Hope that helps! Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

6 years, 6 months

2
1
0 / 0

Re: Antw: Re: Secure replication

by Michael Ströder

Ulrich Windl wrote: > I have a related question: Can you have different certificates, depending on > "Normal use" and replication? I guess no, so if you use a load balancer, you'll > have a problem with every server having a different cert (This is how I reaed > your message). Didn't we discuss that before? When running different replicas which terminate TLS themselves you can issue a different server cert with distinct subject-DN for each of them and put FQDN(s) of the same HA address(es) (e.g. of your load-balancer(s)) into subjectAltName extension in all these different server certs. Does that answer your question? Ciao, Michael.

6 years, 6 months

1
0
0 / 0

Re: [SOLVED] Re: chain overlay does an anonymous bind and ignores the chain binddn (v2.4.44)

by Quanah Gibson-Mount

--On Friday, May 05, 2017 10:27 AM +0000 mailing lists <listas.correo(a)yahoo.es> wrote: >> config to the config used in that test? > > > > the chain works as expected, with the identity configurated, if the port > is not included in the updatedn. An DN by definition wouldn't contain port information. Can you provide a real example of the problem and how you fixed it? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

6 years, 6 months

2
1
0 / 0

ACL to authenticate gitlab users

by Xaar

Hello, I want to authenticate users via OpenLDAP to Gitlab. In Gitlab configuration there is a gitlab.rb file, where I can write some special user (let it be gitlabuser) with credentials who will be bind to ldap server. Now my question is, what acl should I provide to this user on OpenLDAP server to allow other users authenticate to Gitlab ? Now my DIT looks like this: dc=company,dc=com | | - cn=admin - cn=gitlabuser | | - ou=Groups - ou=Users -> here are users which I want to give access to Gitlab Is this entry is fair enough ? dn: olcDatabase={1}hdb,cn=config changetype: modify replace: olcAccess olcAccess: {0} to attrs=userPassword by anonymous auth by dn=„cn=admin,dc=company,dc=com” write by * none olcAccess: {1} to dn.base=„” by * read olcAccess: {2} to * by * read Best Regards !

6 years, 6 months

1
0
0 / 0

Interpreting RFC 2849

by Joseph L. Casale

Do I read the RFC correctly regarding the value-spec for the ASCII value case stating exactly one FILL character follows the colon by zero or more SAFE-STRING occurrences? In other words, the following is OK: `attribute-type: ` but not `attribute-type:` This format only applies to changetype add, if I interpret the spec correctly, what sense does it make to ask the dsa to remove any values for the specified attribute type on the new, yet to be created entry, effectively removing the type? And why is the later not tolerated, neither makes sense to me on a changetype add? Thanks, jlc

6 years, 7 months

1
0
0 / 0

Secure replication

by Real, Elizabeth (392K)

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

6 years, 7 months

3
2
0 / 0

Re: chain overlay does an anonymous bind and ignores the chain binddn (v2.4.44)

by Howard Chu

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/

6 years, 7 months

2
2
0 / 0

Unable to load the lastbind module with 2.4.44 (custom build)

by mailing lists

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?

6 years, 7 months

2
2
0 / 0

Re: Multi Master replication with many 'nonpresent_callback' lines

by Quanah Gibson-Mount

--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>

6 years, 7 months

2
1
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical May 2017