Error -- failed to map user

Hi, we are setting up OnDemand 2.0 and have run into an issue while setting up authentication.

We are using Dex for LDAP (can we still use the basic auth in 2.0 or do we need to use Dex?)

I believe we have everything set up correctly but when we go to log in we get “Error – failed to map user (first.last)”

If I look in the SSL log I have:

[Fri May 21 13:53:01.489468 2021] [lua:debug] [pid 1705] @/opt/ood/mod_ood_proxy/lib/ood/user_map.lua(21): [client xxx.xxx.xxx.xx:50618] Mapped 'first.last' => '' [0.029 ms]

I saw another topic in which someone was having issues with the same thing but they had a hypen in the name. This is not the case here.

My apologies as I am sure this is something simple, we have just not been able to figure it out yet.

It’s the default user_map_match: '.*' (which is everything) that needs to change likely. I assume you want to map to just first name?

You can find docs on user_map_match here:

https://osc.github.io/ood-documentation/latest/reference/files/ood-portal-yml.html

But I just got this pattern to work '^([^.]+).*$' but you’re likely going to want to beef that up a bit instead of looking for anything (.*) for a little robustness
.

> string.match('kilgore.ktrout', '^([^.]+).*$')
kilgore

Thanks Jeff for the quick reply. We are currently using

user_map_match: '.*'

We do want to match both first name and last name in the format firstname.lastname. Am I understanding correctly that the .* should do this for us?

Not sure what’s going on. For dex we actually force '^([^@]+)@.*$' if we use the email as the claim.

What do you see in your ood-portal.conf file in your httpd’s etc directory as the OOD_USER_MAP_MATCH?.

What do you set as your oidc_remote_user_claim or your user_env?

There could be something amiss here. Where one is set, but not being checked for here, and we’re giving you the wrong user_map_match based on it.

Hi. I’m just starting to look at OOD now (so I don’t have much experience with it), and am having authentication issues similar to what’s described here (but I’m using PAM authentication). I’m running 2.0.9 and when I set specifically the user_map_match: '.’ in the ood_portal.yml file and recreate the config, the /opt/rh/httpd24/root/etc/httpd/conf.d/ood-portal.conf file lists this environment: SetEnv OOD_USER_MAP_MATCH "^([^@]+)@.$"

…and I get a login error (failed to match user)

If I modify the ood-portal.conf file directly and change the OOD_USER_MAP_MATCH to “.*” and restart the server, I can log in.

Seems like the /opt/ood/ood-portal-generator/sbin/update_ood_portal process is ignoring that setting.

@groucho64738 welcome!

Thanks! I’ve created this ticket based off of this topic. Do you set any of these oidc_remote_user_claim or your user_env ?

I do not have either of those options set.

Most likely you need to modify oidc_remote_user_claim otherwise it will default to email and the regex used is to extract the part before @ symbol. The value to set depends on what exactly you want to use to log people into OnDemand. If you look at the Dex logs you should be able to see which claims are being returned so know which claim to assign based on the data you want to use to log into OnDemand.

Ok. Let me check that out. We really just want the entered username to be the same as the system username (so no email format, just ‘userA’ mapped to ‘userA’ on the system)

I see what the issue was. I had installed ondemand-dex (but wasn’t really using it for anything). The fact that it was installed was making the portal generator assume ‘email’. After removing the package and re-running the generator, it stuck the correct info in the ood-portal.conf file.

The comment “# Dex support will auto-enable if ondemand-dex package is installed” was the tip-off there.