On ti, 10 touko 2022, Mariusz Stysiak via FreeIPA-users wrote:
Rob, thank you for your prompt answer.
Could you elaborate a bit, just so I could have a proper understanding
of what is going on when authentication against IPA happens?
I thought that when AD user tries to log into Linux server,
credentials
are sent to IPA, then forwarded to AD and IPA trusts the answer
received from AD controller (user authenticated or not). In the next
step, basing on its own resources (e.g. group privileges), IPA
evaluates if this particular user (already authenticated by the AD) is
allowed to log into the server X. Is this correct?
No, it is not correct. Authentication always happens at the source of
truth. For AD users that's AD DCs. When you log through SSH or locally,
SSSD on the host attempts to obtain Kerberos ticket using the creds you
have provided as a part of PAM conversation. This happens directly from
the host you are trying to access, IPA servers aren't involved in
authenticating AD users.
The following section in RHEL documentation shows the flow:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/...
If so, I thought, IPA gets the information 'user authenticated or
not'
even if authentication is done by the AD and based on this information
should be able to answer questions sent by saslauthd. Or maybe
saslauthd is more like a 'ldapsearch + password check' and its
requests are answered only within specific LDAP set in the sasl config
(and since he LDAP is not the IPA part that forwards the auth request
to the AD, it cannot get any info from it?)
Information about AD users is not stored in IPA LDAP.
If you'd use PAM to authenticate inside saslauthd and your PAM stack for
the specific service would include pam_sss, you'd get the same behavior
like 'sshd' PAM service does.
E.g. use SASLAUTHD_OPTS="-a pam", then make sure your SASL app's PAM
configuration includes system-auth, then HBAC rules allow to access to
your PAM service (e.g. smtp HBAC service is allowed to access on the
specific host by those users).
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland