@arashnh11 I think this topic may be the only documentation on it. Feel free to open another topic and post logs (you can obsfucate the users/hostsnames). I’m unfamiliar with winbind, but logs & configs may help us pin down the problem.
I’m RC from the Stanford Research Computing Center.
I used mod_authnz_pam instead of mod_authnz_external and pwauth. In our earth science configuration, we use authentication through the campus kerberos, and a local ldap server with our user accounts available.
This is how I got it to work for the earth sciences cluster, mazama, which uses CentOS 7.8:
I first installed all the pam module packages I could. You could use the
pwauth pam module, but I have found it to be slow compared to other modules on the system.
yum -y install mod_authnz_pam mod_authnz_external pwauth
Next copy the files over the the chroot directory where httpd24, for OOD, lives:
cp /etc/httpd/conf.modules.d/55-authnz_pam.conf /opt/rh/httpd24/root/etc/httpd/conf.modules.d/
cp /etc/httpd/conf.d/authnz_pam.conf /opt/rh/httpd24/root/etc/httpd/conf.d/
cp /usr/lib64/httpd/modules/mod_authnz_pam.so /opt/rh/httpd24/root/usr/lib64/httpd/modules/
Now we need to edit the copied module config files, and uncomment one line:
nano /opt/rh/httpd24/root/etc/httpd/conf.modules.d/55-authnz_pam.conf #edit the one line here
#LoadModule authnz_pam_module modules/mod_authnz_pam.so
LoadModule authnz_pam_module modules/mod_authnz_pam.so
Next we edit the the ood_portal yaml file:
This is it for the auth section:
- 'AuthType Basic'
- 'AuthName "ood-webapp-priv"'
- 'AuthBasicProvider PAM'
- 'AuthPAMService ood-webapp'
- 'Require valid-user'
Now for the name of what we declared as the PAM module in “AuthPAMService”, we copy the sshd pam module as the name declared in the
cp /etc/pam.d/sshd /etc/pam.d/ood-webapp #copy an already great functioning pam module
I have found the sshd PAM module to be much faster than doing something similar to
pwauth, which just uses the
password-auth PAM modules.
Next restart the services:
systemctl try-restart httpd24-httpd.service httpd24-htcacheclean.service
I hope this helps!
I think there might be something to do with ood code .
Our system is using the sssd proxying our ldap to institute AD, only difference is we use a VIP token.
When I use the pwauth with generic apache following CentOS 7 : Apache httpd : Basic Auth+PAM : Server World, the authentication works fine (w/ VIP token). Also I tested OK with pwauth on CLI.
But when I follow exactly all your notes with authnz_pam for ood, copying the sshd in /etc/pam.d , it just does not work anyway.
I have tried also the authnz_external with pwauth, no luck.
The error log always say password mismatch.
hi, is there an update on this? it looks like the original post marked “solution” is wrong?
I’m not sure. But with PAM being so insecure - I think the best solution now is Dex with LDAP.
Regarding your comment about ‘PAM being so insecure’, I am wondering whether that is in relation just to authentication via Apache or refers to PAM in general? Would you be willing to elaborate? That’s really outside of the scope of OnDemand support, but if you have any references to articles, blog posts, CVEs, etc. that you would be willing to share so I can get a better understanding, I would be very grateful.
I am also a bit confused because I am not a full-time system administrator and don’t deal with the authentication components regularly, but for Red Hat 8 (and substitutes), I think SSSD is handing some things now that used to be handled directly by PAM modules, so I was wondering whether issues with authentication that involve SSSD will be solved by PAM or by SSSD?
Sorry to keep the discussion going on a closed issue; any further information optional would but would be really welcome.
It’s related to basic auth in apache and sending your password in a plaintext header (for every request!).
Here’s a decent stack overflow clone on the same (I googled ‘apache basic auth insecure’).
And it’s no issue to continue to respond to old topic - we rarely lock them for this reason (things change!)