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 ?
I defined:ldap_mech: PLAINI 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 :main : num_procs : 5saslauthd :main : mech_option: NULLsaslauthd :main : run_path : /var/run/saslauthdsaslauthd :main : auth_mech : ldapsaslauthd :ipc_init : using accept lock file: /var/run/saslauthd/mux.acceptsaslauthd :detach_tty : master pid is: 0saslauthd :ipc_init : listening on socket: /var/run/saslauthd/muxsaslauthd :main : using process modelsaslauthd :have_baby : forked child: 19272saslauthd :have_baby : forked child: 19273saslauthd :have_baby : forked child: 19274saslauthd :have_baby : forked child: 19275saslauthd :get_accept_lock : acquired accept locksaslauthd :rel_accept_lock : released accept locksaslauthd :get_accept_lock : acquired accept lockldap_sasl_interactive_bind: user selected: PLAINldap_int_sasl_bind: PLAINldap_new_connection 1 1 0ldap_int_open_connectionldap_connect_to_host: TCP 188.8.131.52:389ldap_new_socket: 10ldap_prepare_socket: 10ldap_connect_to_host: Trying 184.108.40.206:389ldap_pvt_connect: fd: 10 tm: 10 async: 0ldap_ndelay_on: 10attempting to connect:connect errno: 115ldap_int_poll: fd: 10 tm: 10ldap_is_sock_ready: 10ldap_ndelay_off: 10ldap_pvt_connect: 0ldap_int_sasl_open: host=220.127.116.11ldap_msgfreeldap_err2stringldap_unbindldap_free_connection 1 1ldap_send_unbindldap_free_connection: actually freedldap_createldap_url_parse_ext(ldap:// 18.104.22.168:389)ldap_sasl_interactive_bind: user selected: PLAINldap_int_sasl_bind: PLAINldap_new_connection 1 1 0ldap_int_open_connectionldap_connect_to_host: TCP 22.214.171.124:389ldap_new_socket: 10ldap_prepare_socket: 10ldap_connect_to_host: Trying 126.96.36.199:389ldap_pvt_connect: fd: 10 tm: 10 async: 0ldap_ndelay_on: 10attempting to connect:connect errno: 115ldap_int_poll: fd: 10 tm: 10ldap_is_sock_ready: 10ldap_ndelay_off: 10ldap_pvt_connect: 0ldap_int_sasl_open: host=188.8.131.52ldap_msgfreeldap_err2stringsaslauthd :do_auth : auth failure: [user=testuser] [service=slapd] [realm=] [mech=ldap] [reason=Unknown]saslauthd :do_request : response: NOTimOn Thu, Dec 31, 2015 at 10:29 AM, Dan White <email@example.com> 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
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 <firstname.lastname@example.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)
Is DIGEST-MD5 available on your ldap server? Try:
ldapsearch -LLL -x -H ldap://184.108.40.206 -s "base" -b ""
Which should list the advertised sasl mechanisms.
Verify the digest-md5 mechanism is installed with
Dan, that ldapsearch returns :
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.