I'm using sssd 1.11.7 in a jail on freebsd 10.2. and seeing an odd failure. sssd is configured for nss, and pam both against an openldap server. Nss seems to work as evidenced by various getent calls.
When I ssh to the jail as an ldap user the authentication fails with return code 9:
(Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_print_data] (0x0100): domain: default (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_print_data] (0x0100): user: myuser (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_print_data] (0x0100): tty: not set (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_print_data] (0x0100): rhost: host.edu (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 65873 (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_dp_process_reply] (0x0100): received: [9][default] (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [9]. (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_reply] (0x0200): blen: 24 (Thu Aug 25 10:55:52 2016) [sssd[pam]] [client_recv] (0x0200): Client disconnected!
When I login to the jail as an un-privleged user and su to the ldap user authentication succeeds:
(Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_print_data] (0x0100): domain: not set (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_print_data] (0x0100): user: myser (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_print_data] (0x0100): service: su (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_print_data] (0x0100): tty: /dev/pts/1 (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_print_data] (0x0100): ruser: anotheruser (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_print_data] (0x0100): rhost: not set (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_print_data] (0x0100): priv: 0 (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 67944 (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [myuser@default] (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_print_data] (0x0100): domain: default (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_print_data] (0x0100): user: myuser (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_print_data] (0x0100): service: su (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_print_data] (0x0100): tty: /dev/pts/1 (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_print_data] (0x0100): ruser: anotheruser (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_print_data] (0x0100): rhost: not set (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_print_data] (0x0100): priv: 0 (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 67944 (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_dp_process_reply] (0x0100): received: [0][default] (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]. (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_reply] (0x0200): blen: 24 (Thu Aug 25 11:00:24 2016) [sssd[pam]] [pam_cmd_setcred] (0x0100): entering pam_cmd_setcred
Even weirder is the fact that having once used su to authenticate the ldap user, subsequent attempts to ssh as the ldap user succeed!
(Thu Aug 25 11:31:03 2016) [sssd[pam]] [sss_cmd_get_version] (0x0200): Received client version [3]. (Thu Aug 25 11:31:03 2016) [sssd[pam]] [sss_cmd_get_version] (0x0200): Offered version [3]. (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_cmd_authenticate] (0x0100): entering pam_cmd_authenticate (Thu Aug 25 11:31:03 2016) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'myuser' matched without domain, user is myuser (Thu Aug 25 11:31:03 2016) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_print_data] (0x0100): domain: not set (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_print_data] (0x0100): user: myuser (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_print_data] (0x0100): tty: not set (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_print_data] (0x0100): rhost: host.edu (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 78882 (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [myuser@default] (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_print_data] (0x0100): domain: default (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_print_data] (0x0100): user: myuser (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_print_data] (0x0100): tty: not set (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_print_data] (0x0100): rhost: host.edu (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 78882 (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_dp_process_reply] (0x0100): received: [0][default] (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]. (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_reply] (0x0200): blen: 24 (Thu Aug 25 11:31:03 2016) [sssd[pam]] [client_recv] (0x0200): Client disconnected! (Thu Aug 25 11:31:03 2016) [sssd[pam]] [sss_cmd_get_version] (0x0200): Received client version [3]. (Thu Aug 25 11:31:03 2016) [sssd[pam]] [sss_cmd_get_version] (0x0200): Offered version [3]. (Thu Aug 25 11:31:03 2016) [sssd[pam]] [pam_cmd_setcred] (0x0100): entering pam_cmd_setcred (Thu Aug 25 11:31:03 2016) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'myuser' matched without domain, user is myuser (Thu Aug 25 11:31:03 2016) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)]
Suggestions for next steps are welcome. Thanks
On (25/08/16 16:35), rpoyner@wisc.edu wrote:
I'm using sssd 1.11.7 in a jail on freebsd 10.2. and seeing an odd failure. sssd is configured for nss, and pam both against an openldap server. Nss seems to work as evidenced by various getent calls.
When I ssh to the jail as an ldap user the authentication fails with return code 9:
(Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_print_data] (0x0100): domain: default (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_print_data] (0x0100): user: myuser (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_print_data] (0x0100): tty: not set (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_print_data] (0x0100): rhost: host.edu (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 65873 (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_dp_process_reply] (0x0100): received: [9][default] (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [9]. (Thu Aug 25 10:55:52 2016) [sssd[pam]] [pam_reply] (0x0200): blen: 24 (Thu Aug 25 10:55:52 2016) [sssd[pam]] [client_recv] (0x0200): Client disconnected!
pam error code 9 is PAM_AUTH_ERROR. Which does not say a lot.
Could you provide a ssds log file from domain (and not just from pam responder) Please use full debug level "0xfff0" in domain section of sssd.conf
LS
Lukas,
Below is a log excerpt from a failed authentication. It looks like sssd tries to bind to the ldap server with the given username, which fails. I'll ask my ldap admin, but I think the openldap server is set up to transfer shadow data over tls without the need for a username/password to bind. I thought the bind user/password was an AD thing. I'm sure I never needed a bind user when authenticating to this server with nslcd.
Thanks again.
START TLS result: Success(0), (null) (Thu Aug 25 12:44:05 2016) [sssd[be[default]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'ldap.edu' as 'working' (Thu Aug 25 12:44:05 2016) [sssd[be[default]]] [set_server_common_status] (0x0100): Marking server 'ldap.edu' as 'working' (Thu Aug 25 12:44:05 2016) [sssd[be[default]]] [fo_set_port_status] (0x0400): Marking port 389 of duplicate server 'ldap.edu' as 'working' (Thu Aug 25 12:44:05 2016) [sssd[be[default]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x806606f20
(Thu Aug 25 12:44:05 2016) [sssd[be[default]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x806606fe0
(Thu Aug 25 12:44:05 2016) [sssd[be[default]]] [ldb] (0x4000): Running timer event 0x806606f20 "ltdb_callback"
(Thu Aug 25 12:44:05 2016) [sssd[be[default]]] [ldb] (0x4000): Destroying timer event 0x806606fe0 "ltdb_timeout"
(Thu Aug 25 12:44:05 2016) [sssd[be[default]]] [ldb] (0x4000): Ending timer event 0x806606f20 "ltdb_callback"
(Thu Aug 25 12:44:05 2016) [sssd[be[default]]] [find_password_expiration_attributes] (0x4000): No password policy requested. (Thu Aug 25 12:44:05 2016) [sssd[be[default]]] [simple_bind_send] (0x0100): Executing simple bind as: uid=myuser,ou=People,o=ENGR (Thu Aug 25 12:44:05 2016) [sssd[be[default]]] [simple_bind_send] (0x2000): ldap simple bind sent, msgid = 2 (Thu Aug 25 12:44:05 2016) [sssd[be[default]]] [sdap_process_result] (0x2000): Trace: sh[0x806613740], connected[1], ops[0x8066064a0], ldap[0x806417940] (Thu Aug 25 12:44:05 2016) [sssd[be[default]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Thu Aug 25 12:44:05 2016) [sssd[be[default]]] [sdap_process_result] (0x2000): Trace: sh[0x806613740], connected[1], ops[0x8066064a0], ldap[0x806417940] (Thu Aug 25 12:44:05 2016) [sssd[be[default]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_BIND] (Thu Aug 25 12:44:05 2016) [sssd[be[default]]] [simple_bind_done] (0x1000): Server returned no controls. (Thu Aug 25 12:44:05 2016) [sssd[be[default]]] [simple_bind_done] (0x0400): Bind result: Invalid credentials(49), no errmsg set (Thu Aug 25 12:44:05 2016) [sssd[be[default]]] [sdap_handle_release] (0x2000): Trace: sh[0x806613740], connected[1], ops[0x0], ldap[0x806417940], destructor_lock[0], release_memory[0] (Thu Aug 25 12:44:05 2016) [sssd[be[default]]] [remove_connection_callback] (0x4000): Successfully removed connection callback. (Thu Aug 25 12:44:05 2016) [sssd[be[default]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 9, <NULL>) [Success] (Thu Aug 25 12:44:05 2016) [sssd[be[default]]] [be_pam_handler_callback] (0x0100): Sending result [9][default] (Thu Aug 25 12:44:05 2016) [sssd[be[default]]] [be_pam_handler_callback] (0x0100): Sent result [9][default]
On (25/08/16 18:09), rpoyner@wisc.edu wrote:
Lukas,
Below is a log excerpt from a failed authentication. It looks like sssd tries to bind to the ldap server with the given username, which fails. I'll ask my ldap admin, but I think the openldap server is set up to transfer shadow data over tls without the need for a username/password to bind. I thought the bind user/password was an AD thing. I'm sure I never needed a bind user when authenticating to this server with nslcd.
I briefly looked into nss-pam-ldapd source code but I could not see exported function _nss_ldap_getspnam_r for freebsd. nss plugin from nslcd doesn't export shadow entries.
So are you sure that nslcd does not use simple bind for authenticaton? Is it possible that you used wrong password?
LS
On Thu, Aug 25, 2016 at 06:09:59PM -0000, rpoyner@wisc.edu wrote:
Lukas,
Below is a log excerpt from a failed authentication. It looks like sssd tries to bind to the ldap server with the given username, which fails. I'll ask my ldap admin, but I think the openldap server is set up to transfer shadow data over tls without the need for a username/password to bind. I thought the bind user/password was an AD thing. I'm sure I never needed a bind user when authenticating to this server with nslcd.
No, this is how an LDAP authentication works. We ask the user to try to read their own entry (in your case uid=myuser,ou=People,o=ENGR) binding as itself (again, uid=myuser,ou=People,o=ENGR) authenticating with their password.
Does an equivalent of the following work: ldapsearch -H ldap.edu -b uid=myuser,ou=People,o=ENGR -s base -W ?
This error: (Thu Aug 25 12:44:05 2016) [sssd[be[default]]] [simple_bind_done] (0x0400): Bind result: Invalid credentials(49), no errmsg set normally really means wrong password.
about ssh not working and su working - I really have no idea about BSD, but on Linux there is a PAM module pam_rootok.so that permits the authentication as long as it's requested by root, so maybe BSD has something similar?
Jakub,
ldapsearch fails if I type the correct password for myuser. If I just hit return at the password prompt the search succeeds.
Is it possible to tell sssd to use a blank password?
RP.
ldapsearch with myuser as the binddn and the correct password works.
ldapsearch -H ldaps://unixauth2.cae.wisc.edu -b uid=myuser,ou=People,o=ENGR -s base -D uid=myuser,ou=People,o=ENGR -W
If I give the correct password for myuser the search works. If I hit enter at the password prompt it fails. So it would appear that ldap searches work as expected.
On (26/08/16 14:39), rpoyner@wisc.edu wrote:
ldapsearch with myuser as the binddn and the correct password works.
ldapsearch -H ldaps://unixauth2.cae.wisc.edu -b uid=myuser,ou=People,o=ENGR -s base -D uid=myuser,ou=People,o=ENGR -W
If I give the correct password for myuser the search works. If I hit enter at the password prompt it fails. So it would appear that ldap searches work as expected.
IIUC, it works with -w 'your_secret_password' But It does not work with interactive prompting e.g. -W
That sounds weird and sounds like a bug in libldap which is used by sssd.
LS
On Fri, Aug 26, 2016 at 05:06:08PM +0200, Lukas Slebodnik wrote:
On (26/08/16 14:39), rpoyner@wisc.edu wrote:
ldapsearch with myuser as the binddn and the correct password works.
ldapsearch -H ldaps://unixauth2.cae.wisc.edu -b uid=myuser,ou=People,o=ENGR -s base -D uid=myuser,ou=People,o=ENGR -W
If I give the correct password for myuser the search works. If I hit enter at the password prompt it fails. So it would appear that ldap searches work as expected.
IIUC, it works with -w 'your_secret_password' But It does not work with interactive prompting e.g. -W
That sounds weird and sounds like a bug in libldap which is used by sssd.
I'm not sure, I would have guessed someone would have found a bug like this a long time ago..
I'm not really sure how to debug this further, we test this case all the time and I've never seen any case where password-based authentication via LDAP doesn't work for anyone.
I wonder if the PAM configuration could be sending a wrong password down the stack?
Maybe the server logs would reveal something or maybe you can dissect the traffic with wireshark to see if the password is the one you'd expect or you can gdb sssd_be and peek at the authtok value..
On Mon, Aug 29, 2016 at 03:51:29PM +0200, Jakub Hrozek wrote:
On Fri, Aug 26, 2016 at 05:06:08PM +0200, Lukas Slebodnik wrote:
On (26/08/16 14:39), rpoyner@wisc.edu wrote:
ldapsearch with myuser as the binddn and the correct password works.
ldapsearch -H ldaps://unixauth2.cae.wisc.edu -b uid=myuser,ou=People,o=ENGR -s base -D uid=myuser,ou=People,o=ENGR -W
Can you try with
ldapsearch -ZZ -H ldap://unixauth2.cae.wisc.edu -b uid=myuser,ou=People,o=ENGR -s base -D uid=myuser,ou=People,o=ENGR -W
i.e. use StartTLS on port 389 to create the TLS tunnel instead of using the ldaps port 636. Maybe the server is configured to reject authentication on port 389?
bye, Sumit
If I give the correct password for myuser the search works. If I hit enter at the password prompt it fails. So it would appear that ldap searches work as expected.
IIUC, it works with -w 'your_secret_password' But It does not work with interactive prompting e.g. -W
That sounds weird and sounds like a bug in libldap which is used by sssd.
I'm not sure, I would have guessed someone would have found a bug like this a long time ago..
I'm not really sure how to debug this further, we test this case all the time and I've never seen any case where password-based authentication via LDAP doesn't work for anyone.
I wonder if the PAM configuration could be sending a wrong password down the stack?
Maybe the server logs would reveal something or maybe you can dissect the traffic with wireshark to see if the password is the one you'd expect or you can gdb sssd_be and peek at the authtok value.. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
Lukas Slebodnik -
rpoyner＠wisc.edu -
Sumit Bose