> attempting to connect:
> connect errno: 115

EINPROGRESS

The socket is nonblocking and the connection cannot be completed immediately. It is possible to select(2) or poll(2) for completion by selecting the socket for writing. After select(2) indicates writability, use getsockopt(2) to read the SO_ERROR option at level SOL_SOCKET to determine whether connect() completed successfully (SO_ERROR is zero) or unsuccessfully (SO_ERROR is one of the usual error codes listed here, explaining the reason for the failure).


What might be producing the EINPROGRESS ?


On Thu, Dec 31, 2015 at 11:13 AM, Timothy Keith <timothy.g.keith@gmail.com> wrote:
I defined:
     ldap_mech: PLAIN

I am new at LDAP , that is obvious I guess.  But, I've been around Unix for 30 years.

This is the latest output from saslauthd in debug mode :

saslauthd[19271] :main            : num_procs  : 5
saslauthd[19271] :main            : mech_option: NULL
saslauthd[19271] :main            : run_path   : /var/run/saslauthd
saslauthd[19271] :main            : auth_mech  : ldap
saslauthd[19271] :ipc_init        : using accept lock file: /var/run/saslauthd/mux.accept
saslauthd[19271] :detach_tty      : master pid is: 0
saslauthd[19271] :ipc_init        : listening on socket: /var/run/saslauthd/mux
saslauthd[19271] :main            : using process model
saslauthd[19271] :have_baby       : forked child: 19272
saslauthd[19271] :have_baby       : forked child: 19273
saslauthd[19271] :have_baby       : forked child: 19274
saslauthd[19271] :have_baby       : forked child: 19275
saslauthd[19271] :get_accept_lock : acquired accept lock
saslauthd[19271] :rel_accept_lock : released accept lock
saslauthd[19272] :get_accept_lock : acquired accept lock
ldap_sasl_interactive_bind: user selected: PLAIN
ldap_int_sasl_bind: PLAIN
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP  182.19.136.42:389
ldap_new_socket: 10
ldap_prepare_socket: 10
ldap_connect_to_host: Trying  182.19.136.42:389
ldap_pvt_connect: fd: 10 tm: 10 async: 0
ldap_ndelay_on: 10
attempting to connect:
connect errno: 115
ldap_int_poll: fd: 10 tm: 10
ldap_is_sock_ready: 10
ldap_ndelay_off: 10
ldap_pvt_connect: 0
ldap_int_sasl_open: host=182.19.136.42
ldap_msgfree
ldap_err2string
ldap_unbind
ldap_free_connection 1 1
ldap_send_unbind
ldap_free_connection: actually freed
ldap_create
ldap_url_parse_ext(ldap:// 182.19.136.42:389)
ldap_sasl_interactive_bind: user selected: PLAIN
ldap_int_sasl_bind: PLAIN
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP  182.19.136.42:389
ldap_new_socket: 10
ldap_prepare_socket: 10
ldap_connect_to_host: Trying  182.19.136.42:389
ldap_pvt_connect: fd: 10 tm: 10 async: 0
ldap_ndelay_on: 10
attempting to connect:
connect errno: 115
ldap_int_poll: fd: 10 tm: 10
ldap_is_sock_ready: 10
ldap_ndelay_off: 10
ldap_pvt_connect: 0
ldap_int_sasl_open: host=182.19.136.42
ldap_msgfree
ldap_err2string
saslauthd[19271] :do_auth         : auth failure: [user=testuser] [service=slapd] [realm=] [mech=ldap] [reason=Unknown]
saslauthd[19271] :do_request      : response: NO


Tim


On Thu, Dec 31, 2015 at 10:29 AM, Dan White <dwhite@cafedemocracy.org> wrote:
On 12/17/15 18:32 -0600, Timothy Keith wrote:
We are attempting to set up an LDAP server which will answer queries
from an application. The database will contain metadata on a set of
users in the application. The application will also query the server
to authenticate the user’s password, however, this server will not
house the password. That resides on another server, which our server
will query.   We do not have administrative rights to the other
server.

The difficulty we are having now is setting up the pass-through
authentication for the passwords. Any pointers in how to proceed with
this would be greatly appreciated.

 On 12/21/15 17:24 -0600, Timothy Keith wrote:
We have limited access to the servers.  Same company, different IT
organization.   Our LDAP requirement must be transparent to those servers.
We want to inherit the LDAP directory information from the Unix servers -
mostly the user Id and passwords, and add information that is needed  by
applications that our servers will manage.

 On 12/31/15 09:51 -0600, Timothy Keith wrote:
On Wed, Dec 30, 2015 at 7:04 PM, Dan White <dwhite@cafedemocracy.org> wrote:
On 12/30/15 18:51 -0600, Timothy Keith wrote:

This is tail of the latest saslauthd debug  output :

ldap_sasl_interactive_bind: user selected: DIGEST-MD5


 res_errno: 7, res_error: <SASL(-4): no mechanism available: >, res_matched:
<>
ldap_free_request (origid 1, msgid 1)
ldap_int_sasl_bind: DIGEST-MD5
ldap_parse_sasl_bind_result
ldap_parse_result
ldap_msgfree
ldap_err2string


 Is DIGEST-MD5 available on your ldap server? Try:

ldapsearch -LLL -x -H ldap://1.2.3.4 -s "base" -b ""
supportedSASLMechanisms
Which should list the advertised sasl mechanisms.

Verify the digest-md5 mechanism is installed with
saslpluginviewer/pluginviewer.

Dan, that ldapsearch returns :
dn:
supportedSASLMechanisms: PLAIN

The server is only offering the PLAIN mechanism to you. It appears you're
using saslauthd's ldap backend, and have explicitly configured 'ldap_mech:
digest-md5' in your corresponding config. If that's correct, you could
change that to PLAIN instead.

Consider protecting the bind with tls if available.

slapo-pbind may be a simpler alternative (to pass-through sasl
authentication), depending on the specifics of your setup.

--
Dan White