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.
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
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
On 12/31/15 11:13 -0600, Timothy Keith 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
On 12/31/15 11:43 -0600, Timothy Keith wrote:
attempting to connect: connect errno: 115
*EINPROGRESS*
That doesn't appear to be a critical piece of the problem. Notice libldap is polling and reporting the socket as ready.
Trouble shoot this as a basic authentication problem between your unix server and the ldap server. I.e., attempt to reproduce a sasl plain authentication using ldapwhoami:
ldapwhoami -Y PLAIN -H ldap://182.19.136.42 -U testuser
Adjust to match your saslauthd ldap config.
Assuming your connection is unencrypted, which is appears to be, performing a tcpdump/wireshark trace will help.
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@cafedemocracy.org wrote:
On 12/31/15 11:13 -0600, Timothy Keith 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
On 12/31/15 11:43 -0600, Timothy Keith wrote:
attempting to connect:
connect errno: 115
*EINPROGRESS*
That doesn't appear to be a critical piece of the problem. Notice libldap is polling and reporting the socket as ready.
Trouble shoot this as a basic authentication problem between your unix server and the ldap server. I.e., attempt to reproduce a sasl plain authentication using ldapwhoami:
ldapwhoami -Y PLAIN -H ldap://182.19.136.42 -U testuser
Adjust to match your saslauthd ldap config.
Assuming your connection is unencrypted, which is appears to be, performing a tcpdump/wireshark trace will help.
-- Dan White
On 01/04/16 09:41 -0600, Timothy Keith wrote:
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
Verify you have the sasl plain mechanism available on your local system with saslpluginviewer/pluginviewer. On some systems it is contained in a separate package from the libsasl2 glue library, e.g. libsasl2-modules.
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@cafedemocracy.org wrote:
On 01/04/16 09:41 -0600, Timothy Keith wrote:
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
Verify you have the sasl plain mechanism available on your local system with saslpluginviewer/pluginviewer. On some systems it is contained in a separate package from the libsasl2 glue library, e.g. libsasl2-modules.
-- Dan White
--On Monday, January 04, 2016 2:47 PM -0600 Timothy Keith timothy.g.keith@gmail.com 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
So you don't have the GSSAPI mech available. As noted, if you're using a distribution provided build of cyrus-sasl, you may have to specifically install additional mechanisms, such as GSSAPI.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On Wed, Dec 30, 2015 at 7:04 PM, Dan White dwhite@cafedemocracy.org wrote:
Is DIGEST-MD5 available on your ldap server? Try:
ldapsearch -LLL -x -H ldap://1.2.3.4 -s "base" -b "" supportedSASLMechanisms
On 12/31/15 09:51 -0600, Timothy Keith wrote:
Dan, that ldapsearch returns : dn: supportedSASLMechanisms: PLAIN
On Mon, Jan 4, 2016 at 1:16 PM, Dan White dwhite@cafedemocracy.org wrote:
On 01/04/16 09:41 -0600, Timothy Keith wrote:
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
On 01/04/16 14:47 -0600, Timothy Keith 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
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.
openldap-technical@openldap.org
-
Dan White -
Quanah Gibson-Mount -
Timothy Keith