Hello everyone,
I have a nice and working IPA v3 with trust to AD set up. On one of our smtp servers (with authentication against different LDAP via sssd) I have set a saslauthd service which binds to our ipa server on 636/tcp using credentials and certificate issued for specific ipa user. Sasl works perfectly well as long as I try to authenticate ipa users (who can be found with ipa-user command) even with 2FA enabled, yet it fails if I try to authenticate AD user who was 'imported' into IPA via 'ipa group-add-member' command and 'external group as a member of posix group' method. AD users can be seen using 'id' command and can be allowed to log on linux servers, execute sudo commands based on hbac rules and so on. Even freeradius with OTP works. Alas, no sasl. I know that probably it would be wiser to set sasl to ask AD directly, but I am just curious if it is possible to make it work via IPA.
Best regards
Mariusz Stysiak via FreeIPA-users wrote:
Hello everyone,
I have a nice and working IPA v3 with trust to AD set up. On one of our smtp servers (with authentication against different LDAP via sssd) I have set a saslauthd service which binds to our ipa server on 636/tcp using credentials and certificate issued for specific ipa user. Sasl works perfectly well as long as I try to authenticate ipa users (who can be found with ipa-user command) even with 2FA enabled, yet it fails if I try to authenticate AD user who was 'imported' into IPA via 'ipa group-add-member' command and 'external group as a member of posix group' method. AD users can be seen using 'id' command and can be allowed to log on linux servers, execute sudo commands based on hbac rules and so on. Even freeradius with OTP works. Alas, no sasl. I know that probably it would be wiser to set sasl to ask AD directly, but I am just curious if it is possible to make it work via IPA.
You need to use SASL directly. IPA doesn't authenticate to AD, the user does. Then IPA resources are available to them via trust.
rob
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? 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?)
I understand that my question might seem purely academic, but a good understanding of how it all works under the hood never hurts and could save a lot of time one day.
regards,
M
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/htm...
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).
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Mariusz Stysiak -
Rob Crittenden