Re: Problem with ldap table lookups and TLS

2009-03-03 Thread Wietse Venema 
Victor Duchovni:
 With OpenLDAP 2.4 it is possible to set the TLS properties for
 a particular LDAP connection (not just global properties), and to
 associate a new OpenLDAP managed TLS context for the connection via the
 new LDAP_OPT_X_TLS_NEWCTX option.
 
 Try this completely untested patch (it may not even compile, but it
 looks promising):

Is this the version that is ready, or have there been furth changes?

Wietse

 Index: src/global/dict_ldap.c
 --- src/global/dict_ldap.c28 Jan 2008 04:29:48 -  1.1.1.2
 +++ src/global/dict_ldap.c26 Feb 2009 00:04:18 -
 @@ -484,10 +484,16 @@
  {
  const char *myname = dict_ldap_set_tls_options;
  int rc;
 +#ifdef LDAP_OPT_X_TLS_NEWCTX
 +int am_server = 0;
 +LDAP   *ld = dict_ldap-ld;
 +#else
 +LDAP   *ld = 0;
 +#endif
  
  if (dict_ldap-start_tls || dict_ldap-ldap_ssl) {
   if (*dict_ldap-tls_random_file) {
 - if ((rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_RANDOM_FILE,
 + if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_RANDOM_FILE,
  dict_ldap-tls_random_file)) != LDAP_SUCCESS) {
   msg_warn(%s: Unable to set tls_random_file to %s: %d: %s,
myname, dict_ldap-tls_random_file,
 @@ -496,7 +502,7 @@
   }
   }
   if (*dict_ldap-tls_ca_cert_file) {
 - if ((rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE,
 + if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_CACERTFILE,
 dict_ldap-tls_ca_cert_file)) != LDAP_SUCCESS) {
   msg_warn(%s: Unable to set tls_ca_cert_file to %s: %d: %s,
myname, dict_ldap-tls_ca_cert_file,
 @@ -505,7 +511,7 @@
   }
   }
   if (*dict_ldap-tls_ca_cert_dir) {
 - if ((rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTDIR,
 + if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_CACERTDIR,
  dict_ldap-tls_ca_cert_dir)) != LDAP_SUCCESS) {
   msg_warn(%s: Unable to set tls_ca_cert_dir to %s: %d: %s,
myname, dict_ldap-tls_ca_cert_dir,
 @@ -514,7 +520,7 @@
   }
   }
   if (*dict_ldap-tls_cert) {
 - if ((rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_CERTFILE,
 + if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_CERTFILE,
 dict_ldap-tls_cert)) != LDAP_SUCCESS) {
   msg_warn(%s: Unable to set tls_cert to %s: %d: %s,
myname, dict_ldap-tls_cert,
 @@ -523,7 +529,7 @@
   }
   }
   if (*dict_ldap-tls_key) {
 - if ((rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_KEYFILE,
 + if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_KEYFILE,
 dict_ldap-tls_key)) != LDAP_SUCCESS) {
   msg_warn(%s: Unable to set tls_key to %s: %d: %s,
myname, dict_ldap-tls_key,
 @@ -532,7 +538,7 @@
   }
   }
   if (*dict_ldap-tls_cipher_suite) {
 - if ((rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_CIPHER_SUITE,
 + if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_CIPHER_SUITE,
 dict_ldap-tls_cipher_suite)) != LDAP_SUCCESS) {
   msg_warn(%s: Unable to set tls_cipher_suite to %s: %d: %s,
myname, dict_ldap-tls_cipher_suite,
 @@ -540,13 +546,21 @@
   return (-1);
   }
   }
 - if ((rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT,
 + if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_REQUIRE_CERT,
  (dict_ldap-tls_require_cert))) != LDAP_SUCCESS) {
   msg_warn(%s: Unable to set tls_require_cert to %d: %d: %s,
myname, dict_ldap-tls_require_cert,
rc, ldap_err2string(rc));
   return (-1);
   }
 +#ifdef LDAP_OPT_X_TLS_NEWCTX
 + if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_NEWCTX, am_server))
 + != LDAP_SUCCESS) {
 + msg_warn(%s: Unable to allocate new TLS context %d: %s,
 +  myname, rc, ldap_err2string(rc));
 + return (-1);
 + }
 +#endif
  }
  return (0);
  }
 @@ -592,10 +606,6 @@
  
  #ifdef LDAP_OPT_NETWORK_TIMEOUT
  #ifdef LDAP_API_FEATURE_X_OPENLDAP
 -if (dict_ldap_set_tls_options(dict_ldap) != 0) {
 - dict_errno = DICT_ERR_RETRY;
 - return (-1);
 -}
  ldap_initialize((dict_ldap-ld), dict_ldap-server_host);
  #else
  dict_ldap-ld = ldap_init(dict_ldap-server_host,
 @@ -700,6 +710,8 @@
  #endif
  
  #ifdef LDAP_API_FEATURE_X_OPENLDAP
 +if (dict_ldap_set_tls_options(dict_ldap) != 0)
 + DICT_LDAP_UNBIND_RETURN(dict_ldap-ld, DICT_ERR_RETRY, -1);
  if (dict_ldap-start_tls) {
   if ((saved_alarm = signal(SIGALRM, dict_ldap_timeout)) == SIG_ERR) {
   msg_warn(%s: Error setting signal handler for STARTTLS timeout: 
 %m,
 
 -- 
   Viktor.
 
 Disclaimer: off-list followups get on-list replies or get ignored.

Re: Problem with ldap table lookups and TLS

2009-03-03 Thread Victor Duchovni 
On Tue, Mar 03, 2009 at 07:30:39PM -0500, Wietse Venema wrote:

 Victor Duchovni:
  With OpenLDAP 2.4 it is possible to set the TLS properties for
  a particular LDAP connection (not just global properties), and to
  associate a new OpenLDAP managed TLS context for the connection via the
  new LDAP_OPT_X_TLS_NEWCTX option.
  
  Try this completely untested patch (it may not even compile, but it
  looks promising):
 
 Is this the version that is ready, or have there been furth changes?
 

No changes. It worked as originally posted.

  Index: src/global/dict_ldap.c
  --- src/global/dict_ldap.c  28 Jan 2008 04:29:48 -  1.1.1.2
  +++ src/global/dict_ldap.c  26 Feb 2009 00:04:18 -
  @@ -484,10 +484,16 @@
   {
   const char *myname = dict_ldap_set_tls_options;
   int rc;
  +#ifdef LDAP_OPT_X_TLS_NEWCTX
  +int am_server = 0;
  +LDAP   *ld = dict_ldap-ld;
  +#else
  +LDAP   *ld = 0;
  +#endif
   
   if (dict_ldap-start_tls || dict_ldap-ldap_ssl) {
  if (*dict_ldap-tls_random_file) {
  -   if ((rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_RANDOM_FILE,
  +   if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_RANDOM_FILE,
 dict_ldap-tls_random_file)) != LDAP_SUCCESS) {
  msg_warn(%s: Unable to set tls_random_file to %s: %d: %s,
   myname, dict_ldap-tls_random_file,
  @@ -496,7 +502,7 @@
  }
  }
  if (*dict_ldap-tls_ca_cert_file) {
  -   if ((rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE,
  +   if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_CACERTFILE,
dict_ldap-tls_ca_cert_file)) != LDAP_SUCCESS) {
  msg_warn(%s: Unable to set tls_ca_cert_file to %s: %d: %s,
   myname, dict_ldap-tls_ca_cert_file,
  @@ -505,7 +511,7 @@
  }
  }
  if (*dict_ldap-tls_ca_cert_dir) {
  -   if ((rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTDIR,
  +   if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_CACERTDIR,
 dict_ldap-tls_ca_cert_dir)) != LDAP_SUCCESS) {
  msg_warn(%s: Unable to set tls_ca_cert_dir to %s: %d: %s,
   myname, dict_ldap-tls_ca_cert_dir,
  @@ -514,7 +520,7 @@
  }
  }
  if (*dict_ldap-tls_cert) {
  -   if ((rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_CERTFILE,
  +   if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_CERTFILE,
dict_ldap-tls_cert)) != LDAP_SUCCESS) {
  msg_warn(%s: Unable to set tls_cert to %s: %d: %s,
   myname, dict_ldap-tls_cert,
  @@ -523,7 +529,7 @@
  }
  }
  if (*dict_ldap-tls_key) {
  -   if ((rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_KEYFILE,
  +   if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_KEYFILE,
dict_ldap-tls_key)) != LDAP_SUCCESS) {
  msg_warn(%s: Unable to set tls_key to %s: %d: %s,
   myname, dict_ldap-tls_key,
  @@ -532,7 +538,7 @@
  }
  }
  if (*dict_ldap-tls_cipher_suite) {
  -   if ((rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_CIPHER_SUITE,
  +   if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_CIPHER_SUITE,
dict_ldap-tls_cipher_suite)) != LDAP_SUCCESS) {
  msg_warn(%s: Unable to set tls_cipher_suite to %s: %d: %s,
   myname, dict_ldap-tls_cipher_suite,
  @@ -540,13 +546,21 @@
  return (-1);
  }
  }
  -   if ((rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT,
  +   if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_REQUIRE_CERT,
 (dict_ldap-tls_require_cert))) != LDAP_SUCCESS) {
  msg_warn(%s: Unable to set tls_require_cert to %d: %d: %s,
   myname, dict_ldap-tls_require_cert,
   rc, ldap_err2string(rc));
  return (-1);
  }
  +#ifdef LDAP_OPT_X_TLS_NEWCTX
  +   if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_NEWCTX, am_server))
  +   != LDAP_SUCCESS) {
  +   msg_warn(%s: Unable to allocate new TLS context %d: %s,
  +myname, rc, ldap_err2string(rc));
  +   return (-1);
  +   }
  +#endif
   }
   return (0);
   }
  @@ -592,10 +606,6 @@
   
   #ifdef LDAP_OPT_NETWORK_TIMEOUT
   #ifdef LDAP_API_FEATURE_X_OPENLDAP
  -if (dict_ldap_set_tls_options(dict_ldap) != 0) {
  -   dict_errno = DICT_ERR_RETRY;
  -   return (-1);
  -}
   ldap_initialize((dict_ldap-ld), dict_ldap-server_host);
   #else
   dict_ldap-ld = ldap_init(dict_ldap-server_host,
  @@ -700,6 +710,8 @@
   #endif
   
   #ifdef LDAP_API_FEATURE_X_OPENLDAP
  +if (dict_ldap_set_tls_options(dict_ldap) != 0)
  +   DICT_LDAP_UNBIND_RETURN(dict_ldap-ld, DICT_ERR_RETRY, -1);
   if (dict_ldap-start_tls) {
  if ((saved_alarm = signal(SIGALRM, dict_ldap_timeout)) == SIG_ERR) {
  msg_warn(%s: Error setting signal handler for STARTTLS timeout: 
  %m,

--

Re: Problem with ldap table lookups and TLS

2009-02-27 Thread Quanah Gibson-Mount 
--On Wednesday, February 25, 2009 7:12 PM -0500 Victor Duchovni 
victor.ducho...@morganstanley.com wrote:




Note, the OpenLDAP API design issue is resolved with OpenLDAP 2.4.

With OpenLDAP 2.4 it is possible to set the TLS properties for
a particular LDAP connection (not just global properties), and to
associate a new OpenLDAP managed TLS context for the connection via the
new LDAP_OPT_X_TLS_NEWCTX option.

Try this completely untested patch (it may not even compile, but it
looks promising):



Victor,

If you are unable to test this patch at this time, I can do some testing on 
my systems using OpenLDAP 2.4.15  Postfix 2.5.6.


--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

Re: Problem with ldap table lookups and TLS

2009-02-27 Thread Victor Duchovni 
On Fri, Feb 27, 2009 at 09:35:39AM -0800, Quanah Gibson-Mount wrote:

 --On Wednesday, February 25, 2009 7:12 PM -0500 Victor Duchovni 
 victor.ducho...@morganstanley.com wrote:


 Note, the OpenLDAP API design issue is resolved with OpenLDAP 2.4.

 With OpenLDAP 2.4 it is possible to set the TLS properties for
 a particular LDAP connection (not just global properties), and to
 associate a new OpenLDAP managed TLS context for the connection via the
 new LDAP_OPT_X_TLS_NEWCTX option.

 Try this completely untested patch (it may not even compile, but it
 looks promising):


 Victor,

 If you are unable to test this patch at this time, I can do some testing on 
 my systems using OpenLDAP 2.4.15  Postfix 2.5.6.

That would be great. My ability to test LDAP with TLS is very limited. I
have (only since this morning) access to one LDAP + TLS server. The
patch should support the ability to establish separate SSL verification,
CA list, cipher, ... requirements for different LDAP tables.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
mailto:majord...@postfix.org?body=unsubscribe%20postfix-users

If my response solves your problem, the best way to thank me is to not
send an it worked, thanks follow-up. If you must respond, please put
It worked, thanks in the Subject so I can delete these quickly.

Re: Problem with ldap table lookups and TLS

2009-02-27 Thread Victor Duchovni 
On Fri, Feb 27, 2009 at 09:35:39AM -0800, Quanah Gibson-Mount wrote:

 If you are unable to test this patch at this time, I can do some testing on 
 my systems using OpenLDAP 2.4.15  Postfix 2.5.6.

The patch is working for me, please confirm that it is working for you
also. It is simple enough that the only possible isue is a misreading
of the new OpenLDAP 2.4 API or implementation bugs in OpenLDAP.

The new Postfix code itself is obviously correctly trying set up
connection specific SSL parameters, so the question is only whether
there is some additional subtle steps needed to make this happen.
So far it looks like the changes in the patch are a correct interpretation
of the LDAP API:

- Set TLS parameters for the current LDAP handle, not the NULL
  (global) handle.

- After all the parameters are in place, request a dedicated SSL
  context for the current LDAP handle.

Provided this is the right approach, we are good to go.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
mailto:majord...@postfix.org?body=unsubscribe%20postfix-users

If my response solves your problem, the best way to thank me is to not
send an it worked, thanks follow-up. If you must respond, please put
It worked, thanks in the Subject so I can delete these quickly.

Re: Problem with ldap table lookups and TLS

2009-02-25 Thread Victor Duchovni 
On Wed, Feb 25, 2009 at 03:30:51PM -0600, Nick Geron wrote:

 Well, I have found my problem.  I probably should have mentioned earlier 
 (how many times has than appeared on this list?) that ldap is used on this 
 system for local user authentication, meaning pam/nss are tied into ldap.  
 I noticed in traces that the system configs and certificates were being 
 loaded/read by proxymap and wondered if proxymap was not resetting the 
 value of the ca cert or ca dir as one would expect after it reads in the 
 alias map config.

This is an OpenLDAP API design issue. The OpenLDAP library (at least up
to version 2.3) has a single global SSL_CTX object, that is initialized
just once by the first call that creates an SSL-protected LDAP connection.
All requests to set the global SSL context properties are ignored silently
after that point.

To solve your problem you must make sure that your nsswitch CAfile and
CAfile include all the certificates needed by Postfix.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
mailto:majord...@postfix.org?body=unsubscribe%20postfix-users

If my response solves your problem, the best way to thank me is to not
send an it worked, thanks follow-up. If you must respond, please put
It worked, thanks in the Subject so I can delete these quickly.

Re: Problem with ldap table lookups and TLS

2009-02-25 Thread Nick Geron 

Victor Duchovni wrote:

On Wed, Feb 25, 2009 at 03:30:51PM -0600, Nick Geron wrote:

  
Well, I have found my problem.  I probably should have mentioned earlier 
(how many times has than appeared on this list?) that ldap is used on this 
system for local user authentication, meaning pam/nss are tied into ldap.  
I noticed in traces that the system configs and certificates were being 
loaded/read by proxymap and wondered if proxymap was not resetting the 
value of the ca cert or ca dir as one would expect after it reads in the 
alias map config.



This is an OpenLDAP API design issue. The OpenLDAP library (at least up
to version 2.3) has a single global SSL_CTX object, that is initialized
just once by the first call that creates an SSL-protected LDAP connection.
All requests to set the global SSL context properties are ignored silently
after that point.

To solve your problem you must make sure that your nsswitch CAfile and
CAfile include all the certificates needed by Postfix.

  


Understood.  Thanks again to Victor and Quanah.

-Nick

Re: Problem with ldap table lookups and TLS

2009-02-25 Thread Victor Duchovni 
On Wed, Feb 25, 2009 at 05:34:26PM -0600, Nick Geron wrote:

 This is an OpenLDAP API design issue. The OpenLDAP library (at least up
 to version 2.3) has a single global SSL_CTX object, that is initialized
 just once by the first call that creates an SSL-protected LDAP connection.
 All requests to set the global SSL context properties are ignored silently
 after that point.

 To solve your problem you must make sure that your nsswitch CAfile and
 CAfile include all the certificates needed by Postfix.

 Understood.  Thanks again to Victor and Quanah.

Note, the OpenLDAP API design issue is resolved with OpenLDAP 2.4.

With OpenLDAP 2.4 it is possible to set the TLS properties for
a particular LDAP connection (not just global properties), and to
associate a new OpenLDAP managed TLS context for the connection via the
new LDAP_OPT_X_TLS_NEWCTX option.

Try this completely untested patch (it may not even compile, but it
looks promising):

Index: src/global/dict_ldap.c
--- src/global/dict_ldap.c  28 Jan 2008 04:29:48 -  1.1.1.2
+++ src/global/dict_ldap.c  26 Feb 2009 00:04:18 -
@@ -484,10 +484,16 @@
 {
 const char *myname = dict_ldap_set_tls_options;
 int rc;
+#ifdef LDAP_OPT_X_TLS_NEWCTX
+int am_server = 0;
+LDAP   *ld = dict_ldap-ld;
+#else
+LDAP   *ld = 0;
+#endif
 
 if (dict_ldap-start_tls || dict_ldap-ldap_ssl) {
if (*dict_ldap-tls_random_file) {
-   if ((rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_RANDOM_FILE,
+   if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_RANDOM_FILE,
   dict_ldap-tls_random_file)) != LDAP_SUCCESS) {
msg_warn(%s: Unable to set tls_random_file to %s: %d: %s,
 myname, dict_ldap-tls_random_file,
@@ -496,7 +502,7 @@
}
}
if (*dict_ldap-tls_ca_cert_file) {
-   if ((rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE,
+   if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_CACERTFILE,
  dict_ldap-tls_ca_cert_file)) != LDAP_SUCCESS) {
msg_warn(%s: Unable to set tls_ca_cert_file to %s: %d: %s,
 myname, dict_ldap-tls_ca_cert_file,
@@ -505,7 +511,7 @@
}
}
if (*dict_ldap-tls_ca_cert_dir) {
-   if ((rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTDIR,
+   if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_CACERTDIR,
   dict_ldap-tls_ca_cert_dir)) != LDAP_SUCCESS) {
msg_warn(%s: Unable to set tls_ca_cert_dir to %s: %d: %s,
 myname, dict_ldap-tls_ca_cert_dir,
@@ -514,7 +520,7 @@
}
}
if (*dict_ldap-tls_cert) {
-   if ((rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_CERTFILE,
+   if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_CERTFILE,
  dict_ldap-tls_cert)) != LDAP_SUCCESS) {
msg_warn(%s: Unable to set tls_cert to %s: %d: %s,
 myname, dict_ldap-tls_cert,
@@ -523,7 +529,7 @@
}
}
if (*dict_ldap-tls_key) {
-   if ((rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_KEYFILE,
+   if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_KEYFILE,
  dict_ldap-tls_key)) != LDAP_SUCCESS) {
msg_warn(%s: Unable to set tls_key to %s: %d: %s,
 myname, dict_ldap-tls_key,
@@ -532,7 +538,7 @@
}
}
if (*dict_ldap-tls_cipher_suite) {
-   if ((rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_CIPHER_SUITE,
+   if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_CIPHER_SUITE,
  dict_ldap-tls_cipher_suite)) != LDAP_SUCCESS) {
msg_warn(%s: Unable to set tls_cipher_suite to %s: %d: %s,
 myname, dict_ldap-tls_cipher_suite,
@@ -540,13 +546,21 @@
return (-1);
}
}
-   if ((rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT,
+   if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_REQUIRE_CERT,
   (dict_ldap-tls_require_cert))) != LDAP_SUCCESS) {
msg_warn(%s: Unable to set tls_require_cert to %d: %d: %s,
 myname, dict_ldap-tls_require_cert,
 rc, ldap_err2string(rc));
return (-1);
}
+#ifdef LDAP_OPT_X_TLS_NEWCTX
+   if ((rc = ldap_set_option(ld, LDAP_OPT_X_TLS_NEWCTX, am_server))
+   != LDAP_SUCCESS) {
+   msg_warn(%s: Unable to allocate new TLS context %d: %s,
+myname, rc, ldap_err2string(rc));
+   return (-1);
+   }
+#endif
 }
 return (0);
 }
@@ -592,10 +606,6 @@
 
 #ifdef LDAP_OPT_NETWORK_TIMEOUT
 #ifdef LDAP_API_FEATURE_X_OPENLDAP
-if (dict_ldap_set_tls_options(dict_ldap) != 0) {
-   dict_errno = DICT_ERR_RETRY;
-   return (-1);
-}
 ldap_initialize((dict_ldap-ld),

Problem with ldap table lookups and TLS

2009-02-24 Thread Nick Geron 
I'm in the process of putting together a postfix system with an ldap 
back-end and have come
across something very odd regarding ldap_table.   Basically, postfix 
does not load my private CA.
The CA is really a self signed cert generated by java keytool - try as I 
might, I couldn't get keytool to

use our private CA generated by openssl.

Without a local copy of the 'CA', TLS connections fail with or without 
requiring a cert.  I found a similar thread in
the archive, but the root problem there was related to random number 
generation, GNUTLS and

the key in the log was an exit status 2 from trivial-rewrite.

http://archives.neohapsis.com/archives/postfix/2008-01/0764.html

Now, my tests are similar to this fellow, but I do not get the same exit 
status.  Also, all maps work fine without encryption.


So as root or my limited rights postfix user this works:

#postmap -q j...@example.com ldap:/etc/postfix/ldap/aliases.cf
j...@example.com

However, any lookup actions from the server fails to establish the TLS 
connection.


Feb 24 18:15:27 smtp11 postfix/trivial-rewrite[17631]: dict_ldap_lookup: 
In dict_ldap_lookup
Feb 24 18:15:27 smtp11 postfix/trivial-rewrite[17631]: dict_ldap_lookup: 
No existing connection for LDAP source /etc/postfix/ldap/aliases.cf, 
reopening
Feb 24 18:15:27 smtp11 postfix/trivial-rewrite[17631]: 
dict_ldap_connect: Connecting to server ldap://ldap13.example.com:389
Feb 24 18:15:27 smtp11 postfix/trivial-rewrite[17631]: 
dict_ldap_connect: Actual Protocol version used is 3.
Feb 24 18:15:27 smtp11 postfix/trivial-rewrite[17631]: error: 
dict_ldap_connect: Unable to set STARTTLS: -11: Connect error
Feb 24 18:15:27 smtp11 postfix/trivial-rewrite[17631]: fatal: 
ldap:/etc/postfix/ldap/aliases.cf(0,lock|fold_fix): table lookup problem


I do see that dict_ldap read my config here:
Feb 24 18:22:38 smtp11 postfix/trivial-rewrite[17698]: cfg_get_str: 
/etc/postfix/ldap/aliases.cf: tls_ca_cert_file = /etc/postfix/ssl/ldap13.crt


I've been around and around with this all day and keep coming back to 
the same conclusion - proxymap and/or trivial-rewrite (or whatever is 
responsible for establishing the connection) is not loading my CA file, 
though it's explicitly set in my ldap table conf file:


(/etc/postfix/ldap/aliases.cf)
bind = yes
bind_dn = uid=postfix,ou=ldap,cn=mailsystem
bind_pw = abc123
start_tls = yes
version = 3
tls_ca_cert_file = /etc/postfix/ssl/ldap13.crt
#tls_require_cert = yes
server_host = ldap://ldap13.example.com:389
search_base = ou=domains,cn=mailsystem
query_filter = ((objectClass=CourierMailAlias)(mail=%s))
result_attribute = maildrop
#debuglevel = 1
tls_random_file = /dev/urandom

(in main.cf)
virtual_alias_maps = proxy:ldap:/etc/postfix/ldap/aliases.cf

Running strace for opened files shows that the server loads another 
private ca and cert for smtpd (smtp auth) and even system specified 
certificates it or openssl libs read out of /etc/ldap.conf.  Traces even 
show that something is loading /etc/openldap/ldap.conf, which I've also 
explicitly set a TLS_CAFILE entry for testing with openldap binaries.  I 
should also note that courier authlib and saslauthd both work fine with 
TLS to the same ldap server using the same ca.


As one might expect, tracing the successful postmap command does show 
that it opens and reads the cert specified via tls_ca_cert_file:


#strace -e trace=open postmap -q j...@example.com 
ldap:/etc/postfix/ldap/aliases.cf

...
open(/etc/postfix/ssl/ldap13.crt, O_RDONLY) = 5
...

Again, if I tell postmap to use the proxymap daemon with 'postmap -q 
j...@example.com proxy:ldap:/etc/postfix/ldap/aliases.cf', the same 
failure to load the cert and an error -11 as in the above syslog output.


The test rig is on a recent build of gentoo with postfix 2.5.6 built 
against openssl 0.9.8g.  The LDAP server is running openDS 1.2.


Thanks for any help.  This one's got me baffled.  Please let me know if 
I should provide any additional output.


-Nick Geron

Re: Problem with ldap table lookups and TLS

2009-02-24 Thread Quanah Gibson-Mount 
--On Tuesday, February 24, 2009 6:48 PM -0600 Nick Geron 
nge...@corenap.com wrote:



I'm in the process of putting together a postfix system with an ldap
back-end and have come
across something very odd regarding ldap_table.   Basically, postfix does
not load my private CA.
The CA is really a self signed cert generated by java keytool - try as I
might, I couldn't get keytool to
use our private CA generated by openssl.


It all works for me with OpenLDAP, and openssl generating all the certs. 
Have you tried using ldapsearch to do a startTLS session, using that same 
CA cert?  Are you sure it is a fully formed CA cert?  I usually use a CA 
Cert directory, so any intermediate certs are in the chain along with the 
root cert.


--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

Re: Problem with ldap table lookups and TLS

2009-02-24 Thread Victor Duchovni 
On Tue, Feb 24, 2009 at 06:48:12PM -0600, Nick Geron wrote:

 So as root or my limited rights postfix user this works:

 #postmap -q j...@example.com ldap:/etc/postfix/ldap/aliases.cf
 j...@example.com

You only show a test running as root, not postfix. What versions of
Postfix and OpenLDAP are these? There was TLS API creep in OpenLDAP
between 2.0 and 2.1, and the Postfix LDAP driver was originally based
on OpenLDAP 2.0, this was resolved in Postfix 2.5 as described in
ldap_table(5) under tls_require_cert.

Please show complete output from postmap -q running as the $mail_owner
user, just hide the bind password.

 Feb 24 18:15:27 smtp11 postfix/trivial-rewrite[17631]: dict_ldap_lookup: In 

Is trivial-rewrite in a chroot jail? Please show equivalent dict_ldap
logging (to that from postmap -q) from trivial-rewrite -v on an idle
Postfix system asked to deliver one message to one recipient.

 Feb 24 18:22:38 smtp11 postfix/trivial-rewrite[17698]: cfg_get_str: 
 /etc/postfix/ldap/aliases.cf: tls_ca_cert_file = 
 /etc/postfix/ssl/ldap13.crt

What's in this file? Is it a PEM file? Does your LDAP server expect
client certificates?

 I've been around and around with this all day and keep coming back to the 
 same conclusion - proxymap and/or trivial-rewrite (or whatever is 
 responsible for establishing the connection) is not loading my CA file, 
 though it's explicitly set in my ldap table conf file:

 (/etc/postfix/ldap/aliases.cf)
 start_tls = yes
 tls_ca_cert_file = /etc/postfix/ssl/ldap13.crt
 tls_random_file = /dev/urandom

Shouldn't this be dev:/dev/urandom (better yet, leave this out, it
should default sensibly in OpenSSL). Are you using OpenSSL or GnuTLS to
add TLS support in OpenLDAP?

 Again, if I tell postmap to use the proxymap daemon with 'postmap -q 
 j...@example.com proxy:ldap:/etc/postfix/ldap/aliases.cf', the same failure 
 to load the cert and an error -11 as in the above syslog output.

Is proxymap chrooted?

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
mailto:majord...@postfix.org?body=unsubscribe%20postfix-users

If my response solves your problem, the best way to thank me is to not
send an it worked, thanks follow-up. If you must respond, please put
It worked, thanks in the Subject so I can delete these quickly.