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-le...@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.fedorahosted.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
