Permissions Error with cron PAM configuration
Arta Seyedian
Hello.
I am getting this error repeatedly in my server log digest everyday:
**Unmatched Entries** PAM ERROR (Permission denied) FAILED to authorize user with PAM (Permission denied) PAM ERROR (Permission denied) FAILED to authorize user with PAM (Permission denied) PAM ERROR (Permission denied) PAM ERROR (Permission denied) FAILED to authorize user with PAM (Permission denied) FAILED to authorize user with PAM (Permission denied) PAM ERROR (Permission denied) FAILED to authorize user with PAM (Permission denied) PAM ERROR (Permission denied) PAM ERROR (Permission denied) FAILED to authorize user with PAM (Permission denied) FAILED to authorize user with PAM (Permission denied)I was under the impression that I had resolved this issue because I found this article, but I guess it didn’t stick for some reason? Not entirely sure but somehow access.conf went back to how it was before.
And then I decided to ssh into my server a couple of weeks after I finished installing and I wasn’t allowed in. It would just close the port and kick me out as soon as I would get in.
I asked my coworker and he said,
Hey Arta, I also cannot get in, the issue is that PAM is connected to the Azure AD and that the DSpace user is not in AD so I guess that is why the cron tab isn’t working. Hopefully we can just restart the SSH daemon on the server. A lot of the system configs are set by puppet which is a remote management service so be careful editing those as clearly it can cause some unintended consequences
So now I have to figure out how to set PAM permissions for my dspace user account to run cron chores without touching system config files like access.conf? And then his advice was to use root but… I have Tomcat set up under the dspace user account, not root, and the installation instructions say to set cron under the same account that runs Tomcat.
Please let me know what I should do in this situation. We don’t have access to Azure AD, which would be the simplest solution.
Arta Seyedian
Never mind, I found out that this has more to do with my institution’s extremely secure permissions and user management system. I’m going to just call the cron commands from my sudo user account.