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(a)AD.DOMAIN
On IPA my user principal is: ad_user\@ad.domain(a)IPA.DOMAIN (the canonical one, it can
still have the standard ipa_user(a)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(a)IPA.DOMAIN"
aname_to_localname(ad_user\@ad.domain(a)IPA.DOMAIN) // this gives us
"ad_user(a)ad.domain"
pam_set_item(PAM_USER, "ad_user(a)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