Hi, I'm on a travel right now but you are right. You will not get it working because we require PAC presence to protect Kerberos impersonation cross-realm. This is not a theoretical probability anymore since November 2022 Microsoft security updates.
Please read my posts here in past few years. We have some plans on this topic but the focus has been shifted to make passwordless authentication working first. On Tuesday, February 21, 2023, Jostein Fossheim via FreeIPA-users < [email protected]> wrote: > Update: > > I created a new FreeIPA realm (SUB.LAB.EXAMPLE.COM) to make further tests, with a fresh install of the IPA-environment, and was able to replicate the problem described above. I had a hunch, thanks to earlier online posts, discussing a similar error that the problem could relate to the MS-PAC-diagram, and changed the "Default PAC types" from "MS-PAC, nfs:NONE" to "PAD". Via the command: > > ipa config-mod --pac-type=PAD > > After that the trust-relationship worked as expected between the two ipa realms SUB.LAB.EXAMPLE.COM and LAB.EXAMPLE.COM. > > I can only find documentation describing this from IPA V3.: > https://www.freeipa.org/page/V3/Read_and_use_per_service_pac_type > > I am not entirely sure about the consequences of changing the PAC-type in an environment that is more or less only consists for unix-machines. Is the PAD-diagram (POSIX Authorization Data), described in the draft: > > https://datatracker.ietf.org/doc/html/draft-ietf-krb-wg-pad-01 > > In use at all? > > I do plan to integrate an Samba Active Directory and and Microsoft Active Directory in the environment to deepen our understanding on trust-relationships. So I still wonder, if there is another way I can maintain a trust-relationship between two ipa-instances without changing the PAC-type. > > Because of this, I assume it would be more logical to disable MS-PAC in our main realm than in our LAB-environment. > > I still appreciate thoughts or comments, or documentation regarding this. > _______________________________________________ > FreeIPA-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedorahosted.org/archives/list/[email protected] > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue > -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
_______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
