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(a)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(a)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(a)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
>>
>
>