On 08/09/2016 03:42 PM, Thomas Beaudry wrote:
(Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_dp_send_req] (0x0100):
Sending request with the following data:
(Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_print_data] (0x0100): command:
SSS_PAM_AUTHENTICATE
(Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_print_data] (0x0100): domain: concordia.ca
(Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_print_data] (0x0100): user: tbeaudry
(Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_print_data] (0x0100): service: su
(Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_print_data] (0x0100): tty: /dev/pts/1
(Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_print_data] (0x0100): ruser: tmtg
(Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_print_data] (0x0100): rhost: not set
(Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1
(Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0
(Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_print_data] (0x0100): priv: 0
(Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 6032
(Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_print_data] (0x0100): logon name: tbeaudry
(Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req
returned 0
(Tue Aug 9 15:39:32 2016) [sssd[pam]] [sss_dp_req_destructor] (0x0400): Deleting
request: [0x410090:3:tbeaudry@concordia.ca]
(Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [6
(Permission denied)][concordia.ca]
(Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result
[6]: Permission denied.
(Tue Aug 9 15:39:32 2016) [sssd[pam]] [pam_reply] (0x0200): blen: 83
(Tue Aug 9 15:39:33 2016) [sssd[pam]] [client_recv] (0x0200): Client disconnected!
Any thoughts? I am going over the troubleshooting wiki now for a 3rd time.
Thomas, this response indicates that SSSD did try to contact the authentication
provider and received a response that explicitly said "this user is not
permitted". Usually that means the wrong password (or sometimes expired
password, if they are beyond the grace period).
Please add "debug_level = 7" to the [domain/concordia.ca] section of sssd.conf,
restart and then try to log in as that user again. This time, send us
/var/log/sssd/sssd_concordia.ca.log and /var/log/sssd/krb5_child.log which
should show us the exact reason why the user is denied.