Depending on the available Kerberos pre-authentication methods pam_sss
will prompt the user for a password, 2 authentication factors or both.

Resolves https://fedorahosted.org/sssd/ticket/2988

Reviewed-by: Nathaniel McCallum <npmccallum@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>

If an IPA client uses the SSH integration and a local user logs in with
SSH, the sss_ssh_authorizedkeys looks up their keys in the SSH
responder, which doesn't find the user and returns ENOENT. The
sss_ssh_authorizedkeys reports a failure on any error, including ENOENT
which produced a confusing error message in the logs.

This patch adds a new error code that handles users that are not found
by SSSD but exist on the system and also special cases root with the
same error code. Therefore, logging in as a local user no longer prints
an error message.

Resolves:
https://fedorahosted.org/sssd/ticket/3003

Reviewed-by: Pavel Březina <pbrezina@redhat.com>

Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>

Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>

With this option SSSD can be used with the gdm Smartcard feature.

Resolves:
https://fedorahosted.org/sssd/ticket/2941

Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>

Resolves: https://fedorahosted.org/sssd/ticket/3028

Reviewed-by: Alexander Bokovoy <abokovoy@redhat.com>

There are different expectations about how the pam_message array is
organized, details can be found in the pam_conv man page. E.g. sudo was
not able to handle the Linux-PAM style but expected the Solaris PAM
style. With this patch both styles should work as expected.

Resolves https://fedorahosted.org/sssd/ticket/2971

Reviewed-by: Pavel Březina <pbrezina@redhat.com>

We have a function sss_cli_check_socket which checks
socket in client code. The socket is reopened in case of some
issues e.g. responder terminated connections ...

We use syscall poll for checking status of socket.
It's not 100% reliable method because there is still
chance that responder will terminate socket after this check.

Here is a schema of sss_*_make_request functions:
    sss_cli_check_socket
    sss_cli_make_request_nochecks {
       sss_cli_send_req {
           poll
           send
       }
       sss_cli_recv_rep {
           poll
           read
       }
    }

The syscall pool does not return EPIPE directly but we convert
special revents from poll to EPIPE. As it was mentioned earlier,
checking of socket in the sss_cli_check_socket is not 100% reliable.
It can happen very rarely due to TOCTOU issue (Time of check to time of use)

We can return EPIPE from the sss_cli_make_request_nochecks function
in case of failure in poll in sss_cli_send_req. The send function
in sss_cli_send_req can also return EPIPE is responder close socket
in the same time. The send function can succeed in sss_cli_send_req
but it does not mean that responder read the message. It can happen
that timer for closing socket can be handled before reading a message.
Therefore there is a still a chance that we might return EPIPE in case
of failure in poll in sss_cli_recv_rep.

Therefore we need to reconnect to responder(sss_cli_check_socket)
in case of EPIPE returned from sss_cli_make_request_nochecks and
try to do the same request one more time.

Resolves:
https://fedorahosted.org/sssd/ticket/2626

Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>

Patch for #2626 will be simpler with this small refactoring

Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>

Resolves:
https://fedorahosted.org/sssd/ticket/2909

Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
Reviewed-by: Noam Meltzer <tsnoam@gmail.com>