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.