Hi,
I developed a Keycloak extension (Keycloak PSSO extension) so that users of managed macOS machines get SSO. The framework used - Platform Single Sign-on - also allows returning kerberos tickets.
But I'm not sure how Keycloak could programmatically return kerberos tickets for a user without the password. Some of the pPlatform SSO flows do not involve using passwords.
The idea I had first was to use my extension with some keytab with permissions to request kerberos tickets on behalf of other users.
But has FreeIPA support for OAuth2 tokens, so that I could simply exchange an OAuth2 token to a kerberos tickets? This would be easier since I already control token issuing on the keycloak side.
Best, Francis
On Fri, 28 Aug 2026, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
Hi,
I developed a Keycloak extension (Keycloak PSSO extension) so that users of managed macOS machines get SSO. The framework used - Platform Single Sign-on - also allows returning kerberos tickets.
But I'm not sure how Keycloak could programmatically return kerberos tickets for a user without the password. Some of the pPlatform SSO flows do not involve using passwords.
Standard way of achieving this is to let a service to perform Kerberos protocol transition (S4U operations). S4U2Self is allowed to any service, S4U2Proxy is privileged. This is what IPA API is using already.
The idea I had first was to use my extension with some keytab with permissions to request kerberos tickets on behalf of other users.
But has FreeIPA support for OAuth2 tokens, so that I could simply exchange an OAuth2 token to a kerberos tickets? This would be easier since I already control token issuing on the keycloak side.
You can create your own OAuth2 service with a Kerberos service keytab and then handle it there. The service will have to be explicitly allowed to perform operations on behalf of users towards IPA services.
I have integration like that done for Ahdapa, see the design and the code in the work in progress modrnizer branch here: https://github.com/abbra/freeipa/blob/modrnizer/doc/designs/webui-oauth2-log... and Ahdapa side endpoint documentation here: https://ahdapa.dev/doc/api/internal.html#credential-exchange-oidc-to-kerbero...
Ahdapa is a next generation integrated OAuth2 IdP for FreeIPA, https://forge.fedoraproject.org/freeipa/ahdapa
Note that the code in modrnizer branch is building on top of gssproxy integration for existing IPA HTTP service, so we cannot use the issued ccache outside IPA server itself: the credentials in the ccache are encrypted by gssproxy and can only be decrypted by the same gssproxy session. However, Ahdapa can be set up as a separate IdP endpoint on enrolled IPA client and joined the same IPA topology. If that is done in a way that doesn't use gssproxy, then the ccache produced by that instance's OBO endpoint would be usable beyond that service point.
If you want to try it, use COPR abbra/modrnizer for experiments.
Thanks a lot Alexander! I will look into it and try to start a PoC.
Best, Francis
On 31 Aug 2026, at 09:41, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On Fri, 28 Aug 2026, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
Hi,
I developed a Keycloak extension (Keycloak PSSO extension) so that users of managed macOS machines get SSO. The framework used - Platform Single Sign-on - also allows returning kerberos tickets.
But I'm not sure how Keycloak could programmatically return kerberos tickets for a user without the password. Some of the pPlatform SSO flows do not involve using passwords.
Standard way of achieving this is to let a service to perform Kerberos protocol transition (S4U operations). S4U2Self is allowed to any service, S4U2Proxy is privileged. This is what IPA API is using already.
The idea I had first was to use my extension with some keytab with permissions to request kerberos tickets on behalf of other users.
But has FreeIPA support for OAuth2 tokens, so that I could simply exchange an OAuth2 token to a kerberos tickets? This would be easier since I already control token issuing on the keycloak side.
You can create your own OAuth2 service with a Kerberos service keytab and then handle it there. The service will have to be explicitly allowed to perform operations on behalf of users towards IPA services.
I have integration like that done for Ahdapa, see the design and the code in the work in progress modrnizer branch here: https://github.com/abbra/freeipa/blob/modrnizer/doc/designs/webui-oauth2-log... and Ahdapa side endpoint documentation here: https://ahdapa.dev/doc/api/internal.html#credential-exchange-oidc-to-kerbero...
Ahdapa is a next generation integrated OAuth2 IdP for FreeIPA, https://forge.fedoraproject.org/freeipa/ahdapa
Note that the code in modrnizer branch is building on top of gssproxy integration for existing IPA HTTP service, so we cannot use the issued ccache outside IPA server itself: the credentials in the ccache are encrypted by gssproxy and can only be decrypted by the same gssproxy session. However, Ahdapa can be set up as a separate IdP endpoint on enrolled IPA client and joined the same IPA topology. If that is done in a way that doesn't use gssproxy, then the ccache produced by that instance's OBO endpoint would be usable beyond that service point.
If you want to try it, use COPR abbra/modrnizer for experiments.
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
One quick questions: can I fetch tgt’s using this setup or just service tickets? __ Francis Augusto Medeiros-Logeay Oslo, Norway Sent from a mobile device / Enviado a partir de dispositivo móvel
On 31 Aug 2026, at 09:42, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On Fri, 28 Aug 2026, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
Hi,
I developed a Keycloak extension (Keycloak PSSO extension) so that users of managed macOS machines get SSO. The framework used - Platform Single Sign-on - also allows returning kerberos tickets.
But I'm not sure how Keycloak could programmatically return kerberos tickets for a user without the password. Some of the pPlatform SSO flows do not involve using passwords.
Standard way of achieving this is to let a service to perform Kerberos protocol transition (S4U operations). S4U2Self is allowed to any service, S4U2Proxy is privileged. This is what IPA API is using already.
The idea I had first was to use my extension with some keytab with permissions to request kerberos tickets on behalf of other users.
But has FreeIPA support for OAuth2 tokens, so that I could simply exchange an OAuth2 token to a kerberos tickets? This would be easier since I already control token issuing on the keycloak side.
You can create your own OAuth2 service with a Kerberos service keytab and then handle it there. The service will have to be explicitly allowed to perform operations on behalf of users towards IPA services.
I have integration like that done for Ahdapa, see the design and the code in the work in progress modrnizer branch here: https://github.com/abbra/freeipa/blob/modrnizer/doc/designs/webui-oauth2-log... and Ahdapa side endpoint documentation here: https://ahdapa.dev/doc/api/internal.html#credential-exchange-oidc-to-kerbero...
Ahdapa is a next generation integrated OAuth2 IdP for FreeIPA, https://forge.fedoraproject.org/freeipa/ahdapa
Note that the code in modrnizer branch is building on top of gssproxy integration for existing IPA HTTP service, so we cannot use the issued ccache outside IPA server itself: the credentials in the ccache are encrypted by gssproxy and can only be decrypted by the same gssproxy session. However, Ahdapa can be set up as a separate IdP endpoint on enrolled IPA client and joined the same IPA topology. If that is done in a way that doesn't use gssproxy, then the ccache produced by that instance's OBO endpoint would be usable beyond that service point.
If you want to try it, use COPR abbra/modrnizer for experiments.
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
On Mon, 31 Aug 2026, Francis Augusto Medeiros-Logeay wrote:
One quick questions: can I fetch tgt’s using this setup or just service tickets?
Only service tickets. With https://github.com/krb5/krb5/pull/1498 merged, that's all you'd need -- if they exist, they'll be prioritized.
__ Francis Augusto Medeiros-Logeay Oslo, Norway Sent from a mobile device / Enviado a partir de dispositivo móvel
On 31 Aug 2026, at 09:42, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On Fri, 28 Aug 2026, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
Hi,
I developed a Keycloak extension (Keycloak PSSO extension) so that users of managed macOS machines get SSO. The framework used - Platform Single Sign-on - also allows returning kerberos tickets.
But I'm not sure how Keycloak could programmatically return kerberos tickets for a user without the password. Some of the pPlatform SSO flows do not involve using passwords.
Standard way of achieving this is to let a service to perform Kerberos protocol transition (S4U operations). S4U2Self is allowed to any service, S4U2Proxy is privileged. This is what IPA API is using already.
The idea I had first was to use my extension with some keytab with permissions to request kerberos tickets on behalf of other users.
But has FreeIPA support for OAuth2 tokens, so that I could simply exchange an OAuth2 token to a kerberos tickets? This would be easier since I already control token issuing on the keycloak side.
You can create your own OAuth2 service with a Kerberos service keytab and then handle it there. The service will have to be explicitly allowed to perform operations on behalf of users towards IPA services.
I have integration like that done for Ahdapa, see the design and the code in the work in progress modrnizer branch here: https://github.com/abbra/freeipa/blob/modrnizer/doc/designs/webui-oauth2-log... and Ahdapa side endpoint documentation here: https://ahdapa.dev/doc/api/internal.html#credential-exchange-oidc-to-kerbero...
Ahdapa is a next generation integrated OAuth2 IdP for FreeIPA, https://forge.fedoraproject.org/freeipa/ahdapa
Note that the code in modrnizer branch is building on top of gssproxy integration for existing IPA HTTP service, so we cannot use the issued ccache outside IPA server itself: the credentials in the ccache are encrypted by gssproxy and can only be decrypted by the same gssproxy session. However, Ahdapa can be set up as a separate IdP endpoint on enrolled IPA client and joined the same IPA topology. If that is done in a way that doesn't use gssproxy, then the ccache produced by that instance's OBO endpoint would be usable beyond that service point.
If you want to try it, use COPR abbra/modrnizer for experiments.
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
But is there a way to return TGT’s? __ Francis Augusto Medeiros-Logeay Oslo, Norway Sent from a mobile device / Enviado a partir de dispositivo móvel
On 31 Aug 2026, at 17:03, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On Mon, 31 Aug 2026, Francis Augusto Medeiros-Logeay wrote:
One quick questions: can I fetch tgt’s using this setup or just service tickets?
Only service tickets. With https://github.com/krb5/krb5/pull/1498 merged, that's all you'd need -- if they exist, they'll be prioritized.
__ Francis Augusto Medeiros-Logeay Oslo, Norway Sent from a mobile device / Enviado a partir de dispositivo móvel
On 31 Aug 2026, at 09:42, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On Fri, 28 Aug 2026, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
Hi,
I developed a Keycloak extension (Keycloak PSSO extension) so that users of managed macOS machines get SSO. The framework used - Platform Single Sign-on - also allows returning kerberos tickets.
But I'm not sure how Keycloak could programmatically return kerberos tickets for a user without the password. Some of the pPlatform SSO flows do not involve using passwords.
Standard way of achieving this is to let a service to perform Kerberos protocol transition (S4U operations). S4U2Self is allowed to any service, S4U2Proxy is privileged. This is what IPA API is using already.
The idea I had first was to use my extension with some keytab with permissions to request kerberos tickets on behalf of other users.
But has FreeIPA support for OAuth2 tokens, so that I could simply exchange an OAuth2 token to a kerberos tickets? This would be easier since I already control token issuing on the keycloak side.
You can create your own OAuth2 service with a Kerberos service keytab and then handle it there. The service will have to be explicitly allowed to perform operations on behalf of users towards IPA services.
I have integration like that done for Ahdapa, see the design and the code in the work in progress modrnizer branch here: https://github.com/abbra/freeipa/blob/modrnizer/doc/designs/webui-oauth2-log... and Ahdapa side endpoint documentation here: https://ahdapa.dev/doc/api/internal.html#credential-exchange-oidc-to-kerbero...
Ahdapa is a next generation integrated OAuth2 IdP for FreeIPA, https://forge.fedoraproject.org/freeipa/ahdapa
Note that the code in modrnizer branch is building on top of gssproxy integration for existing IPA HTTP service, so we cannot use the issued ccache outside IPA server itself: the credentials in the ccache are encrypted by gssproxy and can only be decrypted by the same gssproxy session. However, Ahdapa can be set up as a separate IdP endpoint on enrolled IPA client and joined the same IPA topology. If that is done in a way that doesn't use gssproxy, then the ccache produced by that instance's OBO endpoint would be usable beyond that service point.
If you want to try it, use COPR abbra/modrnizer for experiments.
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
On Mon, 31 Aug 2026, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
But is there a way to return TGT’s?
You have to control the access to the passwordless method's credential in order to do that. For passkey this means the machine where such service runs should have access to the physical key supported by libfido2, for example. Same for smartcards. For OTP someone has to enter the pin+token value.
KDC can issue a ticket in the name of any principal because they possess the master key of the realm and have access to individual principal's keys but this is insecure to grant access to for any other entity.
Nvidia implemented something like this in Sybil for cross-realm principals but we strongly don't recommend this approach (https://github.com/NVIDIA/sybil). Sybil's code basically uses kadmin.local-like interface to perform this and is something to guard as close as krb5kdc process.
Nvidia's code will not work for passwordless methods without additional logic because for these principals there are no encryption keys in the entry.
__ Francis Augusto Medeiros-Logeay Oslo, Norway Sent from a mobile device / Enviado a partir de dispositivo móvel
On 31 Aug 2026, at 17:03, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On Mon, 31 Aug 2026, Francis Augusto Medeiros-Logeay wrote:
One quick questions: can I fetch tgt’s using this setup or just service tickets?
Only service tickets. With https://github.com/krb5/krb5/pull/1498 merged, that's all you'd need -- if they exist, they'll be prioritized.
__ Francis Augusto Medeiros-Logeay Oslo, Norway Sent from a mobile device / Enviado a partir de dispositivo móvel
On 31 Aug 2026, at 09:42, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On Fri, 28 Aug 2026, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
Hi,
I developed a Keycloak extension (Keycloak PSSO extension) so that users of managed macOS machines get SSO. The framework used - Platform Single Sign-on - also allows returning kerberos tickets.
But I'm not sure how Keycloak could programmatically return kerberos tickets for a user without the password. Some of the pPlatform SSO flows do not involve using passwords.
Standard way of achieving this is to let a service to perform Kerberos protocol transition (S4U operations). S4U2Self is allowed to any service, S4U2Proxy is privileged. This is what IPA API is using already.
The idea I had first was to use my extension with some keytab with permissions to request kerberos tickets on behalf of other users.
But has FreeIPA support for OAuth2 tokens, so that I could simply exchange an OAuth2 token to a kerberos tickets? This would be easier since I already control token issuing on the keycloak side.
You can create your own OAuth2 service with a Kerberos service keytab and then handle it there. The service will have to be explicitly allowed to perform operations on behalf of users towards IPA services.
I have integration like that done for Ahdapa, see the design and the code in the work in progress modrnizer branch here: https://github.com/abbra/freeipa/blob/modrnizer/doc/designs/webui-oauth2-log... and Ahdapa side endpoint documentation here: https://ahdapa.dev/doc/api/internal.html#credential-exchange-oidc-to-kerbero...
Ahdapa is a next generation integrated OAuth2 IdP for FreeIPA, https://forge.fedoraproject.org/freeipa/ahdapa
Note that the code in modrnizer branch is building on top of gssproxy integration for existing IPA HTTP service, so we cannot use the issued ccache outside IPA server itself: the credentials in the ccache are encrypted by gssproxy and can only be decrypted by the same gssproxy session. However, Ahdapa can be set up as a separate IdP endpoint on enrolled IPA client and joined the same IPA topology. If that is done in a way that doesn't use gssproxy, then the ccache produced by that instance's OBO endpoint would be usable beyond that service point.
If you want to try it, use COPR abbra/modrnizer for experiments.
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
Thanks a lot Alexander.
I think I might just drop this.
You see, Platform SSO is a framework from Apple where the IdP (in our case Keycloak) returns ID and Refresh tokens to a Mac which can be used for SSO later. Optionally, the IdP could also return kerberos tickets.
But since the authentication towards keycloak will be based on user certificates, I can’t see how these certificates could be used to issue tokens. The public keys from the user are stored in Keycloak, and the private on the mac’s Secure Enclave.
Is there a way that the KDC could use these keys so that I could simply present a signed assertion with the user’s keys to fetch a TGT?
Best, Francis
On 31 Aug 2026, at 18:44, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On Mon, 31 Aug 2026, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
But is there a way to return TGT’s?
You have to control the access to the passwordless method's credential in order to do that. For passkey this means the machine where such service runs should have access to the physical key supported by libfido2, for example. Same for smartcards. For OTP someone has to enter the pin+token value.
KDC can issue a ticket in the name of any principal because they possess the master key of the realm and have access to individual principal's keys but this is insecure to grant access to for any other entity.
Nvidia implemented something like this in Sybil for cross-realm principals but we strongly don't recommend this approach (https://github.com/NVIDIA/sybil). Sybil's code basically uses kadmin.local-like interface to perform this and is something to guard as close as krb5kdc process.
Nvidia's code will not work for passwordless methods without additional logic because for these principals there are no encryption keys in the entry.
__ Francis Augusto Medeiros-Logeay Oslo, Norway Sent from a mobile device / Enviado a partir de dispositivo móvel
On 31 Aug 2026, at 17:03, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On Mon, 31 Aug 2026, Francis Augusto Medeiros-Logeay wrote:
One quick questions: can I fetch tgt’s using this setup or just service tickets?
Only service tickets. With https://github.com/krb5/krb5/pull/1498 merged, that's all you'd need -- if they exist, they'll be prioritized.
__ Francis Augusto Medeiros-Logeay Oslo, Norway Sent from a mobile device / Enviado a partir de dispositivo móvel
On 31 Aug 2026, at 09:42, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On Fri, 28 Aug 2026, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
Hi,
I developed a Keycloak extension (Keycloak PSSO extension) so that users of managed macOS machines get SSO. The framework used - Platform Single Sign-on - also allows returning kerberos tickets.
But I'm not sure how Keycloak could programmatically return kerberos tickets for a user without the password. Some of the pPlatform SSO flows do not involve using passwords.
Standard way of achieving this is to let a service to perform Kerberos protocol transition (S4U operations). S4U2Self is allowed to any service, S4U2Proxy is privileged. This is what IPA API is using already.
The idea I had first was to use my extension with some keytab with permissions to request kerberos tickets on behalf of other users.
But has FreeIPA support for OAuth2 tokens, so that I could simply exchange an OAuth2 token to a kerberos tickets? This would be easier since I already control token issuing on the keycloak side.
You can create your own OAuth2 service with a Kerberos service keytab and then handle it there. The service will have to be explicitly allowed to perform operations on behalf of users towards IPA services.
I have integration like that done for Ahdapa, see the design and the code in the work in progress modrnizer branch here: https://github.com/abbra/freeipa/blob/modrnizer/doc/designs/webui-oauth2-log... and Ahdapa side endpoint documentation here: https://ahdapa.dev/doc/api/internal.html#credential-exchange-oidc-to-kerbero...
Ahdapa is a next generation integrated OAuth2 IdP for FreeIPA, https://forge.fedoraproject.org/freeipa/ahdapa
Note that the code in modrnizer branch is building on top of gssproxy integration for existing IPA HTTP service, so we cannot use the issued ccache outside IPA server itself: the credentials in the ccache are encrypted by gssproxy and can only be decrypted by the same gssproxy session. However, Ahdapa can be set up as a separate IdP endpoint on enrolled IPA client and joined the same IPA topology. If that is done in a way that doesn't use gssproxy, then the ccache produced by that instance's OBO endpoint would be usable beyond that service point.
If you want to try it, use COPR abbra/modrnizer for experiments.
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
On Wed, 02 Sep 2026, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
Thanks a lot Alexander.
I think I might just drop this.
You see, Platform SSO is a framework from Apple where the IdP (in our case Keycloak) returns ID and Refresh tokens to a Mac which can be used for SSO later. Optionally, the IdP could also return kerberos tickets.
But since the authentication towards keycloak will be based on user certificates, I can’t see how these certificates could be used to issue tokens. The public keys from the user are stored in Keycloak, and the private on the mac’s Secure Enclave.
Is there a way that the KDC could use these keys so that I could simply present a signed assertion with the user’s keys to fetch a TGT?
macOS has support for PKINIT: https://support.apple.com/en-euro/guide/deployment/depe6a1cda64/web
GSA maintains some instructions against Active Directory which should be usable to FreeIPA as well: https://www.idmanagement.gov/implement/scl-macos/
As long as these public keys are mapped in IPA to the users through cert mapping or by associating the public keys with the specific users, it should work.
Best, Francis
On 31 Aug 2026, at 18:44, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On Mon, 31 Aug 2026, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
But is there a way to return TGT’s?
You have to control the access to the passwordless method's credential in order to do that. For passkey this means the machine where such service runs should have access to the physical key supported by libfido2, for example. Same for smartcards. For OTP someone has to enter the pin+token value.
KDC can issue a ticket in the name of any principal because they possess the master key of the realm and have access to individual principal's keys but this is insecure to grant access to for any other entity.
Nvidia implemented something like this in Sybil for cross-realm principals but we strongly don't recommend this approach (https://github.com/NVIDIA/sybil). Sybil's code basically uses kadmin.local-like interface to perform this and is something to guard as close as krb5kdc process.
Nvidia's code will not work for passwordless methods without additional logic because for these principals there are no encryption keys in the entry.
__ Francis Augusto Medeiros-Logeay Oslo, Norway Sent from a mobile device / Enviado a partir de dispositivo móvel
On 31 Aug 2026, at 17:03, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On Mon, 31 Aug 2026, Francis Augusto Medeiros-Logeay wrote:
One quick questions: can I fetch tgt’s using this setup or just service tickets?
Only service tickets. With https://github.com/krb5/krb5/pull/1498 merged, that's all you'd need -- if they exist, they'll be prioritized.
__ Francis Augusto Medeiros-Logeay Oslo, Norway Sent from a mobile device / Enviado a partir de dispositivo móvel
> On 31 Aug 2026, at 09:42, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On Fri, 28 Aug 2026, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote: > > Hi, > > I developed a Keycloak extension (Keycloak PSSO extension) so that users of managed macOS machines get SSO. > The framework used - Platform Single Sign-on - also allows returning kerberos tickets. > > But I'm not sure how Keycloak could programmatically return kerberos tickets for a user without the password. Some of the pPlatform SSO flows do not involve using passwords.
Standard way of achieving this is to let a service to perform Kerberos protocol transition (S4U operations). S4U2Self is allowed to any service, S4U2Proxy is privileged. This is what IPA API is using already.
> > The idea I had first was to use my extension with some keytab with permissions to request kerberos tickets on behalf of other users. > > But has FreeIPA support for OAuth2 tokens, so that I could simply exchange an OAuth2 token to a kerberos tickets? > This would be easier since I already control token issuing on the keycloak side.
You can create your own OAuth2 service with a Kerberos service keytab and then handle it there. The service will have to be explicitly allowed to perform operations on behalf of users towards IPA services.
I have integration like that done for Ahdapa, see the design and the code in the work in progress modrnizer branch here: https://github.com/abbra/freeipa/blob/modrnizer/doc/designs/webui-oauth2-log... and Ahdapa side endpoint documentation here: https://ahdapa.dev/doc/api/internal.html#credential-exchange-oidc-to-kerbero...
Ahdapa is a next generation integrated OAuth2 IdP for FreeIPA, https://forge.fedoraproject.org/freeipa/ahdapa
Note that the code in modrnizer branch is building on top of gssproxy integration for existing IPA HTTP service, so we cannot use the issued ccache outside IPA server itself: the credentials in the ccache are encrypted by gssproxy and can only be decrypted by the same gssproxy session. However, Ahdapa can be set up as a separate IdP endpoint on enrolled IPA client and joined the same IPA topology. If that is done in a way that doesn't use gssproxy, then the ccache produced by that instance's OBO endpoint would be usable beyond that service point.
If you want to try it, use COPR abbra/modrnizer for experiments.
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
Thanks a lot Alexander! Some comments:
On 2 Sep 2026, at 15:37, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
macOS has support for PKINIT: https://support.apple.com/en-euro/guide/deployment/depe6a1cda64/web
Yes, but in our case, we’ll fetch the TGT from Keycloak to be delivered via Platform SSO to the Mac. So Keycloak here is a man-in-the-middle.
GSA maintains some instructions against Active Directory which should be usable to FreeIPA as well: https://www.idmanagement.gov/implement/scl-macos/
Thanks a lot. In a quick look, what I saw is that a direct relationship between the Mac and AD. In our case, Keycloak should be able to fetch the TGT.
As long as these public keys are mapped in IPA to the users through cert mapping or by associating the public keys with the specific users, it should work.
Ok, this is a great idea worth exploring. Maybe having a key that’s signed by Keycloak, or something like that? Or, maybe, issuing private keys for the user to be stored in Keycloak, so that it can independently request authentication from the KDC? This seems an even better idea, not sure if it is defendable from a security perspective.
Best, Francis
Best, Francis
On 31 Aug 2026, at 18:44, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On Mon, 31 Aug 2026, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
But is there a way to return TGT’s?
You have to control the access to the passwordless method's credential in order to do that. For passkey this means the machine where such service runs should have access to the physical key supported by libfido2, for example. Same for smartcards. For OTP someone has to enter the pin+token value.
KDC can issue a ticket in the name of any principal because they possess the master key of the realm and have access to individual principal's keys but this is insecure to grant access to for any other entity.
Nvidia implemented something like this in Sybil for cross-realm principals but we strongly don't recommend this approach (https://github.com/NVIDIA/sybil). Sybil's code basically uses kadmin.local-like interface to perform this and is something to guard as close as krb5kdc process.
Nvidia's code will not work for passwordless methods without additional logic because for these principals there are no encryption keys in the entry.
__ Francis Augusto Medeiros-Logeay Oslo, Norway Sent from a mobile device / Enviado a partir de dispositivo móvel
On 31 Aug 2026, at 17:03, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On Mon, 31 Aug 2026, Francis Augusto Medeiros-Logeay wrote:
One quick questions: can I fetch tgt’s using this setup or just service tickets?
Only service tickets. With https://github.com/krb5/krb5/pull/1498 merged, that's all you'd need -- if they exist, they'll be prioritized.
__ Francis Augusto Medeiros-Logeay Oslo, Norway Sent from a mobile device / Enviado a partir de dispositivo móvel
>> On 31 Aug 2026, at 09:42, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote: > > On Fri, 28 Aug 2026, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote: >> >> Hi, >> >> I developed a Keycloak extension (Keycloak PSSO extension) so that users of managed macOS machines get SSO. >> The framework used - Platform Single Sign-on - also allows returning kerberos tickets. >> >> But I'm not sure how Keycloak could programmatically return kerberos tickets for a user without the password. Some of the pPlatform SSO flows do not involve using passwords. > > Standard way of achieving this is to let a service to perform Kerberos > protocol transition (S4U operations). S4U2Self is allowed to any > service, S4U2Proxy is privileged. This is what IPA API is using already. > >> >> The idea I had first was to use my extension with some keytab with permissions to request kerberos tickets on behalf of other users. >> >> But has FreeIPA support for OAuth2 tokens, so that I could simply exchange an OAuth2 token to a kerberos tickets? >> This would be easier since I already control token issuing on the keycloak side. > > You can create your own OAuth2 service with a Kerberos service keytab > and then handle it there. The service will have to be explicitly allowed > to perform operations on behalf of users towards IPA services. > > I have integration like that done for Ahdapa, see the design and the code in the > work in progress modrnizer branch here: > https://github.com/abbra/freeipa/blob/modrnizer/doc/designs/webui-oauth2-log... > and Ahdapa side endpoint documentation here: > https://ahdapa.dev/doc/api/internal.html#credential-exchange-oidc-to-kerbero... > > Ahdapa is a next generation integrated OAuth2 IdP for FreeIPA, > https://forge.fedoraproject.org/freeipa/ahdapa > > Note that the code in modrnizer branch is building on top of gssproxy > integration for existing IPA HTTP service, so we cannot use the issued > ccache outside IPA server itself: the credentials in the ccache are > encrypted by gssproxy and can only be decrypted by the same gssproxy > session. However, Ahdapa can be set up as a separate IdP endpoint on > enrolled IPA client and joined the same IPA topology. If that is done in > a way that doesn't use gssproxy, then the ccache produced by that > instance's OBO endpoint would be usable beyond that service point. > > If you want to try it, use COPR abbra/modrnizer for experiments. > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > > -- > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave@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/freeipa-users@lists.fedorahoste... > Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
What I did, which worked;
1 - Created a CA certificate 2 - imported that certificate into FreeIPA via ipa-cacert-manage 2 - Created a certificate mapping rule
So Keycloak can ask the kdc via pkinit to generate a certificate for any user, which was the goal.
Best, Francis
On 2 Sep 2026, at 15:37, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On Wed, 02 Sep 2026, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
Thanks a lot Alexander.
I think I might just drop this.
You see, Platform SSO is a framework from Apple where the IdP (in our case Keycloak) returns ID and Refresh tokens to a Mac which can be used for SSO later. Optionally, the IdP could also return kerberos tickets.
But since the authentication towards keycloak will be based on user certificates, I can’t see how these certificates could be used to issue tokens. The public keys from the user are stored in Keycloak, and the private on the mac’s Secure Enclave.
Is there a way that the KDC could use these keys so that I could simply present a signed assertion with the user’s keys to fetch a TGT?
macOS has support for PKINIT: https://support.apple.com/en-euro/guide/deployment/depe6a1cda64/web
GSA maintains some instructions against Active Directory which should be usable to FreeIPA as well: https://www.idmanagement.gov/implement/scl-macos/
As long as these public keys are mapped in IPA to the users through cert mapping or by associating the public keys with the specific users, it should work.
Best, Francis
On 31 Aug 2026, at 18:44, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On Mon, 31 Aug 2026, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
But is there a way to return TGT’s?
You have to control the access to the passwordless method's credential in order to do that. For passkey this means the machine where such service runs should have access to the physical key supported by libfido2, for example. Same for smartcards. For OTP someone has to enter the pin+token value.
KDC can issue a ticket in the name of any principal because they possess the master key of the realm and have access to individual principal's keys but this is insecure to grant access to for any other entity.
Nvidia implemented something like this in Sybil for cross-realm principals but we strongly don't recommend this approach (https://github.com/NVIDIA/sybil). Sybil's code basically uses kadmin.local-like interface to perform this and is something to guard as close as krb5kdc process.
Nvidia's code will not work for passwordless methods without additional logic because for these principals there are no encryption keys in the entry.
__ Francis Augusto Medeiros-Logeay Oslo, Norway Sent from a mobile device / Enviado a partir de dispositivo móvel
On 31 Aug 2026, at 17:03, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On Mon, 31 Aug 2026, Francis Augusto Medeiros-Logeay wrote:
One quick questions: can I fetch tgt’s using this setup or just service tickets?
Only service tickets. With https://github.com/krb5/krb5/pull/1498 merged, that's all you'd need -- if they exist, they'll be prioritized.
__ Francis Augusto Medeiros-Logeay Oslo, Norway Sent from a mobile device / Enviado a partir de dispositivo móvel
>> On 31 Aug 2026, at 09:42, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote: > > On Fri, 28 Aug 2026, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote: >> >> Hi, >> >> I developed a Keycloak extension (Keycloak PSSO extension) so that users of managed macOS machines get SSO. >> The framework used - Platform Single Sign-on - also allows returning kerberos tickets. >> >> But I'm not sure how Keycloak could programmatically return kerberos tickets for a user without the password. Some of the pPlatform SSO flows do not involve using passwords. > > Standard way of achieving this is to let a service to perform Kerberos > protocol transition (S4U operations). S4U2Self is allowed to any > service, S4U2Proxy is privileged. This is what IPA API is using already. > >> >> The idea I had first was to use my extension with some keytab with permissions to request kerberos tickets on behalf of other users. >> >> But has FreeIPA support for OAuth2 tokens, so that I could simply exchange an OAuth2 token to a kerberos tickets? >> This would be easier since I already control token issuing on the keycloak side. > > You can create your own OAuth2 service with a Kerberos service keytab > and then handle it there. The service will have to be explicitly allowed > to perform operations on behalf of users towards IPA services. > > I have integration like that done for Ahdapa, see the design and the code in the > work in progress modrnizer branch here: > https://github.com/abbra/freeipa/blob/modrnizer/doc/designs/webui-oauth2-log... > and Ahdapa side endpoint documentation here: > https://ahdapa.dev/doc/api/internal.html#credential-exchange-oidc-to-kerbero... > > Ahdapa is a next generation integrated OAuth2 IdP for FreeIPA, > https://forge.fedoraproject.org/freeipa/ahdapa > > Note that the code in modrnizer branch is building on top of gssproxy > integration for existing IPA HTTP service, so we cannot use the issued > ccache outside IPA server itself: the credentials in the ccache are > encrypted by gssproxy and can only be decrypted by the same gssproxy > session. However, Ahdapa can be set up as a separate IdP endpoint on > enrolled IPA client and joined the same IPA topology. If that is done in > a way that doesn't use gssproxy, then the ccache produced by that > instance's OBO endpoint would be usable beyond that service point. > > If you want to try it, use COPR abbra/modrnizer for experiments. > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > > -- > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave@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/freeipa-users@lists.fedorahoste... > Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Francis Augusto Medeiros-Logeay