Quanah Gibson-Mount wrote:
> --On Wednesday, March 30, 2022 8:28 PM +0200 Stefan Kania
> <stefan(a)kania-online.de> wrote:
>
> > That's what can be found in the FAQ on openldap.org:
> >
> > https://www.openldap.org/faq/data/cache/605.html
> >
> > I would trust this more then any rumors on any stackxxxx page ;)
> Unfortunately, the FAQ is dead weight we want to kill and not maintained in
> any way, shape, or form. It's currently provided for historical purposes.
>
> As to this overall discussion, one of the primary issues with connections
> over ldap:/// is that there's zero way with simple binds to prevent the
> bind dn + password being sent in the clear by a client to the server. With
> ldaps:/// the encryption is set up before the BIND occurs so you don't run
> this risk.
Is that true? Surely I can
1. connect to the server
2. Send starttls
3. Then bind bind can't I?
I'm fairly certain I've used LDAP Client operating in that order.
>
> So from that standpoint, I'd personally prefer to see ldaps:/// qualified
> in an RFC so the standardization argument goes away and ldaps be noted as
> the preferred method for sites that require encryption.
I agree there is no technical reason LDAPS would not be better. It should be made standard.
--On Tuesday, May 09, 2017 2:11 AM +0000 "Real, Elizabeth (392K)"
<Elizabeth.Real(a)jpl.nasa.gov> wrote:
Hi Elizabeth,
> If "ldap://" is secure already then I do not need to proceed further.
That says nothing about whether or not your configuration is secure.
Again, if it is "ldap://" with the startTLS LDAPv3 extension, and you've
configured it be required that it succeed, then it is secure. You've not
provided the information that would be necessary to make such a
determination. I would again advise reading the slapd-config(5) man page
for the olcSyncRepl attribute, specifically the bits on the starttls,
tls_cacert/tls_cacertdir, tls_cipher_suite, and tls_protocol_min
configuration parameters.
You may also want to set olcSecurity (A value of "ssf=1" requires any and
all connections to the server be encrypted). Changing this value from the
default requires a server restart for it to go into effect.
> SSLv3
> TLSv1.2
Those look like protocol versions, not cipher suites. ;)
> Why is version 2.4.40 unsafe for multi-master replication? I can upgrade
> at a later time I just wanted to find out how to enable ldaps between the
> two servers.
You can read through the OpenLDAP Release notes here:
<http://www.openldap.org/software/release/changes.html>
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
On 05/16/12 11:47 +0200, Pieter Baele wrote:
>Hi,
>
>My current LDAP setup uses SASL PTA to authenticate against Active Directory.
>For users only existing in OpenLDAP, I would use SASL SCRAM, so no
>passes over the wire except for these in AD ;-)
For SASL SCRAM support, you'll need to compile the OpenLDAP server and
client utilities against cyrus sasl 2.1.25. And/or you can use SSL/STARTTLS to
protect the authentication exchange. SASL SCRAM requires that you perform
SASL authentication from your LDAP clients, and not simple authentication.
An alternative to SCRAM that is supported in older versions of cyrus sasl
is DIGEST-MD5.
>But I believe only 1 method can be used by SASL External?
Neither pass-through authentication nor SCRAM really have anything to do
with SASL EXTERNAL. SASL EXTERNAL might come into play if you're performing
STARTTLS with client certificates.
>Any guidelines on configuring something as this? Do I really need the
>meta backend or is there a better way?
Specifically with regards to SCRAM (or DIGEST-MD5), you will need to store
your passwords in clear text. See:
http://www.openldap.org/lists/openldap-technical/201110/msg00168.html
The meta backend is not necessary to support either pass-through
authentication nor local SCRAM authentication. In what scenario are you
looking to use the meta backend?
--
Dan White
On 23/11/11 17:06 +0100, Kasper Loopstra wrote:
>Dear list,
>
>We are using PAM to authenticate posixUsers against OpenLDAP. This
>works great, and allows 'local' (ssh) logins. However, we also use
>LDAP for a number of other services, including remote access and
>editing via other software. This means we would like to keep our
>users passwords as secure as possible, and enforce encrypted logins
>for all remote hosts. However, PAM should still be able to
>authenticate. The manner of encryption is not really important, it
>just has to be strong enough to be useful over the internet, and
>usable for all (or most) clients.
>
>We have tried various solutions with ssf directives in
>/etc/ldap/slapd.conf as well as the security tls=1 directive. All of
>these attempts broke PAM.
Which PAM ldap module are you using? with PADL's module, you'd want to
configure 'ssl on' (for ldaps:///) or 'ssl starttls' (for starttls over
ldap:///) and also configure the tls_* settings appropriately.
For your slapd configuration, see the slapd.conf manpage - the TLS*
options, as well as the 'security' option. If you are wishing to perform
secure connections over ldaps:///, verify that in your slapd init script,
that you are passing 'ldaps:///' as one of your '-h' command line
parameters.
--
Dan White
Le 2017-06-02 16:55, Quanah Gibson-Mount a écrit :
> --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>
Hello !
Thanks for your reply. I just upgraded the preproduction environment
provider and consumers to the jessie-backports version. I will check the
prod to preprod injections during the next days then let you know.
Have a good weekend !
Am Sun, 27 Mar 2016 19:15:20 -0400
schrieb Xavier Landreville <xavier(a)openconcept.ca>:
> Hello,
>
> I am currently in the grips of trying to get syncrepl replication
> working with StartTLS. It was working fine until recently. The only
> change that occurred over the last 12 months (that relates to
> OpenLDAP) is that I've started requiring TLS for connections.
>
> My provider is running OpenLDAP 2.4.31 on Ubuntu 14.04, while one
> consumer is running the exact same version on a Ubuntu 14.04 machine
> and the other consumer is running OpenLDAP 2.4.28 on Ubuntu 12.04.
>
> The provider has, AFAIK, a correct TLS configuration, given that I can
> connect and search using the ldapsearch -ZZ utility from any of the
> servers.
>
> The syncprov overlay is loaded and configured on the provider.
>
> The consumers have the following (redacted, with unique rid values)
> olcSyncRepl:
>
> olcSyncrepl: {0}rid=1 provider=ldap://[LDAP_DNS] bindmethod=simple bi
> nddn="[SYNC_USER]" credentials=[SYNC_PASS] searchbase="[L
> DAP_BASE]" logbase="cn=accesslog" logfilter="(&(objectClass=auditWr
> iteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist
> retry="60
> +" syncdata=accesslog starttls=critical tls_reqcert=demand
>
> Unfortunately, on both consumers can't seem to be able to actually
> start the TLS connection:
>
> slapd[1257]: slap_client_connect: URI=ldap://[LDAP_DNS] Error,
> ldap_start_tls failed (-11)
> slapd[1257]: do_syncrepl: rid=001 rc -11 retrying
>
> And the provider shows the following errors:
>
> slapd[2126]: conn=1586 fd=100 ACCEPT from IP=[CONSUMER_IP]:35500
> (IP=0.0.0.0:389)
> slapd[2126]: conn=1586 op=0 EXT oid=1.3.6.1.4.1.1466.20037
> slapd[2126]: conn=1586 op=0 STARTTLS
> slapd[2126]: conn=1586 op=0 RESULT oid= err=0 text=
> slapd[2126]: conn=1586 fd=100 closed (TLS negotiation failure)
>
> Is there anything that I'm missing?
Yes, you need to configure path to CA cert.
-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:DA147B05
53°37'09,95"N
10°08'02,42"E
Interesting. Is "-q" implemented after 2.4.9? It's not supported by my
installation.
My man page says: "-Z[Z] Issue StartTLS (Transport Layer Security) extended
operation. If you use -ZZ, the command will require the operation to be
successful."
Which is what I did.
Thanks,
-Jake
On Wed, Jul 30, 2008 at 12:37 PM, Patrick Patterson <ppatters(a)gmail.com>wrote:
> Hello
>
> On Wed, Jul 30, 2008 at 9:59 AM, J Davis <mrsalty0(a)gmail.com> wrote:
>
>> Greetings,
>>
>> I'm testing an installation of openldap 2.4.9. I want to enforce TLS for
>> all access to the directory.
>> My problem is that I cannot get the client to meet the ssf restictions I
>> have in place. The documentation I've seen on ssf and tls_ssf is very sparse
>> so I don't really understand what it does.
>>
>> I'm using self signed cert created using the openssl CA.sh script.
>>
>> Relevant portions of the slapd.conf...
>>
>> TLSCACertificateFile /etc/ldap/ssl/cacert.pem
>> TLSCertificateFile /etc/ldap/ssl/servercrt.pem
>> TLSCertificateKeyFile /etc/ldap/ssl/serverkey.pem
>> ...
>> access to *
>> by tls_ssf=128 ssf=128 anonymous auth
>> by tls_ssf=128 ssf=128 self write
>>
>> Relevant portions of the lapd.conf...
>>
>> TLS_CACERT /etc/ldap/ssl/cacert.pem
>>
>> With those ACLs in place I get the following error:
>>
>> $ ldapsearch -x -ZZ -D "uid=jake,ou=people,dc=example,dc=com" -W -b
>> "uid=jake,ou=people,dc=example,dc=com"
>> ldap_bind: Invalid credentials (49)
>>
>
> You may want to try adding -q as one of the options to your ldapsearch. It
> appears that the tls_ssf turns on STARTTLS, instead of LDAP over SSL and in
> order to use that, you need to tell the client to use starttls as well,
> which is what (if I read the man page correctly), -q does.
>
> Have fun.
>
>
> --
> Personal Mail from Patrick Patterson
> No company affiliation
>
Hi Hauke,
I still can't get TLS to work. Here is the error message.
TLS certificate verification: Error, self signed certificate
tls_write: want=7, written=7
0000: 15 03 01 00 02 02 30 ......0
TLS trace: SSL3 alert write:fatal:unknown CA
TLS trace: SSL_connect:error in SSLv3 read server certificate B
TLS trace: SSL_connect:error in SSLv3 read server certificate B
TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed.
ldap_err2string
ldap_start_tls: Connect error (-11)
Thanks
----- Original Message ----
From: Hauke Coltzau <hauke.coltzau(a)FernUni-Hagen.de>
To: Dat Duong <datduong2000(a)yahoo.com>
Cc: openldap-technical <openldap-technical(a)openldap.org>
Sent: Tuesday, October 7, 2008 1:25:37 AM
Subject: AW: StartTLS is not working
Hi Dat,
first of all: Please send your questions to the list so that
other users with the same problem can find the solution, too.
To your problem: Please make sure that you have a correct
value for your ServerCA's private key in your openssl.cnf. It
should read something like this:
[ ServerCA ]
# Where is the base directory for the ServerCA
dir = /usr/lib/ssl/ServerCA
# Where is the ServerCA's certificate
certificate = $dir/ServerCA.cert.pem
# and where is the ServerCA's private key
private_key = $dir/private/ServerCA.key.pem
Without the private key, the ServerCA will not be
able to sign your LDAP certificate. You will find more
configuration hints for openssl.cnf in the tutorial.
Hope this helps,
Hauke
--
----- Ursprüngliche Mail -----
Von: "Dat Duong" <datduong2000(a)yahoo.com>
An: "hauke coltzau" <hauke.coltzau(a)FernUni-Hagen.de>
Gesendet: Dienstag, 7. Oktober 2008 09:06:07 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien
Betreff: StartTLS is not working
Hi Hauke,
I read your instruction on how to create Root CA ...I have a hard time understanding the step. I have a question on how to sign the ldap server certificated using Server CA? I get an error message:
bash-3.00# openssl ca -name ServerCA -in afldap01.req.pem -out afldap01.cert.pem
Using configuration from /usr/local/ssl/openssl.cnf
variable lookup failed for ServerCA::private_key
18908:error:0E06D06C:configuration file routines:NCONF_get_string:no value:conf_lib.c:329:group=ServerCA name=private_key
Thanks
Dat
--
------------------------------------
Fernuniversität in Hagen
Lehrgebiet Kommunikationsnetze
http://www.fernuni-hagen.de/kn
Fon/Fax: +49 2331 987 -1142 / -353
------------------------------------
I have setup two ldap servers for authentication and access control in a multi-master configuration. I am concerned about the number of contextcsn entries that are supposed to be present in each database. Right now there are two servers participating in the multi-master configuration. From my understanding, there should be one contextCSN entry per database per host. My cn=config database has two contextCSN entries as I would expect. One for each syncrepl rid configured. My bdb database only has one contextCSN entry though, with an rid of just "000". (my rid's are 001, 002, 101, and 102)
Replication seems to work fine on both databases. I can write to either one and the changes are replicated over immediately. I am just curious about this discrepancy in the number of contextCSN entries. Could someone confirm the number of contextCSN entries per database and if it should match the number of hosts participating in the multi-master replication? Here are some relevant settings for the replication:
dn: cn=config
olcServerID: 1 ldap://<server1>
olcServerID: 2 ldap://<server2>
#######################
# module{0}, config
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib64/openldap2.4
olcModuleLoad: {0}syncprov.la
#######################
# {0}config, config
dn: olcDatabase={0}config,cn=config
olcSyncrepl: {0}rid=001 provider=ldap://<server1> binddn="cn=Ma
nager,cn=config" bindmethod=simple credentials=<password> searchbase="cn=config
" type=refreshAndPersist retry="5 500 5 +" timeout=1 starttls=yes
olcSyncrepl: {1}rid=002 provider=ldap://<server2> binddn="cn=Ma
nager,cn=config" bindmethod=simple credentials=<password> searchbase="cn=config
" type=refreshAndPersist retry="5 500 5 +" timeout=1 starttls=yes
olcMirrorMode: TRUE
#######################
# {0}syncprov, {0}config, config
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
#######################
# {1}bdb, config
dn: olcDatabase={1}bdb,cn=config
olcSyncrepl: {0}rid=101 provider=ldap://<server1> binddn="cn=Ma
nager,dc=mgcorp,dc=net" bindmethod=simple credentials=<password> searchbase="dc
=mgcorp,dc=net" type=refreshAndPersist interval=00:00:00:10 retry="5 500 5 +"
timeout=1 starttls=yes
olcSyncrepl: {1}rid=102 provider=ldap://<server2> binddn="cn=Ma
nager,dc=mgcorp,dc=net" bindmethod=simple credentials=<password> searchbase="dc
=mgcorp,dc=net" type=refreshAndPersist interval=00:00:00:10 retry="5 500 5 +"
timeout=1 starttls=yes
olcMirrorMode: TRUE
##############################
Here are the results of searches for contextCSN in cn=config and dc=mgcorp,dc=net:
ldapsearch -x -W -s base -D "cn=Manager,cn=config" -h "<server2>" -b "cn=config" contextCSN
contextCSN: 20101110214932.998233Z#000000#000#000000
contextCSN: 20101028121213.444193Z#000000#001#000000
ldapsearch -x -W -s base -D "cn=Manager,dc=mgcorp,dc=net" -h "<server2>" -b "dc=mgcorp,dc=net" contextCSN
contextCSN: 20101110213409.736943Z#000000#000#000000
