Hello
I would like to setup a ldaprc so that an application uses: - a localhost-base slapd without authentification (just relying on filesystem permission on the slapd socket) - if it is not available, a remote slapd, authenticating using client certificate
Here is the desired ldaprc: BASE dc=example,dc=net URI ldapi:/// ldaps://ldap.example.net TLS_CACERT /etc/openssl/ca.crt TLS_CERT /etc/openssl/host.crt TLS_KEY /etc/openssl/host.key SASL_MECH EXTERNAL TLS_REQCERT demand
Of course it will not work, as the ldapi:/// connection will present a certificate. I have the feeling the setup I am looking for cannot be configured. Is that right?
manu@netbsd.org (Emmanuel Dreyfus) writes:
Hello
I would like to setup a ldaprc so that an application uses:
- a localhost-base slapd without authentification (just relying on
filesystem permission on the slapd socket)
- if it is not available, a remote slapd, authenticating using client
certificate
Here is the desired ldaprc: BASE dc=example,dc=net URI ldapi:/// ldaps://ldap.example.net TLS_CACERT /etc/openssl/ca.crt TLS_CERT /etc/openssl/host.crt TLS_KEY /etc/openssl/host.key SASL_MECH EXTERNAL TLS_REQCERT demand
Of course it will not work, as the ldapi:/// connection will present a certificate. I have the feeling the setup I am looking for cannot be configured. Is that right?
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.
-Dieter
Dieter Kluenter dieter@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 wrote:
Dieter Kluenter dieter@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.
Why not use SASL/EXTERNAL in both cases and let slapd map SASL authc-DN to the same authz-DN?
Ciao, Michael.
On 24/06/10 11:57 +0200, Emmanuel Dreyfus wrote:
Dieter Kluenter dieter@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.
You could do SASL EXTERNAL over both, with ldapi:/// using Unix peercred, i.e.:
authz-regexp ".*uidNumber=([^,]+),cn=peercred,cn=external,cn=auth" ldap:///ou=People,dc=example,dc=net??one?(uidNumber=$1)
Dan White dwhite@olp.net wrote:
You could do SASL EXTERNAL over both, with ldapi:/// using Unix peercred, i.e.:
authz-regexp ".*uidNumber=([^,]+),cn=peercred,cn=external,cn=auth" ldap:///ou=People,dc=example,dc=net??one?(uidNumber=$1)
That sounds nice, but will it works with the "TLS_REQCERT demand" I have for ldaps:// ?
On 24/06/10 22:13 +0200, Emmanuel Dreyfus wrote:
Dan White dwhite@olp.net wrote:
You could do SASL EXTERNAL over both, with ldapi:/// using Unix peercred, i.e.:
authz-regexp ".*uidNumber=([^,]+),cn=peercred,cn=external,cn=auth" ldap:///ou=People,dc=example,dc=net??one?(uidNumber=$1)
That sounds nice, but will it works with the "TLS_REQCERT demand" I have for ldaps:// ?
Try:
TLS_REQCERT: try
In this case, EXTERNAL should only be offered after successful TLS negotiation, or over a unix domain socket.
If TLS negotiation fails, then a SASL bind won't work without selecting another mechanism.
Dan White dwhite@olp.net wrote:
Try:
TLS_REQCERT: try
In this case, EXTERNAL should only be offered after successful TLS negotiation, or over a unix domain socket.
If TLS negotiation fails, then a SASL bind won't work without selecting another mechanism.
But Idap.conf(5) says "The server certificate is requested. If no certificate is provided, the session proceeds normally. ", which suggests that the TLS negociation may succeed without a server certificate being sent. Is that wrong?
On 25/06/10 05:29 +0200, Emmanuel Dreyfus wrote:
Dan White dwhite@olp.net wrote:
Try:
TLS_REQCERT: try
In this case, EXTERNAL should only be offered after successful TLS negotiation, or over a unix domain socket.
If TLS negotiation fails, then a SASL bind won't work without selecting another mechanism.
But Idap.conf(5) says "The server certificate is requested. If no certificate is provided, the session proceeds normally. ", which suggests that the TLS negociation may succeed without a server certificate being sent. Is that wrong?
SASL EXTERNAL will only be offered if the server can identify you, or derive an authentication identity, which it can never do if TLS does not succeed - since it derives your identity from the contents of the client certificate.
Apologies for the list clutter, but I couldn't find a more appropriate place to send this.
I originally sent this question to mailman@www.openldap.org, which is listed on:
http://www.openldap.org/mailman/listinfo
as the contact for list problems, but that address was rejected with:
mailman@www.openldap.org: host www.openldap.org[204.152.186.57] said: 550 5.1.2 mailman@www.openldap.org... Rejected; bad system address (in reply to RCPT TO command)
My original question was:
I've noticed that my emails to the openldap-technical list are delayed. Typically the email is delayed from 30 minutes to an hour or two.
However, this email I sent yesterday was delayed for 16 hours. In all cases, the delay appears to happen internally within boole.openldap.org.
Could this be due to a reputation issue with my relay server (pinky.olp.net)? Or is this just moderation delay?
Here's a header snippet from the email in question:
... Received: from psmtp.com (exprod5mx267.postini.com [64.18.0.90]) by neo.olp.net (Postfix) with ESMTP id 8E23420EDC1 for dwhite@olp.net; Fri, 25 Jun 2010 08:56:28 -0500 (CDT)
Received: from source ([204.152.186.50]) (using TLSv1) by exprod5mx267.postini.com ([64.18.4.10]) with SMTP; Fri, 25 Jun 2010 09:56:28 EDT
Received: from boole.openldap.org (mailman@localhost [IPv6:::1]) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id o5PDj7QP064017 for dwhite@olp.net; Fri, 25 Jun 2010 13:56:20 GMT (envelope-from openldap-technical-bounces+dwhite=olp.net@openldap.org)
Received: from pinky.olp.net (postfix@pinky.olp.net [67.217.151.200]) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id o5OLriEj067106 for openldap-technical@openldap.org; Thu, 24 Jun 2010 21:54:08 GMT (envelope-from dwhite@olp.net)
Received: from quark.olp.net (vpn.olp.net [67.217.151.100]) by pinky.olp.net (Postfix) with ESMTP id 378C0292E8E; Thu, 24 Jun 2010 16:53:42 -0500 (CDT)
Received: by quark.olp.net (Postfix, from userid 1000) id 1EFE6E7E002; Thu, 24 Jun 2010 16:53:40 -0500 (CDT)
On 24/06/10 16:53 -0500, Dan White wrote:
On 24/06/10 22:13 +0200, Emmanuel Dreyfus wrote:
Dan White dwhite@olp.net wrote:
You could do SASL EXTERNAL over both, with ldapi:/// using Unix peercred, i.e.:
authz-regexp ".*uidNumber=([^,]+),cn=peercred,cn=external,cn=auth" ldap:///ou=People,dc=example,dc=net??one?(uidNumber=$1)
That sounds nice, but will it works with the "TLS_REQCERT demand" I have for ldaps:// ?
Try:
TLS_REQCERT: try
In this case, EXTERNAL should only be offered after successful TLS negotiation, or over a unix domain socket.
If TLS negotiation fails, then a SASL bind won't work without selecting another mechanism.
-- Dan White
On 06/25/10 16:25, Dan White wrote:
Apologies for the list clutter, but I couldn't find a more appropriate place to send this.
I originally sent this question to mailman@www.openldap.org, which is listed on:
http://www.openldap.org/mailman/listinfo
as the contact for list problems, but that address was rejected with:
mailman@www.openldap.org: host www.openldap.org[204.152.186.57] said: 550 5.1.2 mailman@www.openldap.org... Rejected; bad system address (in reply to RCPT TO command)
My original question was:
I've noticed that my emails to the openldap-technical list are delayed. Typically the email is delayed from 30 minutes to an hour or two.
However, this email I sent yesterday was delayed for 16 hours. In all cases, the delay appears to happen internally within boole.openldap.org.
Could this be due to a reputation issue with my relay server (pinky.olp.net)? Or is this just moderation delay?
It's quite common these days (weeks, month). In other words, you're not alone who gets delayed e-mails.
Regards, Zdenek
Dan White wrote:
On 24/06/10 22:13 +0200, Emmanuel Dreyfus wrote:
Dan White dwhite@olp.net wrote:
You could do SASL EXTERNAL over both, with ldapi:/// using Unix peercred, i.e.:
authz-regexp ".*uidNumber=([^,]+),cn=peercred,cn=external,cn=auth" ldap:///ou=People,dc=example,dc=net??one?(uidNumber=$1)
That sounds nice, but will it works with the "TLS_REQCERT demand" I have for ldaps:// ?
Try:
TLS_REQCERT: try
In this case, EXTERNAL should only be offered after successful TLS negotiation, or over a unix domain socket.
Why should this have effect for ldapi:/// at all?
If TLS negotiation fails, then a SASL bind won't work without selecting another mechanism.
There is no TLS negotiation on a Unix domain socket at all.
IMO many statements in this thread cause confusion: EXTERNAL acts differently depending on the connection type used. AFAIK you can query whether it's available for a certain connection by reading attribute supportedSASLMechanisms in the rootDSE.
Emmanuel should simply set up a test environment where all the relevant clients always use SASL/EXTERNAL and have a SASL authc-to-authz-DN mapping in place for ldaps:// with client certs and ldapi:/// with peer credentials. The TLS options only affect ldaps:// or ldap:// with StartTLS ext.op.
Ciao, Michael.
Emmanuel Dreyfus wrote:
Dan White dwhite@olp.net wrote:
You could do SASL EXTERNAL over both, with ldapi:/// using Unix peercred, i.e.:
authz-regexp ".*uidNumber=([^,]+),cn=peercred,cn=external,cn=auth" ldap:///ou=People,dc=example,dc=net??one?(uidNumber=$1)
That sounds nice, but will it works with the "TLS_REQCERT demand" I have for ldaps:// ?
It's simply not needed for ldapi:/// if the client sends a SASL/EXTERNAL bind request.
Ciao, Michael.
Dan White dwhite@olp.net wrote:
You could do SASL EXTERNAL over both, with ldapi:/// using Unix peercred, i.e.:
authz-regexp ".*uidNumber=([^,]+),cn=peercred,cn=external,cn=auth" ldap:///ou=People,dc=example,dc=net??one?(uidNumber=$1)
That works fine.
manu@netbsd.org (Emmanuel Dreyfus) writes:
Dieter Kluenter dieter@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.
This can be achieved by ACL's, man slapd.access(5),
access to ... by sockname=... access to .. by tls_ssf=...
-Dieter
openldap-technical@openldap.org
-
Dan White -
Dieter Kluenter -
manu＠netbsd.org -
Michael Ströder -
Zdenek Styblik