From 11435b1060675339263ce0a2a546cc44ab9bd576 Mon Sep 17 00:00:00 2001
From: Sumit Bose <sbose@redhat.com>
Date: May 19 2020 09:06:23 +0000
Subject: krb5: do not cache ccache or password during preauth


The PAM preauth step is mainly used to determine which authentication
methods (single factor, two factor, Smartcard) are available for the
user. It does not make sense to try to store the password hash or the
credential cache at this step because this information is not available
or not accurate at this step.

It might even cause issue is the credential cache name contains a random
component. This is typically used for file based credential caches
stored in the /tmp directory to avoid attacks to pre-create the file
since the name is known. Since the credential cache name still contains
the template for the random component 'XXXXXX' updating the credential
cache name in the cache during preauth destroys the information about
the currently used credential cache and upcoming authentications will
create a new one.

This causes issues with screen-savers or screen-lock where every
unlocking creates a new credential cache file and not updates the
existing one as it is expected. Another case is if a user logs in
multiple times to the same host, e.g. with ssh. Here it is expected as
well that the first session will create a new credential cache file
while all additional sessions will reuse it and only update the TGT in
the existing credential.

Resolves: https://github.com/SSSD/sssd/issues/5160

Reviewed-by: Alexey Tikhonov <atikhonov@redhat.com>

---

diff --git a/src/providers/krb5/krb5_auth.c b/src/providers/krb5/krb5_auth.c
index 903db6c..a1c0b36 100644
--- a/src/providers/krb5/krb5_auth.c
+++ b/src/providers/krb5/krb5_auth.c
@@ -1087,6 +1087,13 @@ static void krb5_auth_done(struct tevent_req *subreq)
                               kr->srv, PORT_WORKING);
     }
 
+    if (pd->cmd == SSS_PAM_PREAUTH) {
+        state->pam_status = PAM_SUCCESS;
+        state->dp_err = DP_ERR_OK;
+        ret = EOK;
+        goto done;
+    }
+
     /* Now only a successful authentication or password change is left.
      *
      * We expect that one of the messages in the received buffer contains