sssd-ad uses wrong key to verify tgt at login time

[Jurjen Bokma]

I try to log in using sssd with AD authentication. It fails.
When I remove the first key from the keytab, logging in succeeds.
Restoring the previous keytab brings the failure back.

Hence, I believe the closing of https://fedorahosted.org/sssd/ticket/1871#comment:2 to be wrong.
(But I use Trusty, with sssd-*-1.11.3-1, so I'm not sure whether to report here or at Fedora.)

Additional circumstantial evidence:
The offending first key in the keytab belongs to a principal - let's call it 'ADJoiner' - used solely for the purpose of joining the machine to the AD domain (which was done using msktutil). The AD admins here say they deliberately reduced the access rights of ADJoiner. So from Linux perspective, this principal behaves a bit oddly:
I can kgetcred a ticket for many principals in the same realm, but I cannot kgetcred a ticket for ADJoiner. I *can* kinit ADJoiner though.

I believe the cause of the problem to be in src/providers/krb5/krb5_child.c in the loop immediately following the comment:
/* We look for the first entry from our realm or take the last one */
Indeed, if I make that loop skip the first key found (diff below), everything works as expected, whether the ADJoiner key is in the keytab or not.

This is an ad-hoc fix for my case of course. I think *all* keys from the keytab should be tried. But sssd obviously intends not to.

*** src/providers/krb5/krb5_child.c.old 2014-01-30 15:48:15.197154787 +0100
--- src/providers/krb5/krb5_child.c 2014-01-30 15:26:02.729103935 +0100
***************
*** 703,706 ****
--- 703,707 ----
      krb5_ccache validation_ccache = NULL;
      krb5_authdata **pac_authdata = NULL;
+ int skip = 0;

      memset(&keytab, 0, sizeof(keytab));
***************
*** 741,750 ****

          if (krb5_realm_compare(kr->ctx, validation_princ, kr->creds->client)) {
! {
              DEBUG(SSSDBG_TRACE_INTERNAL,
                    ("Found keytab entry with the realm of the credential.\n"));
              realm_entry_found = true;
              break;
! }
      }

--- 742,757 ----

          if (krb5_realm_compare(kr->ctx, validation_princ, kr->creds->client)) {
! if (skip == 0)
! {
! skip++;
! }
! else
! {
              DEBUG(SSSDBG_TRACE_INTERNAL,
                    ("Found keytab entry with the realm of the credential.\n"));
              realm_entry_found = true;
              break;
! }
! }
      }

[Jurjen Bokma (j-bokma-t)]

Additional information:
The account ADJoiner is an ordinary user in that it has no servicePrincipalName, whereas hosts do have one. I believe this is a crucial difference, because I can get a ticket for anything that has a servicePrincipalName, but not for anything that doesn't.

And indeed, when the first key in the keytab is for another principal that has no servicePrincipalName, the error also occurs.

[Jakub Hrozek (jakub-hrozek)]

Hi,

Can you bring this issue up on the sssd-devel list so it can be discussed with other developers as well? Or open an upstream ticket.

I don't like the idea of trying all principals in the keytab, simply because it would be uneffective, but I would personally be fine with using the same code that we use for selecting the 'right' principal which is either what the admin sets manually as ldap_sasl_authid, or, the default AD case which is shortname$@realm.