There’s nothing in the error logs for shibboleth, Apache, or ondemand-nginx; is there an option in the config .yml file for turning up the logging verbosity, or at least to log what username Apache is trying to map?
Hi, sorry for the trouble. Have you already gone through the setup for the user mapping?
If so, failed logins are not actually logged by apache, but you can still turn the logging up regardless. To turn the logging up, you can set lua_log_level: debug in the ood-portal.yml to get more information though which might turn up more useful data.
I’ve set the lua_log_level to debug & restarted everything, but I don’t notice anything very different in the logs after I get a new private browser window on my client, and login via shib w/ duo 2FA.
I’ve tried both:
user_map_match: ‘.*’
and
user_map_match: ‘^([^@]+)@myschool.edu$’
…but neither seems to make a difference. The last few lines of /var/log/httpd/ood.services.myschool.edu_access_ssl.log consist of:
Have you tested the regex against the expected form of users to get the map working? If you can provide what the expected form is I can make one up for you.
I have no idea what the expected form is; is that something that Shibboleth would be passing back to Apache? Is there a way to dump the REMOTE_USER value that Apache is failing to map?
Yeah it’s something coming from the auth system and the regex then maps that from a file to a user on the system, which looks to not be happening here.
The doc entry on this talks more about what this is and how to find it:
This is the stanza in our shibboleth2.xml config, where we set the REMOTE_USER to the attribute that our shib admin says is equivalent to the username on the host running OOD:
That is defining the attribute for shib and saying that’s what we want back for REMOTE_USER but at runtime I don’t know what the value will look like exactly.
This stage is basically shib/apache at the moment so the best bet is to dump that environment out that apache sees at login and look at the actual username from REMOTE_USER looks like when it comes back and build a regex off that to map to the system users.
System command used to map authenticated-user to system-user
This option takes precedence over user_map_match
Example:
user_map_cmd: ‘/usr/local/bin/ondemand-usermap’
Default: null (use user_map_match)
user_map_cmd: ‘/opt/bin/ondemand-usermap.sh’
The ondemand-usermap.sh script looks like this:
#!/bin/bash
export DATE_STAMP=date +%s%3N
if [[ ! -z $1 ]]; then
MATCH=“gavila1”
echo “$1, $MATCH” > /tmp/output.$DATE_STAMP
echo “$MATCH”
else
logger -t ‘ood-mapping’ “cannot do anything, no value passed!”
exit 1
fi
If I run the above script (as the apache user), passing, say “gavila1-user” as an argument, I get a file in /tmp/output.233234whatever with “gavila1-user, gavila1” in it, as expected.
If I run it with no argument, I get a message in /var/log/messages with the “cannot do anything” etc. string, again as expected.
If I restart apache, get a new private browser window, and try to login as gavila1…Shibboleth passes me to Duo 2FA, I am prompted successfully-and I get the same “failed to map user” error.
There is no new file in /tmp/output., nor is there any message about no value being passed in /var/log/messages.
It is almost like it isn’t trying to do any match at all…
Which looks like it ought to match properly with the stock user_map_match command, which if I test as per the documentation, it does. Provided of course that it is trying to match on the above eppn value!!