On Monday 28 January 2008 16:57:28 Chris Carr wrote:
> 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.
Which version of Evolution? Mine has a "Use secure connection" drop-down box,
with "SSL encryption", "TLS encryption" and "No encryption" options. Since
the port doesn't change based on your selection, I'll assume what they
actually mean is "ldaps", "STARTTLS", and "No encryption". Naturally,
STARTTLS would run on the normal unencrypted port (389 by default),
and "upgrade" to SSL/TLS with a STARTTLS command.
It seems that no matter what you select here, if the port is 389, it does
STARTTLS:
Jan 29 17:59:16 seaknight slapd[840]: conn=0 fd=15 ACCEPT from
IP=127.0.0.1:53243 (IP=0.0.0.0:389)
Jan 29 17:59:16 seaknight slapd[840]: conn=0 op=0 STARTTLS
Jan 29 17:59:16 seaknight slapd[840]: conn=0 op=0 RESULT oid= err=0 text=
Jan 29 17:59:16 seaknight slapd[840]: conn=0 fd=15 TLS established tls_ssf=256
ssf=256
However, if you select 636 as the port, it greys out the "Use secure
connection" drop-down box, and does ldaps.
Jan 29 18:03:51 seaknight slapd[840]: conn=14 fd=27 ACCEPT from
IP=127.0.0.1:54153 (IP=0.0.0.0:636)
Jan 29 18:03:51 seaknight slapd[840]: conn=14 fd=27 closed (TLS negotiation
failure)
Jan 29 18:03:58 seaknight slapd[840]: conn=15 fd=27 ACCEPT from
IP=127.0.0.1:45074 (IP=0.0.0.0:389)
(Can't get it to work right right now with ldaps ...).
Note however that evo caches LDAP connections, it seems you need to restart it
for your config changes to take effect.
And, it will only prompt you for the password once the connection is up ...
> When I type
>
> openssl s_client -connect my.server.com:389
>
> It says connection refused. When I type the same command with :636 at
> the end it connects fine.
>
> Could somebody explain to me how to tell slapd to accept secure
> connections on port 389? I am using the new version of slapd in Debian
> Testing (2.4.7-1).
start slapd with with no -h flag, or -h "ldaps:/// ldap:///" so it listens on
port 636 for ldaps connections, and 389 for ldap connections (which could use
START_TLS to upgrade).
> Sorry if this is a really stupid question, but according to the docs the
> "startTLS" process should be automatic if a secure connection comes in
> on port 389. Something is obviously not quite right.
Hmm, SSL/TLS isn't really automatic ...
Regards,
Buchan
Look at the options for setting ssf (Security Strength Factors):
http://www.openldap.org/doc/admin24/access-control.html#Granting%20and%20De…
I typically setup a global minssf of 256 to ensure maximum security, when possible via the 'security minssf=256'.
re: man slapd.conf
HTH,
Joshua Miller
ITSA Consulting, LLC
http://itsecureadmin.com/
On Feb 26, 2012, at 2:49 AM, Daniel Pocock wrote:
>
>
>
> 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:/// ?
>
>
On Tue, Mar 13, 2012 at 11:30 AM, Rich Megginson
<rich.megginson(a)gmail.com>wrote:
> On 03/13/2012 12:03 PM, Peter Wood wrote:
>
>
>
> On Mon, Mar 12, 2012 at 9:41 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote:
>
>> --On Monday, March 12, 2012 6:52 PM -0700 Peter Wood <
>> peterwood.sd(a)gmail.com> wrote:
>>
>> Hi,
>>>
>>>
>>> I setup openldap-2.4.23 server
>>>
>>
>> Why? I'd suggest you start with the current release, 2.4.30. You may
>> also want to look at <http://www.openldap.org/its/index.cgi/?findid=7197>
>>
>>
> That's the openldap version in centos6.2 repo. In production I try to
> stick with stock versions.
>
> Also I tried all variations of olcTLSVerifyClient: [demand|hard|true]
> with the same result.
>
> I don't think StartTLS is enabled. I'm wondering if just setting
> olcTLSCACertificateFile, olcTLSCertificateFile and olcTLSCertificateKeyFile
> is enough to get StartTLS enabled.
>
> Yes, it is.
>
>
> It's very frustrating. I'd hate to go to ldaps just because I can't get
> StartTLS working.
>
> Is there anything else I have to set on the server to get StartTLS
> working?
>
> Can you provide the exact command line you are using to test the server
> connection? Note that if the client is using regular LDAP and not LDAPS
> nor LDAP+startTLS, the olcTLSVerifyClient: demand setting does nothing.
>
This is exactly what I'm seeing. I misunderstood the documentation. I
thought that when olcTLSVerifyClient is set to demand then a valid
certificate is required and the connection will drop if one is not provided.
>
> If you are trying to make the client always use SASL/EXTERNAL auth with a
> valid client cert, you must first force the server to reject any
> non-TLS/SSL connection using the sasl-secprops minssf setting.
>
Yes. I'd like the server to reject any non-TLS/SSL connections. I'll look
into the settings you mentioned.
As I was typing this I received a few more answers. Thank you very much.
Last question:
If the FQN of the client is server1.mydomain.com and in the certificate
the commonName is server1.mydomain.com but
in openldap the DSE is "dc=hr,dc=mydomain,dc=com".
Will that work or the DSE has to match the domain name i.e.
"dc=mydomain,dc=com"?
Thank you
Peter
If you want to disable simple bind (password) etc. without encryption,
you might go along the lines:
security ssf=1 update_ssf=112 simple_bind=112
in slapd.conf
>>> 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:/// ?
That would be another option, its feasibility depending on your environment.
kind regards /markus
r0m5 wrote:
> So I set up a PKI and now it looks OK regarding syncrepl. So I guess my problem might
> be related to ITS#8427, which I didn't see before posting here.
>
> I still have issues though, with applications randomly failing STARTTLS to my consumers
Many problems like this are caused by not getting the PKI to issue correct public-key
certs. Especially you should put all DNS names a LDAP client might use to connect to your
LDAP server in subjectAltName extension.
E.g. ITS#8427 says:
"Provide the servers with TLS certificates that are correct but do not include
an address used in syncrepl provider setting."
What the heck does that mean?!?
Ciao, Michael.
Peter Marschall wrote:
> On Monday, 28. May 2012, Philip Guenther wrote:
>> On Mon, 28 May 2012, Michael Ströder wrote:
>>> Peter Marschall wrote:
>>>> how do the openldap tools technically verfify certificates with
>>>> ldapi:// ?
>>>
>>> Which certs do you want to verify?
>>
>> I assume the answer is "the one the server returns when you do StartTLS on
>> the ldapi:// connection".
> Correct.
So if the quite liberal RFC 6125 does not provide any inspiration this boils
down to being undefined. StartTLS over LDAPI is an unusal scenario anyway.
Ciao, Michael.
Hi,
On November 4, 2012 11:13:27 PM admus wrote:
> Hello,
> I'm following
> https://help.ubuntu.com/12.04/serverguide/openldap-server.html#openldap-tls
> -replication how to: LDAP serwer starts correctly but when I tries to test
> StartTLS:
> ldapsearch -x -H ldap:/// -ZZ -d -1
> I gets the following error:
> TLS: peer cert untrusted or revoked (0x42)
> TLS: can't connect: (unknown error code).
> ldap_err2string
> ldap_start_tls: Connect error (-11)
> additional info: (unknown error code)
> Any idea?
Have you verified your certificate? What is the output of :
openssl s_client -connect ldap1.example.com:636 -showcerts
or on the server itself you can dump the cert info
cat ldap-cert.pem | openssl x509 -text
Dieter Klünter wrote:
> Am Mon, 2 Nov 2015 17:28:06 +0100
> schrieb Matthias Apitz <guru(a)unixarea.de>:
>
>>
>> Hello,
>>
>> I'm trying to make from FreeBSD a LDAPsearch in some Novell eDirectory
>> with the following command:
>>
>> $ ldapsearch -Z -H ldaps://romega:1027 -b 'ou=person,o=uni' -D
> [...]
>
> Quite obvious, you initiated startTLS AND ldaps. To my knowledge,
> edirectory does not support startTLS, so just omit -Z.
No, that's not the problem. Note that with a single -Z, ldapsearch will
proceed even if the server doesn't support startTLS.
The problem here is that he hasn't configured the local LDAP clients to trust
the remote server's certificates.
> $ ldapsearch -Z -H ldaps://romega:1027 -b 'ou=person,o=uni' -D 'cn=XXXXXXXXXX,ou=service,o=uni' -w XXXXXXXXXX
> ldap_start_tls: Can't contact LDAP server (-1)
> additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self signed certificate in certificate chain)
The error message is quite explicit - "certificate verify failed" - this
obviously means that it started a TLS handshake, which obviously makes your
focus on -Z completely off base.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
r0m5 wrote:
> Le 2017-08-09 14:13, Michael Ströder a écrit :
>> Many problems like this are caused by not getting the PKI to issue correct
>> public-key certs. Especially you should put all DNS names a LDAP client might use to
>> connect to your LDAP server in subjectAltName extension.
>>
>> E.g. ITS#8427 says:
>> "Provide the servers with TLS certificates that are correct but do not include
>> an address used in syncrepl provider setting."
>> What the heck does that mean?!?
>
> I guess the guy uses in order to reproduce a provider certificate which is signed by a
> CA his consumer trusts, but the consumer connects to the provider using a DNS name
> different from the certificate CN and not included in subjectAltName.
Yes, therefore I'd see ITS#8427 resolved as do-not-use-broken-certs.
> Regarding my applications randomly failing STARTTLS to my consumers, it's not related
> to the use of a DNS name different from the certificate CN and not included in
> subjectAltName. Considering an application using always the same DNS name
> [..]
> I will dig more into it. So far it appears than only PHP applications fail this way, it
> seems like there are no probrems with STARTTLS from freeradius or Apache Basic AuthType
> with AuthBasicProvider ldap.
Then this sounds like PHP-LDAP being broken.
Ciao, Michael.
Heya,
In order to enable write chaining, I used the normal mechanism of using a
slapd.conf file to generate the necessary slapd.d configuration that I'm
now using to seed the servers that I'm building.
Out of interest - why do I need the two separate overlays (shown bellow) in
the final config? Trying to understand what's actually happening and can't
quite make sense of why this is defined like this.
dn:
olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {0}ldap
olcDbStartTLS: start starttls=yes
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: FALSE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbOnErr: continue
olcDbKeepalive: 0:0:0
dn:
olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {1}ldap
olcDbURI: "ldap://*ldapserver*/"
olcDbStartTLS: start starttls=yes
olcDbIDAssertBind: mode=self
flags=prescriptive,proxy-authz-non-critical
bindmethod=simple
timeout=0
network-timeout=0
binddn="*binddn*"
credentials="*cred*"
keepalive=0:0:0
starttls=yes
tls_cacert="/etc/openldap/certs/CA.crt"
tls_reqcert=demand
olcDbRebindAsUser: TRUE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: FALSE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbOnErr: continue
olcDbKeepalive: 0:0:0
Thanks in advance,
--
Tim
tim(a)yetanother.net
