One-Way Trust between two IPA Realms: Tips for debugging/further research?

[Jostein Fossheim]

I know this is not officially supported. But I would still like to make it work.

We have a main IPA-Realm EXAMPLE.COM, and we have subdomain LAB.EXAMPLE.COM as another
IPA-Eealm. We wan't a one-way trust-relationship from the LAB-realm to our main realm.


I have testet this with two MIT-kerberos barebone KDCs, and I have been able to establish
both one and two way trust between LAB.EXAMPLE.COM and a barebone MIT-realm. But for some
reason I am not able to this between our main realm, and the lab realm. 

The krbtgt/-principial that establishes the trust is created in both realms with the
following command: 

kadmin.local -e 'aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96' -q 'addprinc
-requires_preauth krbtgt/LAB.EXAMPLE.COM(a)EXAMPLE.COM' -x
ipa-setup-override-restrictions

When I try to log into a service in the lab realm with a valid ticket in the trusted
domain via SSH (which work nicely with IPA and the barebone MIT setup), i just keep
getting a "HANDLE_AUTHDATA"-error, which I just find briefly mentioned in a few
posts online: 

debug1: Unspecified GSS failure.  Minor code may provide more information
KDC returned error string: HANDLE_AUTHDATA

On the lab-KDC: /var/log/krb5kdc.log
Feb 20 21:47:42 test-ipa.lab.example.com krb5kdc[1540](info): closing down fd 11
Feb 20 21:47:46 test-ipa.lab.example.com krb5kdc[1540](info): TGS_REQ : handle_authdata
(22)
Feb 20 21:47:46 test-ipa.lab.example.com krb5kdc[1540](info): TGS_REQ (2 etypes
{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17)})
fdd0:192:168:250:ad3:e32b:ef6b:486f: HANDLE_AUTHDATA: authtime 1676921750, etypes
{rep=UNSUPPORTED:(0)} username(a)EXAMPLE.COM for
host/test-ipa.lab.example.com(a)LAB.EXAMPLE.COM, Invalid argument

Any thoughts or tips would be greatly appreciated.

[Jostein Fossheim]

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.

[Alexander Bokovoy]

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 <
freeipa-users(a)lists.fedorahosted.org&gt; 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 -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>  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/[e-mail]...
>  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

[Jostein Fossheim]

Thank you for you're comment/answer. I will do a search for earlier comments, I have
noticed your name in discussions regarding this topic. 

I am not entirely sure what security benefits MS-PAC has, over no PAC/PAD at all, besides
offloading the directory-servers. If you really trust (or control) the other REALM,
impersonation-attacks should not be a problem. If they choose to trust you, well, it is
their security-problem, not yours. 

If you have time between the moments while you travel, might you lend us our opinion on
the following setup: 


We have four realms in play in our setup: 

EXAMPLE.COM (IPA/IdM) 

LAB.EXAMPLE.COM (IPA/IdM)
SAD.EXAMPLE.COM (Samba-based Active Directory)
MAD.EXAMPLE.COM (Microsoft-based Active Directory) 

My hope is to achieve the following: 

LAB.EXAMPLE.COM will have a one-way trust-relationship to EXAMPLE.COM (Users in
EXAMPLE.COM will be trusted the LAB-realm). The three other realms LAB.EXAMPLE.COM,
SAD.EXAMPLE.COM, MAD.EXAMPLE.COM will be a playground for trust between IPA and AD. 

Since our MAIN realm will not trust any other realm, I assume we don't risk any treats
by turning of MS-PAC there? Though, I am not sure if there are other consequences that I
haven't foreseen by doing that. (We don't have any windows-servers/services in
production there) And it does work to turn off MS-PAC (switch to PAD) in one of the
realms, for trust to behave as we expect (in any direction). At least in the test I made
today between two IPA-based realms.  

Best Regards, 

Jostein Fossheim

[Alexander Bokovoy]

Hi,

Just to make clear: the scenario you are trying to set up is not
supported. Any issues found in it, would not be fixed until we start
working on IPA-IPA trust again. I am trying to point out that you are
on your own with this approach at this point.

FreeIPA and RHEL IdM by extension are often used in critical
infrastructure deployments. From my  (developer) perspective, I cannot
recommend a hacked up solution that knowingly degrades security of a
deployed environment configuration.

For why PAC enforcement is important, I would recommend you to read
through Andrew Bartlett's talk at SambaXP'22:
https://sambaxp.org/fileadmin/user_upload/sambaxp2022-Slides/Bartlett-Ker...
(there should be videos available too).

On Tue, Feb 21, 2023 at 4:54 PM Jostein Fossheim via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org&gt; wrote:
>  Thank you for you're comment/answer. I will do a search for earlier comments, I have
> noticed your name in discussions regarding this topic.
>
>  I am not entirely sure what security benefits MS-PAC has, over no PAC/PAD at all, besides
> offloading the directory-servers. If you really trust (or control) the other REALM,
> impersonation-attacks should not be a problem. If they choose to trust you, well, it is
> their security-problem, not yours.
>
>  If you have time between the moments while you travel, might you lend us our opinion on
> the following setup:
>
>
>  We have four realms in play in our setup:
>
>  EXAMPLE.COM (IPA/IdM)
>
>  LAB.EXAMPLE.COM (IPA/IdM)
>  SAD.EXAMPLE.COM (Samba-based Active Directory)
>  MAD.EXAMPLE.COM (Microsoft-based Active Directory)
>
>  My hope is to achieve the following:
>
>  LAB.EXAMPLE.COM will have a one-way trust-relationship to EXAMPLE.COM (Users in
> EXAMPLE.COM will be trusted the LAB-realm). The three other realms LAB.EXAMPLE.COM,
> SAD.EXAMPLE.COM, MAD.EXAMPLE.COM will be a playground for trust between IPA and AD.
>
>  Since our MAIN realm will not trust any other realm, I assume we don't risk any
> treats by turning of MS-PAC there? Though, I am not sure if there are other consequences
> that I haven't foreseen by doing that. (We don't have any windows-servers/services
> in production there) And it does work to turn off MS-PAC (switch to PAD) in one of the
> realms, for trust to behave as we expect (in any direction). At least in the test I made
> today between two IPA-based realms.
>
>  Best Regards,
>
>  Jostein Fossheim
>  _______________________________________________
>  FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>  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/[e-mail]...
>  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

[Jostein Fossheim]

We are fine with being alone, but seeking knowledge and try to understand what we are
doing as deeply as possible, is a high priority. 

I knew about a problem with digitally unsigned PACs, recently addressed by Microsoft and
the Samba team. And I do see the problems pointed out in the slides, and of course that is
a problem that breaks Active Directory at least, since the kerberos-principals and the
actual username are separate entities. In a Unix-only environment without user-access to
renaming accounts, and with a complete control over the principal and username, space (for
both hosts, users and services), and with no trust to external parties, I still don't
see how our setup would be vulnerable. I appreciate your reservations though. 

And just to be clear: The LAB, SAD and MAD, subdomains, are meant as technological testing
and development grounds, for system tests, application tests and a playground for making
deep-dives into authentication-systems in general. 

One last ting: Any other information about the PAD-approach contra MS-PAC. If I enable
this in my IPA-deployment, is it actually used and have consequences? Through a
half-hearted google search, I was only able to find these two sources: 

https://www.freeipa.org/page/V3/Read_and_use_per_service_pac_type
https://datatracker.ietf.org/doc/html/draft-ietf-krb-wg-pad-01

Is there any internal freeIPA-development discussion, that one can read where one is 
discussing the implementation/use of PADs ? 

Does it make any difference setting: 

ipa config-mod --pac-type=nfs:NONE --pac-type=PAD

contra: 

ipa config-mod --pac-type=

(where as I understand it everything defaults to NONE-PAC)

[Alexander Bokovoy]

Short note: PAD does not exist. It was planned, never implemented. The
coffee in FreeIPA KDB driver will reject this setting when using tickets so
do not set it.

Also SSSD expects PAC presence, see SSSD documentation.

Finally, there is no way to resolve users from another realm. Either they
exactly the same as in this realm or ... SSSD has no way to resolve those
users yet.



On Tuesday, February 21, 2023, Jostein Fossheim via FreeIPA-users <
freeipa-users(a)lists.fedorahosted.org&gt; wrote:
>  We are fine with being alone, but seeking knowledge and try to
> understand 
what we are doing as deeply as possible, is a high priority.
>  I knew about a problem with digitally unsigned PACs, recently addressed 
by
Microsoft and the Samba team. And I do see the problems pointed out in
the slides, and of course that is a problem that breaks Active Directory at
least, since the kerberos-principals and the actual username are separate
entities. In a Unix-only environment without user-access to renaming
accounts, and with a complete control over the principal and username,
space (for both hosts, users and services), and with no trust to external
parties, I still don't see how our setup would be vulnerable. I appreciate
your reservations though.
>  And just to be clear: The LAB, SAD and MAD, subdomains, are meant as 
technological
testing and development grounds, for system tests,
application tests and a playground for making deep-dives into
authentication-systems in general.
>  One last ting: Any other information about the PAD-approach contra 
MS-PAC. If I
enable this in my IPA-deployment, is it actually used and have
consequences? Through a half-hearted google search, I was only able to find
these two sources:
>  https://www.freeipa.org/page/V3/Read_and_use_per_service_pac_type
>  https://datatracker.ietf.org/doc/html/draft-ietf-krb-wg-pad-01
>
>  Is there any internal freeIPA-development discussion, that one can read 
where one
is  discussing the implementation/use of PADs ?
>  Does it make any difference setting:
>
>  ipa config-mod --pac-type=nfs:NONE --pac-type=PAD
>
>  contra:
>
>  ipa config-mod --pac-type=
>
>  (where as I understand it everything defaults to NONE-PAC)
>  _______________________________________________
>  FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>  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/[e-mail]...
>  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

[Jostein Fossheim]

Thank you for the clarification regarding PAD.  I read through the IEFT-draft, and 
it's a petty that it never was implemented. But I have always though that SIDs does
make more sense, from a design point of view. 

I read through the section from sssd.conf-manpage, and that was enlightening regarding how
PACs are handled. 

I am aware that the users have to be exactly the same, for our planned setup, that is no
problem, since the LAB-realm that is trusting our main-realm, and is primarily a
test-bench and a technical playground. Its no more complicated than running a barebone
MIT-realm, on top of a FLAT passwd-/group-file or a simple LDAP-backend. 

I hope we will see a trust-relationship between IPA-realms implemented in a not too
distant future. If we had more resources, we would have have loved to sponsor or
contribute to the development.

[Alexander Bokovoy]

Hi,

our progress of IPA-IPA trust is tightly coupled with implementation
of the Global Catalog service to allow a practical use of the other
leg in trust to Active Directory. As I said, the focus currently is
elsewhere; you can see a state by 2021 here:
https://talks.vda.li/talks/2021/2021-02-global-catalog.pdf, the code
it references is working to a certain degree but incomplete. It also
allowed finding some missing functionality in SSSD when IPA domain
controllers are used instead of AD DCs in this trust. That branch does
not contain one important commit where I experimented with IPA-IPA
trust creation. Sadly, the commit (in
https://github.com/freeipa/freeipa/compare/master...abbra:freeipa:wip-ipa...)
is not kept up to date, it is now a year behind current IPA
development.

If you'd find any resources to help with debugging these
configurations in future, let me know.

On Wed, Feb 22, 2023 at 12:18 AM Jostein Fossheim via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org&gt; wrote:
>  Thank you for the clarification regarding PAD.  I read through the IEFT-draft, and 
> it's a petty that it never was implemented. But I have always though that SIDs does
> make more sense, from a design point of view.
>
>  I read through the section from sssd.conf-manpage, and that was enlightening regarding
> how PACs are handled.
>
>  I am aware that the users have to be exactly the same, for our planned setup, that is no
> problem, since the LAB-realm that is trusting our main-realm, and is primarily a
> test-bench and a technical playground. Its no more complicated than running a barebone
> MIT-realm, on top of a FLAT passwd-/group-file or a simple LDAP-backend.
>
>  I hope we will see a trust-relationship between IPA-realms implemented in a not too
> distant future. If we had more resources, we would have have loved to sponsor or
> contribute to the development.
>  _______________________________________________
>  FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>  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/[e-mail]...
>  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