*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(a)gmail.com&gt; 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 > 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 > 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(a)cafedemocracy.org&gt; > 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(a)cafedemocracy.org&gt; >>> 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 >> > >

ldapwhoami -Y PLAIN -H ldap://182.19.136.42 -U testuser produces : ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: No worthy mechs found Tim On Mon, Jan 4, 2016 at 8:42 AM, Dan White <dwhite(a)cafedemocracy.org&gt; wrote:

pluginviewer returned this, as well as several other plugins : List of server plugins follows Plugin "plain" [loaded], API version: 4 SASL mechanism: PLAIN, best SSF: 0, supports setpass: no security flags: NO_ANONYMOUS features: WANT_CLIENT_FIRST|PROXY_AUTHENTICATION Tim On Mon, Jan 4, 2016 at 1:16 PM, Dan White <dwhite(a)cafedemocracy.org&gt; wrote:

On 12/31/15 09:51 -0600, Timothy Keith wrote: On Mon, Jan 4, 2016 at 1:16 PM, Dan White <dwhite(a)cafedemocracy.org&gt; wrote: On 01/04/16 14:47 -0600, Timothy Keith wrote: Something doesn't add up here. The remote server claims to support sasl plain, and your local server claims to support it as well. I suppose your server could be claiming support, but not really supporting it without a security layer, in which case you might investigate doing ssl/starttls. See if you can get a hold of any logs from the server. -- Dan White