--On Monday, January 18, 2021 3:52 AM +0000 shelke.sachitanand(a)gmail.com
wrote:
> Few queries I have for these openLDAP,
> 1) Does Symas OpenLDAP or LTB OpenLDAP supports rolling updates?
Symas OpenLDAP on RHEL is a drop in replacement for the RHEL packages. You
can use yum to update it when new builds are released.
> 2) is there any way we can enable/disable SSL/Non-SSL mode for openldap..
Read the man pages and admin guide. Your question, however, is vague.
Please expand on what you're asking. There's no such thing as an
"SSL/Non_SSL" mode for the LDAP protocol. One can (optionally) use
startTLS over ldap:///, one can require TLS with ldaps://, and one can mix
the two. And it's possible to configure the slapd server to reject any
connection that doesn't have a security factor of X.
> a) I have installed symas openLDAP with default configuration and
> observed its running in Non-SSL mode and running on 389 port.
That implies you don't understand the LDAP protocol.
> b) I
> tried LTB openLDAP with default configuration and observed its going for
> SSL mode and observed its running on two ports 389 and 636
This also implies you don't understand the LDAP protocol.
Again, ldap:/// can be used both with or without startTLS. slapd can be
configured to require all connections be encrypted, regardless of whether
it's ldap:/// or ldaps:///
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Dear openldap-technical users,
my password policies (openldap 2.5.11) are not enforced and Roland
Gruber (author of LAM (Pro)) kindly advised me that passwords must be
stored in plaintext (Hash=PLAIN) in order to be able to enforce password
minimal length, password quality etc (i.e. when using passwd(1) on Linux
or an LDAP client on Windows).
Currently we are storing passwords as base64 encoded (::*) Salted SHA1
hashes ("{SSHA}*") (according to slapcat -n 1).
tl;dr: For enforcing password policies, what is the role of
"password-hash:PLAIN"(?) and olcPPolicyHashCleartext: TRUE (applied to
dn: olcOverlay=ppolicy,olcDatabase={1}mdb,cn=config) and what is
the security implication of these changes (we are using starttls on
linux / ssl on windows with a self-signed certificate in intranet)?
- Is it (necessary and) enough to switch to "password-hash:PLAIN" to be
able to enforce password policies? Does olcPPolicyHashCleartext: TRUE
[alone] help as written in this post [1]?
[1] https://www.openldap.org/lists/openldap-technical/201708/msg00024.html
EDIT: I think that olcPPolicyHashCleartext==ppolicy_hash_cleartext
(one is OLC, one is trad. config)? -> can we update the documentation [2]?
[2] https://www.openldap.org/doc/admin25/guide.html#Password%20Policies
- I am worried about security when storing/transferring pwds in
plain text (we are using starttls on linux / ssl on windows with a
self-signed certificate in intranet) [3]. Will
"ppolicy_hash_cleartext" [2] help with this?
[3] The manual states "Unfortunately, as dictionary and brute force
attacks are generally quite easy for attackers to successfully mount,
this advantage is marginal at best (this is why all modern Unix systems
use shadow password files)."
Many Thanks and Best Regards,
Felix
--
Felix Natter
Hi,
I am trying to force users to change their password at first login or
after
password reset by administrator.
Tried following:
1)Password policy 'pwdMustChange TRUE' doesn't seems to be working as non
of the
users get prompt to change their password at first login.
2) used the 'pwdReset TRUE' attribute in users attributes, and it won't
prompt
to change the password and didn't allow to login
i observe below messages in log
"slapd[12684]: connection restricted to password changing only
slapd[12684]: send_ldap_result: err=50 matched="" text="Operations are
restricted to bind/unbind/abandon/StartTLS/modify password"
slapd[12684]: conn=1053 op=1 SEARCH RESULT tag=101 err=50 nentries=0
text=Operations are restricted to bind/unbind/abandon/StartTLS/modify
password"
Please help me configure the option to force all users to change their
password
at first login or after pwd reset by administrator.
Thanks & Regards
Raj
Tata Consultancy Services
Mailto: rajagopal.rc(a)tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
On 04/10/11 09:22 -0700, Howard Chu wrote:
>Dan White wrote:
>>On 03/10/11 21:43 +0200, Andreas Rudat wrote:
>>>Am 03.10.2011 20:51, schrieb Dan White:
>>>>On 03/10/11 19:41 +0200, Andreas Rudat wrote:
>>>>>tls_cert
>>>>>tls_key
>>>>
>>>>My mail client may have corrupted this part of your configuration. You'll
>>>>of course need valid entries here.
>>>>
>>>These options are defaults in my conf. With some comments, after
>>>installing the slapd package
>>
>>You'll need to create a (client) certificate and populate those two values,
>>or otherwise find a way to specify them while performing your ldapsearch
>>command.
>>
>>I don't see how you will will be able to obtain SASL EXTERNAL over STARTTLS
>>otherwise.
>
>How did this conversation get to STARTTLS? The Subject is asking
>about SASL EXTERNAL over ldapi, which does not need TLS.
I was led down that path via the howto referenced in the original post, and
made several, possibly incorrect, assumptions about what the end goal is.
--
Dan White
On Mon, 2008-01-28 at 09:00 -0800, Quanah Gibson-Mount wrote:
> --On Monday, January 28, 2008 2:57 PM +0000 Chris Carr
>
> > Hi All,
> >
> > I've been running slapd with "-h ldaps:///" so that it takes SSL/TLS
> > connections on port 636. This has worked with most clients (Outlook,
> > Seamonkey, Thunderbird) but does not work for Evolution. I don't know
> > why not, but Evolution seems to insist on using port 389 for secure
> > connections.
> >
> > When I type
> >
> > openssl s_client -connect my.server.com:389
>
> If you read the documentation on openssl, it clearly states it doesn't
> support doing LDAP startTLS over port 389.
I thought startTLS was supposed to be the replacement for ldaps, so that
only one port was needed for both secure and insecure connections.
Wasn't that discussed on this list quite recently? I have definitely
misunderstood something.
Still, at least I can now focus on why Evolution isn't connecting
properly on port 636.
> I suggest using ldapsearch -ZZ -H ldap://my.server.com:389/
That gives me "Can't contact LDAP server (-1)". Same if I use :636 in
fact.
CC
This e-mail may contain information which is confidential, legally privileged and/or copyright protected. This e-mail is intended for the addressee only. If you receive this in error, please contact the sender and delete the material from your computer
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
------------------------------------
hi,
while I can hardly say anything about your code, I think you should read
up on how to use openssl in objective c (I guess thats what you use to
write your app).
The general Idea would be to open an SSL connection to ldapserver port
636 and then through that connection (e.g. the socket), do exactly the
same as you did before with an unencrypted connection.
As a side note, LDAPS is considered deprecated in favour of using
STARTTLS on Port 389 instead, so you might want to read up on that too.
Regards,
--
Bernd May
Dieter Kluenter <dieter(a)dkluenter.de> wrote:
> No, ldapi:/// doesn't present a certificate, but you may establish a
> startTLS session to ldapi:///, in this case the client requests a
> server certificate.
Let me rephrase: I would like to specify two LDAP servers in ldaprc
- one ldapi:/// with anonymous bind
- one ldaps:// with SASL EXTERNAL for and required server certificate
It seems to me it is not possible.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
On 10/10/2011 11:40 AM, Olivier wrote:
> Hello,
>
> I have two ldap servers, my goal is to configure them
> in multimaster mode with an sasl authentication based
> on certificates. With the following configurations, that
> works well :
>
>
> ### slapd.conf for ldap1 :
>
> syncrepl rid=121
> provider=ldap://ldap2.example.fr
> searchbase="dc=example,dc=fr"
> schemachecking=on
> type=refreshOnly
> interval=00:00:00:05
> retry="10 +"
> bindmethod=sasl
> saslmech=external
> authcid="cn=replicator,ou=system,dc=example,dc=fr"
> authzid="dn:cn=replicator,ou=system,dc=example,dc=fr"
> tls_cert=/etc/openldap/cacerts/syncrepl.crt
> tls_key=/etc/openldap/cacerts/syncrepl.key
> tls_reqcert=demand
>
> mirrormode on
>
> ### slapd.conf for ldap1 :
>
> syncrepl rid=121
> provider=ldap://ldap2.example.fr
> searchbase="dc=example,dc=fr"
> schemachecking=on
> type=refreshOnly
> interval=00:00:00:05
> retry="10 +"
> bindmethod=sasl
> saslmech=external
> authcid="cn=replicator,ou=system,dc=example,dc=fr"
> authzid="dn:cn=replicator,ou=system,dc=example,dc=fr"
> tls_cert=/etc/openldap/cacerts/syncrepl.crt
> tls_key=/etc/openldap/cacerts/syncrepl.key
> tls_reqcert=demand
>
> mirrormode on
>
> # of course I have provided the CA certificate in both files.
> TLSCACertificateFile /etc/openldap/cacerts/CA.crt
>
> # I also configured properly acl for "replicator"
> # and have issued the right certificate
>
> -> No problem, it works.
>
> Now I also have configured certificates to be able to talk with the
> servers on TLS :
>
> ### slapd.conf for ldap1 :
> TLSCertificateFile /etc/openldap/cacerts/server1.crt
> TLSCertificateKeyFile /etc/openldap/cacerts/server1.key
> TLSCipherSuite HIGH
>
> ### slapd.conf for ldap2 :
> TLSCertificateFile /etc/openldap/cacerts/server2.crt
> TLSCertificateKeyFile /etc/openldap/cacerts/server2.key
> TLSCipherSuite HIGH
>
> That also works perfectly ( ldapsearch with -ZZ responds properly )
>
> I therefore decided to try to starttls for synchronisation.
>
> I added in syncrepl for ldap1 :
>
> ## ldap1
>
> syncrepl
> ...
> starttls=yes
> tls_cacert=/etc/openldap/cacerts/CA.crt
> ...
>
> And the synchronizations worked well, TLS being started when ldap1 is client.
>
> I then added the starttls directive on server ldap2 and removed it
> on server ldap1 :
>
> ## ldap2
>
> syncrepl
> ...
> starttls=yes
> tls_cacert=/etc/openldap/cacerts/CA.crt
> ...
>
> The synchronization also worked well, TLS being started this time when
> ldap2 is client.
>
> HERE IS THE PROBLEM :
>
> II tried to starttls in bothe syncrepl directives on both servers
> ldap1 and ldap2,
> here is what I get :
>
> ldap1 # /usr/sbin/slapd -f slapd.conf -h ldap:/// -u ldap -d Sync
> ...
> TLS: error: accept - force handshake failure: errno 11 - moznss error -12273
> TLS: can't accept: TLS error -12273:Unknown code ___P 15.
> TLS: error: connect - force handshake failure: errno 0 - moznss error -12272
> TLS: can't connect: TLS error -12272:Unknown code ___P 16.
> slap_client_connect: URI=ldap://ldap2.example.fr Warning,
> ldap_start_tls failed (-11)
> slap_client_connect: URI=ldap://ldap2.example.fr
> ldap_sasl_interactive_bind_s failed (-6)
> do_syncrepl: rid=121 rc -6 retrying
>
> ldap2 # /usr/sbin/slapd -f slapd.conf -h ldap:/// -u ldap -d Sync
> ...
> TLS: error: connect - force handshake failure: errno 0 - moznss error -12272
> TLS: can't connect: TLS error -12272:Unknown code ___P 16.
> slap_client_connect: URI=ldap://ldap1.eaxample.fr:389 Warning,
> ldap_start_tls failed (-11)
> slap_client_connect: URI=ldap://ldap1.example.fr:389
> ldap_sasl_interactive_bind_s failed (-6)
> do_syncrepl: rid=211 rc -6 retrying
> TLS: error: accept - force handshake failure: errno 11 - moznss error -12273
> TLS: can't accept: TLS error -12273:Unknown code ___P 15.
>
> Any idea ?
-12272 is SSL_ERROR_BAD_MAC_ALERT and -12273 is SSL_ERROR_BAD_MAC_READ
I've seen this when the client and server do not have the same SSL
certificate signature algorithm support. Is everything running on RHEL6
and/or Fedora 14 and later?
> ---
> Olivier
>
Dieter Klünter wrote:
> Am Sun, 26 Feb 2012 12:39:26 +0100
> schrieb Daniel Pocock<daniel(a)pocock.com.au>:
>
>>
>>
>> On 26/02/12 12:15, Dieter Klünter wrote:
>>> Am Sun, 26 Feb 2012 11:49:14 +0100
>>> schrieb Daniel Pocock<daniel(a)pocock.com.au>:
>>>
>>>>
>>>>
>>>>
>>>> Is there some way to ensure that a client who connects on port 389
>>>> can do nothing without StartTLS?
>>>>
>>>> Or is it necessary to just disable port 389 and only listen for
>>>> ldaps:/// ?
>>>
>>> read on TLS OPTIONS in
>>> man ldap.conf(5) and man slapd.conf(5)
>>>
>>
>> Thanks for the fast reply
>>
>> I'm not keen to rely on ldap.conf (client side config) - I want to
>> enforce a preference for TLS from the server side, to avoid a
>> situation where some application might be configured non-TLS by
>> mistake.
>>
>> I've looked at the TLS options and I have TLS running fine already. I
>> notice the TLSCipherSuite option sets the cipher level within TLS, but
>> it doesn't appear to guarantee that TLS is used.
>
>> From man slapd.conf
> TLSVerifyClient<level>
> demand | hard | true
> These keywords are all equivalent, for
> compatibility reasons. The client certificate is
> requested. If no certificate is provided, or a bad
> certificate is provided, the session is immediately terminated.
>
>
>>
>> To make an analogy, in postfix, I require `plain' authentication: but
>> the client is not allowed to try to authenticate until it has done
>> StartTLS, because I never want a client to try sending a password
>> over a channel that is not encrypted.
>
> Postfix is a LDAP client, thus all client configurations apply
> according to man ldap.conf(5).
Dieter, no.
Josh Miller's post was correct.
http://www.openldap.org/lists/openldap-technical/201202/msg00414.html
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
