We have several deployments of RHEL IdM consisting of a cross-forest trust with on-prem MS Active Directory. Users are able to login to the IdM resources with their Corporate AD credentials (i.e. password or existing AD ticket). Users identities (including Posix attributes) are fetched from AD along with all their group information.
Recently we've had the need to support Azure AD authentication motivated by several factors such as cloud-joined clients and FIDO2 requirements. In our case, Azure AD is partially synced with the on-prem AD through Azure AD connect.
Given our current deployments how can we achieve this? Namely, how can we support AAD authentication on top of our current authentication with our user identities sourced from on-prem AD?
The first thing that comes to mind is the external IdP integration in IPA, however given the nature of its implementation, this requires that IdP identities are managed through IdM. So what we need is effectively a way to link an IdM user (referenced by the IdP association) to an external trust user, which doesn't seem possible today.
We've tried several things, and glancing at the various software pieces of the IdM stack, this doesn't look supported. We might have missed something obvious though. Nonetheless, the main ideas we had were:
1. Add a reference to the AD trust user in the IdM user through the use of Kerberos enterprise principals. Here the idea is to define the IdM user (for IdP) with a canonical principal name set to the fully qualified trust user (i.e. ipa user-add idm_user --principal ad_user\@ad_domain --idp-user-id aad_user@aad_domain) This way SSSD could theoretically detect and use the trust user instead of the IdM one during authentication. We've personally tried this but hit a few roadblocks (and this list is probably non-exhaustive): - KDB returns KRB5KDC_ERR_WRONG_REALM on enterprise principals consisting of a trusted domain - krb5_child responder would need to return the new user translation (i.e. aname_to_lname of ad_user@ad_domain@IDM_REALM -> ad_user@ad_domain) - To support the above, sssd_krb5_localauth_plugin would need to be aware of this specific case, or be disabled to simply strip IDM_REALM as opposed to returning the IdM user back (i.e. ad_user@ad_domain@IDM_REALM -> idm_user) - pam_sss would need to set PAM_USER to the result of this translation and use the resulting name for subsequent queries (similar to user hints in certificates) - getAccountInfo would probably need tweaking too (not exactly sure)
2. Modify the trust IDView to include the IdP association and signal the fact that IdP authentication should be done through IdM and not the trusted KDC. From there, I'm not sure how this would work on the IdM KDC side since there wouldn't be any existing principal to authenticate against (maybe matching enterprise principals could be created dynamically similar to 1.)
Hopefully there exists a simple solution for this use-case already, if not, I hope that the ask was clear enough.
Finally, note that this is somewhat related to the recent talks at FOSDEM, specifically https://fosdem.org/2024/schedule/event/fosdem-2024-2587-posix-identities-out.... Also, another way around this could be to support WHfB / Cloud Kerberos trust on Linux, but this is somewhat orthogonal to the above.
Hi,
On Суб, 09 сак 2024, Jonathan Calmels via FreeIPA-users wrote:
We have several deployments of RHEL IdM consisting of a cross-forest trust with on-prem MS Active Directory. Users are able to login to the IdM resources with their Corporate AD credentials (i.e. password or existing AD ticket). Users identities (including Posix attributes) are fetched from AD along with all their group information.
Recently we've had the need to support Azure AD authentication motivated by several factors such as cloud-joined clients and FIDO2 requirements. In our case, Azure AD is partially synced with the on-prem AD through Azure AD connect.
Given our current deployments how can we achieve this? Namely, how can we support AAD authentication on top of our current authentication with our user identities sourced from on-prem AD?
The first thing that comes to mind is the external IdP integration in IPA, however given the nature of its implementation, this requires that IdP identities are managed through IdM. So what we need is effectively a way to link an IdM user (referenced by the IdP association) to an external trust user, which doesn't seem possible today.
Correct. It is not possible and will not be possible, in IPA deployment, without some external entity's help.
IPA only responsible for its own users. If authentication relies on an external identity (e.g. AD user), then authority holding information about that identity would need to be responsible for its authentication Kerberos-wise.
We've tried several things, and glancing at the various software pieces of the IdM stack, this doesn't look supported. We might have missed something obvious though. Nonetheless, the main ideas we had were:
- Add a reference to the AD trust user in the IdM user through the use
of Kerberos enterprise principals. Here the idea is to define the IdM user (for IdP) with a canonical principal name set to the fully qualified trust user (i.e. ipa user-add idm_user --principal ad_user\@ad_domain --idp-user-id aad_user@aad_domain) This way SSSD could theoretically detect and use the trust user instead of the IdM one during authentication. We've personally tried this but hit a few roadblocks (and this list is probably non-exhaustive):
- KDB returns KRB5KDC_ERR_WRONG_REALM on enterprise principals consisting of a trusted domain
- krb5_child responder would need to return the new user translation (i.e. aname_to_lname of ad_user@ad_domain@IDM_REALM -> ad_user@ad_domain)
- To support the above, sssd_krb5_localauth_plugin would need to be aware of this specific case, or be disabled to simply strip IDM_REALM as opposed to returning the IdM user back (i.e. ad_user@ad_domain@IDM_REALM -> idm_user)
- pam_sss would need to set PAM_USER to the result of this translation and use the resulting name for subsequent queries (similar to user hints in certificates)
- getAccountInfo would probably need tweaking too (not exactly sure)
This is not supported. Technically, you can use trusted domains' principals as aliases of IPA principals with
$ ipa user-add-principal ipa_user ad_user@AD.DOMAIN
If enterprise principal support is advertised by the client, a KDC would return the primary principal name in the ticket, which has to be IPA realm's principal. However, this would make impossible to login as AD user through IPA KDC because we would find that principal alias and instead of issuing a cross-realm referral handle it locally.
On top of that, IPA has no realm aliases, that's why one cannot set AD_DOMAIN as a realm for IPA principals and expect it working.
The principal aliasing should work to allow AD users to have "shadow" IPA users they'll map onto with the help of external IdP authentication, kerberos-wise. It might need more support from SSSD side, though. Obviously, these IPA users will be then the POSIX users on IPA systems as they will technically be different from AD users. One might try to map AD users to these IPA users via ID overrides but it would be a bit muddy to maintain since there will definitely be a problem with ID ranges or SSSD expectations.
A possible solution here would be to use IPA users as jump-host-style entities: - login as normal IPA users (without AD aliases), authenticated by an external IdP - do 'ksu' or 'ssh' onto AD users, with the help of .k5user mapping.
- Modify the trust IDView to include the IdP association and signal the fact that IdP authentication should be done through IdM and not the trusted KDC.
From there, I'm not sure how this would work on the IdM KDC side since there wouldn't be any existing principal to authenticate against (maybe matching enterprise principals could be created dynamically similar to 1.)
It will not work. IPA KDC does not look into ID Views at all -- those aren't considered Kerberos principals at all. Either you have a Kerberos in this realm (IPA's) or KDC will route to the known trusted realm directly or via some known trusted realm and there KDC would handle this principal.
Hopefully there exists a simple solution for this use-case already, if not, I hope that the ask was clear enough.
Finally, note that this is somewhat related to the recent talks at FOSDEM, specifically https://fosdem.org/2024/schedule/event/fosdem-2024-2587-posix-identities-out....
It would still not be possible to make what you want even if we'd treat AD users somehow as Azure/Entra ID users. The identities coming from two separate places would need to be separate. If one source already handles Kebreros for those *same* identities, the other one cannot provide the same Kerberos identity unless it is a part of the same realm.
Also, another way around this could be to support WHfB / Cloud Kerberos trust on Linux, but this is somewhat orthogonal to the above.
The 'cloud Kerberos' thing is pretty much a setup where Entra ID would become a yet another (read-only) KDC for the on-premise Active Directory. So in this case two requirements would be put towards IPA hosts:
- IPA host needs to be registered against Entra ID - IPA host would need to handle PRT and other things to perform user authentication.
While that would be eventually possible, I hope, it would mean use of a completely different mechanism to obtain actual Kerberos ticket for the user, one that avoids talking to IPA KDC for this purpose. E.g. we are back to dealing with AD DCs issuing that user's ticket.
Thanks for the detailed answer, glad we didn't miss anything obvious. I just want to add a bit more clarification on what we were proposing
IPA only responsible for its own users. If authentication relies on an external identity (e.g. AD user), then authority holding information about that identity would need to be responsible for its authentication Kerberos-wise.
This is not supported. Technically, you can use trusted domains' principals as aliases of IPA principals with
$ ipa user-add-principal ipa_user ad_user(a)AD.DOMAIN
If enterprise principal support is advertised by the client, a KDC would return the primary principal name in the ticket, which has to be IPA realm's principal. However, this would make impossible to login as AD user through IPA KDC because we would find that principal alias and instead of issuing a cross-realm referral handle it locally.
I understand that, in the case I described, technically IPA doesn't rely on an external identity. The principal alias is still part of the IPA realm, it's just that we "encode" the trusted domain in it, it doesn't use the AD realm at all. All the magic happens in SSSD.
On AD my user principal is: ad_user@AD.DOMAIN On IPA my user principal is: ad_user@ad.domain@IPA.DOMAIN (the canonical one, it can still have the standard ipa_user@IPA.DOMAIN as an alias)
Nothing changes here, the AD user authenticates through the referral, the IPA user authenticates normally in the IPA realm either with "kinit -C ipa_user" or "kinit -E ad_user@ad_domain" and gets a TGT from IPA.
Where it changes is on the SSSD side. What we want is effectively something akin to: auth_provider = ipa (for IdP) id_provider = ad (but really we want ipa here to do the idview)
There would be an option so that SSSD could handle this enterprise principal encoding and thus switch to the shadow user. In pseudo code, it would go something like this when the IPA user authenticates:
pam_authenticate(ipa_user) kinit(ipa_user@IPA_REALM) // this gets canonicalized to "ad_user@ad.domain@IPA.DOMAIN" aname_to_localname(ad_user@ad.domain@IPA.DOMAIN) // this gives us "ad_user@ad.domain" pam_set_item(PAM_USER, "ad_user@ad.domain") // this effectively switches the identity from the IPA user to the AD one going forward ...
So the user is authenticated against IPA with a TGT, but its username, UID, GIDs, etc are fetched from AD. The Posix information in IPA are never used (i guess they would if you wanted to by turning off canonicalization)
I realize this is pretty hacky, but in theory this could work right?
A possible solution here would be to use IPA users as jump-host-style entities:
- login as normal IPA users (without AD aliases), authenticated by an external IdP
- do 'ksu' or 'ssh' onto AD users, with the help of .k5user mapping.
Um yeah this could work but this not ideal for users. They would have to be aware of those two different accounts and how to manage them (shell, home dir, etc)
On Суб, 09 сак 2024, Jonathan Calmels via FreeIPA-users wrote:
Thanks for the detailed answer, glad we didn't miss anything obvious. I just want to add a bit more clarification on what we were proposing
IPA only responsible for its own users. If authentication relies on an external identity (e.g. AD user), then authority holding information about that identity would need to be responsible for its authentication Kerberos-wise.
This is not supported. Technically, you can use trusted domains' principals as aliases of IPA principals with
$ ipa user-add-principal ipa_user ad_user(a)AD.DOMAIN
If enterprise principal support is advertised by the client, a KDC would return the primary principal name in the ticket, which has to be IPA realm's principal. However, this would make impossible to login as AD user through IPA KDC because we would find that principal alias and instead of issuing a cross-realm referral handle it locally.
I understand that, in the case I described, technically IPA doesn't rely on an external identity. The principal alias is still part of the IPA realm, it's just that we "encode" the trusted domain in it, it doesn't use the AD realm at all. All the magic happens in SSSD.
On AD my user principal is: ad_user@AD.DOMAIN On IPA my user principal is: ad_user@ad.domain@IPA.DOMAIN (the canonical one, it can still have the standard ipa_user@IPA.DOMAIN as an alias)
Nothing changes here, the AD user authenticates through the referral, the IPA user authenticates normally in the IPA realm either with "kinit -C ipa_user" or "kinit -E ad_user@ad_domain" and gets a TGT from IPA.
Where it changes is on the SSSD side. What we want is effectively something akin to: auth_provider = ipa (for IdP) id_provider = ad (but really we want ipa here to do the idview)
What we have now in SSSD for this case is
id_provider = ad, because AD domain is a subdomain of IPA auth_provider = ad
The latter is the same krb5 auth provider in disguise so it will accept any pre-authentication method negotiated between Kerberos client and KDC. But it would use a different KDC (AD DC) to do its operations. I am not sure you can change/force it to a different one right now except hardcoding IPA KDC in the AD realm configuration.
There would be an option so that SSSD could handle this enterprise principal encoding and thus switch to the shadow user. In pseudo code, it would go something like this when the IPA user authenticates:
pam_authenticate(ipa_user) kinit(ipa_user@IPA_REALM) // this gets canonicalized to "ad_user@ad.domain@IPA.DOMAIN" aname_to_localname(ad_user@ad.domain@IPA.DOMAIN) // this gives us "ad_user@ad.domain" pam_set_item(PAM_USER, "ad_user@ad.domain") // this effectively switches the identity from the IPA user to the AD one going forward ...
So the user is authenticated against IPA with a TGT, but its username, UID, GIDs, etc are fetched from AD. The Posix information in IPA are never used (i guess they would if you wanted to by turning off canonicalization)
I realize this is pretty hacky, but in theory this could work right?
Probably. I'd leave that to answer to Sumit or other SSSD developers on this list.
If you are using RHEL subscription, it might make sense to open a customer case and provide more details there, along with a request for enhancement and point to this thread so that we can connect the dots and get this request analyzed faster from engineering developemnt priorities point of view.
A possible solution here would be to use IPA users as jump-host-style entities:
- login as normal IPA users (without AD aliases), authenticated by an external IdP
- do 'ksu' or 'ssh' onto AD users, with the help of .k5user mapping.
Um yeah this could work but this not ideal for users. They would have to be aware of those two different accounts and how to manage them (shell, home dir, etc)
It would work today without much changes.
Am Sun, Mar 10, 2024 at 04:46:45PM +0200 schrieb Alexander Bokovoy via FreeIPA-users:
On Суб, 09 сак 2024, Jonathan Calmels via FreeIPA-users wrote:
Thanks for the detailed answer, glad we didn't miss anything obvious. I just want to add a bit more clarification on what we were proposing
IPA only responsible for its own users. If authentication relies on an external identity (e.g. AD user), then authority holding information about that identity would need to be responsible for its authentication Kerberos-wise.
This is not supported. Technically, you can use trusted domains' principals as aliases of IPA principals with
$ ipa user-add-principal ipa_user ad_user(a)AD.DOMAIN
If enterprise principal support is advertised by the client, a KDC would return the primary principal name in the ticket, which has to be IPA realm's principal. However, this would make impossible to login as AD user through IPA KDC because we would find that principal alias and instead of issuing a cross-realm referral handle it locally.
I understand that, in the case I described, technically IPA doesn't rely on an external identity. The principal alias is still part of the IPA realm, it's just that we "encode" the trusted domain in it, it doesn't use the AD realm at all. All the magic happens in SSSD.
On AD my user principal is: ad_user@AD.DOMAIN On IPA my user principal is: ad_user@ad.domain@IPA.DOMAIN (the canonical one, it can still have the standard ipa_user@IPA.DOMAIN as an alias)
Nothing changes here, the AD user authenticates through the referral, the IPA user authenticates normally in the IPA realm either with "kinit -C ipa_user" or "kinit -E ad_user@ad_domain" and gets a TGT from IPA.
Where it changes is on the SSSD side. What we want is effectively something akin to: auth_provider = ipa (for IdP) id_provider = ad (but really we want ipa here to do the idview)
What we have now in SSSD for this case is
id_provider = ad, because AD domain is a subdomain of IPA auth_provider = ad
The latter is the same krb5 auth provider in disguise so it will accept any pre-authentication method negotiated between Kerberos client and KDC. But it would use a different KDC (AD DC) to do its operations. I am not sure you can change/force it to a different one right now except hardcoding IPA KDC in the AD realm configuration.
There would be an option so that SSSD could handle this enterprise principal encoding and thus switch to the shadow user. In pseudo code, it would go something like this when the IPA user authenticates:
pam_authenticate(ipa_user)
Hi,
you have to keep in mind the most login/authentication applications like e.g. /bin/login, sshd etc., will do a user lookup with the user name first, so with `id_provider = ad` AD must be able to resolve the user name `ipa_user` and return a proper user entry ideally with the userPrincipalName attribute set.
Given that I would like to suggest to tr< to do it the other way round, use `id_provider = ad` and `auth_provider = krb5` (you can try `auth_provider = ipa` as well but I sould suggest `krb5` for initial testing because it has no dependencies to the id_provider, I'm not sure where with respect to the IPA auth_provider).
Now set userPrincipalName in AD to `ipa_user@IPA_REALM`. This will most probably not work via the `User logon name` in the `Account` tab of the User properties because you would have to add the IPA realm to the alternative domain suffixes which might not work if there is a trusted domain with the same name. But you can set it directly via the `Attribute Editor` tab. There is a fair chance that this will break the user for AD usage but I'm not sure here, you have to test it. If it break you can try to add the principal in a less critical attribute, e.g. `description` and set the `ldap_user_principal` option in the [domain/...] section in sssd.conf to thus attribute.
Now when looking up `ad_user@ad.domain` SSSD should see the principal `ipa_user@IPA.REALM` and the auth_provider should try to get the Kerberos ticket from the IPA realm.
HTH
bye, Sumit
kinit(ipa_user@IPA_REALM) // this gets canonicalized to "ad_user@ad.domain@IPA.DOMAIN" aname_to_localname(ad_user@ad.domain@IPA.DOMAIN) // this gives us "ad_user@ad.domain" pam_set_item(PAM_USER, "ad_user@ad.domain") // this effectively switches the identity from the IPA user to the AD one going forward ...
So the user is authenticated against IPA with a TGT, but its username, UID, GIDs, etc are fetched from AD. The Posix information in IPA are never used (i guess they would if you wanted to by turning off canonicalization)
I realize this is pretty hacky, but in theory this could work right?
Probably. I'd leave that to answer to Sumit or other SSSD developers on this list.
If you are using RHEL subscription, it might make sense to open a customer case and provide more details there, along with a request for enhancement and point to this thread so that we can connect the dots and get this request analyzed faster from engineering developemnt priorities point of view.
A possible solution here would be to use IPA users as jump-host-style entities:
- login as normal IPA users (without AD aliases), authenticated by an external IdP
- do 'ksu' or 'ssh' onto AD users, with the help of .k5user mapping.
Um yeah this could work but this not ideal for users. They would have to be aware of those two different accounts and how to manage them (shell, home dir, etc)
It would work today without much changes.
-- / 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://pagure.io/fedora-infrastructure/new_issue
On Суб, 09 сак 2024, Jonathan Calmels via FreeIPA-users wrote:
If you are using RHEL subscription, it might make sense to open a customer case and provide more details there, along with a request for enhancement and point to this thread so that we can connect the dots and get this request analyzed faster from engineering developemnt priorities point of view.
Yeah, we did. I just wanted to get more precision and who knows it might help someone else by having it here too.
It would work today without much changes.
Yes, I'll experiment with this in the meantime, see how the user experience is.
Am Sun, Mar 10, 2024 at 04:46:45PM +0200 schrieb Alexander Bokovoy via FreeIPA-users:
you have to keep in mind the most login/authentication applications like e.g. /bin/login, sshd etc., will do a user lookup with the user name first, so with `id_provider = ad` AD must be able to resolve the user name `ipa_user` and return a proper user entry ideally with the userPrincipalName attribute set.
I was about to say, I looked into it more and while it would work with "login", you're right that "sshd" goes through NSS first and never relies on the PAM user so this wouldn't work.
Given that I would like to suggest to tr< to do it the other way round, use `id_provider = ad` and `auth_provider = krb5` (you can try `auth_provider = ipa` as well but I sould suggest `krb5` for initial testing because it has no dependencies to the id_provider, I'm not sure where with respect to the IPA auth_provider).
Now set userPrincipalName in AD to `ipa_user@IPA_REALM`. This will most probably not work via the `User logon name` in the `Account` tab of the User properties because you would have to add the IPA realm to the alternative domain suffixes which might not work if there is a trusted domain with the same name. But you can set it directly via the `Attribute Editor` tab. There is a fair chance that this will break the user for AD usage but I'm not sure here, you have to test it. If it break you can try to add the principal in a less critical attribute, e.g. `description` and set the `ldap_user_principal` option in the [domain/...] section in sssd.conf to thus attribute.
Now when looking up `ad_user(a)ad.domain` SSSD should see the principal `ipa_user(a)IPA.REALM` and the auth_provider should try to get the Kerberos ticket from the IPA realm.
Yeah, this would probably work. The problem with that is that it breaks the AD auth, so I couldn't have both at the same time (e.g. a user has a domain-joined workstation and cloud-joined laptop and potentially needs both auth schemes). Ideally I would want SSSD to figure this out automatically based on some attribute in the IDView. Basically, if auth is set to "idp", read this custom attribute in the view and perform auth against the shadow user in IPA. Otherwise, perform the usual AD referral. Having said that, I'm not even sure if one can request a specific preauth method today in SSSD.
Having said that, I'm not even sure if one can request a specific preauth method today in SSSD.
And by that I mean as a hint before the actual AS_REQ. IIUC this isn't straightforward to do currently because: - The PAM conversation happens after the AS_REP and depends on the supported auth methods - There is no password fallback with the idp auth
The other way would be to contact both KDC and somehow keep track of both until you get the user input, but it gets tricky
On Аўт, 12 сак 2024, Jonathan Calmels via FreeIPA-users wrote:
Having said that, I'm not even sure if one can request a specific preauth method today in SSSD.
And by that I mean as a hint before the actual AS_REQ. IIUC this isn't straightforward to do currently because:
- The PAM conversation happens after the AS_REP and depends on the
supported auth methods
- There is no password fallback with the idp auth
The other way would be to contact both KDC and somehow keep track of both until you get the user input, but it gets tricky
There is no explicit way in MIT Kerberos client side to influence which pre-auth mechanism is used other than forcing configuration externally to avoid certain choices. There is no API to control what happens at pre-authentication. All methods available to both KDC and the client will be tried one by one by the client code until they produce an answer that can be sent out to the KDC.
This gives us one option, though: an application may register prompt handlers that a pre-auth method may use to query a user for a detail to complete the pre-auth and this is something you can influence by choosing to not respond to a prompt request. This is something that was broken in SSSD until the past week.
If you have idp or passkey method enabled alongside with a password, SSSD did not fall. This has been fixed just recently upstream: https://github.com/SSSD/sssd/issues/7152
We also have a very crude way: don't provide FAST channel, this removes KDC response for OTP, RADIUS, external IdP, and passkey methods. This is, obviously, not what you'd want for this situation. Similarly, one can redefine plugins_base_dir and then play with clpreauth in [plugins] section to force not using or, instead, using a particular plugin.
All these aren't the things you are looking for. ;)
So, I got to play around with this and implemented the "workaround" we discussed. I ended up using ksu with sshd ForceCommand to make it more seamless for users. Here are some of the issues I faced though:
1. IdP requires FAST and I'm not sure how I'm supposed to configure that correctly in SSSD since I need it for both AD and IPA and can't set two different krb5_fast_principal. With one, it could work with cross-realm requests I suppose but it's not ideal. SPAKE 2FA would also be nice here but doesn't seem supported yet?
2. I need two distinct usernames per user, e.g. myuser and myuser_idp. I tried using the same usernames for both AD and IPA users but SSSD gets really confused depending on what's cached. We use shortnames with a domain resolution order, so I thought having both usernames alias could work and SSSD would just prefer the IPA one if it exists. On the bright side, this allows users to pick the authentication method depending on which username they choose, so there is that
3. SSSD localauth plugin gets in the way when it comes to remapping both principals to the AD user (e.g. for ksu authorization). The IPA principal gets mapped to myuser_idp and one cannot write custom aname2lname rules because SSSD is always called first in the krb5 module order. Only way I found is to disable all the SSSD snippet generation and write my own rules but I would rather avoid that.
4. IdP auth doesn't work when the SSSD PAM responder is socket activated. I haven't really looked into why it fails, but this caught me off guard at first.
I'm not sure if I should file separate bugs for those, but after all of that it works.
Overall, I would still prefer if there was a way to do this natively in SSSD somehow (i.e. external users shadowed by IPA auth). Having said that, I understand that this is quite challenging.
On Пят, 15 сак 2024, Jonathan Calmels via FreeIPA-users wrote:
So, I got to play around with this and implemented the "workaround" we discussed. I ended up using ksu with sshd ForceCommand to make it more seamless for users. Here are some of the issues I faced though:
- IdP requires FAST and I'm not sure how I'm supposed to configure
that correctly in SSSD since I need it for both AD and IPA and can't set two different krb5_fast_principal. With one, it could work with cross-realm requests I suppose but it's not ideal. SPAKE 2FA would also be nice here but doesn't seem supported yet?
No, 2FA SPAKE is not implemented. Even if it would be implemented, it still needs FAST channel wrapping.
- I need two distinct usernames per user, e.g. myuser and myuser_idp.
I tried using the same usernames for both AD and IPA users but SSSD gets really confused depending on what's cached. We use shortnames with a domain resolution order, so I thought having both usernames alias could work and SSSD would just prefer the IPA one if it exists. On the bright side, this allows users to pick the authentication method depending on which username they choose, so there is that
I think it is also helpful from auditing purposes, a poor man's replacement of exposing auth indicators at an application level or in KDC logs. Explicitly different user name helps to hilight the fact that this user is 2FA-authenticated for login.
- SSSD localauth plugin gets in the way when it comes to remapping
both principals to the AD user (e.g. for ksu authorization). The IPA principal gets mapped to myuser_idp and one cannot write custom aname2lname rules because SSSD is always called first in the krb5 module order. Only way I found is to disable all the SSSD snippet generation and write my own rules but I would rather avoid that.
Feel free to propose a specific algorithm to extend the plugin.
- IdP auth doesn't work when the SSSD PAM responder is socket
activated. I haven't really looked into why it fails, but this caught me off guard at first.
I think it should work. Debug logs would help -- please open an issue, may be upstream for SSSD, with debug logs to show what's wrong. That said, I think main responders (nss, pam) should not use socket activation. Debian packaging was wrong in defaulting to this.
I'm not sure if I should file separate bugs for those, but after all of that it works.
Overall, I would still prefer if there was a way to do this natively in SSSD somehow (i.e. external users shadowed by IPA auth). Having said that, I understand that this is quite challenging.
Glad that it worked overall. Please file bugs, we can look at what could be improved. This is indeed a challenging area and a certain level of hand-helding is still needed so that admins wouldn't go too wild. ;)
freeipa-users@lists.fedorahosted.org