In which PAM phase are the UID/GID in AD required?

[Spike White]

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 [e-mail]

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 [e-mail]

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?

Spike

[Sumit Bose]

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 [e-mail]
>
> 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.
>  If the incoming user is in AMER, this login will fail twice (APAC,
>
> EMEA), then finally succeed for [e-mail]
>  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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail].o...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue