我需要有关 PAM 配置的帮助。
我有一台安装了 kerberos 的 Debian 11.5 机器，连接到 MS AD 服务器。我想配置这台机器，以允许某些 AD 用户登录，并按 AD 组成员身份筛选他们。我的 AD 用户 uid 从 3000 开始。本地机器用户必须照常登录。
因此我在这里编辑 /etc/pam.d/common-auth 中的 PAM 配置的全部内容：
auth [success=4 default=ignore] pam_unix.so nullok_secure try_first_pass
auth [success=3 default=ignore] pam_krb5.so minimum_uid=3000
auth [success=2 default=ignore] pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass
auth [success=1 default=ignore] pam_sss.so use_first_pass
# here's the fallback if no module succeeds
auth requisite pam_deny.so
# check the groups
auth [success=3 default=ignore] pam_succeed_if.so uid < 3000 quiet_success
auth [success=2 default=ignore] pam_succeed_if.so user ingroup mymachineadmins
auth [success=1 default=ignore] pam_succeed_if.so user ingroup mymachineendusers
auth requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth required pam_permit.so debug
在自我庆幸配置似乎运行良好之后，我发现 cron 服务停止工作了。当需要启动一项工作时，我却收到错误：
设置用户凭据失败
并且这项工作根本没有被调用。
我尝试做的
我尝试更改配置，发现如果删除第二行 pam_deny.so，cron 就可以正常工作。我尝试向模块添加“调试”选项，但 cron 运行时没有日志。
提前感谢您的时间和耐心。
编辑：
经过一些测试后，我将配置更改为：
auth [success=5 default=ignore] pam_unix.so nullok_secure try_first_pass debug
auth [success=1 default=ignore] pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass debug
# here's the fallback if no module succeeds
auth requisite pam_deny.so debug
# check the groups
auth [success=2 default=ignore] pam_succeed_if.so user ingroup mymachineadmins debug
auth [success=1 default=ignore] pam_succeed_if.so user ingroup mymachineendusers debug
auth requisite pam_deny.so debug
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth required pam_permit.so debug
而且它似乎运行良好，关键的变化是将 pam_unix 设置为“success=5”，我认为这将避免对 cron 运行期间失败的 uid 进行进一步检查。
但我不知道这是否是更好、最安全的解决方案。