validate_tgt fails to validate trusted domain when the last entry is cannot be used

[luizluca]

I have a machine with two configured AD domains (example.com and subdomain.example.com) but only joined to one domain (example.com). Both domains trust each other but they do not belong to the same forest.

When I'm using sssd-ad, krb5_validate became true by default. However, when I'm doing a cross-domain check, it can fail to get the correct keytab entry. I'm facing an adcli issue where it adds invalid entries as mymachine.subdomain.example.com even when I'm not joined to that domain nor my hostname(5) uses it (although my machine is trusted there). However, I think it can also happen if I had a third not-trusted domain. I just need to add anything to keytab that cannot validate a TGT. The "last keytab entry" is not a flexible solution.

It would be good to have a way to specify which realm should be used to validate a TGT for a specific domain (as I can set ldap_sasl_realm) instead of simply relying on the last entry. Maybe "krb5_validate_realm"?

As a workaround, I can disable adcli for the domain I'm not joined or disable krb5_validate.

# sssd --version
2.3.1

Relevant logs:

sssd_subdomain.example.com.log:
(2020-09-16 19:42:09): [be[subdomain.example.com]] [krb5_auth_done] (0x0040): The krb5_child process returned an error. Please inspect the krb5_child.log file or the journal for more information

krb5_child.log:
(2020-09-16 19:42:09): [krb5_child[1652]] [validate_tgt] (0x2000): Keytab entry with the realm of the credential not found in keytab. Using the last entry.
...
(2020-09-16 19:42:09): [krb5_child[1652]] [validate_tgt] (0x0020): TGT failed verification using key for [host/machine.subdomain.example.com@EXAMPLE.COM].

[sumit-bose]

Hi,

for the validation SSSD is looking for a principal in the keytab which is coming from the same realm as the user trying to authenticate because this will result in the shortest validation path (same realm). As already mentioned, as a fallback the last entry is used.

We AD forests where the users might come from a different trusted realm we will typically not have principals frpm the other realm in the keytab and as a result the fallback is quite often used.

Instead of adding a new option my suggestion would be to use an additional fallback before using the last entry. The value of the suggested krb5_validate_realm would be most probably the realm the client is joined to, so we can use this directly without adding a new option. So the loop looking for the validation principal should not only look for the user realm but also for the one the client is joined to, if they are different, and if the first is not found the second should be used. And only if neither of them is found, which is highly improbable because this principal from the joined domain is e.g. needed for FAST or for the LDAP SASL bind, the last entry should be tried.

bye, Sumit