> 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. -- _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
