Cannot authenticate using Kerberos after upgrade to 4.10.1

[Gianluca Amato]

Hi all,
I have a FreeIPA installation with three servers on CentOS Stream 9. Recently, I upgraded
one server from FreeIPA 4.10.0 to 4.10.1. After the upgrade, kinit <user> fails in
the new server for all users, with the only exception of the admin user. The following
happens:

1) In the command shell, I type "kinit studente" (or any other user but admin)
2) I enter the correct password
3) The result is "kinit: Generic error (see e-text) while getting initial
credentials"

Kerberos authentication still works correctly on the servers which are still on 4.10.0.
LDAP authentication works correctly everywhere.

If I check the /var/log/krb5kdc.log, I notice the following:

Mar 14 13:35:13 ipa1.labeconomia.unich.it krb5kdc2868: AS_REQ (4 etypes
{aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20),
aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17)}) 10.1.68.199:
HANDLE_AUTHDATA: studente(a)LABECONOMIA.UNICH.IT for
krbtgt/LABECONOMIA.UNICH.IT(a)LABECONOMIA.UNICH.IT, No such file or directory

So the problem seems this "No such file or directory" during the HANDLE_AUTHDATA
phase, but I have no idea what file it is looking for. This error only appears if I type
the correct password. In case of wrong password, I get a standard "Preauthentication
failed" error.

Note also that "admin" is the only user with a SID (attribute
"ipaNTSecurityIdentifier" in LDAP), which is required for generating Kerberos
tickets with PACs. Is it possible the new FreeIPA insists in generating PACs? In case, is
it possible to disable this behavior ?

Thanks for any help,
--gianluca

[Gianluca Amato]

At the end, I opted for the opposite solution. I just enabled support for SID with the
command

ipa config-mod --enable-sid --add-sids

and now all servers seems to work fine again.

[Alexander Bokovoy]

On ti, 14 maalis 2023, Gianluca Amato via FreeIPA-users wrote:
> At the end, I opted for the opposite solution. I just enabled support
> for SID with the command
>
> ipa config-mod --enable-sid --add-sids
>
> and now all servers seems to work fine again. 
Correct. There is no way to disable that due to a need to protect
against a number of Kerberos-based attacks which were developed over
past several years based on the Active Directory environments and
targeting Linux systems. FreeIPA, SSSD, Samba Team, and both MIT
Kerberos and Heimdal Kerberos projects have been working together with
Microsoft folks to address these issues in industry-wide manner. We are
still not entirely there (new PAC signatures, for example, will be fully
enforced by Microsoft in autumn 2023 and we need to be ready for that)
but for the directory services there is no a way back.

I have a blog post in works that tries to summarize the changes that
have been done over past few years in this area. It is not complete yet,
I'll reference it here once it is published.


-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Gianluca Amato]

>  but for the directory services there is no a way back. 
I see, thanks for the explanation. I have no problems in enabling SIDs, but probably,
considering  it is the only way to get a fully working system, this should have been done
automatically by the upgrade scripts in FreeIPA.
 
>  I have a blog post in works that tries to summarize the changes that
>  have been done over past few years in this area. It is not complete yet,
>  I'll reference it here once it is published. 
Thanks, wonderful idea!

--gianluca

[Alexander Bokovoy]

On ke, 15 maalis 2023, Gianluca Amato via FreeIPA-users wrote:
> > but for the directory services there is no a way back.
>
> I see, thanks for the explanation. I have no problems in enabling SIDs,
> but probably, considering  it is the only way to get a fully working
> system, this should have been done automatically by the upgrade scripts
> in FreeIPA. 
SIDs need to be assigned to all users/groups (and in some cases also to
machines and Kerberos services). For large deployments this would mean a
lot of LDAP modifications and replication traffic. Current solution
gives administrators a way to control when this activity happens. For
example, you might want to run SID generation on a hidden replica and
proceed with upgrades of other replicas in your topology after that.


-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland