Am Tue, Nov 19, 2024 at 02:37:13PM -0600 schrieb Spike White via sssd-users: > Sssd experts, > > > We have an app that’s having AD users connect to their app -- users that > don’t have UIDs and GIDs stored in AD. They’re allowing these remote > connections for DB queries and our cybersecurity team wants to see the > username/ip addresses from which these queries originate. > > That is, the app team has this. In /etc/pam.d/krb5 file: > > > > auth sufficient /usr/lib64/security/pam_krb5.so no_user_check realm= > APAC.COMPANY.COM try_first_pass > auth sufficient /usr/lib64/security/pam_krb5.so no_user_check realm= > EMEA.COMPANY.COM try_first_pass > auth sufficient /usr/lib64/security/pam_krb5.so no_user_check realm= > AMER.COMPANY.COM use_first_pass > > > Our company has 3 regional AD domains. AMER, EMEA, APAC. > > > Here’s the logs from /var/log/secure. Cybersecurity is happy with these > logs, because they give the incoming AD account and the remote IP address. > > > Nov 19 07:17:26 cepnlmemf01 memsqld[159234]: pam_krb5(krb5:auth): unknown > option no_user_check > > Nov 19 07:17:26 cepnlmemf01 memsqld[159234]: pam_krb5(krb5:auth): > authentication failure; logname=karunakanti_chiranje uid=7202893 > euid=7202893 tty= ruser= rhost=10.107.18.78 > > Nov 19 07:17:26 cepnlmemf01 memsqld[159234]: pam_krb5(krb5:auth): unknown > option no_user_check > > Nov 19 07:17:26 cepnlmemf01 memsqld[159234]: pam_krb5(krb5:auth): > authentication failure; logname=karunakanti_chiranje uid=7202893 > euid=7202893 tty= ruser= rhost=10.107.18.78 > > Nov 19 07:17:26 cepnlmemf01 memsqld[159234]: pam_krb5(krb5:auth): unknown > option no_user_check > > Nov 19 07:17:26 cepnlmemf01 memsqld[159234]: pam_krb5(krb5:auth): user > karunakanti_chiranje authenticated as karunakanti_chira...@amer.company.com > > Nov 19 07:17:26 cepnlmemf01 memsqld[159234]: pam_krb5(krb5:account): > unknown option no_user_check > > > > This approach is functional, but has several drawbacks. > > 1. If the incoming user is in AMER, this login will fail twice (APAC, > EMEA), then finally succeed for u...@amer.company.com > > 2. Pam_krb5 has no caching, so every DB query results in hitting the > AD domain controllers. (Multiple times, if user in EMEA or AMER). > > > > We’re using pam_sss successfully for ssh logins. It works great! With the > caveat that all AD users and groups have to have a UID and GID. Otherwise > the AD user cannot login via ssh. They have to be realm permitted also > (usually by group). > > > Can the above pam file be replaced by similar pam_sss.so invocations? > I.e., at which PAM phase is the UID and GID required? Is it required in > the auth phase? Account phase? Or only in the session phase?
Hi, PAM does not need UIDs or GIDs at all, it is typically the application, e.g. sshd, which checks for the existence of a user with `getpwnam()` or similar commands which required UIDs and GIDs. To allow the use-case you've described above SSSD has `domain_type = application`, see man sssd.conf for details. To select this application domain in the PAM configuration of the application you can use the `domains` option of pam_sss.so, see man pam_sss for details. HTH bye, Sumit > > > > Spike > -- > _______________________________________________ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > 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/sssd-users@lists.fedorahosted.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org 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/sssd-users@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
