Score:0

CRON[83463]: Failure setting user credentials

us flag

I have a number of docker containers, all set up mostly identically, which successfully use cron to run nightly backup jobs.

I have another container, set up mostly identically, which tries, and fails, to use cron to run a nightly backup job.

I installed rsyslog to get more information, and when cron runs root's crontab I see the following entry in the syslog file:

CRON[83463]: Failure setting user credentials

The one difference between this container and all the others is that this one allows users to log in using LDAP. It has the following extra lines in the Dockerfile:

RUN echo '*;*;*;Al0000-2400;svn' >> /etc/security/group.conf
COPY pam_group /usr/share/pam-configs/groups
RUN echo "session required        pam_mkhomedir.so skel=/etc/skel umask=077" >> /etc/pam.d/common-session
RUN sed -i 's#\(.*pam_ldap.so.*\)#auth    required     pam_group.so\n\1#' /etc/pam.d/common-auth
RUN sed -i 's#^passwd:.*#passwd:  files ldap systemd#;s#^group:.*#group:   files ldap systemd#;s#^shadow:.*#shadow:  files ldap#' /etc/nsswitch.conf

The pam_group file looks like:

Name: activate /etc/security/group.conf
Default: yes

Priority: 900
Auth-Type: Primary Auth:
        required                        pam_group.so

Clearly, something about setting up the LDAP, and trying to ensure that all users get added to the svn group (which doesn't work at all) broke the root user session for cron.

I have looked all over the internet, but not found this specific error. I have tried related solutions, but nothing works.

UPDATE:

pam.d/common-auth looks like:

auth    [success=2 default=ignore]  pam_unix.so nullok_secure
auth    required     pam_group.so
auth    [success=1 default=ignore]  pam_ldap.so use_first_pass
# here's the fallback if no module succeeds
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
# and here are more per-package modules (the "Additional" block)
auth    optional            pam_cap.so 

pam.d/cron looks like:

@include common-auth

# Sets the loginuid process attribute
session    required     pam_loginuid.so

# Read environment variables from pam_env's default files, /etc/environment
# and /etc/security/pam_env.conf.
session       required   pam_env.so

# In addition, read system locale information
session       required   pam_env.so envfile=/etc/default/locale

@include common-account
@include common-session-noninteractive 

# Sets up user limits, please define limits for cron tasks
# through /etc/security/limits.conf
session    required   pam_limits.so
Score:1
pk flag

Your problem is probably that the root user isn't in LDAP; you'll need to include pam_unix.so in /etc/pam.d/cron somehow.

For example:

auth    [success=2 default=ignore]      pam_unix.so nullok_secure
@include common-auth

Assuming that common-auth begins something like this:

auth    [success=1 default=ignore]      pam_ldap.so
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so
us flag
I added more information to the question. I think I have what you suggest in that I have a pam_unix.so "auth" line before the LDAP lines, in a file (common-auth) which is included in the pam.d/cron file.
András Korn avatar
pk flag
The `success=2` bit is wrong. It will skip to pam_deny.so. Make it `success=3`.
us flag
Thanks for the help and advice. I'll have a go at it tomorrow. So I can learn more I have a question. Your example gives `"success=2"` and that's the default too. What does the number signify and why should it be 3?
András Korn avatar
pk flag
The number tells PAM how many of the next modules in this stack to skip if the outcome reported by this module is "success". It's a conditional `goto`, if you will. In your config, `success=2` causes `pam_group` and `pam_ldap` to be skipped if `pam_unix` succeeds. You also want to skip `pam_deny`, because that's just a catch-all to deny everything. The idea with the `success=X` rules is to skip past `pam_deny`, to any optional modules.
us flag
Thanks. That really helps.
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.