On Fri, Sep 12, 2025 at 9:20 AM frank rust via sssd-users
<sssd-users@lists.fedorahosted.org> wrote:
> I have to filter the access to a system to allow several hundred
> users out of a ldap server with several 10 thousands of users.
>
> How would I do this? I think the way to define a simple filter line
>
> ```
> ldap_user_search_filter = ( | (uid=user_1)(uid=user_2)(uid=user_7470)(...) )
> ```
>
> is not possible for the amount of users.
>
> I have no possibility to create a new group in ldap or add anything
> else, I only have read access.
>
> What can I do?
You might be conflating visibility (e.g., whether `getent passwd` will
succeed for a user) with authorization. If all you need to do is
limit the LDAP-based users who are permitted to login, then there are
multiple pam(8) modules that can do this.
For example, if all local users (listed in the `/etc/passwd` file)
should be permitted to login, and you only need to restrict users
mapped from LDAP via sssd, then create the file:
/etc/security/permitted-users.txt
List all LDAP users who should be permitted to login, one per line,
with no leading or trailing whitespace.
(This is an ideal format for maintaining via Puppet/Ansible/Chef, or
other configuration management tools of your choice.)
Then append these two lines (beware unhelpful email line wrapping!) to
the PAM account stack:
account sufficient pam_localuser.so
account required pam_listfile.so item=user sense=allow
file=/etc/security/permitted-users.txt onerr=fail
In English, if the user is a local user, the pam_localuser.so module
succeeds (which permits the user to login) and ends the stack.
Otherwise, if the user is listed in the
`/etc/security/permitted-users.txt` file, the pam_listfile.so module
succeeds. As long as no previous required account modules failed,
this will permit the user to login. If the user is *not* listed in
the `/etc/security/permitted-users.txt` file, then the pam_listfile.so
module will fail, which (because it is a required module) will fail
the account stack, and thus deny the user access.
You can use pam_access.so instead of pam_listfile.so, but if (and only
if) you do not enable the sssd *use_fully_qualified_names* option.
(The access.conf(5) syntax assigns special meaning to the `@`
character when it appears in the user/group field, so you cannot place
fully-qualified users into access.conf.)
If you can go the pam_access.so route, then you *might* be able to get
away with using (e.g.) authselect(8) to maintain your PAM stack,
instead of having to maintain custom configuration. (At our site, we
require additional complexity (e.g. MFA) in our PAM stack that breaks
authselect’s tiny little mind, so we long ago abandoned using
automated tools to maintain the PAM stack.)
I know that many sysadmins want to run shrieking from PAM (the PAM
stack is essentially account management assembler language), but if
you must implement nontrivial authentication and/or authorization
conditions, it’s arguably the best tool for the job.
--
_______________________________________________
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
