Just starting up an OOD installation; using LDAP with a PAM auth method in the yml. The user can log in, but mapping “fails”. The other report on this kind of topic was dealing with hyphenated user names. We don’t have that issue.
For what it’s worth, the following command works as expected:
/opt/ood/ood_auth_map/bin/ood_auth_map.regex ‘swheat’
giving swheat as the output.
The error and access log don’t seem to show anything relevant to this.
Hi and welcome!
I guess I’d ask if swheat is a real user on the machine? I mean can you su as root into that user on that machine?
Also the error page does indicate that it couldn’t map user swheat. I just want to be sure that REMOTE_USER is being passed to the ood_auth_map.regex command. Did you happen to change user_env in ood_portal.yml?
Jeff,
Thank you for the quick response. Your question reminded me that our /home was not yet mounted from our NFS server and when I log in as swheat, it would have a problem without the /home in place. So, I fixed that just now. But that didn’t change the behavior of the OOD portal … I get the same error.
Within the yml file, all user_env settings are the original from the original file and they are all commented. So, there is no executed definition of user_env. Is that a problem?
Here are the last few lines of the error log:
[Wed Dec 09 16:30:07.021366 2020] [auth_openidc:warn] [pid 1978] oidc_check_config_openid_openidc: the URL scheme (http) of the configured OIDCRedirectURI SHOULD be “https” for security reasons (moreover: some Providers may reject non-HTTPS URLs)
[Wed Dec 09 16:35:18.523232 2020] [auth_openidc:warn] [pid 2396] oidc_check_config_openid_openidc: the URL scheme (http) of the configured OIDCProviderMetadataURL SHOULD be “https” for security reasons!
[Wed Dec 09 16:35:18.523249 2020] [auth_openidc:warn] [pid 2396] oidc_check_config_openid_openidc: the URL scheme (http) of the configured OIDCRedirectURI SHOULD be “https” for security reasons (moreover: some Providers may reject non-HTTPS URLs)
Here are the last few lines of the access log:
These are coming from an unknown site across our “public” address:
91.241.19.84 - - [10/Dec/2020:07:06:59 -0600] “GET /pun/sys/dashboard?XDEBUG_SESSION_START=phpstorm HTTP/1.1” 401 381 “http://156.110.41.154:80/?XDEBUG_SESSION_START=phpstorm” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36”
91.241.19.84 - - [10/Dec/2020:07:07:00 -0600] “GET /pun/sys/dashboard?a=fetch&content=die(@md5(HelloThinkCMF)) HTTP/1.1” 401 381 “http://156.110.41.154:80/?a=fetch&content=die(@md5(HelloThinkCMF))” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36”
51.15.21.205 - - [10/Dec/2020:09:02:44 -0600] “HEAD /robots.txt HTTP/1.0” 404 - “-” “-”
165.22.190.158 - - [10/Dec/2020:09:08:14 -0600] “POST / HTTP/1.1” 302 223 “-” “Mozilla/0 (Project 25499 Scanner)”
77.179.92.247 - - [10/Dec/2020:09:52:06 -0600] “GET /phpmyadmin/ HTTP/1.1” 404 196 “-” “Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36”
These are from the login I just tried to do after mounting /home
10.80.2.5 - - [10/Dec/2020:10:04:04 -0600] “GET / HTTP/1.1” 302 220 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36”
10.80.2.5 - - [10/Dec/2020:10:04:04 -0600] “GET /pun/sys/dashboard HTTP/1.1” 401 381 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36”
10.80.2.5 - swheat [10/Dec/2020:10:04:11 -0600] “GET /pun/sys/dashboard HTTP/1.1” 404 36 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36”
10.80.2.5 - - [10/Dec/2020:10:04:12 -0600] “GET /favicon.ico HTTP/1.1” 404 196 “http://10.2.23.215/pun/sys/dashboard” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36”
10.80.2.5 - - [10/Dec/2020:10:05:03 -0600] “-” 408 - “-” “-”
Here is the last line from the ssl_error_log:
This is from an unknown site
[Thu Dec 10 09:38:54.506444 2020] [autoindex:error] [pid 2402] [client 91.241.19.84:36198] AH01276: Cannot serve directory /opt/rh/httpd24/root/var/www/html/: No matching DirectoryIndex (index.html) found, and server-generated directory index forbidden by Options directive
That’s no problem. REMOTE_USER should work some fine given other configuration below if you’re using openidc.
Sorry, what authentication are you using? [Wed Dec 09 16:30:07.021366 2020] [auth_openidc:warn] [pid 1978] seems to indicate you have openidc enabled.
For openidc I think oidc_remote_user_claim: preferred_username (in ood_portal.yml in 1.8) should work for you if preferred_username ends up resolving to the system username.
The trick here is first getting the oidc system to return what apache will save as the REMOTE_USER.
I’m guessing you’re using openidc and what’s being returned is swheat@some.college.edu.
When you get the error page, what does it say the user is it’s trying to map?
Jeff,
The error page reports “swheat”. For logging in, I simply put in swheat. This is the exact text:
Error – failed to map user (swheat)
We are based on OpenLDAP. We tried the dex approach, but it seems to have wanted our host name DNS resolvable, which it is not. We made much greater progress with going the PAM route.
We’re trying the very simplest approach. Here are the only uncommented lines from the yml file:
auth:
‘AuthType Basic’
‘AuthName “Open OnDemand”’
‘AuthBasicProvider PAM’
‘AuthPAMService ood’
‘Require valid-user’
user_map_cmd: “/opt/ood/ood_auth_map/bin/ood_auth_map.regex”
We did not have oidc_remote_user_claim set to anything; all was commented out.
I have tried uncommenting that line just now. I regenerated the portal, restarted the service. I get the same issue/error.
Perhaps the default was really the default, as I got this output when I did the rebuild of the portal:
[root@dtnvm5 config]# /opt/ood/ood-portal-generator/sbin/update_ood_portal
No change in Apache config.
No change in the Dex config.
Completed successfully!
hmmmm. Not sure what’s wrong. I see now the openidc logs are there just if you have the library installed and whether you have it enabled or not.
Maybe you can try lua_log_level: 'debug' in ood_portal.yml and look for a log line like this:
ood_proxy/lib/ood/user_map.lua(14): [client 127.0.0.1:53428] Mapped 'jeff' => 'jeff' [849.164 ms]
Honestly the default is just to echo the string back, it doesn’t actually do anything at this point.
What’s your user_map_cmd set to in ood_portal.yml?
The user_map_cmd is set as follows, and we have not changed the regex file
user_map_cmd: “/opt/ood/ood_auth_map/bin/ood_auth_map.regex”
And we did test that to emit the expected string from the input … swheat in … swheat out.
Well, this is interesting:
[Thu Dec 10 12:47:04.454821 2020] [lua:debug] [pid 5193] @/opt/ood/mod_ood_proxy/lib/ood/user_map.lua(14): [client 10.80.2.5:64970] Mapped ‘swheat’ => ‘’ [137.861 ms]
Try keeping user_map_cmd commented, and just let us set the default. Also be sure it’s getting populated in the /opt/rh/httpd24/root/etc/httpd/conf.d/ood-portal.conf and be sure to bounce httpd24 - just in case just to be extra double sure changes get propogated.
That lua code only reads 1 line from whatever command is being invoked. That log line tells me that you’re definitely passing the right thing to the command. So the question is, is the actual command valid. You may be able to check /var/log/httpd/error_log for an error message (note it’s just the error log, not the error_site_log).
I was able to set my user_map_cmd to ssafsdf, which doesn’t exist, and got the same error page. So maybe that’s what’s happening to you too.
[Thu Dec 10 19:13:43.868425 2020] [lua:debug] [pid 21:tid 140296408008448] lua_request.c(1852): [client 127.0.0.1:54194] AH01487: request_rec->dispatching escape -> lua_CFunction
sh: ssafsdf: command not found
[Thu Dec 10 19:13:43.878458 2020] [lua:debug] [pid 21:tid 140296408008448] lua_request.c(1852): [client 127.0.0.1:54194] AH01487: request_rec->dispatching clock -> lua_CFunction
[Thu Dec 10 19:13:43.878482 2020] [lua:debug] [pid 21:tid 140296408008448] lua_request.c(1852): [client 127.0.0.1:54194] AH01487: request_rec->dispatching debug -> lua_CFunction
[Thu Dec 10 19:13:43.878520 2020] [lua:debug] [pid 21:tid 140296408008448] @/opt/ood/mod_ood_proxy/lib/ood/user_map.lua(14): [client 127.0.0.1:54194] Mapped 'jeff' => '' [10.056 ms]
Jeff,
Working with Kali McLennan at OU, we got this figured out … well, kind of. We bailed on the PAM approach and she worked with me to get the dex method figured out. I’ve got some configuration changes to my LDAP structure that I need to address, but we have it logging in and serving a browser environment of my file system.
As for this issue, it’s fair to say it has been resolved, though not explained.
Thanks for the help.
Hello,
What was the fix exactly? After the configuration working perfect right before Thanksgiving, I came back to this and now I’m getting this same issue. I tried following along but still not making much progress I will say turning on debuging I get below and I believe it should say tlewis in the quotes. BTW we are using Shibboleth for authentication.
[Thu Dec 10 18:11:36.053312 2020] [lua:debug] [pid 14422] @/opt/ood/mod_ood_proxy/lib/ood/user_map.lua(14): [client 172.30.191.241:53160] Mapped ‘’ => ‘’ [67.775 ms]
We could not figure out the mapping issue. We finally bailed on the PAM approach and went back and worked out getting DEX to work for us.
Once we got DEX working, we didn’t look back at the PAM approach.
One thing we found was that we had a firewall issue on port 5556/tcp; that needed to be enabled for the DEX to work. But whether that is material to the PAM, I have no idea. We also had to get the hostname and the hostname in the browser to match up. That was frustrating. We suspect there is a way around that, but it was a blocking issue for DEX. Again, I don’t know that it matters for the PAM approach.
I wish I had better news for you as to why the simple mapping didn’t map a simple name back to itself.
BTW, I just remembered another thing we had experienced. Apparently, the webpage caching and cookies will mess things up. So, we resorted to testing each change in a new incognito window.
There’s something about the cookies going on … maybe try incognito mode and see if that gets you going again. And then kill the cookies for that site. It’s a guess. Hopefully it’s a good one.
I appreciate the help here.
Hi Jeff,
Do you have any other suggestions? It doesn’t look like ID are being sent
[Thu Dec 10 18:11:36.053312 2020] [lua:debug] [pid 14422] @/opt/ood/mod_ood_proxy/lib/ood/user_map.lua(14): [client 172.30.191.241:53160] Mapped ‘’ => ‘’ [67.775 ms]
You’re right, the id isn’t being set. By default we use REMOTE_USER here. I’m not 100% sure about shibb. It seems like it should be returning your email address in that variable as a default.
Did you happen to change user_env in ood_portal.yml ? This variable (user_env) is what instructs apache to pass into the regex. Mostly REMOTE_USER is fine and folks don’t have to set it.
From the docs here, it doesn’t see like we need to change it. I’d turn debug logging on for your shibboleth auth module and see what variables it’s setting (and if REMOTE_USER is one) when you authenticate.
I’m using most of the doc recommended settings. This is the only thing in that file uncommented.
auth:
user_map_cmd: “/opt/ood/ood_auth_map/bin/ood_auth_map.regex --regex=’^(\w+)@gwu.edu’”
I’ll double check with shibb debug
So I reached out to out to our Shibboleth admin, turns out due to a sync issue in the shibboleth service when they failed over to a backup last week my server’s metadata wasn’t there. It’s working fine now. Thanks for your help!
Know it’s been a while for this one, but ran into same issue and fixed by manually removing the --regex from ood-portal.conf
Already had the machine integrated with LDAP via PAM so didn’t want to introduce new service. Followed steps in this link, except skipped step 5 due to LDAP, then modified configs listed below: Add PAM Authentication — Open OnDemand 1.8.12 documentation
# /etc/ood/config/ood_portal.yml
auth:
- 'AuthType Basic'
- 'AuthName "Open OnDemand"'
- 'AuthBasicProvider PAM'
- 'AuthPAMService ood'
- 'Require valid-user'
user_map_cmd: "/opt/ood/ood_auth_map/bin/ood_auth_map.regex"
user_env: 'REMOTE_USER'
Ran update script then modified the following in apache config:
# diff ood-portal.conf.20210418 ood-portal.conf
86c86
< SetEnv OOD_USER_MAP_CMD "/opt/ood/ood_auth_map/bin/ood_auth_map.regex --regex='^([^@]+)@.*$'"
---
> SetEnv OOD_USER_MAP_CMD "/opt/ood/ood_auth_map/bin/ood_auth_map.regex"
Then restarted apache services