sssd-ad uses wrong key to verify tgt at login time
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
sssd (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
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:/
(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/
/* 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/
--- src/providers/
***************
*** 703,706 ****
--- 703,707 ----
krb5_ccache validation_ccache = NULL;
krb5_authdata **pac_authdata = NULL;
+ int skip = 0;
memset(
***************
*** 741,750 ****
if (krb5_realm_
! {
! }
}
--- 742,757 ----
if (krb5_realm_
! if (skip == 0)
! {
! skip++;
! }
! else
! {
! }
! }
}
tags: | added: trusty |
Additional information: lName, whereas hosts do have one. I believe this is a crucial difference, because I can get a ticket for anything that has a servicePrincipa lName, but not for anything that doesn't.
The account ADJoiner is an ordinary user in that it has no servicePrincipa
And indeed, when the first key in the keytab is for another principal that has no servicePrincipa lName, the error also occurs.