Does SSSD work with Microsoft's newish Cloud Kerberos? If not, are there any plans to?
On Пан, 12 лют 2024, David L wrote:
Does SSSD work with Microsoft's newish Cloud Kerberos? If not, are there any plans to?
It is not really SSSD task in itself, so yes and no and yes. :)
For 'Cloud' Kerberos reference I assume you mean what Steve Syfuhs describes here: https://syfuhs.net/how-azure-ad-kerberos-works
The way how Kerberos support is built into Azure AD/Entra ID, is by introducing a virtual realm (per-tenant) where an access to its KDCs is given over MS-KKDCP (KDC proxy) protocol. This part is already supported by MIT Kerberos and can be configured easily. We use it in production in FreeIPA for years, all Fedora contributors use it to obtain their Kerberos tickets when managing their RPM package builds.
However, there is one part that is missing currently. In order to talk to that KDC, a machine needs to be joined to Entra ID and be capable to request and process primary resource token (PRT) associated with such join. When PRT is requested, one can ask for a TGT too (two, actually) and they will be returned on behalf of the user.
This part is not implemented. David Mulder (SUSE and Samba Team) is working on an implementation of that for Samba join to Entra ID, a draft merge request is available at https://gitlab.com/samba-team/samba/-/merge_requests/3394. This is far from being a usable code yet and retrieving a special key for Kerberos operations is missing there.
We are working as a community on a more generic integration with OAuth2-based environments. The "Cloud" Kebreros thing you see in Entra ID is part of it, so 'yes' for plans but no specific timeline is there at the moment.
I realized I have a couple more questions.
For 'Cloud' Kerberos reference I assume you mean what Steve Syfuhs describes here: https://syfuhs.net/how-azure-ad-kerberos-works
Yes. I think I'm using a newer name. For a little bit they called is Cloud Business Kerberos too.
The way how Kerberos support is built into Azure AD/Entra ID, is by introducing a virtual realm (per-tenant) where an access to its KDCs is given over MS-KKDCP (KDC proxy) protocol. This part is already supported by MIT Kerberos and can be configured easily. We use it in production in
However, there is one part that is missing currently. In order to talk to that KDC, a machine needs to be joined to Entra ID and be capable to request and process primary resource token (PRT) associated with such join. When PRT is requested, one can ask for a TGT too (two, actually)
OK, I'm confused. Can you please clarify what can be done right now and what cannot be done right now?
In particular: 1. Right now, can SSSD auth to Entra if SSSD has been domain joined to an on-prem that is sync'ing with Entra (or whatever other requirements you need)? 1b. If no to 1, is this part of what David M is working on? 2. Right now, can SSSD domain join to Entra? 2b. If no to 1, is this part of what David M is working on?
On Аўт, 13 лют 2024, David L wrote:
I realized I have a couple more questions.
For 'Cloud' Kerberos reference I assume you mean what Steve Syfuhs describes here: https://syfuhs.net/how-azure-ad-kerberos-works
Yes. I think I'm using a newer name. For a little bit they called is Cloud Business Kerberos too.
The way how Kerberos support is built into Azure AD/Entra ID, is by introducing a virtual realm (per-tenant) where an access to its KDCs is given over MS-KKDCP (KDC proxy) protocol. This part is already supported by MIT Kerberos and can be configured easily. We use it in production in
However, there is one part that is missing currently. In order to talk to that KDC, a machine needs to be joined to Entra ID and be capable to request and process primary resource token (PRT) associated with such join. When PRT is requested, one can ask for a TGT too (two, actually)
OK, I'm confused. Can you please clarify what can be done right now and what cannot be done right now?
In particular:
- Right now, can SSSD auth to Entra if SSSD has been domain joined to
an on-prem that is sync'ing with Entra (or whatever other requirements you need)?
Depends on whether this machine is part of RHEL IdM environment or not. RHEL IdM can authenticate to Entra ID. This authentication process will obtain a Kerberos ticket from RHEL IdM realm. This has nothing to do with 'Cloud' Kerberos that Entra ID provides but authorization would be done by Entra ID OAuth2 end-point.
Other situations: currently no.
1b. If no to 1, is this part of what David M is working on?
No exactly but the work on Entra ID join is required to have individual machines joined to Entra ID.
- Right now, can SSSD domain join to Entra?
2b. If no to 1, is this part of what David M is working on?
No and no.
There are independent bits and pieces of a bigger puzzle that need to be worked on, they are done by different groups but altogether they contribute to the same goal. Most of the specifications aren't written yet or not documented publicly so regardless of the projects being done, discovering all that information is crucial.
What is your interest in all this? Are you willing to help with the development effort around OAuth2 authentication and identity management?
No and no.
There are independent bits and pieces of a bigger puzzle that need to be worked on, they are done by different groups but altogether they contribute to the same goal. Most of the specifications aren't written yet or not documented publicly so regardless of the projects being done, discovering all that information is crucial.
As Alexander said, I'm not working on SSSD, but really on learning all the bits, how they go together, and what we need to do as a community. Right now the Samba team is investigating and working on a proof of concept. We know now how to join to Azure AD, and I have figured out how to request a PRT (Primary Refresh Token) with a partial Kerberos TGT. There is a protocol that needs implemented before we can do anything with that TGT, IIUC. If you're able to help with implementation in SSSD, I can point you in the right direction for documentation, etc.
Depends on whether this machine is part of RHEL IdM environment or not. RHEL IdM can authenticate to Entra ID. This authentication process will obtain a Kerberos ticket from RHEL IdM realm. This has nothing to do with 'Cloud' Kerberos that Entra ID provides but authorization would be done by Entra ID OAuth2 end-point.
OK. Is RHEL IdM proprietary/closed source, or just a different set of open-source that supports this?
Thankyou much for the answers.
What is your interest in all this? Are you willing to help with the development effort around OAuth2 authentication and identity management?
My interest is in obtaining better visibility into Cloud Kerberos support in SSSD/open source - where it is, future intents, complexity of remaining problems, etc. I can't say better than that right now.
I would love to help but lack the time right now. Partly it's our 1 year old who has limited ability to authenticate and at best an ill defined relationship with the word "no." Fortunately he's meeting all his milestones and there have been no build breaks. :-) I will definiately let you know when I can.
On Чцв, 15 лют 2024, David L wrote:
Depends on whether this machine is part of RHEL IdM environment or not. RHEL IdM can authenticate to Entra ID. This authentication process will obtain a Kerberos ticket from RHEL IdM realm. This has nothing to do with 'Cloud' Kerberos that Entra ID provides but authorization would be done by Entra ID OAuth2 end-point.
OK. Is RHEL IdM proprietary/closed source, or just a different set of open-source that supports this?
RHEL IdM is a component of RHEL. Upstream project is FreeIPA.
Thankyou much for the answers.
What is your interest in all this? Are you willing to help with the development effort around OAuth2 authentication and identity management?
My interest is in obtaining better visibility into Cloud Kerberos support in SSSD/open source - where it is, future intents, complexity of remaining problems, etc. I can't say better than that right now.
OK. Let us know when you are able to. ;)
This part is not implemented. David Mulder (SUSE and Samba Team) is working on an implementation of that for Samba join to Entra ID, a draft merge request is available at https://gitlab.com/samba-team/samba/-/merge_requests/3394. This is far from being a usable code yet and retrieving a special key for Kerberos operations is missing there.
Here are some links to in-progress work: A join spec, since MS isn't documenting any of this: https://github.com/himmelblau-idm/aad-join-spec/releases/tag/0.02 A rust library which implements broker functionality (the ability to enroll a device and request a PRT and TGT, then exchange the PRT for access tokens): https://github.com/himmelblau-idm/microsoft-authentication-library-for-rust
On Срд, 14 лют 2024, David Mulder wrote:
This part is not implemented. David Mulder (SUSE and Samba Team) is working on an implementation of that for Samba join to Entra ID, a draft merge request is available at https://gitlab.com/samba-team/samba/-/merge_requests/3394. This is far from being a usable code yet and retrieving a special key for Kerberos operations is missing there.
Here are some links to in-progress work: A join spec, since MS isn't documenting any of this: https://github.com/himmelblau-idm/aad-join-spec/releases/tag/0.02 A rust library which implements broker functionality (the ability to enroll a device and request a PRT and TGT, then exchange the PRT for access tokens): https://github.com/himmelblau-idm/microsoft-authentication-library-for-rust
Thank you, David. I am aware of this work but it is helpful to point others to it as well.
FYI, Microsoft also have added an FAQ on some details for Kerberos part in Entra ID here: https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authen...
Have you already got to handle that TGT in a ccache that can be used by a system Kerberos library?
sssd-devel@lists.fedorahosted.org