Error -- failed to map user , OOD and Shibboleth authentication

Hello Support,
This seems to be a common issue with Open On Demand but I haven’t come across a definitive solution.
I note however that i am using shibboleth authentication and have setup Open On Demand authentication following this guide to the letter,
Shibboleth — Open OnDemand 2.0.5 documentation

I am able to authenticate to with my Shibboleth 3.4.7 Identity Provider, But i get an error,
Error – failed to map user (user@tld.tld.tld)

Kindly help with a workaround , because I haven’t found a solution from the recently posted identical issues.

Hi and welcome! Sorry for the delay.

You’re trying to map the user user@some-email.edu to just user. This is done through regular expressions and the user_map_cmd in versions 1.8 and below and user_map_match in versions 2.0 and above.

Here are the docs for the same, let us know if you have any questions on those 2 fields.
https://osc.github.io/ood-documentation/latest/reference/files/ood-portal-yml.html

Hello Jeff,
I have reviewed the documentation and changed to user_map_match: '^([^@]+)@tld.ac.ug$'
I mapped user_env: null such that it obtains values from REMOTE_USER CGI variables.

However I am still getting the same error with user mapping and users dont get redirected to the OOD dashboard.

Are there any missing pieces of this in other parts of the documentation and in terms of user provisioning and roles mapping.

When I check the logs under /var/log/ondemand-nginx/ood/ both access and error log files are empty. Could you comment on logging setup or where the actual logs are being kept.

I have pasted all the configs I have in the file /etc/ood/config/ood_portal.yml

--- 
auth: 
  - "AuthType shibboleth"
  - "ShibRequestSetting requireSession 1"
  - "RequestHeader edit* Cookie \"(^_shibsession_[^;]*(;\\s*)?|;\\s*_shibsession_[^;]*)\" \"\""
  - "RequestHeader unset Cookie \"expr=-z %{req:Cookie}\""
  - "Require valid-user"
map_fail_uri: null
register_root: /var/www/ood/register
register_uri: /register
user_env: null
user_map_match: "^([^@]+)@tld.ac.ug$"

Kindly suggest any further modifications I should make to solve this.

What version of OnDemand are you using?

First, I’d get rid of user_env: null. If you’re using the default then just comment that out or don’t use it. Actually forcing it to null could be the issue.

If that’s not the issue, I’d still just get rid of it because it may lead to further confusion later on down the road.

The next thing I’d look at is the regular expression "^([^@]+)@tld.ac.ug$" and how it’s being formatted from yaml → the apache config. You’ve listed here the ood_portal.yml, what does it show up as in the ood-portal.conf? You may need to use single quotes here for safety - there’s a similar issue on this discourse about single and double quotes and how it affects yaml.

I quickly tested that regex using ood_auth_map.regex in 1.8 and in lua for 2.0 and they both work out OK. So it’s not the regex directly but maybe some formatting issue interpolating it from YAML into the commands.

Lastly you could set lua_log_level: 'debug' and you’ll start to see log messages like this in your apache logs (though they’ll likely indicate what we already know - you’re mapping user@email => user@email).

[Fri Jul 16 15:17:25.331560 2021] [lua:debug] [pid 54:tid 140649550563072] @/opt/ood/mod_ood_proxy/lib/ood/user_map.lua(21): [client 127.0.0.1:46224] Mapped 'jeff@localhost' => 'jeff'

Hello Jeff,
Thanks for the replies and recommendations,
ood-portal.yml (3.9 KB)

I got rid of user_env: null but that didnt solve the issue. I also enabled the lua logs but still didn’t see anything in the httpd logs that point to the root cause.

FYI, I am running version 2.0 of OnDemand.

For further troubleshooting I have attached a copy of the OOD configuration file, ood_portal.yml

Kindly look through to see if something is misconfigured.

Sorry - did you modify the file you uploaded? Your comments indicate it’s tld.ac.ug but the file has tld.tld.tld? It may be as simple as running the ood_portal_generator to update the ood-portal.conf file from the yaml input you’ve given.

  # Authenticated-user to system-user mapping configuration
  #
  SetEnv OOD_USER_MAP_MATCH "^([^@]+)@tld.tld.tld$"

I modified it just for upload. But the generated file has proper FQDN,

hmmmm, OK what do lua:debug log entires say?

Are they similar to this? It’s mapping and email address to the same email address?

Mapped 'jeff@example.edu' => 'jeff@example.edu'

No Jeff,
I do not have such an error logged.

Below are the last few lines of the httpd error log file, /var/log/httpd/error.log after enabling lua: debug logs

[lua:debug] [pid 47922:tid 140039799392000] lua_request.c(1842): [client 196.43.137.4:56653] AH01486: request_rec->dispatching subprocess_env -> apr table
 [lua:debug] [pid 47922:tid 140039799392000] lua_request.c(1842): [client 196.43.137.4:56653] AH01486: request_rec->dispatching subprocess_env -> apr table
 [mod_shib:error] [pid 47922:tid 140039790999296] [client 196.43.137.4:56655] Blocked unacceptable redirect location., referer: https://login.ace.ac.ug/
 [lua:debug] [pid 47922:tid 140039715464960] lua_request.c(1842): [client 205.185.115.135:60830] AH01486: request_rec->dispatching subprocess_env -> apr table, referer: http://137.63.194.16:80/admin/login.asp
 [lua:debug] [pid 47922:tid 140039715464960] lua_request.c(1842): [client 205.185.115.135:60830] AH01486: request_rec->dispatching subprocess_env -> apr table, referer: http://137.63.194.16:80/admin/login.asp
 [lua:debug] [pid 47922:tid 140039715464960] lua_request.c(1842): [client 205.185.115.135:60830] AH01486: request_rec->dispatching subprocess_env -> apr table, referer: http://137.63.194.16:80/admin/login.asp

If I need to look at a different set of logs, you can also let me know.
I also upgraded to the latest version of OnDemand, v2.0.13 but the same error persists.

Yea I would grep for Mapped in that file. That directory is the right location, and any *error.log is the right place (you may have my_servername_error.log )

Does grepping for Mapped in /var/log/httpd/error.log (or error_<servername>.log) show anything useful?