Score:1

Cron not working after pam customization to check groups

in flag

I need help with a PAM configuration.

I've a Debian 11.5 machine with kerberos connected to an MS AD server. I want to configure the machine in order to allow some AD user to login, filtering them by AD group membership. My AD users uids starts from 3000. The local machine users have to login as usual.

So I edit the PAM configuration in /etc/pam.d/common-auth here the entire body:

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

After congratulating with myself because the configuration seemes to work good I see the cron service stops working. When a job has to start I have an error instead:

Failure setting user credentials

and the job is not called at all.

What I tried to do

I tried to change the configuration and I see that cron works good if I remove the second pam_deny.so row. I tried to add the "debug" option to the modules but there aren't logs when cron runs.

Thank you for your time and patience in advance.

EDIT:

After some tests i changed my configuration to this:

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

And it seems to work good, the key change was to set the pam_unix as "success=5", I think this will avoid further checks against the uid which was the one who failed during the cron's run.

But i don't know if this is the better and safest solution.

cn flag
I'm a bit surprised that you're using both winbind and sssd at the same time. Do all the jobs from all users fail? including root? Including /etc/cron.* jobs? What happens if you run "crontab -l" from root or a local user? an AD user?
Lorenzo Sorace avatar
in flag
@wazoox after some trying it seems to work if I just put the pam_unix check as "sufficient". Actually I don't need sss and krb5 line. With "sufficient" I don't need the uid check too (I think it was the one who fails with the cronjobs).
Lorenzo Sorace avatar
in flag
@wazoox the crontab -l was working good with local and AD's users. As I can see the /etc/cron.* failed as well. The root's cronjobs failed too.
c4f4t0r avatar
nl flag
Suse and Redhat family has tools to not edit pam manually, I think Debian has the same too pam-auth-update
cn flag
If the first line succeeds, then it skips 5 lines directly to the last one (pam_permit). It only checks the groups if going through winbind. If that's what you want it's OK :)
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.